Утечка секретов: Один шаг к разгадкеsaster

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

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

МОЙ БОГ! Я поместил свои ключи доступа к облаку в общедоступный репозиторий.

Жестко закодированные секреты в исходном коде или файлах конфигурации инструментов DevOps может оказаться в плохих руках. Если секрет commitЕсли вы находитесь в репозитории общедоступных источников, вы наверняка обречены. Но даже частные репозитории небезопасны, поскольку секреты также просачиваются через двоичные файлы приложений, журналы или украденный исходный код.

Оглядываясь назад, это тревожно как часто простая оплошность приводила к серьезному нарушению безопасности. Просто погуглите»Утечка ключей AWS»,«Утечка токена доступа GitHub", и так далее. Не воспринимайте эти примеры как скрытые рекомендации для того или иного поставщика. Используй свой собственный !

Например, (не)знаменитый Атака кодеков от апреля 2021 года стало возможным, поскольку образ Codecov Docker содержал учетные данные git, которые позволяли злоумышленнику получить доступ к частным репозиториям git Codecov и добавить одну строку в скрипт загрузки bash Codecov для переменных среды сбора и URL-адресов репозитория git.

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

Проблема в том, что жестко закодированные секреты — обычное дело. В марте 2022 года Lapsus$ APT слито 189 ГБ исходного кода Samsung и других конфиденциальных файлов. Анализ показал, что в нем содержится некоторое количество 6,600 жестко закодированных секретов: 90 % для внутренних систем и 10 % для внешних сервисов и инструментов, таких как GitHub, AWS или Google. Эти секреты включали ключи API AWS/Twilio/Google, строки подключения к базе данных и другую конфиденциальную информацию. Это самое современное состояние в большинстве баз кода.

Утечка секретов — самый простой путь к атакам на цепочку поставок

Зависимости пакетов в настоящее время являются наиболее частой, хотя и не единственной целью атак в цепочке поставок. Злоумышленники могут создать новый пакет, который в конечном итоге будет установлен в программное обеспечение жертвы (используя Typosquatting и другие методы), но обычно они пытаются заразить существующий пакет либо путем добавления изменений в исходный код в репозиториях программного обеспечения (SCM), таких как GitHub, GitLab или BitBucket, или путем добавления вредоносных версий в публичные реестры, такие как NPM, PyPI, RubyGems, Maven Central.

