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

Мне было предложено протестировать хостинг провайдера.

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

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

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

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

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

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

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



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

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

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

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



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

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

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

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



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



Но такого же не может быть! Как так ?! Ведь классическая 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 от одного пользователя.

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

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

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