GitHub для охотников за ошибками

Apr 28 2023

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

1-массовое клонирование

Вы можете просто провести исследование на github.com, однако для локального тестирования я советую клонировать каждый целевой репозиторий. GitHubCloner от @mazen160 — фантастический продукт. Все, что вам нужно сделать, это выполнить сценарий, чтобы быть готовым к работе.

$ python githubcloner.py --org organization -o /tmp/output

Крайне важно действительно понять проект, к которому вы стремитесь, прежде чем начинать статический анализ. Используйте основные функции во время работы над проектом. Причина, по которой я называю это «шагом Жобера», заключается в том, что я слышал, что перед началом каждой охоты Жоберт использует проект и хорошо понимает цель, прежде чем искать слабые места.

3- Ручной анализ

В этой ситуации применима поговорка «научись делать, а потом ломай» . Если вы можете выучить язык программирования, вы должны быть в состоянии понять все тонкости мер безопасности, которые следует принимать и избегать.

Вы можете начать поиск, когда ознакомитесь с целью и ее архитектурой. Ищите ключевые слова, которые вас интересуют, с которыми вы знакомы или о которых вы знаете, что разработчики часто ошибаются.

Вот основной список некоторых поисковых терминов, которые я буду использовать во время первой широкой оценки:

API и ключ. (Получите еще несколько конечных точек и найдите ключи API.)
жетон
секрет
ДЕЛАТЬ
пароль
уязвимый
http:// и https://

CSRF
случайный
хэш
МД5, ША-1, ША-2 и т.д.
HMAC

Еще одним важным шагом является просмотр истории коммитов. Вы будете удивлены тем, как много информации вы можете почерпнуть из коммитов. Я видел, как участники ошибочно полагали, что они удалили учетные данные, хотя они остаются в истории коммитов. Из-за истории git я обнаружил старые конечные точки, которые все еще работают. Помимо текущих проблем, вы можете столкнуться с историческими проблемами, которых можно избежать благодаря старым коммитам.

4- Инструменты

Иногда автоматизация скучных задач может помочь вам получить общее представление о том, что искать. Важно помнить, что вы никогда не должны копировать и вставлять результаты сканирования в отчеты. Вы получите много ложных срабатываний, поэтому всегда следует тщательно исследовать любые потенциальные проблемы, чтобы убедиться, что их можно использовать.

Основной инструмент, который я использую при работе над проектами Python, — это Bandit .

Bandit выявляет распространенные проблемы, но часто возвращает ложные срабатывания или легко висящие плоды. Поэтому используйте его с осторожностью. Без сомнения, на это не следует полагаться.

$ bandit -r path/to/your/code -ll

Snyk.io — замечательный инструмент для проверки зависимостей. Платформа поддерживает множество языков.

Для разведки многие исследователи предлагают использовать Gitrob . Этот инструмент будет искать конфиденциальную информацию в общедоступных репозиториях GitHub.

$ gitrob analyze acme,johndoe,janedoe

$ truffleHog https://github.com/dxa4481/truffleHog.git

Для приложений Ruby on Rails я рекомендую Brakeman . Brakeman — это сканер безопасности со статическим анализом, который может найти массу различных проблем с безопасностью в коде.

Используйте LinkFinder от Gerben Javado , чтобы найти конечные точки в JS-файлах репозитория.

$ python linkfinder.py -i 'path/to/your/code/*.js' -r ^/api/ -o cli

Хорошо, серьезно, не занимайтесь социальной инженерией владельцев проекта.

Сообщение о ваших выводах

Как всегда, когда дело доходит до поиска ошибок, внимательно прочитайте политику программы. Очень редко программа принимает отчеты через GitHub. Обратитесь в службу безопасности или, если возможно, используйте платформу для поиска ошибок, такую как HackerOne или Bugcrowd.

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