У цій статті я розповім, як з одного повідомлення про помилку на сайті я випадково отримав доступ до внутрішньої інформації компанії (і навіть трохи більше). Зазначу, що це можна виконати, використовуючи один лише браузер.
Пролог
Сайти іноді падають. Таке трапляється. Але ось те, що описано в статті, траплятися не повинно.
#1
Нещодавно зайшов на сайт однієї компанії і побачив (в черговий раз, зауважу) замість нього повідомлення про помилку:
Чому сайт впав - це окрема розмова. Скажу лише, що це на совісті його розробників.
Перша помилка (занадто очевидна, але...): показує повідомлення про вади. Так, всі знають, що потрібно відключати дебаг у продакшені. Але, чорт візьми, чому я регулярно бачу повідомлення про помилки в своєму браузері?!
#2
Отже, що ми можемо почерпнути з цього повідомлення? Та ні багато ні мало публічна адреса SOAP-сервісу. Ну гаразд, навряд чи він все-таки доступний відкрито, але про всяк випадок копіюємо в адресний рядок і отримуємо... список доступних методів. Багато методів, більша частина явно для внутрішнього користування. До кожного додається опис запиту і приклад відповіді. Багато хто вимагає авторизацію (передачу в запиті логіна і пароля), але далеко не все. Вибираємо один відкритий метод з балакучою назвою і конструюємо запит прямо в браузері. Так, багато хто лає вбудований в Firefox Web Developer (і є за що), але для простих завдань він цілком придатний:
Друга помилка: доступні публічно сервіси. Ось навіщо цей сервер дивиться в світ? Ним користуються якісь віддалені програми? Добре, тоді закрийте його авторизацією. Або хоча б не супроводжуйте докладною інструкцією до дії.
#3
Подивимося, що відповів нам сервер. Для зручності перегляду відкриємо отриманий XML все в тому ж переглядачі:
Це список співробітників компанії, трохи менше двохсот елементів. Відмінно, пошукаємо керівництво. Знаходимо, м'яко кажучи, не останню людину в компанії (на скріншоті). Тепер ми знаємо його email і щось підозріло схоже на Base64 в елементі SotrudnikPassword. Декодуємо пароль у будь-якому з безлічі онлайн-декодерів.
Третя помилка: паролі у відкритому вигляді. Навіть якщо винести за дужки питання, навіщо взагалі віддавати паролі (хеші) назовні, все одно незрозуміло, чому хоча б не хеші. Чи девелопери вважають, що Base64 підходить для цих цілей?
Примітка: помилки # 4 і # 5 відносяться вже не до безпеки сервісів, а до особистої безпеки. Тут вина не розробників, а користувача, але я вирішив залишити їх, оскільки вони а) частина цієї історії б) такі ж банальні і всім очевидні, але так само часто досконалі.
#4
Подивимося, що можна зробити з отриманою інформацією. Спробуємо отримати доступ до вказаної пошти. Перевіряємо домен у першому-ліпшому сервісі перегляду DNS-записів. Судячи з MX, це GMail. Що ж, спробуємо авторизуватися, використовуючи декодований пароль:
Ви ж не здивуєтеся, якщо я скажу, що пароль підійшов?
Четверта помилка: один пароль для різних облікових записів. Буде не важливо, якої він довжини і скільки в ньому букв різного регістру і цифр, якщо він витече за вашою або чиєюсь (як у цьому випадку) дурниці.
#5
Пароль підійшов, але Google на сторожі безпеки користувача - бачить, що зайшли з іншого IP, і вимагає додаткового підтвердження:
Ось тільки останній пропонований ним варіант виглядає занадто просто. Google, ти серйозно?
В даному випадку було досить рідкісне прізвище, тому не знадобилася навіть назва компанії вказувати. Спробуємо ввести знайдений телефон:
Підходить. Відкривається корпоративний GMail (і, відповідно, Google Tasks, Google Drive та інші сервіси).
П'ята помилка: використання як додаткового фактора авторизації/контрольного питання легко дізнаваної інформації (в даному випадку відомого іншим та інтернету номера телефону). Чи важко дізнатися дівоче прізвище матері або дату її народження? Так чому багато сервісів і банків як і раніше використовують їх за замовчуванням?
Епілог
Написав цій людині листа про необхідність змінити пароль. Ще прийнято повідомляти про вразливості розробникам і давати час на виправлення. Але. Перечитайте помилки # 1 - # 3. Потрібно повідомити їм, що у них повідомлення про падіння всім показуються, сервери, вибачте, голий ж. в інтернет дивляться і паролі віддаються першому зустрічному хіба що не плейн-текстом? Про це дійсно потрібно нагадувати комерційним розробникам, які претендують на корпоративний рівень? Про речі настільки прості і очевидні, що без знання їх і на роботу-то брати не повинні? Сподіваюся, що вони це прочитають і впізнають себе. Хочу сказати їм тільки одне: «Хлопці, геть із професії!»
Про себе: не розробник, не фахівець з безпеки і взагалі ніяким боком не IT. Просунутий користувач інтернету, скажімо так.