Но внедрение вредоносного кода или вредоносной зависимости, скрытой в сложном графе зависимостей, требует login учетные данные, такие как имя пользователя/пароль, токены или ключи доступа (назовем их «ключи(для краткости) для целевого исходного репозитория или общедоступного реестра соответственно. 

Плохие парни иногда получают ключи через социальная инженерия,  нападение на event-stream популярный пакет NPM представляет собой хороший пример. Но в поисках утечки login учетные данные или ключи доступа — наиболее частый метод атаки для атак на цепочку поставок программного обеспечения.

Репозитории исходного кода и реестры пакетов — две важные системы сборки программного обеспечения. pipeline. Но в DevOps есть много инструментов: CI/CD системы, инструменты для запуска тестов, настройки и автоматизации предоставления или развертывания и выпуска. Все они могут быть использованы для внедрения вредоносного кода в программное обеспечение. Утечка действительных ключей для этих инструментов приводит непосредственно к несчастью и мучениям. Представьте себе утечку ключей доступа root с полным контролем над вашими общедоступными облачными ресурсами…

Обычные рекомендации

Мы не говорим здесь ничего нового, вы все это знаете. Но действуйте! Помните, что боты регулярно сканируют все публичные SCM репозитории. Некоторые рекомендации, в произвольном порядке.

• Если вы отвечаете за управление ИТ-безопасностью, определить, как следует обращаться с секретами в политике безопасности. Но политики эффективны лишь настолько, насколько эффективно их соблюдение: убедитесь, что в вашей организации соблюдаются рекомендации по обращению с секретами, включая не только ваши команды DevOps, но и ваших поставщиков программного обеспечения, и что план реагирования на инциденты вашей организации содержит положения на случай утечки секретов.
• Внедрить и обеспечить соблюдение многофакторная аутентификация (MFA, 2FA или любая другая аббревиатура). И никаких ухудшений безопасности: USB-ключ безопасности стоит тех нескольких долларов, которые он стоит. Вам нужно ввести любой из тысяч ваших учетных данных (легко), а затем напиться и оставить ключи в баре с чем-то, связанным с вами (шансы немного меньше, особенно если вы трезвенник).
• Используйте менеджер паролей с надежным несохраненным паролем. Для обработки секретов в системах используйте Секретные хранилища. CI/CD системы, поставщики облачных услуг, SCMs и другие инструменты DevOps предоставляют эту услугу, но вы можете выбрать универсальное решение Secret Vault.
• предпочитать недолговечны токены к долгоживущим ключам доступа. Их легче отменить и открыть более ограниченное окно для зла.
• Ограничить повторное использование учетных данных: злоумышленники будут повторно использовать собранные учетные данные цели в других системах, что является еще одним моментом для использования менеджера паролей. Менеджеры паролей и секретные хранилища должны оставить повторное использование учетных данных в прошлом.
• Ограничивайте и контролируйте использование и пароли. Они достаточно сильны, чтобы заслуживать особого внимания.
• Осуществлять сильное хеширование и шифрование. Вернемся к USB (криптографическим) ключам, строгим процедурам передачи учетных данных партнерам и коллегам и так далее.
• Использовать сканер секретов, например, запустить в pre-commit крючок во избежание утечек в системах контроля версий, в качестве ворот безопасности. Прежде чем дело здесь важно. В качестве альтернативы используйте post-hoc сканирование для обнаружения утечки секретов, например, как проверку перед pull request объединяет. Примечание: наша платформа Xygeni включает сканер секретов, позволяющий использовать оба режима работы. 
• Ручной вариант использования обзоры кода поиск жестко закодированных секретов требует более высоких затрат и работает послеcommit (но, будем надеяться, по крайней мере, до того, как секрет станет доступен посторонним). Но обзоры могут обнаружить нетрадиционные секреты, которые могут ускользнуть от сканеров секретов.       
• Избегайте случайно commitпередача общих файлов с секретами для контроля версий с помощью соответствующих исключить шаблоны (например, шаблон `gitignore`), принимая во внимание такие файлы, как .env, .npmrc, .pypirc, временные файлы… Действительно, дополнительный уровень безопасности.
• И последнее в этом длинном списке: позвольте облачным провайдерам выполнять сканирование на предмет утечек своих ключей, если таковые имеются. По крайней мере, это май сообщит вам об утечке, когда она произошла, но безопасность является обязательным условием для поставщиков облачных услуг. Этот ретроспективном секретное сканирование не очень прозрачно в отношении того, где и как часто оно выполняется, и часто требует явной настройки, но, безусловно, является последним ресурсом, когда все остальное терпит неудачу.

МОЙ БОГ! Я отправил свои ключи доступа к облаку в общедоступный репозиторий, возьмите № 2.

Это может случиться с лучшими из нас. Засучи рукава !

Немедленно обновите/отзовите/отключите раскрытый секрет! Если на счете приличный MFA, риск намного ниже. Это может быть сложнее, например, с закрытыми ключами на веб-сайтах (вам необходимо выдать новый сертификат для нового закрытого ключа и отозвать существующий), но современные инструменты позволяют быстро обновить учетные данные или отозвать токены. 

Выполните действия, рекомендованные провайдером, если они доступны, например AWS в этом примере.

Определите причину утечки. Знание того, как это произошло, имеет важное значение для раскрытия, анализа, сдерживания и извлечения уроков.

Затем сообщите об утечке пострадавшим сторонам, объяснив действия, которые вы предпринимаете для устранения утечки и уменьшения ущерба. Невозможно исправить нанесенный ущерб, то, что было слито, слито. Будьте прозрачны и информируйте других, чтобы они могли принять меры. 

Затем начните с судебно-медицинская экспертиза,  окно экспозиции — это время между утечкой и моментом, когда секрет оказался недействителен. Будьте готовы читать журналы и отслеживать необычную активность с затронутой учетной записью в течение этого периода. Удалите учетные записи и ключи, созданные с использованием затронутой учетной записи. Напоминаем, что если затронутая учетная запись имеет права администратора, исправить ситуацию гораздо сложнее. 

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

Если вы любите приключения и хотите сами увидеть, сколько времени понадобится ботам, чтобы обнаружить утечку секрета, воспользуйтесь такими натяжками, как Канарские жетоны позвольте вам поэкспериментировать. Помните, что боты заносят в черный список настройки по умолчанию. canarytokens.org домен…