Як я зламав одного хостинг провайдера

З недавніх пір мені стали приходити пропозицію перевірити роботу різних сервісів на предмет наявності помилок і вразливостей. І в таких пропозиціях я намагаюся працювати на результат і отримувати максимальне задоволення від процесу. Але результат останнього «проекту» мене, м’яко кажучи, шокував.

Мені було запропоновано протестувати хостинг провайдера.

Розкривати назву я не стану. І в своїй розповіді я буду використовувати назву Hoster. З самим сайтом хостинг сервісу було все стандартно. Пропозиції купити VDS, Домени SSL сертифікати.

В першу чергу мене здивувало те, як був реалізований особистий кабінет користувача. Підтверджень володіння електронною адресою при реєстрації не потрібно. Тобто можна було реєструватися за електронною адресою steve.jobs@apple.com. Або ще краще — support@hoster.com.

Але, на щастя, за аналогією з цією історією, розкриття чутливої інформації служби підтримки сервісу не сталося.

Однак воно все ж сталося, коли я створив тестовий запит на підтримку і відразу перевірив доступність сусідніх ID-шників інших запитів на підтримку. На диво вони виявилися доступні. І можна було спостерігати хто і що реєструє у хостера. І з якими проблемами стикаються користувачі. Вообщем стандартна IDOR вразливість, якій зараз нікого не здивуєш. Її звичайно вмить виправили.

Так само було кілька місць з Stored XSS. Була і Blind XSS яка повернула мені Cookie Адміністратора сервісу. Завдяки цій XSS мені вдалося дізнатися де знаходитися інтерфейс адміністратора, ну і взагалі розкривало багато цікавої інформації.

  • Скільки активних користувачів.
  • Скільки доменів в управлінні.
  • Скільки VDS розгорнуто.

І багато іншого…

Були різні помилки з CSRF токенами, які дозволяли від імені користувача робити багато небезпечних речей в особистому кабінеті. І якщо були місця де передавалися CSRF токени, то вони просто передавалися. Перевіряти їх на backend ніхто не планував. В результаті моїх знахідок частина функціоналу зовсім відключили. Так наприклад 2FA аутентифікацію було вирішено тимчасово прибрати, як не відбулася реалізації.

Читайте також  Як зробити розширення на PHP7 складніше, ніж «hello, world», і не стати красноглазиком.

В ході своєї роботи я звертав увагу не тільки на проблеми безпеки, але і на помилки реалізації або проблеми в роботі певного функціоналу. Я як QA не міг проходити мимо такого. У підсумку мій issue tracker дійшов до цифри — 22. Стільки проблем в сукупності я знайшов і зафіксував (виключно заслуговують уваги).

Результати були більш ніж переконливі. І я вже планував завершувати цей проект. Але чомусь знову згадав про проблему відсутності підтвердження власника електронного адреси при реєстрації. І почав придумувати ситуації при яких це може створити максимальні проблеми хостингу і його власникам. В якийсь момент я почав думати про зв’язки власників цього хостинг сервісу з іншими проектами цієї ж компанії, про яких мені було відомо. Через пару хвилин я зареєстрував аккаунт з email адресою іншого проекту цієї компанії (нехай буде support@example.com). Далі мені вдалося прив’язати домен example.com до моєї створеного облікового запису suppot@example.com. Але контролювати контент прив’язаного домену я все ще не міг.

Зате міг відмінно фишить електронними листами від імені сервісу example.com.

До кінця незрозуміло куди приходили відповідні листи. Т. до на одну таке тестове лист самому собі я відповів. Але відповіді я не отримав. Ймовірно воно пішло у відповідь реальному власнику електронної скриньки support@example.com.

І ось тут сталося те, заради чого я вирішив написати цю статтю.

Мені вдалося зробити resolve піддомену, про який забули. Класична вразливість subdomain takeover. Дуже докладно про це можна почитати тут.

Не знаю чому, але я спробував додати прив’язку до неіснуючого домену. І у мене це вийшло.

Піддомен було успішно додано і я міг контролювати вміст цього піддомену. І контент відображався.

Читайте також  Де знайти налаштування DNS в MacOS

Але такого ж не може бути! Як так ?! Адже класична subdomain takeover уразливість працює тільки з існуючими поддоменами.

В моїй голові абсолютно не укладалася ця ситуація. Т. е ладно я зміг минути рівні валідації мого ставлення до адресою example.com, який жодного разу не мій (ймовірно завдяки example.com в імені мого акаунту). Але яким чином можливо взагалі додавати піддомени і контролювати їх без всіляких перевіряльників складових у записах A, TXT, CNAME …?

Зазвичай я зустрічаю подібне — ми тобі додамо піддомен, тільки ти доведи що ти можеш це робити. Піди і додай в TXT даний hash ololopyshpyshpyshbdysh123.

Але тут такого не було. Хочеш admin.example.com піддомен? Без проблем!

Як ніби вразливість Subdomain Takeover V2.

Завдяки можливості оперативно спілкуватися з власниками досліджуваного хостинг сервісу — мені відкрили цей ящик пандори.

З’ясувалося наступне. Хостинг працював через CloudFlare. І працював дуже хитрим чином.
Постараюся пояснити простими словами.

Грубо кажучи я вам кажу, йдемо до мене я буду вас хостити. Делегуйте свої домени на мене.
А далі всі вхідні звернення без розбору я шлю в CloudFlare, вважаючи їх коректними.
І якщо мені довірили домен vasya.ru, а сусід прийшов і запив сайт з test.vasya.ru і теж мені його дав для хостингу, то мій сервер маючи доступ до CloudFlare і вже має права на vasya.ru — без проблем додав третій рівень домену для сусіда і все норм, швидко і без питань. Для всіх DNS коректна інформація від CloudFlare прийшла. А CloudFlare мені довіряє.

Зазвичай звичайно хостинг провайдери свої DNS сервіси налаштовують. Але тут виходить схитрували і просто все передають у CloudFlare від одного користувача.

Читайте також  П'ятничний JS: гра в 0 рядків JS і CSS

Ось і маємо subdomain takeover god_mode. Правда це працювало тільки з тими адресами, які вже контролює хостинг. Але в сукупності з раніше виявленої адмінкою сервісу — це могло зіграти злий жарт як з хостером так і з клієнтами хостинг сервісу.

У даний момент практично всі критичні уразливості і помилки виправлені. І я сподіваюся, що на подібні архітектурні шедеври більше ніхто не вирішиться після прочитання цієї історії.

P. S.: Коментарі та побажання до статті вітаються. Також я відкритий до пропозицій щодо тестування чогось цікавого.

Степан Лютий

Обожнюю технології в сучасному світі. Хоча частенько і замислююся над тим, як далеко вони нас заведуть. Не те, щоб я прям і знаюся на ядрах, пікселях, коллайдерах і інших парсеках. Просто приходжу в захват від того, що може в творчому пориві вигадати людський розум.

You may also like...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *