Хабрахабр

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

И в таких предложениях я стараюсь работать на результат и получать максимальное удовольствие от процесса. С недавних пор мне стали приходить предложение проверить работу различных сервисов на предмет наличия ошибок и уязвимостей. Но результат последнего «проекта» меня мягко сказать шокировал.

И в своем рассказе я буду использовать название Hoster. Мне было предложено протестировать хостинг провайдера.
Раскрывать название я не стану. Предложения купить VDS, Домены, SSL сертификаты. С самим сайтом хостинг сервиса было все стандартно.

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

Но к счастью по аналогии с этой историей, раскрытие чувствительной информации службы поддержки сервиса не произошло.

На удивление они оказались доступны. Однако оно все же случилось, когда я создал тестовый запрос на поддержку и сходу проверил доступность соседних ID-шников других запросов на поддержку. И с какими проблемами сталкиваются пользователи. И можно было наблюдать кто и что регистрирует у хостера. Её конечно моментально исправили. Вообщем стандартная IDOR уязвимость, которой сейчас никого не удивишь.

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

  • Сколько активных пользователей.
  • Сколько доменов в управлении.
  • Сколько VDS развернуто.

И много другого…

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

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

И я уже планировал завершать этот проект. Результаты были более чем убедительные. И начал придумывать ситуации при которых это может создать максимальные проблемы хостингу и его владельцам. Но почему-то снова вспомнил о проблеме отсутствия подтверждения владельца электронного адреса при регистрации. Спустя пару минут я зарегистрировал аккаунт с email адресом другого проекта этой же компании (пусть будет support@example.com). В какой то момент я начал думать о связях владельцев этого хостинг сервиса с другими проектами этой же компании, о которых мне было известно. Но контролировать контент привязанного домена я все еще не мог. Дальше мне удалось привязать домен example.com к моей созданной учетной записи suppot@example.com.

Зато мог отлично фишить электронными письмами от имени сервиса example.com.

Т.к на одно такое тестовое письмо самому себе я ответил. До конца непонятно куда приходили ответные письма. Вероятно оно ушло в ответ реальному владельцу электронного ящика support@example.com. Но самого ответа я не получил.

И вот тут случилось то, ради чего я решил написать эту статью.

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

И у меня это получилось. Не знаю почему, но я попытался добавить привязку к несуществующему домену.

И контент отображался. Поддомен был успешно добавлен и я мог контролировать содержимое этого поддомена.

Как так ?! Но такого же не может быть! Ведь классическая 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 — без проблем добавил третий уровень домена для соседа и все норм, быстро и без вопросов. Грубо говоря я вам говорю, идем ко мне я буду вас хостить. А CloudFlare мне доверяет. Для всех DNS корректная информация от CloudFlare пришла.

Но тут получается схитрили и просто все передают в CloudFlare от одного пользователя. Обычно конечно хостинг провайдеры свои DNS сервисы настраивают.

Правда это работало только с теми адресами, которые уже контролирует хостинг. Вот и имеем subdomain takeover god_mode. Но в совокупности с ранее обнаруженной админкой сервиса — это могло сыграть злую шутку как с хостером так и с клиентами хостинг сервиса.

И я надеюсь что на подобные архитектурные изыски больше никто не решится после прочтения данной истории. В данный момент практически все критические уязвимости и ошибки исправлены.

S.: Комментарии и пожелания к статье приветствуются. P. Также я открыт к предложениям по тестированию чего-то интересного. Отдельное спасибо Patriot2k за техническую консультацию!

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть