CAPEC-68 · Подрыв механизмов подписания кода

Сканер-ВСкаталог уязвимостей · v4.2

Главная Каталог Источники CWE CAPEC ATT&CK Меры защиты Продукты Вендоры Документация

← Вернуться к списку

CAPEC-68СтандартЧерновик

Абстракция: Стандарт

Статус: Черновик

Источник ↗

Подрыв механизмов подписания кода

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

Открыть в каталоге с фильтром CAPEC →

Связанные CWE

Продукт не реализует обязательный шаг криптографического алгоритма, в результате чего шифрование оказывается слабее, чем заявлен

Продукт использует алгоритм, формирующий дайджест (выходное значение), не соответствующий требованиям безопасности для хэш-функц�

Отсутствие неизменяемого корня доверия в аппаратных средствах приводит к возможности обхода защищённой загрузки или исполнения �

Связанные уязвимости

CVE-2026-36182Было обнаружено, что GNCC GP5 v7.1.76 использует слабый алгоритм хеширования для защиты корневого пароля, что, возможно, позволяет злоумышленникам получать учетные данные и привилегии корневых элементов посредством атаки брутальной силы.

CVE-2025-41652Устройства уязвимы для обхода аутентификации из-за недостатков в механизме авторизации. Неаутентифицированный удаленный злоумышленник может использовать эту слабость, выполняя атаки грубой силы, чтобы угадать действительные учетные данные или используя методы столкновения MD5 для создания хеш-ейстей аутентификации, потенциально компрометируя устройство.

CVE-2025-3938Уязвимость, связанная с отсутствием криптографического шага, в Tridium Niagara Framework на Windows, Linux, QNX, Tridium Niagara Enterprise Security на Windows, Linux, QNX позволяет проводить криптоанализ. Эта проблема затрагивает Niagara Framework: до версии 4.14.2, до версии 4.15.1, до версии 4.10.11; Niagara Enterprise Security: до версии 4.14.2, до версии 4.15.1, до версии 4.10.11. Tridium рекомендует обновиться до версий Niagara Framework и Enterprise Security 4.14.2u2, 4.15.u1 или 4.10u.11 [1]. Источники: - [1] https://www.honeywell.com/us/en/product-security#security-notices - [2] https://docs.niagara-community.com/category/tech_bull

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

CVE-2024-54143openwrt/asu — это сервер изображений по запросу для дистрибутивов на основе OpenWrt. Механизм хеширования запросов усекает хеши SHA-256 только до 12 символов. Это значительно снижает энтропию, что позволяет злоумышленнику создавать коллизии. Используя это, ранее созданное вредоносное изображение может быть предоставлено вместо законного, что позволяет злоумышленнику «отравить» кэш артефактов и доставлять скомпрометированные изображения ничего не подозревающим пользователям. Это можно комбинировать с другими атаками, такими как внедрение команд в Imagebuilder, которое позволяет злоумышленникам внедрять произвольные команды в процесс сборки, что приводит к созданию вредоносных образов прошивки, подписанных законным ключом сборки. Это было исправлено с помощью 920c8a1.

CVE-2020-37168Система электронной коммерции 1.0 содержит слабую уязвимость криптографической реализации, которая позволяет злоумышленникам грубо форсировать секретный ключ производства из 16-символьного, используемый для генерации платежной подписи. Злоумышленники могут извлекать данные платежной формы и подписи из запросов POST до конечной точки платежа, а затем использовать хэш-сравнение SHA1 для итеративного тестирования ключевых кандидатов до обнаружения правильного производственного ключа, позволяющего им подделывать действительные платежные подписи и манипулировать суммами транзакций.

CVE-2026-22863Deno - это время выполнения JavaScript, TypeScript и WebAssembly. До 2.6.0, node:crypto не завершает шифр. Уязвимость позволяет злоумышленнику иметь бесконечные шифрования. Это может привести к наивным попыткам грубого форсирования, а также к более утонченным атакам с целью узнать секреты сервера. Эта уязвимость фиксируется в 2.6.0.

CVE-2023-46233crypto-js - это библиотека JavaScript криптостандартов. До версии 4.2.0 crypto-js PBKDF2 в 1 000 раз слабее, чем изначально указано в 1993 году, и по меньшей мере в 1 300 000 раз слабее, чем текущий индустриальный стандарт. Это происходит потому, что она по умолчанию использует SHA1, криптографический хеш-алгоритм, который считается небезопасным как минимум с 2005 года, и по умолчанию использует одну единственную итерацию, значение 'strength' или 'difficulty', указанное как 1 000, когда это было указано в 1993 году. PBKDF2 полагается на количество итераций как противодействие атакам предобраза и коллизиям. Если использовать для защиты паролей, влияние высоко. Если использовать для генерации подписей, влияние высоко. Версия 4.2.0 содержит патч для этой проблемы. В качестве обходного пути настройте crypto-js на использование SHA256 с по меньшей мере 250 000 итерациями.

CVE-2023-46133CryptoES — это библиотека криптографических алгоритмов, совместимая с ES6 и TypeScript. До версии 2.1.0 CryptoES PBKDF2 в 1000 раз слабее, чем было указано изначально в 1993 году, и как минимум в 1 300 000 раз слабее, чем текущий отраслевой стандарт. Это связано с тем, что по умолчанию используется SHA1, криптографический хеш-алгоритм, который считается небезопасным как минимум с 2005 года, и по умолчанию используется одна итерация, значение «силы» или «сложности», указанное как 1000 в 1993 году. PBKDF2 полагается на количество итераций в качестве контрмеры против прообразов и коллизионных атак. При использовании для защиты паролей воздействие является высоким. При использовании для создания подписей воздействие является высоким. Версия 2.1.0 содержит исправление для этой проблемы. В качестве обходного решения настройте CryptoES для использования SHA256 как минимум с 250 000 итераций.

