Будни багхантера — это непрерывная охота за уязвимостями, успех в которой зависит не только от опыта и навыков, но и от банального везения. Недавно мне попалась по-настоящему крупная добыча: я обнаружил XSS-уязвимость (межсайтовый скриптинг) в одном из поддоменов Google.
В статье расскажу, как мне удалось заработать на этой находке и оставить свое имя в «зале славы» багхантеров Google.
Обнаружение уязвимости
Как увлеченный своей работой багхантер, я постоянно занимаюсь «этичным хакингом»: пытаюсь найти уязвимости в системах до того, как это сделают потенциальные злоумышленники. Недавно в процессе таких исканий я наткнулся на непримечательный с виду поддомен, связанный с Google.
Мое внимание привлек этот URL:
https://aihub.cloud.google.com/url?q=https://cidadesmineradoras.com.br
Едва взглянув на него, я заподозрил уязвимость. URL буквально умолял себя проверить.
Рекомендация по отлову багов №1: всегда доверяйте своему чутью. Если URL кажется вам уязвимым, вероятно, так оно и есть!
Я сразу принялся вводить полезные нагрузки в параметр q в надежде обнаружить что-то интересное. Эта стратегия оказалась безуспешной, поэтому я решил сосредоточиться на моей любимой XSS-нагрузке. Я начал модифицировать и улучшать ее.
Полезная нагрузка:
“><SvG/onload=alert(document.domain) id=hncaga>
Чтобы нагрузка работала корректно, нужно было выполнить URL-энкодинг, то есть закодировать специальные символы в URL (пробелы, скобки и так далее).
После этих махинаций URL выглядел так:
https://aihub.cloud.google.com/url?q=https://cidadesmineradoras.com.br%22%3E%3CSvG/onload=alert(document.domain)%20id=hncaga%3E
К несчастью, такой вариант тоже не сработал. Я решил закодировать все символы в моей полезной нагрузке, чтобы проверить, позволит ли это обойти фильтрацию.
URL с закодированной полезной нагрузкой:
https://aihub.cloud.google.com/url?q=%68%6e%63%61%67%61%22%3e%3c%53%76%47%2f%6f%6e%6c%6f%61%64%3d%61%6c%65%72%74%28%64%6f%63%75%6d%65%6e%74%2e%64%6f%6d%61%69%6e%29%20%69%64%3d%68%6e%63%61%67%61%3e
Я попробовал проверить эту закодированную полезную нагрузку, но это тоже не сработало. Уже было решил бросить этот многострадальный URL, но тут меня озарило.
Рекомендация по отлову багов №2: никогда не сдавайтесь!
При тестировании уязвимостей иногда оказывается необходимо кодировать полезную нагрузку несколько раз. Удивительно, но во многих случаях это срабатывает. Я решил выполнить двойной URL-энкодинг: сначала кодируем стандартную нагрузку, затем повторно кодируем полученный результат.
URL с дважды закодированной полезной нагрузкой
https://aihub.cloud.google.com/url?q=%25%36%38%25%36%65%25%36%33%25%36%31%25%36%37%25%36%31%25%32%32%25%33%65%25%33%63%25%35%33%25%37%36%25%34%37%25%32%66%25%36%66%25%36%65%25%36%63%25%36%66%25%36%31%25%36%34%25%33%64%25%36%31%25%36%63%25%36%35%25%37%32%25%37%34%25%32%38%25%36%34%25%36%66%25%36%33%25%37%35%25%36%64%25%36%35%25%36%65%25%37%34%25%32%65%25%36%34%25%36%66%25%36%64%25%36%31%25%36%39%25%36%65%25%32%39%25%32%30%25%36%39%25%36%34%25%33%64%25%36%38%25%36%65%25%36%33%25%36%31%25%36%37%25%36%31%25%33%65
Я снова перешел на целевой URL, воспользовавшись дважды закодированной полезной нагрузкой. К моему удивлению, уязвимость сработала! Я едва не расплакался от радости.
Чтобы задокументировать весь процесс, я записал на видео запуск уязвимости в Burp Suite:
Теперь нужно было подготовить отчет об уязвимости для отдела безопасности Google.
Но тут я заметил одну странность: иногда XSS-нагрузка не работала. Я уже начал переживать, что из-за этого отчет не примут, но все равно отправил его.
Спустя несколько часов отдел безопасности Google прислал ответ, оправдавший мои опасения. Им не удавалось воссоздать найденную мной уязвимость. На их стороне XSS не работала.
Рекомендация по отлову багов №3: не останавливайтесь на первоначальном результате. Если вы уже нашли уязвимость, попробуйте копнуть чуть глубже.
Разбираясь с этой проблемой, я выяснил, что уязвимость иногда срабатывала через две-три попытки. Тогда я написал bash-скрипт с curl, который запрашивал уязвимый URL пять раз и проверял, какое количество ответов включает XSS-нагрузку.
Из пяти ответов на запросы curl три содержали полезную нагрузку. Иными словами, уязвимость срабатывала в трех случаях из пяти.
Вот написанный мной bash-скрипт:
Но постойте, это еще не все! Я уже почти отправил отделу безопасности Google обновленный отчет, но затем обнаружил, что возможности для эксплуатации XSS-уязвимости были намного шире, чем казалось поначалу.
В частности, я выяснил, что все URL с aihub.cloud.google.com вызывали срабатывание XSS при добавлении параметра q. Вставив в URL &q= с дважды закодированной полезной нагрузкой, можно было привести в действие запуск XSS.
Чтобы убедиться в этом, я собрал краулером различные URL, связанные с aihub, и сохранил их в текстовый файл valid_aihub_urls.txt. Затем я модифицировал свой bash-скрипт так, чтобы можно было проверить каждый URL из этого списка. Скрипт пять раз отправлял запросы curl к каждому URL и проверял, сработает ли XSS.
Для запуска скрипта достаточно ввести:
./google_poc_search_another_q.sh valid_aihub_urls.txtИ знаете что? XSS срабатывала для каждого валидного URL из текстового файла. Я даже попробовал выполнить запрос к несуществующей директории, добавив параметр q, но это все равно вызвало срабатывание XSS.
Отправка отчета и реакция Google
Оценив масштабы проблемы, я понял, что действовать нужно оперативно. Следуя практикам ответственного раскрытия, я сразу сообщил о своих находках отделу безопасности Google: подробно описал уязвимость, связанные с ней риски и принцип работы. Также я приложил к отчету написанные мной bash-скрипты.
После этого мой отчет наконец-то приняли к рассмотрению.
Отдел безопасности Google отреагировал молниеносно. Его сотрудники признали наличие проблемы, сменили уровень приоритета с P2 на P1, а уровень критичности — с S4 на S1, и поздравили меня с ценной находкой.
Спустя пару дней безопасники сообщили, что мои усилия будут вознаграждены:
Размер награды составил $4133,70. Сверх положенной суммы в $3133,70 мне выдали премию в $1000.
Рекомендация по отлову багов №4: по возможности отправляйте максимально исчерпывающий отчет. Проявите находчивость и уделите время созданию скриптов, подтверждающих наличие уязвимости — за это можно получить премию.
15 марта 2024 года безопасники Google снова связались со мной и сообщили, что уязвимость устранена. Я рассказал им, что теперь веб-сайт возвращал ошибку 502:
Они ответили, что aihub выведен из эксплуатации и с января 2024 года мигрировал на Vertex AI.
Чем была опасна эта уязвимость
Этот поддомен принадлежал Google, поэтому ему доверяли пользователи всего мира. Именно поэтому найденная мной уязвимость была такой опасной. Давайте разберем, как потенциальные злоумышленники могли бы эксплуатировать эту брешь в защите.
Похищение сессий. Используя вредоносные скрипты, нападающие могли бы похищать пользовательские сессии, получая неавторизованный доступ к аккаунтам и конфиденциальным данным.
Фишинговые атаки. Нападающие могли бы использовать вредоносные скрипты для перенаправления пользователей на фишинговые страницы, чтобы красть их учетные данные и другую чувствительную информацию.
Распространение вредоносного ПО. С помощью вредоносных скриптов можно перенаправлять пользователей на сайты, где вредоносное ПО, заражающее устройства жертв без их ведома.
Кража данных. Уязвимость можно использовать для кражи файлов cookie, токенов или других данных аутентификации.
Не стоит забывать и о репутационных издержках. Любая из этих атак могла навредить имиджу Google и снизить доверие пользователей к компании.
Заключение
Этот случай наглядно подтверждает простую истину: даже технологические гиганты вроде Google не застрахованы от уязвимостей и должны постоянно совершенствовать свою защиту. Если бы до обнаруженной мною уязвимости добрались реальные злоумышленники, это затронуло бы безопасность множества пользователей. Как говорится, чем больше шкаф, тем громче он падает.
Кем бы вы ни были — пользователем, разработчиком или специалистом по кибербезопасности — всегда оставайтесь начеку. Каждый из нас может играть свою собственную роль в противостоянии киберугрозам. Повышайте свою информированность, применяйте проактивные меры защиты, следуйте принципам ответственного раскрытия уязвимостей и делитесь своим опытом с другими людьми — и возможно, тогда цифровой мир станет более безопасным.
PURP — телеграм-канал, где кибербезопасность раскрывается с обеих сторон баррикад
t.me/purp_sec — инсайды и инсайты из мира этичного хакинга и бизнес-ориентированной защиты от специалистов Бастиона
Автор: breakmirrors
