Помните, когда Big Data была такой же популярной, как сейчас искусственный интеллект?
Очень объемная и интересная статья "Secrets and Shadows: Leveraging Big Data for Vulnerability Discovery at Scale". Автор с высокой степенью детализации описывает исследование, которое началось еще в 2021 году. Оно посвящено двум аспектам: поиску "висящих" DNS-записей (записей, указывающих на освобожденные IP-адреса, что может привести к захвату домена) и поиску hardcoded credentials в больших объемах данных, полученных из открытых источников.
В рамках данного поста мы сосредоточимся на аспекте поиска hardcoded credentials, хотя рекомендуем ознакомиться и с кейсом, связанным с DNS-записями.
Многие инженеры знакомы с сервисом VirusTotal, созданным для быстрого анализа файлов на предмет вредоносного кода. При загрузке файла VirusTotal выводит сообщение:
By submitting data ... you are agreeing ... to the sharing of your sample submission with the security community
Вопрос извлечения и анализа загруженных файлов в VirusTotal достаточно прост: используя инструмент Retrohunt и написав YARA-правило, можно извлекать образцы из ранее загруженных файлов на основе регулярных выражений. Учитывая, что захардкоженные секреты часто имеют определенные regexp паттерны, это идеальный способ их идентификации в загруженных файлах. Однако автор пошел дальше, стремясь извлечь и те секреты, которые не поддаются стандартным паттернам. Для этого он искал косвенные признаки, такие как строки вида
[a-zA-Z0-9]{32} для поиска потенциальных API-ключей. Он также создал конвейер на базе AWS Lambda для автоматизированного извлечения и проверки валидности секретов из Retrohunt. Избегая подробностей, в результате было просканировано 5 миллионов файлов, в которых было обнаружено более 15 тысяч секретов, включая ключи OpenAI, AWS и GitHub.
Хотя статья и результаты исследования впечатляют, особенно заслуживают внимания дальнейшие действия автора. В попытке устранить выявленные секреты он решил воспользоваться функционалом GitHub. Платформа, предоставляющая открытые репозитории, может стать источником утечек конфиденциальной информации, которая быстро попадает в руки злоумышленников. В связи с этим GitHub сотрудничает с различными вендорами для оперативного отзыва таких секретов через интеграцию. Однако, поскольку GitHub не предоставляет API для массового отзыва секретов, автор был вынужден использовать кратковременные Gist'ы для публикации всех найденных данных. Идея заключалась в том, чтобы создать настолько коротко живущий Gist, который GitHub успел бы обработать для отзыва секретов, прежде чем их могли бы скомпрометировать. Тем не менее, из-за большого количества созданных Gist'ов, аккаунт автора попал под теневой бан, что лишило его возможности видеть создаваемые публикации. К счастью, несмотря на это ограничение, процесс отзыва секретов продолжал успешно работать, что позволило автору безопасно удалять ключи без дополнительных рисков.
Цитата исследователя:
Облачные провайдеры недостаточно защищают клиентов от неправильных настроек, которые они сами провоцируют. Хотя клиент создает эти уязвимости, то, как спроектированы платформы, напрямую определяет, могут ли такие проблемы возникать вообще.
Вместо того чтобы брать на себя ответственность и внедрять безопасные настройки по умолчанию, большинство провайдеров полагаются на несколько предупреждений в документации, которые большинство пользователей никогда не прочитает. Это исследование показывает, что этого далеко недостаточно, а также подчеркивает возрастающий риск злоупотреблений в случае использования жестко закодированных секретов.
А завершим мы пост цитатой статьи о том, что такое "The Security at Scale Mindset":
- Начните с уязвимости, а не с цели.
- Работайте в обратном направлении, используя креативные источники данных.
- Должны присутствовать взаимосвязи, указывающие на целевой класс уязвимостей.
- Должна быть возможность поиска по этим данным в масштабах.
#secrets
