- Регистрация
- 06.12.2020
- Сообщения
- 181
- Реакции
- 48
Ключи API, пароли и данные о клиентах случайно публикуются на GitHub каждый день.
Хакеры используют эти ключи для входа на серверы, кражи личной информации и взимания абсурдной платы за использование AWS. Утечки GitHub могут стоить компании тысячи или даже миллионов долларов убытков. Сбор разведывательных данных с открытым исходным кодом на GitHub стал мощной стрелой в колчане каждого исследователя безопасности: исследователи из штата Северная Каролина даже написали научную статью на эту тему.
Эта статья, написанная как для багхантеров, так и для команд корпоративной информационной безопасности, демонстрирует общие типы конфиденциальной информации (secrets), которые пользователи публикуют в общедоступных репозиториях GitHub, а также эвристику для их поиска. Приемы, описанные в этой статье, также могут быть применены к сниппетам GitHub Gist.
GitHound - инструмент с открытым исходным кодом, предназначенный для автоматизации процесса поиска ключей в GitHub. GitHound не ограничивается одним пользователем или организацией: он просматривает весь GitHub, используя запросы поиска кода в качестве точки входа в репозитории, а затем используя контекст, регулярные выражения и некоторые другие хитрые приемы для поиска секретов.
Поиск кода 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.
Можно заработать, если обнаружить следующий момент: ключи SaaS API и информация о клиентах представлены в vim_settings.xml.
vim_settings.xml содержит только недавно скопированные строки, но мы можем использовать историю фиксации репозитория, чтобы найти всю историю копирования и вставки. Просто клонируйте репозиторий и запустите этот 14-строчный скрипт, и действия пользователя будут у вас под рукой. GitHound также находит и сканирует строки в кодировке base64 на наличие секретов даже в истории коммитов.
Между прочим: с помощью дорк поиска коммитов GitHub мы можем быстро сканировать все 500 000 коммитов, редактирующих vim_settings.xml.
Эвристика поиска для Bug Bounty Hunters
Сторонники поиска на GitHub обычно находят конфиденциальную информацию, но что, если мы захотим найти информацию о конкретной компании? GitHub имеет миллионы репозиториев и даже больше файлов, поэтому нам понадобятся некоторые эвристики, чтобы сузить область поиска.
Чтобы начать поиск конфиденциальной информации, определите цель.
Лучший способ начать - это найти домены или субдомены, которые идентифицируют корпоративную инфраструктуру.
Поиск по адресу company.com, вероятно, не принесет полезных результатов: многие компании выпускают проверенные проекты с открытым исходным кодом, которые вряд ли содержат секреты. Менее используемые домены и поддомены более интересны. Сюда входят конкретные хосты, такие как jira.company.com, а также более общие домены второго и нижнего уровня. Более эффективно найти шаблон, чем один домен: corp.somecompany.com, somecompany.net или companycorp.com с большей вероятностью появятся только в файлах конфигурации сотрудника.
В этой задаче помогут опенсорсные OSINT - инструменты:
Найдя хост или шаблон для поиска, поиграйте с ним в поиске GitHub (я всегда делаю это перед использованием автоматических инструментов).
Пришло время ответить на несколько вопросов:
Очень важно, чтобы пространство поиска было четко определенным и точным. Автоматические инструменты и ручной поиск будут быстрее и точнее с правильным запросом.
Когда находятся результаты, которые кажутся интересными на основе вышеуказанных критериев, я запускаю их через 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. Важно отметить, что необходимо вручную просматривать результаты, поскольку автоматизированные инструменты часто пропускают информацию о клиенте, конфиденциальный код и комбинации имени пользователя и пароля. Часто это выявляет больше поддоменов или других интересных шаблонов, которые дают идеи для большего количества поисковых запросов. Важно помнить, что разведка с открытым исходным кодом - это рекурсивный процесс.
Этот процесс почти всегда дает результаты. Утечки обычно попадают в одну из следующих категорий (в порядке убывания от наиболее значительного до наименее значимого):
Дорки также могут быть созданы для конкретных поставщиков API и их конечных точек. Это особенно полезно для компаний, создающих автоматические проверки ключей API своих пользователей. Зная контекст и синтаксис ключа API, можно значительно сократить пространство поиска.
Зная конкретного поставщика API, мы можем получить все ключи, которые соответствуют регулярному выражению поставщика API и находятся в контексте вызова API, а затем мы можем проверить их на достоверность с помощью внутренней базы данных или конечной точки 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
Вооружившись этой информацией, мы можем составить собственные dorks на GitHub для ответов HalCorp API:
# Python
"authenticate_by_key" "halapi" language
ython
# 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, который читает из стандартного ввода, проверяет конечную точку 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 по умолчанию сохранялись в файле.
Полное искоренение раскрытия конфиденциальной информации - более сложная проблема:
Хакеры используют эти ключи для входа на серверы, кражи личной информации и взимания абсурдной платы за использование AWS. Утечки GitHub могут стоить компании тысячи или даже миллионов долларов убытков. Сбор разведывательных данных с открытым исходным кодом на GitHub стал мощной стрелой в колчане каждого исследователя безопасности: исследователи из штата Северная Каролина даже написали научную статью на эту тему.
Эта статья, написанная как для багхантеров, так и для команд корпоративной информационной безопасности, демонстрирует общие типы конфиденциальной информации (secrets), которые пользователи публикуют в общедоступных репозиториях GitHub, а также эвристику для их поиска. Приемы, описанные в этой статье, также могут быть применены к сниппетам GitHub Gist.
- GitHub - это весь сайт. Gists - это особый сервис, предлагаемый на этом сайте, а именно фрагменты кода, похожие на pastebin. Однако все управляется git revision control, поэтому у gists также есть полная история ревизий.
GitHound - инструмент с открытым исходным кодом, предназначенный для автоматизации процесса поиска ключей в GitHub. GitHound не ограничивается одним пользователем или организацией: он просматривает весь GitHub, используя запросы поиска кода в качестве точки входа в репозитории, а затем используя контекст, регулярные выражения и некоторые другие хитрые приемы для поиска секретов.
Поиск кода 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.
Можно заработать, если обнаружить следующий момент: ключи SaaS API и информация о клиентах представлены в vim_settings.xml.
vim_settings.xml содержит только недавно скопированные строки, но мы можем использовать историю фиксации репозитория, чтобы найти всю историю копирования и вставки. Просто клонируйте репозиторий и запустите этот 14-строчный скрипт, и действия пользователя будут у вас под рукой. GitHound также находит и сканирует строки в кодировке base64 на наличие секретов даже в истории коммитов.
Между прочим: с помощью дорк поиска коммитов GitHub мы можем быстро сканировать все 500 000 коммитов, редактирующих vim_settings.xml.
Эвристика поиска для Bug Bounty Hunters
Сторонники поиска на GitHub обычно находят конфиденциальную информацию, но что, если мы захотим найти информацию о конкретной компании? GitHub имеет миллионы репозиториев и даже больше файлов, поэтому нам понадобятся некоторые эвристики, чтобы сузить область поиска.
Чтобы начать поиск конфиденциальной информации, определите цель.
Лучший способ начать - это найти домены или субдомены, которые идентифицируют корпоративную инфраструктуру.
Поиск по адресу company.com, вероятно, не принесет полезных результатов: многие компании выпускают проверенные проекты с открытым исходным кодом, которые вряд ли содержат секреты. Менее используемые домены и поддомены более интересны. Сюда входят конкретные хосты, такие как jira.company.com, а также более общие домены второго и нижнего уровня. Более эффективно найти шаблон, чем один домен: corp.somecompany.com, somecompany.net или companycorp.com с большей вероятностью появятся только в файлах конфигурации сотрудника.
В этой задаче помогут опенсорсные OSINT - инструменты:
- Subbrute - инструмент Python для перебора поддоменов.
- ThreatCrowd - для заданного домена найдите связанные домены с помощью нескольких методов OSINT.
- Censys.io - поиск SSL-сертификатов, для доменов.
Найдя хост или шаблон для поиска, поиграйте с ним в поиске 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 keys - Компании редко накладывают ограничения IP на API. AWS, Slack, Google и другие ключи API - это жидкое золото. Обычно они находятся в файлах конфигурации, файлах истории bash и скриптах.
- Server/database credentials - обычно они находятся за брандмауэром, поэтому они менее эффективны. Обычно находится в файлах конфигурации, файлах истории bash и скриптах.
- Customer/employee information - они скрываются в файлах XLSX, CSV и XML и варьируются от электронных писем до информации о выставлении счетов и обзоров производительности сотрудников.
- Data science scripts - SQL-запросы, R-скрипты и проекты Jupyter могут раскрывать конфиденциальную информацию. В этих репозиториях также часто встречаются файлы «тестовых данных».
- Hostnames/metadata - наиболее частый результат. Большинство компаний не считают это уязвимостью, но они могут помочь уточнить будущие запросы.
Дорки также могут быть созданы для конкретных поставщиков API и их конечных точек. Это особенно полезно для компаний, создающих автоматические проверки ключей API своих пользователей. Зная контекст и синтаксис ключа API, можно значительно сократить пространство поиска.
Зная конкретного поставщика API, мы можем получить все ключи, которые соответствуют регулярному выражению поставщика API и находятся в контексте вызова API, а затем мы можем проверить их на достоверность с помощью внутренней базы данных или конечной точки 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
Вооружившись этой информацией, мы можем составить собственные dorks на GitHub для ответов HalCorp API:
# Python
"authenticate_by_key" "halapi" language
ython# 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, который читает из стандартного ввода, проверяет конечную точку 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 по умолчанию сохранялись в файле.
Полное искоренение раскрытия конфиденциальной информации - более сложная проблема:
- Как можно полностью обнаружить информацию о клиентах?
- Что делать, если он находится в Word, Excel или скомпилированном файле?