How Secrets Leak in CI/CD Pipelines

Truffle Security, небезызвестные своими способностями отлавливать секреты, решили осветить вопросы их утечки в пайпланах:
https://trufflesecurity.com/blog/secrets-leak-in-ci-cd/

Тема поднималась уже не раз, но давайте систематизируем затронутые сценарии:

1. Раскрытие секретов в логах CI/CD. Сценарии, когда из-за особенностей синтаксиса заданий платформы CI/CD, хранения секретов в формате JSON или использования кодировок в духе base-64 секреты "проходят мимо" систем маскирования и становятся доступными в лог-файлах CI/CD после отработки соответствующих заданий;

2. Утечка секретов второго порядка. Сценарии, когда "утекают" секреты используемые для доступа к зашифрованным файлам репозиториев или к API хранилищ секретов (Hashicorp Vault, etc.);

3. Публикация артефактов в публичных репозиториях. Сценарии, когда ошибочно допущенная команда (например, npm publish) публикует в репозитории файл конфигурации с секретами в открытом виде.

Как защититься от этих сценариев?

Помимо стандартных рекомендаций и следований принципам "наименьших привилегий" и "уменьшения поверхности атаки" вот кое-что еще :

1. Один из вариантов, предлагаемых Truffle Security, это натравить truflehog на логи CI/CD (в частности в Circle CI)

2. Использовать стандартные workflow вместо кастомных. Например, автор приводит в пример CircleCI "orbs", pre-built задания, которые из коробки безопасно работают с секретами. Подобное есть и у GitHub Actions.

Если вы хотите потренироваться и разобрать в том числе другие сценарии, то можно использовать специальные обучающие инструменты для освоения материала. Например, проект OWASP WorngSecrets, который предлагает 35 упражнений, снабженных подсказками и ликбезами по разным сценариям безопасной работы с секретами (включая K8s и облачных провайдеров). WrongSecrets отлично дополнит программы повышения осведомленности разработчиков, локальные CTF и поможет выращиванию security champions. WrongSecrets может быть запущен как локально в docker, так и онлайн - на платформах herokuapp.com и fly.dev .

#Dev #Ops #Secrets

Binary secret scanning helped us prevent (what might have been) the worst supply chain attack you can imagine

Если история с CrowdStrike – это реализовавшаяся катастрофа в цепочке поставок, то команде JFrog удалось предотвратить атаку, которая потенциально могла бы быть еще более ужасающей. В своей статье команда JFrog Security Research рассказывает, как в одном из публичных репозиториев Docker Hub был обнаружен легаси GitHub токен с админ-правами от репозиториев таких проектов, как python, pypa, psf и pypi. Обладатель данного токена теоретически мог бы скрыть вредоносный код в CPython, который является репозиторием некоторых основных библиотек, составляющих ядро языка программирования Python и скомпилированных из кода на C. Из-за популярности Python, вставка вредоносного кода, который в конечном итоге попадет в дистрибутивы Python, могла бы означать распространение бэкдора на десятки миллионов машин по всему миру.

Токен был найден в бинарном файле .pyc. Как это произошло?

1) Автор добавил авторизационный токен в исходный код.

2) Запустил исходный код (Python-скрипт), который был скомпилирован в бинарный файл .pyc с авторизационным токеном.

3) Удалил авторизационный токен из исходного кода, но не очистил .pyc.

4) Загрузил как очищенный исходный код, так и неочищенный бинарный файл .pyc в Docker-образ.

Какие выводы делают авторы статьи?

- В бинарных файлах тоже могут быть секреты, которые надо искать (отсылка на решение от JFrog).
- Убедитесь, что вы не используете старые GitHub токены (которые были заменены на новые, более безопасные, в 2021 году).
- Предоставляйте доступ к токенам с наименьшими правами.

Отчет об инциденте от самих PyPi можно найти здесь.

#secrets #supplychain

Phantom Secrets: Undetected Secrets Expose Major Corporations

Недавно мы затронули тему появления секретов в неожиданных местах, таких как бинарные файлы. Сегодня мы обсудим обнаружение секретов в удаленных ветках публичных репозиториев. В статье от Aqua исследователи рассказали, как они обнаружили около 18% пропущенных секретов в 50 000 публичных репозиториях, используя команду git clone --mirror вместо стандартного git clone. Авторы подробно объясняют разницу между выполнением этих двух команд и углубляются в нюансы кэширования на платформах управления исходным кодом (SCM).

Почему же ветки на самом деле не удаляются и извлекаются через git clone —mirror?

Если коротко, то удаленные ветки в Git не удаляются полностью, так как они могут быть полезны для восстановления данных или истории изменений. Это связано с тем, что Git, по своему замыслу, должен сохранять максимальную доступность и возможность восстановления данных даже после их удаления на локальном уровне. Когда вы удаляете локальную ветку, удаленные ветки могут оставаться в виде "висячих" ссылок на удаленном репозитории. Эти ссылки могут быть извлечены при использовании команды git clone --mirror, так как она клонирует все ссылки, включая те, которые были удалены локально. У этого явления даже есть оспариваемая CVE-2022-24975 (GitBleed).

Вывод достаточно простой: секрет, который однажды попал в репозиторий, можно считать автоматически скомпрометированным. Для многих использование данного подхода не будет чем-то новым. Соответственно, используйте функции защиты от случайных коммитов (push protection) от ваших SCM и pre-commit хуки, чтобы избегать появления секретов в репозиториях. Если это всё же произошло, то, согласно статье, техподдержка может помочь. Кстати, вслед за статьей Gitleaks и TruffleHog добавили поддержку сканирования через --mirror. Также советуем почитать рекомендации от GitHub - "Best practices for preventing data leaks in your organization".

А как эту проблему решаете Вы?

#secrets

Secrets and Shadows: Leveraging Big Data for Vulnerability Discovery at Scale

Помните, когда 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