С недавних пор мне стали приходить предложение проверить работу различных сервисов на предмет наличия ошибок и уязвимостей. И в таких предложениях я стараюсь работать на результат и получать максимальное удовольствие от процесса. Но результат последнего «проекта» меня мягко сказать шокировал.
Мне было предложено протестировать провайдера.
Раскрывать название я не стану. И в своем рассказе я буду использовать название Hoster. С самим сайтом сервиса было все стандартно. Предложения купить , Домены, SSL сертификаты.
В первую очередь меня удивило то, как был реализован личный кабинет пользователя. Подтверждений владения электронным адресом при регистрации не требовалось. Т.е можно было регистрироваться с электронным адресом steve.jobs@apple.com. Или еще лучше — support@hoster.com.
Но к счастью по аналогии с этой историей, раскрытие чувствительной информации службы поддержки сервиса не произошло.
Однако оно все же случилось, когда я создал тестовый запрос на поддержку и сходу проверил доступность соседних ID-шников других запросов на поддержку. На удивление они оказались доступны. И можно было наблюдать кто и что регистрирует у хостера. И с какими проблемами сталкиваются пользователи. Вообщем стандартная IDOR уязвимость, которой сейчас никого не удивишь. Её конечно моментально исправили.
Так же было несколько мест с Stored XSS. Была и Blind XSS которая вернула мне Cookie Администратора сервиса. Благодаря этой XSS мне удалось узнать где находиться интерфейс администратора, ну и вообще раскрывало много интересной информации.
- Сколько активных пользователей.
- Сколько доменов в управлении.
- Сколько развернуто.
И много другого…
Были различные ошибки с 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 за техническую консультацию! Также я открыт к предложениям по тестированию чего-то интересного.
Автор: Валерий Шевченко
