[Перевод] Вознаграждение в $20 300 за 200 часов хакерского марафона
Вернемся к июлю 2023 года: вместе с Мохаммадом Никуи мы решили посвятить 100 часов работе над публичной программой Bug Bounty на платформе BugCrowd. Мы занимались ею неполный рабочий день, уделяя по 4–6 часов ежедневно. Выбрали программу от известной и крупной компании. Поскольку она была общедоступной, в программе уже успели поработать многие именитые охотники на уязвимости, что сразу отпугнуло бы многих новичков. Мы не заявляем, что относим себя к профессионалам, однако наш подход и мышление дали нам шанс работать с этой программой. Для нас это был серьезный вызов: результатом мы считали не размер вознаграждения, а сам процесс обучения и работы. Поэтому мы определили срок в 200 часов, вместо того чтобы ориентироваться на сумму выплат.
Причиной написания этого поста стали разнообразные техники, которые мы использовали в процессе охоты. Мы хотим поделиться своим подходом и техническими деталями как для начинающих, так и для специалистов среднего уровня.
Выбор программы
Выбор программы — один из самых сложных этапов в поиске уязвимостей. Программа должна соответствовать вашим навыкам и иметь потенциал для длительной работы. На начальную подготовку мы потратили около 10 часов (по 5 часов каждый). Мы отдавали предпочтение программам с широким охватом, включающим как старые, так и современные архитектуры и языки программирования, а также обеспечивающим своевременные выплаты и поддержку профессиональной триаж-команды.
Главной причиной выбора этой программы стало то, что Todayisnew (кто о нем не слышал?) занимал первое место в рейтинге охотников. Это вдохновило нас и заставило задуматься: если он сумел обнаружить множество уязвимостей, почему бы нам не попробовать сделать то же самое? Надеемся, вы уловили суть: не недооценивайте себя, поскольку у каждого исследователя есть свой уникальный подход к тестированию веб-сайтов.
Рекогносцировка
Мы использовали различные методы, чтобы выявить как можно больше активов для исследования, так как более широкий охват увеличивает шансы на обнаружение уязвимостей. Кратко перечислим некоторые из этих методов:
Поиск по сертификатам
Обнаружение активов через IP-адреса
Использование CSP-заголовков
Google Dorks
Поиск по идентификатору Google Analytics
Статический и динамический DNS-брутфорс
OSINT
Рассмотрим подробнее некоторые из этих методов.
Поиск по сертификатам
Обычно в поиске по сертификатам ориентируются на Common Name (CN); однако сертификат содержит и другие поля, такие как Organization (O) и другие метаданные. Существуют сайты, которые сканируют сеть и сохраняют сертификаты, например, Shodan и Censys, хотя могут быть и другие альтернативы. Поскольку мы не можем назвать конкретную программу без разрешения, рассмотрим пример на компании Apple.
Используя следующую команду, можно перечислить корневые домены компании Apple:
«curl -s "https://crt.sh/?O=Apple%20Inc.&output=json" | jq -r ".[].common_name" | tr A-Z a-z | unfurl format %r.%t | sort -u | tee apple.cert.txt»
Использование IP для обнаружения активов
У каждой компании может быть несколько CIDR, иногда их практически невозможно найти, так как название владельца не указано; однако CDIR с названием компании (Apple в названии ASN). Чтобы найти IP-адреса, CIDR и ASN, можно использовать множество способов, и один из моих любимых — ipip.net.
Мы просканировали все диапазоны CIDR, ASN и IP, принадлежащие компании, извлекли информацию о сертификатах и нашли несколько доменов. Следующей командой можно найти альтернативные и общие имена:
echo AS714 | tlsx -san -cn -silent -resp-onlyOSINT
Вероятно, вы уже знакомы с вышеупомянутыми методами, описанными в интернете. Однако, как «белый» хакер или охотник за уязвимостями, важно всегда мыслить нестандартно. На этом этапе, после завершения технического поиска, мы обратились к OSINT. Мы начали просто искать информацию о компании в интернете, не ставя конкретной цели, а просто читая новости, чтобы узнать что-то новое (мы на самом деле не знали, что именно ищем, просто просматривали). В этот момент для нас случился важный прорыв. У компании оказался блог с новостями, и случайно увидев один из постов, я обнаружил домен, похожий на championscompany.com. Я сверил его с результатами своего рекона, и он не присутствовал в моем списке доменов.
Затем я вручную проверил все 5000 постов в блоге компании и нашёл 60 интересных доменов, которых не оказалось в результате разведки.
Уязвимости
Во время нашей работы мы обнаружили несколько интересных (по крайней мере, для нас) уязвимостей безопасности. Начнем с простой, чтобы избежать утомительных деталей, мы опишем только те, которые представляют особый интерес.
Доступ ко всем пользовательским данным через Swagger / Утечка PII
Мы обнаружили субдомен test.target.tld с помощью статического перебора DNS (с использованием ключевого слова «test»). На порту 5000 работал интерфейс Swagger UI, не требующий аутентификации. В нем было около 100 API, которые, по-видимому, требовали аутентификации. Однако мы начали тестировать каждый по отдельности (скучная, но необходимая работа). К нашему удивлению, мы нашли ровно 10 открытых API. Из 2 утекали данные PII, как показано ниже:
Две SQL-инъекции
Одним из самых эффективных этапов баг-баунти или тестирования на проникновение является моделирование угроз. Поняв контекст целевого объекта, мы можем подготовить тест-кейсы и сценарии атак. Моделирование угроз крайне важно; нельзя слепо отправлять или фуззить нагрузочные запросы, так как это не приведет к результатам, учитывая потраченное время. Если приложение устаревшее (легаси) и содержит поля, загружаемые из базы данных (в данном случае, выбор страны), мы тестируем эти поля с временными нагрузками.
Мы обнаружили 2 SQL-инъекции, используя полезную нагрузку 1'XOR (SELECT CASE WHEN (1234=1234) THEN SLEEP (7) ELSE 0 END)XOR’Z:
Утечка всей информации, подлежащей идентификации
Мы попытались получить информацию о пользователе, изменяя числовой идентификатор в запросе, как это делают многие охотники, но столкнулись с ошибкой 403. Затем мы сменили метод запроса на PATCH, тактику, которую используют некоторые охотники, но и это не сработало. Однако нашей ключевой стратегией было добавление специфических заголовков. Включив заголовок Accept: application/json, мы успешно получили ответ 200 OK. Когда мы просматривали приложение, мы увидели запрос следующего вида:
GET /users/58158 HTTP/2
Host: www.target.com
Cookie: x
Content-Length: 0
Sec-Ch-Ua:Мы изменили числовой идентификатор и получили ошибку 403. Для обхода ограничения мы изменили метод на PATCH и добавили заголовок Accept: application/json.
PATCH /users/58158 HTTP/2
Host: www.target.com
Cookie: x
Content-Length: 0
Sec-Ch-Ua:
Accept: application/jsonРезультат:
Stored XSS
Где бы ни использовался ввод текста, это интересная среда для тестирования XSS. Однако в большинстве случаев редактор фильтрует опасные теги с помощью регулярных выражений, поэтому не стоит отчаиваться и нужно продолжать тестирование. При просмотре приложения мы обнаружили поле постов. В поле постов можно писать заметки, как в Twitter. Но у них была CSP, и нам нужно было обойти её. Мы использовали следующий полезный для обхода CSP код:
xss
Доступ к домену сотрудников привел к утечке всех транзакций
Во время нашего разведывательного анализа мы обнаружили особенно интересный домен, который содержал слово demo в своем названии, например companydemonew.com. Этот домен предлагал только возможность входа или регистрации. Для регистрации требовался корпоративный адрес электронной почты, например mamad@company.com:
Мы зарегистрировались с адресом mamad@company.com.burpcollaborator.com и смогли обойти процесс регистрации и получить электронное письмо для активации!
Поскольку домен был недоступен для общего пользования, мы ожидали множество уязвимостей после аутентификации. Наши ожидания оправдались вскоре после изучения функций сайта. В результате, просто изменив числовой идентификатор с 35 на 36, мы обнаружили значительную уязвимость IDOR.
Результат:
Файл конфигурации WPEngine
Используя общедоступный список слов, можно обнаружить некоторые уязвимости, но специализированный список слов может выявить больше. С помощью нашего частного списка слов нам удалось найти файл конфигурации WPEngine:
https://target.com/_wpeprivate/config.json
Результат:
Другие уязвимости
x2 Утечка учетных данных БД
x1 Перехват учетной записи
x10 Reflected XSS
x2 Раскрытие информации
x2 Business Logic
x2 Subdomain Takeover
Общее количество часов
Мы ежедневно отслеживали наше время с помощью приложения Toggl Track, чтобы оценить наш прогресс в конце пути. Результаты представлены на картинке:
Мы потратили около 200 часов (по 100 часов на человека) на наше мероприятие по охоте на уязвимости.
Общие награды
После достижения нашей цели работать вместе в течение 200 часов, мы приостановили нашу охоту и дождались обработки открытых отчетов. Это заняло почти 5 месяцев, чтобы получить вознаграждения за все отчеты. В итоге мы заработали 20,300 долларов за наше путешествие. Мы надеемся, что наш отчет оказался полезным.
Мой тг канал.
Habrahabr.ru прочитано 10531 раз
