Как и зачем искать секреты при помощи пользовательских правил

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

1. Введение
2. Что такое секреты?
3. Проблемы безопасности в управлении секретами
4. Как пользовательские правила помогают искать секреты?
5. Проверка качества обнаружения секретов
   
   1. 5.1. Поиск секретов с помощью Gitleaks
   2. 5.2. Поиск секретов с помощью Gitleaks и пользовательских правил
6. Анализ результатов
7. Выводы

Введение

Как известно, любой программный продукт содержит конфиденциальную информацию. Сведения, которые открывают доступ к базам данных различным службам и ИТ-ресурсам компании, называют секретами. Они являются неотъемлемой частью приложений, защищая инфраструктуру от проникновения сторонних лиц и различных киберугроз.

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

Что такое секреты?

Начнём с того, что определим, что вообще такое «‎секреты». По сути, это любые конфиденциальные данные, используемые для аутентификации в системе. К секретам можно отнести:

• различные ключи — это секретная информация, используемая криптографическим алгоритмом при зашифровании / расшифровании сообщений и проверке цифровой подписи;
• токены — последовательности символов, несущие в себе зашифрованную информацию и позволяющие точно идентифицировать объект, а также определить уровень его привилегий;
• логины и пароли, например для доступа в базу данных;
• любые другие неразглашаемые учётные данные.

Рисунок 1. Пример ключа-секрета

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

Проблемы безопасности в управлении секретами

Хранение секретов в коде может стать серьёзным источником риска для проекта. Если секреты будут раскрыты, то злоумышленники легко могут получить доступ к учётным записям администраторов, исходному коду приложения или всей ИТ-инфраструктуре. Это может привести к утечке данных, нарушению конфиденциальности, а также к катастрофическим финансовым и репутационным убыткам для организации. Так, в 2023 году средний ущерб российских компаний из-за утечек данных составил 5,5 млн рублей.

Главные проблемы, с которыми можно столкнуться при управлении секретами, — это их компрометация и утечка данных. Приведём несколько причин возникновения рисков для безопасности:

• Разработчик случайно оставил в исходном коде или конфигурационных файлах конфиденциальные данные в открытом виде (пароли, ключи шифрования или доступы к базам данных). Эта ошибка даёт злоумышленникам простор для возможных атак.
• Специалисты компании по неосторожности поделились секретом в мессенджере или через личную электронную почту, открыв доступ к нему при возможном взломе аккаунтов.
• Секреты могут быть указаны в конфигурационных файлах Kubernetes, что может привести к компрометации.

Как пользовательские правила помогают искать секреты?

Теперь поговорим о том, что такое пользовательские (кастомные) правила и зачем они нужны.

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

Рисунок 2. Пример секрета, который сканер может пропустить из-за объявления переменной на русском

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

Зачастую правила пишутся на языке регулярных выражений RegExp. Некоторые инструменты предоставляют возможности расширения RegExp, такие как добавление слов-исключений или поиск в определённых файлах.

Проверка качества обнаружения секретов

Теперь давайте проведём поиск секретов без использования кастомных правил, а затем с их применением. В качестве тестового приложения возьмем репозиторий OWASP WrongSecrets в ветке «experiment-bed». В ней содержатся секреты, которые создаются реальными сервисами, поэтому данная ветка отлично подходит для тестирования инструментов по поиску секретов.

В качестве инструмента анализа выберем Gitleaks. Это сканер для поиска конфиденциальной информации в репозиториях Git. Он использует определённые шаблоны для обнаружения секретов и возможных уязвимостей.

Тест анализа репозитория с использованием данного инструмента сначала проведём без дополнительных настроек («из коробки»), а затем с применением пользовательских правил. В конце сравним оба метода и поделимся результатами в виде таблицы.

Поиск секретов с помощью Gitleaks

Установить Gitleaks можно несколькими способами:

1. Использовать Docker.
2. Собрать Gitleaks из исходников.
3. Скачать и установить с помощью пакетного менеджера.
4. Загрузить бинарники со страницы «Releases».

Рисунок 3. Пример сканирования репозитория с помощью Gitleaks

Данный каталог должен быть инициализирован как гит-директория. Проверяться будут только те уязвимости, которые были сохранены (закоммичены). Чтобы обойти это ограничение, можно использовать флаг «--no-git». Тогда не будет проводиться поиск секретов в истории репозитория. Но это и не требуется, поскольку нужно проверить качество настройки правил, а не утечку секретов в пределах коммитов. Однако именно этот режим является отличительной чертой данного инструмента, поскольку он может искать секреты не только в нынешнем коммите, но и во всей истории. Для выведения результатов будет использоваться флаг «-v», а для применения кастомных правил служит флаг «--config», или же «-c».

Поиск секретов с помощью Gitleaks и пользовательских правил

Для применения собственных правил необходимо создать файл формата TOML, описывающий пользовательский набор правил. Он может выглядеть следующим образом (рис. 4).

Рисунок 4. Пример пользовательской конфигурации правил

У каждого правила обязательно должны быть заполнены поля «id» (уникальный идентификатор правила) и «regex» (регулярное выражение, по которому будет происходить поиск секретов). О других настройках правил можно прочитать в официальном репозитории Gitleaks.

После установки программы и написания собственного набора правил запускаем инструмент. Чтобы запустить Gitleaks с предустановленным набором правил, нужно, находясь в директории, которая будет сканироваться, написать команду «gitleaks detect».

Рисунок 5. Сканирование директории с использованием пользовательских правил

Анализ результатов

Итак, давайте посмотрим результаты проверки Gitleaks без применения пользовательских правил, а затем — с ними. 

В результате самостоятельной проверки Gitleaks имеет 14 срабатываний в 13 типах секретов из 21. При подключении пользовательских правил срабатываний стало 49 в 16 типах из 21.

Среди новых срабатываний имеются дубликаты. Это происходит из-за того, что некоторые новые правила охватывают предустановленные правила Gitleaks. Тем самым достигается большая полнота охвата. Результаты сравнения по обнаруженным секретам приведены в таблице ниже.

Таблица 1. Сравнение анализа кода Gitleaks с применением кастомных правил и без них

Выводы

Количество утечек конфиденциальной информации в России продолжает расти, при этом обеспечение безопасности данных пользователей и особо важных систем является обязательным требованием государства. Для защиты цифровых продуктов от киберугроз компаниям необходимо выстроить грамотное управление ИТ-секретами.

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

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