Разведка GitHub: утёкшие секреты в вашей области

Разработчики утекают. Захардкоженный ключ в коммите, конфиг, запушенный по ошибке, внутренний hostname в комментарии: публичный код держит разведывательную ценность для вашей области или программы, в которую вы вступили. Работа в том, чтобы найти репозитории и пользователей, связанных с целью, а затем просканировать их инструментами для секретов. Держитесь области. Вы читаете публичный код и никогда не входите ни с чем из найденного.

#Найдите репозитории и пользователей

Начните с организации и домена. Веб-поиск по коду GitHub, в залогиненном виде, принимает квалификаторы, которые можно сочетать.

"example.com" org:example-inc
"api_key" "example.com"
filename:.env "example.com"

github-search скриптует ту же идею с токеном, вытягивая пользователей, репозитории и совпадения кода по термину. Его скрипт github-subdomains находит hostname, упомянутые где угодно в публичном коде, источник, который DNS-инструменты упускают.

github-subdomains -d example.com -t $GITHUB_TOKEN -o gh-subs.txt

Расширьте сеть на людей вокруг организации. Сотрудники указывают работу в профиле, так что поиск имени компании среди пользователей поднимает аккаунты, чьи личные репозитории иногда упоминают внутренние инструменты. Храните эти зацепки, но помните, чьи это данные, и относитесь к личному аккаунту бережнее, чем к корпоративному.

#Сканируйте клоны на секреты

Получив репозитории, клонируйте те, что в области, и сканируйте локально. gitleaks читает всю историю git, а не только текущие файлы, так что секрет, убранный позже, всё равно всплывает.

gitleaks detect --source ./example-repo --report-path leaks.json

trufflehog идёт дальше и проверяет многие типы секретов, тестируя, работает ли учётка, что резко срезает ложные срабатывания.

trufflehog git https://github.com/example-inc/example-repo --only-verified

Проверенное попадание это живая учётка. Не используйте её. Запишите её, с коммитом и файлом, для отчёта, и дайте владельцу её сменить. Сканирование большого монорепо занимает время, поэтому начните с репозиториев, которые ваши дорки уже привязали к цели, а не с каждого форка и зеркала.

#Пишите хорошие запросы в чате

Доркинг GitHub это задача про язык: верный квалификатор находит утечку, неверный её хоронит. Попросите чат NotHoly развернуть зерно в набор запросов.

Корни моей области example.com и example.net, org example-inc.
Напиши 15 запросов поиска по коду GitHub, чтобы найти утёкшие
секреты, внутренние hostname и config-файлы, связанные с ними. Меняй
квалификаторы (org, filename, path, language). По одному в строке.

Запросы вы сами вставляете обратно в поиск GitHub, а не в инструмент, который их запускает за вас. Модель также хорошо читает отчёт gitleaks: вставьте JSON и попросите сгруппировать попадания по типу секрета и ранжировать по тому, насколько каждое вероятно настоящее и в области.

#Область и приватность

Публичный код часто принадлежит людям, а не компании-цели. Личный репозиторий сотрудника это данные человека, и его старый побочный проект не в вашей области. Оставайтесь на репозиториях организации или явно связанных с инфраструктурой цели. Никогда не аутентифицируйтесь утёкшей учёткой, никогда не пушьте коммит и сообщайте о секретах через канал программы, чтобы их сменили.

#Частые вопросы

#Прочитать найденный секрет это проблема?

Читать публичный код это одно; использовать найденную учётку это другое, и это может пересечь черту неправомерного доступа даже внутри программы bug bounty. Сообщите о ней и не проверяйте входом.

#А старые коммиты, которые удалили?

Git хранит историю. Секрет, убранный в позднем коммите, всё ещё сидит в раннем, и именно поэтому gitleaks и trufflehog сканируют всю историю, а не текущее дерево.

Поиск по коду завершает ваши автоматические источники. Дальше оттачивайте ручную часть в доркинге поисковиков, который работает. Назад к certificate transparency и истории DNS.