При разработке софтверного продукта или облачного SaaS-сервиса достаточно трудно отслеживать сторонние активности всех специалистов, вовлеченных в процесс разработки. Достаточно открыть Github, ввести в поиске «<имя_домена_компании.com> pass» и оценить выдачу. В том случае, если вдруг Github действительно показывает в своей выдаче что-то интересное, то мы рассмотрим сценарии, которые могут помочь злоумышленникам нарушить бизнес-процесс твоей компании. А если Github все же молчит, то рассмотрим альтернативные варианты атаки на цикл разработки продукта, при которых точкой входа в инфраструктуру могут стать не только разработчики, но даже Security-инженеры. Github scrapping При правильных поисковых запросах, можно найти всевозможные фрагменты кода, содержащие учетные данные для подключения к инфраструктуре компании, которые используются разработчиками и QA-инженерами. При этом не только Github можно исследовать на наличие секретов. Техника изучения публичных репозиториев на наличие секретов (данных учетных записей, приватны ключей и т.п.) позволяет открыть доступ к интересным местам приложения еще до того, как начнется его непосредственный анализ защищенности. Если учесть тот факт, что многие продуктовые IT-компании совершенно разного уровня зрелости (от стартапа до enterprise-бизнеса) привлекают к своему циклу разработки различных подрядчиков, то растет вероятность утечки ценных данных в публичные репозитории. Любой эксперт, вовлеченный в цикл разработки, несет с собой определенные риски для продукта. Так, например, в процессе поиска фрагментов исходного кода, содержащих домен SaaS-продукта, могут быть найдены фрагменты авто-тестов, содержащих привилегированные учетные данные для подключения к платформе. И чтобы убедиться, что этот пример не гипотетический, а вполне реальный, достаточно зайти на Techcrunch, найти имя какой-нибудь компании, предоставляющей SaaS-продукт и поискать ее домен на гитхабе. Открываем новости о стартапах, видим много блокчейн-кошельков и блокчейн-платформ, выбираем любой стартап с причудливым названием и ищем его домен на гитхабе. Встречаем много секретов в разных скриптах для подключения к платформе.
Поиск в Github по нужным запросам открывает много интересных скриптов с секретами
Чаще всего секреты встречаются в следующих репозиториях:
код авто-тесты, которые QA-инженеры бэкапят в свои персональные публичные репозитории;
репозитории организаций-подрядчиков, отвечающих за интеграцию клиентов с продуктом;
персональные репозитории разработчиков, которые бэкапят свои внутренние тулзы;
скрипты установки продукта и skeleton-файлы микросервисов, используемые подрядчиками, отвечающими за установку и поддержку продукта (operations).
Пример секрета, оставленного в коде: приватный ключ для подключения к SaaS-платформе
Пример секретов, которые помогут злоумышленнику скомпрометировать продукт или его пользователя:
учетные данные для подключения (пример поисковых запросов: «product_name+pass», «domain_name+login»);
приватные ключи и сертификаты (пример поискового запроса: «domain_name+private»).
Секреты Security-инженеров Кто-то из Security-специалистов сейчас воскликнул: «А вот если бы разработчики использовали Hashicorp Vault, то этих проблем бы не было!». Да, при определенных условиях, подобные решения для secret management эффективны. Однако иногда, даже security-специалисты совершают ошибки. Возьмем топ коммерческих решения для статического анализа кода на предмет уязвимостей (SAST). Среди этого топа наверняка встретятся большие и дорогие продукты, представляющие собой полноценную платформу для интеграции в CI/CD-процессы разработки и имеющие API для сторонних скриптов автоматизации. SonarQube – пример платформы анализа качества и безопасности кода. О ее популярности говорит количество инсталляций, которое можно найти в Shodan одним запросом: port:9000 sonarqube
География доступных инсталляций платформы SonarQube
Количество инсталляций SonarQube по странам
Если поискать на Github какие-либо секреты, относящиеся к SonarQube, то можно найти небольшие скрипты, использующиеся для подключения и управления сканированием.
Скрипты, которые (возможно) содержат секреты для подключения к платформе
Если заглянуть в официальную документацию SonarQube, то можно найти описание формата запуска задач из CLI. В частности, один из ключей отвечает за передачу данных об учетной записи, от имени которой будет выполняться команда.
Ключи, отвечающие за передачу данных об учетной записи в платформе
Используя эту информацию, можно получить более релевантные результаты поиска. Поисковые запросы, содержащие “sonar+login” или “sonar+password”, позволяют найти скрипты автоматизации, которые используются не только разработчиками, но и непосредственно security-командами.
Прочитали документацию, составили новый запрос, получили более релевантную выдачу
Автоматизация поиска секретов Можно искать утечку секретов в официальном репозитории компании, а можно в неофициальных репозиториях ее сотрудников или подрядчиков (а может и пользователей). Процесс поиска секретов на Github или в других репозиториях можно проиллюстрировать следующим образом:
Процесс поиска секретов
Для автоматизации этих действий существует множество утилит и скриптов, поэтому рекомендуется не изобретать велосипед. К примеру, можно взять следующие тулзы:
gitGrabber (https://github.com/hisxo/gitGraber) – позволяет в реальном-времени мониторить Github и прочие сервисы на предмет появления секретов. Подходит для задачи мониторинга появления секретов по заданные поисковые запросы.
gitLeaks (https://github.com/zricethezav/gitleaks) – тулза для мониторинга конкретно заданных репозиториев на утечку секретов. Отлично подходит для выполнения задач мониторинга официального репозитория компании.
Используя эти утилиты вместе с релевантными для своих целей запросами, позволит организовать систему мониторинга утечек секретов в публичные репозитории. При этом, как верно заметили AppSec-коллеги в комментариях твитту, чтобы секрет оставался секретом, нужно внедрять и использовать secret-management решения. Например, Hashicorp Vault, которому здесь посвящен отдельный материал.
Обращаем внимание, что все материалы в этом блоге представляют личное мнение их авторов. Редакция SecurityLab.ru не несет ответственности за точность, полноту и достоверность опубликованных данных. Вся информация предоставлена «как есть» и может не соответствовать официальной позиции компании.
Хочешь поговорить с хакерами, профессорами и разработчиками не в чатике, а глаза в глаза?
Приезжай на Positive Hack Days Fest* 22–24 мая в Москве — здесь кибербез выходит в офлайн.