Как это происходит и как это предотвратить

Одна из худших ошибок, которые можно совершить в сфере безопасности приложений, - это публичное разглашение секретов. Это могут быть ключи API, учетные данные базы данных, токены служб или закрытые ключи для асимметричной криптографии, например RSA, используемого для GPG.

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

Почему это важно

Утечка секретов и учетных данных происходит чаще, чем можно было бы подумать. Я немного удивлен, что мы не часто видим это в новостных статьях, но, безусловно, есть некоторые взломы, которые могут быть прослежены до утечки секретов:

  • 2017: Uber выплатил 100 000 долларов хакерам, получившим личные данные 57 миллионов клиентов.
  • 2019: исследователи находят на GitHub более 200 000 уникальных секретов. Они описывают свою методологию и результаты в статье How Bad It Git? Описание утечки секрета в общедоступных репозиториях GitHub »
  • 2020: внутренний Gitlab Daimlers был открыт для публики (источник). Если в каком-либо из репозиториев были какие-либо учетные данные, теперь они также являются общедоступными. Поэтому Глубокая защита имеет смысл. Не храните свои секреты в репозитории, даже если репозиторий частный.

Как происходит утечка секретов

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

Добавление секретов в общедоступное хранилище - самая очевидная ошибка, которую можно совершить. Добавление секретов в сообщения журнала является более косвенным и не должно вызывать немедленных проблем. Однако он может допускать многоступенчатую атаку. По этой причине «глубокая защита» имеет смысл, и поэтому секреты не должны быть частью сообщений журнала. Даже не обязательно, чтобы злоумышленник имел прямой доступ к файлам журнала. Возможно, разработчик публично поделится частью журналов, чтобы исследовать проблему. Проблема в том, что люди не склонны считать журналы критически важной частью программного обеспечения.

Как предотвратить утечку секретов?

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

логирование

Либо вообще не регистрируйте переменные среды, либо ДЕЙСТВИТЕЛЬНО убедитесь, что внутри нет никаких секретов. Вы также можете занести в черный список шаблоны, как показал Джо Кробак в своем сообщении Семь передовых методов сохранения конфиденциальных данных из журналов.

Хранение секретов локально: Direnv

direnv - это расширение оболочки, которое заставляет вашу оболочку выполнять .envrc файл, если вы находитесь в папке или подпапке. Такой файл может выглядеть так:

export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfYEXAMPLEKEY
export AWS_DEFAULT_REGION=us-west-2

Убедитесь, что файл .envrc является частным, добавив его в файл .gitignore.

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

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

Хуки перед фиксацией

pre-commit - это приложение, которое помогает применять хуки git. Они выполняются перед добавлением кода в репозиторий git.

Вы можете убедиться, что в репозиторий не добавлены учетные данные или закрытые ключи AWS, создав следующий .pre-commit-config.yaml файл:

repos:
-   repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v3.2.0
    hooks:
    -   id: detect-aws-credentials
    -   id: detect-private-key
-   repo: [email protected]:Yelp/detect-secrets
    rev: v0.14.3
    hooks:
    -   id: detect-secrets
        args: ['--baseline', '.secrets.baseline']
        exclude: .*/tests/.*

Затем выполните pre-commit install, и все готово 🙂

Yelps detect-secrets пытается найти секреты в исходном коде, находя строки с высокой энтропией, а другие ищут общие форматы / строки файлов.

Есть много других интересных вещей, которые вы можете сделать с помощью предварительной фиксации.

Хранение секретов на стороне сервера: переменные среды

Существует множество решений для хранилищ секретов, в том числе от поставщиков хостинга исходного кода:

Хранение секретов на стороне сервера: хранилища

Передача секретов через переменные среды имеет два основных недостатка: (1) Каждый процесс может получить к ним доступ (2) Разработчикам может потребоваться регистрировать переменные среды и, таким образом, передавать секреты в журналы.

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

AWS SSM - очень распространенное решение. Вот как вы используете его с Python:

import boto3
def get_ssm_param(name: str) -> str:
    client = boto3.client("ssm")
    param = client.get_parameter(Name=name, WithDecryption=True)
    return param["Parameter"]["Value"]

Обнаружение секретов исходного хостинга

Большинство сервисов хостинга источников предлагают возможность проверить утечку секретов. GitLab называет это секретным обнаружением, GitHub называет это секретным сканированием, а GitGuardian предлагает секретное обнаружение и исправление.

Можно интегрировать Yelps secret-detection в конвейер CI. Для Python инструмент Bandit SAST также может быть интегрирован в конвейер CI. Он предлагает базовое обнаружение секретов. Просто помните: если конвейер CI выходит из строя из-за обнаруженного секрета, вы должны изменить этот секрет.

Тестирование прошлого

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

GitLeaks сканирует весь ваш репозиторий на предмет утечки секретов. Сюда входят учетные данные, которые были зафиксированы и удалены, но все еще находятся в истории фиксации.

Вот как вы устанавливаете его в Linux:

# You can also go to 
# https://github.com/zricethezav/gitleaks/releases
# and download the version you need in the browser
$ wget https://github.com/zricethezav/gitleaks/releases/download/v6.1.2/gitleaks-linux-amd64
$ mv gitleaks-linux-amd64 gitleaks
$ chmod +x gitleaks
$ sudo mv gitleaks /usr/local/bin/
$ cd your-repo
$ gitleaks --repo=. -v
INFO[2020-10-13T17:38:49+02:00] cloning... .
Enumerating objects: 115, done.
Counting objects: 100% (115/115), done.
Compressing objects: 100% (42/42), done.
Total 115 (delta 68), reused 115 (delta 68)
INFO[2020-10-13T17:38:49+02:00] No leaks detected. 29 commits scanned in 111 milliseconds 984 microseconds

Keyhacks - это проект, который показывает, действительны ли утекшие ключи и что злоумышленник может с ними сделать.

HaveIbeenPwned интересен для ваших личных аккаунтов. Вы можете зарегистрироваться и получите электронное письмо, если ваше письмо появится в утечке данных. Это происходит так часто 😱 По этой причине: Не используйте пароли повторно! Повторно используемый пароль - это утекший пароль!

Замечание о переменных окружения

Переменные среды далеко не пуленепробиваемые. Несколько вредоносных сторонних пакетов
просто отправляют имя хоста с переменными среды на сервер (источник).

Что дальше?

В этой серии статей о безопасности приложений (AppSec) мы уже объяснили некоторые приемы атакующих 😈, а также приемы защитников 😇:

И вот-вот это:

  • CSRF 😈
  • DOS 😈
  • Заполнение учетных данных 😈
  • Криптоджекинг 😈
  • Единый вход 😇
  • Двухфакторная аутентификация 😇
  • Резервные копии 😇
  • Шифрование диска 😇

Дайте мне знать, если вас интересуют другие статьи о AppSec / InfoSec!