Как я заработал $15k из-за утечки секретов GitHub
API-ключи, пароли и данные клиентов ежедневно случайно публикуются на GitHub.
Хакеры используют эти ключи для доступа к серверам, кражи личной информации. Утечки на GitHub могут стоить компании тысячи, а то и миллионы долларов в убытках. Сбор открытой разведывательной информации на GitHub стал мощным инструментом в арсенале каждого исследователя безопасности: исследователи из NC State даже написали академическую статью на эту тему.
Эта статья, написанная как для охотников за багами, так и для команд корпоративной информационной безопасности, демонстрирует общие типы конфиденциальной информации (секретов), которые пользователи публикуют в общедоступных репозиториях GitHub, а также эвристику для их поиска. Техники, описанные в этой статье, также можно применить к GitHub Gist.
Благодаря этим техникам, в прошлом году я заработал почти $10,000 за уязвимости на Багбаунти программах HackerOne, даже не посещая сайты этих программ. Я подал более 30 отчетов о раскрытии информации уязвимыми корпорациями, включая восемь компаний из списка Fortune 500.
Я также выпустил GitHound, инструмент с открытым исходным кодом, разработанный для автоматизации процесса поиска ключей по всему GitHub. GitHound не ограничивается одним пользователем или организацией: он просеивает весь GitHub, используя запросы поиска по коду, регулярные выражения и некоторые другие хитрые трюки для нахождения секретов.
Прежде чем мы перейдем к автоматизированным инструментам и стратегиям охоты за уязвимостями, давайте поговорим о поиске по коду.
GitHub предоставляет богатый функционал поиска по коду, который сканирует общедоступные репозитории GitHub (некоторый контент опускается, например, форки и недефолтные ветки). Запросы могут быть простыми, например, uberinternal.com, или могут содержать многословные строки, такие как "Authorization: Bearer". Поиски могут нацеливаться на конкретные файлы (filename: vim_settings.xml) или конкретные языки программирования (language:SQL). Запросы также могут содержать некоторые булевы квалификаторы, такие как NOT и >.
Знание правил поиска по коду GitHub позволяет нам создавать поисковые дорки — запросы, которые предназначены для нахождения чувствительной информации. GitHub-дорки можно найти в интернете, но лучшие из них — те, которые вы придумываете сами.
Например, filename: vim_settings.xml (попробуйте его!) нацелен на файлы настроек IntelliJ. Интересно, что файл vim_settings.xml содержит недавно скопированные строки, закодированные в Base64. Недавно я заработал $2400 на баунти за уязвимости благодаря этому дорку (API-ключи SaaS и информация о клиентах были раскрыты в файле vim_settings.xml).
Файл vim_settings.xml содержит только недавно скопированные строки, но мы можем использовать историю коммитов репозитория, чтобы найти всю историю копирования и вставки. Просто клонируйте репозиторий, запустите этот 14-строчный скрипт, и активность пользователя будет у вас под рукой. GitHound также находит и сканирует закодированные в base64 строки для поиска секретов, даже в истории коммитов.
Кстати, с помощью дорка для поиска коммитов на GitHub, мы можем быстро просканировать все 500,000 коммитов, связанных с vim_settings.xml.
Поисковая эвристика для охотников за багами
GitHub дорки находят конфиденциальную информацию в больших обьемах, но что, если мы хотим искать информацию о конкретной компании? На GitHub миллионы репозиториев и еще больше файлов, поэтому нам понадобятся некоторые навыки для сужения области поиска.
Я обнаружил, что лучший способ начать поиск — это найти домены и поддомены, которые идентифицируют корпоративную инфраструктуру.
Поиск по company.com, вероятно, не даст полезных результатов: многие компании выпускают проверенные open-source проекты, которые вряд ли содержат секреты. Менее используемые домены и поддомены более интересны. Например конкретные хосты, такие как jira.company.com, и прочие домены более низкого уровня. Более эффективно искать по шаблону, чем по одному домену: corp.somecompany.com, somecompany.net или companycorp.com с большей вероятностью появятся только в конфигурационных файлах сотрудников.
Здесь помогут обычные инструменты разведки из открытых источников:
* Subbrute - инструмент на Python для перебора поддоменов
* ThreatCrowd - при вводе домена ищет связанные домены с помощью множества OSINT техник
* Censys.io - при вводе домена находит SSL-сертификаты, которые его используют
GitHound также может помочь с обнаружением поддоменов: добавьте пользовательское регулярное выражение \.company\.com и запустите GitHound с флагом --regex-file.
После того как вы найдете хост или шаблон для поиска, поэкспериментируйте с поиском на GitHub (я всегда делаю это перед использованием автоматизированных инструментов). Здесь я задаю себе несколько вопросов:
- Сколько результатов появилось? Если более 100 страниц, возможно придется найти более подходящий запрос для начала (GitHub ограничивает результаты поиска по коду до 100 страниц).
- Какие результаты появились? Если результаты представляют собой (намеренно) открытые проекты и людей, использующих публичные API, тогда необходимо уточнить поиск, чтобы устранить их.
- Что произойдет, если я изменю язык? language:Shell и language:SQL могут дать интересные результаты.
- Показывают ли эти результаты другие домены или хосты? Результаты на нескольких первых страницах часто включают ссылку на другой домен (например, поиск jira.uber.com может показать существование другого домена, такого как uberinternal.com).
Большую часть времени я провожу на этом этапе.
Очень важно, чтобы пространство поиска было корректно и четко определено. Автоматизированные инструменты и ручной поиск будут значительно быстрее и точнее при использовании правильного запроса.
Как только я нахожу результаты, которые выглядят интересными (на основе приведенных выше критериев), я запускаю их через GitHound с параметрами --dig-files и --dig-commits, чтобы просмотреть весь репозиторий и его историю.
echo "uberinternal.com" | ./git-hound --dig-files --dig-commits
echo "uber.com" | ./git-hound --dig-files --language-file languages.txt --dig-commits
echo "uber.box.net" | ./git-hound --dig-files --dig-commits
GitHound также находит интересные файлы, которые просто поиском выявить не удастся, например .zip или .xlsx файлы. Важно отметить, что также я проверяю результаты вручную, так как автоматизированные инструменты часто пропускают клиентские данные, чувствительный код и комбинации имени пользователя/пароля.
Часто эти файлы раскрывает больше поддоменов или других интересных шаблонов, которые дают мне идеи для дополнительных поисковых запросов. Важно помнить, что разведка из открытых источников — это рекурсивный процесс.
- Этот процесс почти всегда приводит к нахождению результатов. Утечки обычно попадают в одну из следующих категорий (расположены от наиболее значимых, к наименее):
- Ключи SaaS API - Компании редко накладывают ограничения по IP на API. Ключи AWS, Slack, Google и других API - настоящее золото. Обычно их находят в конфигурационных файлах, bash истории и скриптах.
- Учётные данные серверов/баз данных - Обычно находятся за брандмауэром, поэтому менее значимы. Чаще всего их можно найти в конфигурационных файлах, bash истории и скриптах.
- Информация о клиентах/сотрудниках - Скрываются в .xlsx, .csv и .xml файлах и варьируются от электронных адресов до платёжной информации и обзоров трудовой деятельности сотрудников.
- Скрипты дата-сайенс - SQL запросы, скрипты на R, и проекты Jupyter могут раскрыть чувствительную информацию. В этих репозиториях также часто встречаются файлы с "тестовыми данными".
- Имена хостов/метаданные - Самый распространённый результат. Большинство компаний не считают это уязвимостью, но они могут помочь уточнить будущие поиски.
Рабочий процесс для конкретных поставщиков API
Также можно создавать дорки для поиска конкретных поставщиков API и их конечных точек. Это особенно полезно для компаний, создающих автоматические проверки API ключей своих пользователей. С знанием контекста и синтаксиса API ключа, можно значительно сократить область поиска.
Зная конкретного поставщика API, мы можем получить все ключи, которые соответствуют regex шаблону заданного поставщика. Затем мы можем проверить их на валидность, используя внутреннюю базу данных или конечную точку API.
Например, предположим, что компания (HalCorp) предоставляет API для пользователей, чтобы читать и записывать данные аккаунта. Создав собственный аккаунт в HalCorp, мы обнаруживаем, что API ключи имеют формат
[a-f]{4}-[a-f]{4}-[a-f]{4}
# Python
import halapi
api = halapi.API()
api.authenticate_by_key('REDACTED')
# REST API with curl
curl -X POST -H "HALCorp-Key: REDACTED" https://api.halcorp.biz/userinfoВооружившись этой информацией, мы можем составить свои собственные GitHub dorks для ответов HalCorp API:
# Python "authenticate_by_key" "halapi" language:python # REST API "HALCorp-Key"
С помощью инструмента GitHound мы можем использовать регулярные выражения, чтобы находить строки, соответствующие регулярному выражению API ключа, и выводить их в файл:
echo "HALCorp-Key" | git-hound --dig-files --dig-commits --many-results --regex-file halcorp-api-keys.txt --results-only > api_tokens.txt
Теперь, когда у нас есть файл, содержащий потенциальные API токены, мы можем проверять их на актуальность (не делайте этого без письменного разрешения от поставщика API).
В случае с HalCorp, мы можем написать bash-скрипт, который читает из stdin, проверяет конечную точку api.halcorp.biz/userinfo и выводит ответ.
cat api_tokens.txt | bash checktoken.bash
Несмотря на возросшую осведомленность о раскрытии секретов в GitHub, ежедневно публикуется всё больше конфиденциальных данных.
Amazon Web Services начали уведомлять пользователей, если их API ключи размещены в сети. GitHub добавил функции безопасности, которые сканируют публичные репозитории на наличие ключей. Однако эти решения лишь временные меры. Чтобы ограничить утечки секретной информации из исходного кода, мы должны обновлять API фреймворки и DevOps методологии, чтобы полностью предотвратить хранение API ключей в репозиториях Git/SVN. Программное обеспечение, такое как Vault, безопасно хранит ключи, а некоторые поставщики API, такие как Google Cloud Platform, обновили свои библиотеки, чтобы по умолчанию принуждать хранить API ключи в файле.