Чему я научился, прочитав 126* статей о раскрытии информации

Эта статья носит исключительно образовательный характер. Автор не несет ответственности за любые последствия ее прочтения.

Данная статья является переводом и ведется со слов автора. Оригинал тут.

Давайте разберемся с самым ценным и загадочным типом багов…

Во-первых , давайте установим некоторые основные моменты:

Раскрытие информации не имеет полезной нагрузки, поэтому контекстные и качественные данные важны для понимания того, как добиться успеха. Эта статья должна помочь в этом.
Раскрытие информации — третья самая высокооплачиваемая ошибка. (больше, чем IDOR, SQLi, PrivEsc и т.д.)
«Это кажется случайным», «Это основано на удаче и лаже разработчика, а не на навыках». Сначала я был почти согласен с этим мнением, но после прочтения всех отчетов мне удалось разбить их на различные категории и методологии, которые помогут вам стать более эффективными в поиске этих ошибок логичным, последовательным образом, вместо того, чтобы действовать вслепую.

Перейдем к основным фактам…

Что вы на самом деле ищете? Раскрытие информации — это не только учетные данные и персональные данные.

Учетные данные — 18,2%
Персональные данные — 14,1%
Внутренние документы — 12,1%
Электронные письма — 10,1%
API-ключи — 10,1%
Телефонные номера — 8,1%
Исходный код — 5,1%
и так далее...

Теперь мы знаем, что ищем. Как нам их получить?

Злоупотребление API — 45,6%
Брутфорс каталогов — 17,6%
Случайный публичный доступ — 17,6%
Доркинг — 10,3%
Утечки API — 8,8%

Утечки API

Утечка API — это когда функционирующий по назначению API возвращает слишком много информации.

Обычно это API, которые возвращают слишком много ненужной информации, как правило, без необходимости аутентификации. (Источник)

Это довольно очевидный случай, однако они могут быть более дискретными. Например, если сервис пытается анонимизировать пользователей и произошла утечка идентификатора пользователя? Обычно это было бы бесполезно, однако вы можете сравнить это с их деанонимизированной учетной записью, и если они совпадают, это позволит вам раскрыть чью-то личность. (Источник)

Или, возможно, ищите параллельные API, которые пропускают содержимое, недоступное для основного API. (Источник)

Мой совет для их поиска - просто загружайте все через burp и внимательно следите за ответами во время использования приложения.

Доркинг

Доркинг для получения информации, безусловно, мой любимый метод.

Общий доркинг был рассмотрен 1000 ра, поэтому я дам вам несколько дополнительных советов как добиться большего успеха по сравнению с другими багхантерами.

Посмотрите на сторонних сайтах или ресурсах, выходящих за рамки тестирования. Тестирование на ресурсах, выходящих за рамки, является незаконным , а пассивный поиск — нет. Например, выполните доркинг company.atlassian.com и посмотрите, есть ли открытые дашборды Jira.
Git dork для необычных форматов паролей. Вместо того, чтобы искать username и password, попробуйте использовать строки подключения, например postgres://, в надежде, что вы найдете что-то вроде postgress://username:password@subdomain (Источник)
Если вы найдете что-то, вы можете превратить это в шаблон для Nuclei? Таким образом получите в 10 раз больше наград за тот же объем исследований. Например, в этой статье автор нашел во время охоты за ошибками «/plesk-stat» (утечка логов), превратил это в шаблон для Nuclei, а затем использовал его на других целях.

Мой личный совет, который я использовал для поиска критических ключей API, учетных данных и многого другого: соберите поддомены Gitlab или другие поддомены размещающие исходный код, а затем перейдите туда. Github сейчас просматривают все, и git dorking становится все сложнее и сложнее.

Случайный публичный доступ

Люди говорят: “Раскрытие информации - это просто удача”. Но это все равно важная часть, которую нужно признать. Иногда разработчики ошибаются и оставляют пользовательские данные валяться без дела.

Ни для кого не было сюрпризом, что исходный код часто является большой проблемой. Просмотр статических JS-файлов, html-файлов дал множество личных данных, ключей API, учетных данных и многого другого.
Может быть, приложение просто плохо сделано? Было несколько примеров того, как настройки утечки персональных данных сохранялись после исправления (пример) или при плохой реализации анонимности (пример).
Проверьте метаданные загруженных изображений, загруженные изображения, которые не удалены, могут показать местоположение и персональные данные.
Иногда разработчики не ошибаются! Но иногда это делают другие сотрудники... Распространяют ли нанятые по контракту или нетехнические работники секретную информацию на своих личных страницах?

Брутфорс каталогов

Я подробно рассказал о брутфорсе каталогов в своем блоге Content Discovery, поэтому еще раз расскажу о дополнительных советах по сокращению ненужных запросов, которые нагружают целевой сервер и тратят ваше время.

Запуск seclist raft-large-directories-lowercase.txt может дать вам URL-адреса, но не активы . Конфиденциальная информация хранится в файлах, а не на случайных страницах сайта (как правило). Так что всегда делайте акцент на расширениях файлов. Наиболее распространенным расширением в статьях был .json.
Попробуйте фаззить «умнее», используйте небольшие реалистичные списки слов с большим количеством расширений вместо массивных общих списков слов. Что с большей вероятностью приведет к утечке информации domain.com/emeapartner2007/ (взято из raft-large-directories-lowercase.txt) или domain.com/dev.zip?
Я обнаружил, что если вы сталкиваетесь с общей страницей Microsoft IIS, используйте инструмент SNS для поиска конечных точек вместо обычного перебора каталогов.

Злоупотребление API

Теперь о главном… 45,6% раскрытия информации было получено из-за злоупотребления API. Вот что мы узнали.

58% злоупотреблений API были связаны с IDOR.
27,8% злоупотреблений API были связаны с GraphQL.
Большинство злоупотреблений API, которые не были IDOR, произошли из-за использования плохо реализованных средств контроля доступа на конечных точках API.
Злоупотребление API было наиболее распространенным способом утечки чьей-либо личности.

Резюме/Ключевые выводы

Раскрытие информации — это не только утечка паролей или ключей API.
54,4% раскрытий информации связаны с API.
Раскрытие информации — это не просто удача, есть 5 конкретных способов их найти.
Успех в поиске раскрытия информации зависит от творческих способов обнаружения и использования стратегий, которые не являются общепринятыми в сообществах по поиску ошибок.