Зачем обновлять код, если и так работает? Trail of Bits против ленивых программистов

Ошибки в криптографии редко остаются внутри одного проекта. Иногда одна «удобная» мелочь в популярной библиотеке запускает цепочку уязвимостей в сотнях и тысячах зависимостей, а дальше всё упирается в то, как разработчики реагируют на проблему.

Компания Trail of Bits опубликовала материал о двух популярных реализациях AES, JavaScript-библиотеке «aes-js» и Python-библиотеке «pyaes». Обе в API для AES-CTR подставляют вектор инициализации по умолчанию, если его не указали явно. Значение фиксированное, из-за чего пользователи легко приходят к повторному использованию одного и того же ключа и вектора инициализации. А это одна из самых опасных ошибок для CTR и ряда других режимов. При таком сценарии атакующий, имея два зашифрованных текста, может извлечь XOR исходных сообщений, а при наличии предсказуемых фрагментов данных — восстановить поток и раскрыть секреты.

Проблему усугубляет документация. В примерах с «pyaes» показан вызов CTR только с ключом, без генерации уникального вектора инициализации, поэтому разработчики, которые копируют пример, практически гарантированно повторяют одни и те же ключ и вектор инициализации. По оценкам авторов, эффект может затрагивать тысячи проектов, так как «aes-js» и «pyaes» широко разошлись по зависимостям.

Trail of Bits также указывает на сопутствующие риски. В библиотеках нет современных режимов вроде AES-GCM и AES-GCM-SIV, которые дают не только шифрование, но и контроль целостности. Для CTR это критично, так как шифротекст остаётся изменяемым, и незаметная подмена битов ведёт к предсказуемым изменениям в открытом тексте. Отдельно отмечены потенциальные утечки через побочные каналы из-за таблиц подстановки, а также проблемы с реализацией PKCS7, которые в связке с CBC могут открыть путь к атаке типа Padding Oracle. При этом «aes-js» не обновляли с 2018 года, «pyaes» — с 2017-го, а обращения по поводу фиксированного вектора инициализации, по словам авторов, не привели к изменениям.

На практике команда нашла уязвимые проекты, среди них оказался strongMan VPN Manager — веб-инструмент для управления инфраструктурой strongSwan. В strongMan приватные ключи в формате PKCS#8 и сертификаты хранились в SQLite и шифровались через «pyaes» в CTR с тем самым вектором инициализации по умолчанию.

Авторы описывают сценарий, при котором атакующий, получивший файл базы данных, способен восстановить поток шифрования по предсказуемым данным сертификатов и затем расшифровать приватные ключи. Это открывало путь к подмене личности владельца сертификата и атакам «человек посередине» в чужих VPN-сессиях.

Trail of Bits передала находку команде strongSwan в частном порядке. Сопровождающий strongMan Тобиас Бруннер быстро подготовил исправление, организовал ветку для обновления безопасности, согласовал изменения с авторами отчёта и добавил инструменты миграции, чтобы пользователи смогли перевести старые базы на новый формат.

В самом приложении заменили «pyaes» на библиотеку с современными режимами, перешли с CTR на GCM-SIV, добавили проверку тегов аутентификации и схему вывода ключей на уровне отдельных записей, чтобы исключить любые повторы. Для strongMan готовят отдельное уведомление о безопасности с описанием риска и принятых мер.