CVE-2026-4601Версий знака пакета до 11.1.1 уязвимы для пропуска криптографического шага через процесс KJUR.crypto.DSA.signWithMessageHash в реализации подписания DSA. Злоумышленник может восстановить закрытый ключ, заставив r или s быть нулевым, поэтому библиотека излучает недействительную подпись без повторных попыток, а затем решает для x из полученной подписи.

CVE-2024-48847Обнаружены уязвимости, связанные с обходом контрольной суммы MD5, использующие слабость в способе, которым зависимость приложения вычисляет или проверяет хеши контрольной суммы MD5. Затронутые продукты: ABB ASPECT - Enterprise v3.08.01; NEXUS Series v3.08.01; MATRIX Series v3.08.01.

CVE-2023-43635Ключ хранилища запечатан с помощью SHA1 PCR Решение для измеренной загрузки, реализованное в EVE OS, опирается на механизм блокировки PCR. Различные части системы обновляют различные значения PCR в TPM, что приводит к уникальному значению для каждой записи PCR. Эти PCR затем используются для запечатывания/распломбирования ключа из TPM, который используется для шифрования/дешифрования каталога “хранилища”. Этот каталог “хранилища” является наиболее чувствительным местом в системе, и поэтому его содержимое должно быть защищено. Этот механизм отмечен в документации Zededa как механизм “измеренной загрузки”, предназначенный для защиты указанного “хранилища”. Код, отвечающий за создание и получение ключа из TPM, предполагает, что PCR SHA256 используются для запечатывания/распломбирования ключа, и поэтому проверяется их наличие. Проблема здесь в том, что ключ запечатан не с помощью PCR SHA256, а с помощью PCR SHA1. Это приводит к нескольким проблемам: • Машины, у которых включены PCR SHA256, но отключены PCR SHA1, а также вообще не запечатывают свои ключи, что означает, что “хранилище” не защищено от злоумышленника. • SHA1 считается небезопасным и снижает уровень сложности, необходимый для распломбирования ключа на машинах, у которых включены PCR SHA1. Злоумышленник может очень легко получить содержимое “хранилища”, что фактически делает механизм “измеренной загрузки” бессмысленным.

CVE-2023-43630PCR14 отсутствует в списке PCR, которые запечатывают/распломбируют ключ “хранилища”, но из-за изменения, которое было реализовано в коммите “7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, исправление только этой проблемы не решит проблему неправильного измерения раздела конфигурации. Кроме того, ключ “хранилища” запечатывается/распломбируется с помощью SHA1 PCR вместо SHA256. Эта проблема была несколько смягчена благодаря всем функциям расширения PCR, обновляющим как значения SHA256, так и SHA1 для заданного идентификатора PCR. Однако из-за изменения, которое было реализовано в коммите “7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, это больше не относится к PCR14, так как код в “measurefs.go” явно обновляет только экземпляр SHA256 PCR14, что означает, что даже если бы PCR14 был добавлен в список PCR, запечатывающих/распломбирующих ключ “хранилища”, изменения в разделе конфигурации все равно не были бы измерены. Злоумышленник может изменить раздел конфигурации, не запуская измеренную загрузку, что может привести к тому, что злоумышленник получит полный контроль над устройством с полным доступом к содержимому зашифрованного “хранилища”.

CVE-2026-32129Soroban-poseidon предоставляет криптографические хеш-функции Poseidon и Poseidon2 для смарт-контрактов Soroban. Poseidon V1 (PoseidonSponge) принимает входы переменной длины без инъективной прокладки. Когда абонент обеспечивает меньше входов, чем скорость губки (inputs.len() < T - 1), неиспользованные позиции ставки неявно нулевой заполненной. Это позволяет тривиальные хеш-сталкивания: для любого входного вектора [m1 ..., mk] хеш, хеш (m1, mk], равного хэшу (m1, mk]), равно хэш (m1, ..., mk, 0]), потому что оба производят одинаковые состояния предварительной перестановки. Это влияет на любое использование PoseidonSponge или poseidon_hash, где количество входов меньше, чем T-1 (например, хеширование 1 входа с T=3). Poseidon2 (Poseidon2Sponge) не затрагивается.

CVE-2025-30147Besu Native 包含用于构建和打包以太坊客户端 Hyperledger Besu 使用的本机库的脚本和工具。Besu 24.7.1 至 25.2.2 版本（对应 besu-native 版本 0.9.0 至 1.2.1）对预编译的 ALTBN128_ADD (0x06)、ALTBN128_MUL (0x07) 和 ALTBN128_PAIRING (0x08) 存在潜在的共识错误。这些预编译最初使用不再维护且性能不足的库实现，后使用 gnark-crypto 的 bn254 实现重新实现 [1]。问题在于某些 EC 点可能被精心构造，虽然在正确的子群中，但不在曲线上，而 besu-native 的 gnark 实现依赖子群检查来执行点-曲线检查 [1]。当执行这些预编译时，Besu 可能给出错误结果并导致共识失败 [1]。受影响版本的 Besu 可以通过禁用 altbn128 的本地预编译实现来解决此问题，方法是在启动 Besu 时使用 --Xaltbn128-native-enabled=false 标志 [2]。来源: - [1] https://github.com/hyperledger/besu-native/security/advisories/GHSA-jcp8-gh74-97hq - [2] https://github.com/hyperledger/besu/blob/main/besu/src/main/java/org/hyperledger/besu/cli/options/NativeLibraryOptions.java#L31-L38