A02:2021-Сбои в криптографии

Обзор

Переместился на одну позицию выше и занял второе место, ранее известный как утечка чувствительных данных, который был скорее общим симптомом, чем основной причиной. Основное внимание уделяется сбоям, связанным с криптографией (или ее отсутствием). Это часто приводит к утечке чувствительных данных. Известные CWE: CWE-259: Использование жестко закодированного пароля, CWE-327: Сломанный или рискованный криптографический алгоритм и CWE-331 Недостаточная энтропия.

Описание

Первое, что нужно сделать, это определить потребности в защите данных при передаче и в состоянии покоя. Например, пароли, номера кредитных карт, медицинские записи, личная информация и коммерческая тайна требуют дополнительной защиты. Главным образом, если эти данные подпадают под действие законов о конфиденциальности, например, Общего регламента ЕС по защите данных (GDPR), или правил, например, защиты финансовых данных, таких как Стандарт безопасности данных индустрии платежных карт (PCI DSS). Для всех таких данных:

• Передаются ли какие-либо данные открытым текстом? Это касается таких протоколов, как HTTP, SMTP, FTP, также использующих обновления TLS, такие как STARTTLS. Внешний интернет-трафик опасен. Проверьте весь внутренний трафик, например, между подсистемами балансировки нагрузки, веб-серверами или внутренними системами.
• Используются ли какие-либо старые или слабые криптографические алгоритмы или протоколы по умолчанию или в более старом коде?
• Используются ли крипто-ключи по умолчанию, сгенерированы или повторно использованы слабые крипто-ключи, или отсутствует надлежащее управление ключами или их ротация? Проверяются ли крипто-ключи в репозиториях исходного кода?
• Не применяется ли шифрование, например, какие-либо директивы безопасности HTTP-заголовков (браузера) или недостающие заголовки?
• Правильно ли проверен полученный сертификат сервера и цепочка доверия?
• Игнорируются ли векторы инициализации? Используются ли они повторно или сгенерированы недостаточно безопасно для криптографического режима работы? Используется ли небезопасный режим работы, такой как ECB? Используется ли шифрование, когда аутентифицированное шифрование более подходит?
• Используются ли пароли как криптографические ключи при отсутствии функции получения базового ключа пароля?
• Используется ли случайность в криптографических целях, которые не были разработаны для удовлетворения криптографических требований? Даже если выбрана правильная функция, нужно ли ее заполнять разработчиком? А если нет, переписал ли разработчик встроенную в нее мощную начальную функциональность, которой не хватает достаточной энтропии/непредсказуемости?
• Используются ли устаревшие хеш-функции, такие как MD5 или SHA1? Или используются некриптографические хеш-функции, когда требуются криптографические?
• Используются ли устаревшие методы криптографического заполнения, такие как PCS № 1 v5?
• Можно ли использовать сообщения о криптографических ошибках или информацию о побочных каналах, например, в форме «padding oracle attacks»?

См. раздел Криптография ASV (V7), Защита данных (V9) и SSL/TLS (V10).

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

Сделайте как минимум следующее:

• Классифицируйте данные, обрабатываемые, хранимые или передаваемые приложением. Определите, какие данные являются конфиденциальными в соответствии с законами о конфиденциальности, нормативными требованиями или потребностями бизнеса.
• Не храните конфиденциальные данные без необходимости. Откажитесь от него как можно скорее или используйте маркировку, соответствующую стандарту PCI DSS, или даже усечение. Данные, которые не сохраняются, невозможно украсть.
• Убедитесь, что все конфиденциальные данные зашифрованы в состоянии покоя.
• Убедитесь в наличии современных и надежных стандартных алгоритмов, протоколов и ключей; используйте надлежащее управление ключами.
• Шифруйте все передаваемые данные с помощью безопасных протоколов, таких как TLS с шифрами прямой секретности (FS), приоритизацией шифрования сервером и параметрами безопасности. Применяйте шифрование с помощью директив, таких как HTTP Strict Transport Security (HSTS).
• Отключите кэширование ответов, содержащих конфиденциальные данные.
• Применяйте необходимые меры безопасности в соответствии с классификацией данных.
• Не используйте устаревшие протоколы, такие как FTP и SMTP, для передачи конфиденциальных данных.
• Храните пароли с использованием сильных адаптивных и соль (salt) функций хэширования с коэффициентом работы (коэффициентом задержки), таким как Argon2, scrypt, bcrypt или PBKDF
• Векторы инициализации должны быть выбраны в соответствии с режимом работы. Для многих режимов это означает использование CSPRNG (криптографически защищенный генератор псевдослучайных чисел). Для режимов, которые требуют одноразовый код, вектор инициализации (IV) не нуждается в CSPRNG. Во всех случаях IV никогда не следует использовать дважды для фиксированного ключа.
• Всегда используйте аутентифицированное шифрование вместо простого.
• Ключи должны генерироваться криптографически случайным образом и храниться в памяти в виде массивов байтов. Если используете пароль, то он должен быть преобразован в ключ с помощью соответствующей функции получения ключа на основе пароля.
• Убедитесь, что криптографическая случайность используется там, где это уместно, и что она не была засеяна предсказуемым образом или с низкой энтропией. Большинство современных API-интерфейсов не требуют, чтобы разработчик заполнял CSPRNG для обеспечения безопасности.
• Избегайте устаревших криптографических функций и схем заполнения, таких как MD5, SHA1, PKCS номер 1 v5.
• Самостоятельно проверьте эффективность конфигурации и настроек.

Примеры сценариев атак

Сценарий № 1: Приложение шифрует номера кредитных карт в базе данных с помощью автоматического шифрования базы данных. Однако эти данные автоматически расшифровываются при извлечении, что позволяет использовать ошибку SQL-инъекции для извлечения номеров кредитных карт в виде открытого текста.

Сценарий № 2: Сайт не использует или не применяет протокол TLS для всех страниц или поддерживает слабое шифрование. Злоумышленник отслеживает сетевой трафик (например, в небезопасной беспроводной сети), понижает уровень подключений с HTTPS до HTTP, перехватывает запросы и крадет файл cookie сеанса пользователя. Затем злоумышленник воспроизводит этот файл cookie и захватывает сеанс пользователя (прошедшего проверку подлинности), получая доступ или изменяя личные данные пользователя. Вместо вышеперечисленного они могли бы изменить все передаваемые данные, например, получателя денежного перевода.

Сценарий № 3: База данных паролей использует несоленые (без salt) или простые хэши для хранения паролей всех пользователей. Ошибка при загрузке файла позволяет злоумышленнику получить базу данных паролей. Все несоленые хэши могут быть представлены с помощью радужной таблицы предварительно рассчитанных хэшей. Хэши, созданные простыми или быстрыми хэш-функциями, можно взломать с помощью графических процессоров, даже если они были засолены.