ИИ нашёл критическую дыру в шифровании Cloudflare: один ключ открывал все данные
Аудиторская компания zkSecurity протестировала экспериментальную криптографическую библиотеку Cloudflare под названием CIRCL, задействовав собственный ИИ-пайплайн для поиска уязвимостей в коде. Итог этого эксперимента оказался показателен: семь реальных багов в системе шифрования, все уже устранены, а за большинство из них Cloudflare выплатила вознаграждения в рамках баунти-программы. Но главное здесь не количество ошибок, а характер одной из них и то, как именно искусственный интеллект повёл себя в процессе аудита.
Критический баг в схеме шифрования с политиками доступа
В CIRCL реализована схема шифрования с политиками доступа. Идея в том, чтобы не просто зашифровать данные на конкретный ключ, а задать условия, кому разрешено расшифровывать сообщение. Например, доступ дают только тем ключам, которые удовлетворяют политике вроде "сотрудник финансового отдела И офис в США". Это напоминает сложный замок, который должен открываться только при наличии сразу двух "правильных" ключей.
Ошибка заключалась в одной-единственной строке кода, но её последствия были катастрофическими. Логика сборки этого "криптографического замка" была нарушена: фактически система позволяла обойти требование "двух ключей". Первый из них оказывался достаточным, чтобы открыть доступ к данным в одиночку.
Проблему усугублял тот факт, что роль этого "первого ключа" выполняла служебная метка, присутствовавшая во всех выданных пользователям ключах без исключения. То есть каждый обладатель любого ключа мог расшифровать любое сообщение, независимо от установленной политики доступа. Формально схема оставалась политико-ориентированной, но по сути вся система разграничения прав не работала.
Cloudflare признала уязвимость критической: речь шла не о частной ошибке в редком сценарии, а о фундаментальном нарушении модели безопасности для всех, кто полагался на эту конкретную реализацию.
Как ИИ нашёл эту уязвимость
Главный дефект обнаружил специализированный ИИ-агент zkao - собственная разработка zkSecurity, ориентированная на анализ и аудит исходного кода. Этот агент не просто "подсветил странный фрагмент", а указал на реальное расхождение между задекларированной криптографической схемой и её фактическим поведением в библиотеке.
Остальные шесть обнаруженных багов были менее разрушительными по последствиям, но всё равно представляли интерес для безопасности. Пять из них нашёл Claude Opus 4.6 в сочетании с экспертной настройкой и подсказками команды zkSecurity, а ещё один баг был выявлен другой крупной языковой моделью следующего поколения.
При этом роль людей ни на секунду не исчезала: каждый отчёт от ИИ рассматривался специалистами, вручную проверялся на эксплуатируемость и только после этого оформлялся как подтверждённая уязвимость. Авторы подчёркивают: генерировать кандидаты на баги с помощью ИИ дешево, но доверять необработанным отчётам напрямую нельзя.
ИИ ошибается в оценке серьёзности багов
Интереснее всего повёл себя ИИ не на этапе поиска, а в момент оценки критичности найденных проблем. Модели регулярно промахивались в обе стороны.
В большинстве случаев ИИ завышал серьёзность своих находок - относил средние по риску уязвимости к уровню "высокий" или даже "критический". Это типичная защитная гиперосторожность: алгоритм предпочитает перестраховаться, чем пропустить что-то опасное.
Но был и обратный пример, куда более тревожный. Атака на агрегированные подписи BLS - инструмент, который активно обсуждается в контексте блокчейнов, распределённых систем и протоколов с высокой степенью отказоустойчивости, - была моделью оценена как проблема лишь среднего уровня. В действительности же такая уязвимость в зависимости от контекста способна привести к серьёзным последствиям, вплоть до подмены или фальсификации групповых подписей.
В zkSecurity сделали вывод: окончательная оценка серьёзности уязвимостей пока должна оставаться за людьми. Даже рейтинги Cloudflare, подчёркивают аудиторы, ориентированы прежде всего на влияние конкретных багов на собственные сервисы компании. А вот для сторонних проектов, использующих CIRCL, те же самые дефекты могут оказаться куда разрушительнее.
Нестабильность результатов в разных моделях
Ещё один обнаруженный эффект - существенная нестабильность звеньев ИИ-пайплайна при смене версий моделей.
В ходе первого прогона основной вклад в поиск багов вносил Claude Opus 4.6, тогда как модель следующего поколения использовалась в основном как "верификатор" - она перепроверяла уже найденные проблемы и помогала уточнять формулировки отчётов.
Через несколько недель zkSecurity повторила аудит той же библиотеки, но уже с участием обновлённых версий - Opus 4.7 и новой итерации конкурирующей модели. Роли неожиданно поменялись местами: теперь большинство новых находок приходилось на вторую модель, а Claude оказался в позиции проверяющего.
Отсюда родился практический вывод: не стоит "привязываться" к конкретному имени модели или бренду как к вечному лидеру. С выходом новых релизов распределение сильных и слабых сторон меняется, и то, что вчера было лучшим инструментом поиска, завтра может стать лишь вспомогательным.
Почему ошибка в одной строке так опасна
Криптографические библиотеки часто воспринимают как нечто монолитное и надёжное "по определению". Однако случай с CIRCL демонстрирует другую реальность: достаточно одной неверной строки кода, чтобы вся тщательно выстроенная модель безопасности рухнула.
Особенно это критично для схем с политиками доступа. Они именно поэтому и используются, что позволяют точно определять, какой группе пользователей разрешён доступ к шифротексту. Когда внутренняя реализация подменяет "логическое И" на неявное "ИЛИ" (или вообще на "доступ для всех"), проблема не всегда очевидна тестам поверхностного уровня.
В отличие от классических багов, которые приводят к сбоям и крашам, подобные дефекты могут тихо жить годами, не вызывая заметных ошибок в работе сервисов. Но при этом любой злоумышленник, знающий о слабом месте, получает возможность аккуратно и незаметно читать чужие данные.
ИИ как новый инструмент аудита безопасности
История с CIRCL - хороший пример того, как ИИ может работать в связке с людьми в области информационной безопасности.
Во-первых, машины хорошо справляются с рутинным и масштабным просмотром исходников. Там, где человеку нужно много часов или дней, модель способна прогнать тысячи строк кода за минуты, выделив потенциально подозрительные места: несоответствия между документацией и реализацией, аномальные паттерны использования криптопримитивов, странные условия, "магические значения", небезопасные операции с памятью.
Во-вторых, ИИ уже сегодня пригоден как генератор гипотез: он не всегда правильно оценивает риск, но часто способен предложить неожиданную интерпретацию поведения алгоритма или подсказать нетривиальный путь атаки. Для опытной команды безопасности это ценно - специалисту остаётся проверить логическую цепочку и смоделировать практическую эксплуатацию.
Однако ключевая мысль остаётся прежней: без человека в цикле такие системы превращаются в источники либо ложных тревог, либо, что ещё хуже, опасного чувства ложной защищённости.
Ограничения и риски использования ИИ в кибербезопасности
Наряду с преимуществами, у ИИ в этой сфере есть и серьёзные ограничения.
Модели обучаются на огромных корпусах кода и текстов и нередко унаследуют устаревшие, неидеальные или компромиссные практики. Это может приводить к тому, что ИИ считает "нормальными" решения, от которых профессионалы по безопасности давно отказались.
Ещё одна проблема - объяснимость. Даже когда ИИ находит реальную дыру, его пояснения могут быть расплывчатыми, неполными или внутренне противоречивыми. Специалисту приходится не просто проверять сам факт наличия уязвимости, но и разбираться, насколько адекватно модель описала вектор атаки.
Наконец, есть риск неправильного восприятия результатов: руководители и заказчики могут начать переоценивать возможности ИИ как "волшебной палочки", способной разом закрыть все вопросы по аудиту. Случай с некорректной оценкой критичности для BLS-подписей ясно показывает, насколько опасным может быть такое упрощённое отношение.
Как может выглядеть идеальный ИИ-пайплайн аудита
Опыт zkSecurity позволяет очертить контуры более зрелого подхода к внедрению ИИ в аудит безопасности:
- использовать несколько разных моделей одновременно, чтобы минимизировать слепые зоны каждой из них;
- периодически перепроверять те же проекты по мере выхода новых версий моделей - как показала практика, состав "лидера" по качеству поиска быстро меняется;
- явно разделять роли: одни модели отвечают за первичный поиск аномалий, другие - за уточнение, третьи - за генерацию тестов и PoC-эксплойтов;
- все решения о критичности, приоритете исправления и раскрытии уязвимостей оставлять за людьми с опытом в криптографии и прикладной безопасности.
Такой гибридный подход позволяет извлечь максимум пользы из ИИ, не теряя при этом контроля над ключевыми решениями.
Что это значит для разработчиков и компаний
Для разработчиков криптобиблиотек и сервисов, работающих с конфиденциальными данными, эта история - напоминание, что даже тщательно продуманная архитектура не гарантирует безопасности реализации. Стоит:
- регулярно проводить сторонние аудиты, в том числе с использованием ИИ-инструментов;
- уделять особое внимание схемам с политиками доступа и сложным условиям, где логические ошибки особенно коварны;
- отслеживать обновления используемых библиотек и внимательно изучать списки исправленных уязвимостей - критический баг может прятаться именно в "обновлении безопасности".
Бизнесу и руководителям ИБ-инфраструктуры стоит учитывать ещё один момент: внедрение ИИ в процессы аудита меняет экономику безопасности. Стоимость первичного сканирования кода падает, но требования к квалификации специалистов, которые должны разбираться с результатами, наоборот, растут.
Будущее: ИИ как стандартный участник процессов безопасности
Случай с CIRCL и Cloudflare показывает, что ИИ уже перестал быть чисто экспериментальным инструментом. Он становится полноценным участником процессов обеспечения безопасности, пусть и в роли помощника, а не автономного эксперта.
По мере роста сложности криптографических протоколов и количества кода, отвечающего за защиту данных, человеческих ресурсов для тотального ручного анализа будет становиться всё меньше. Инструменты, подобные zkao и другим ИИ-агентам, постепенно станут стандартом: они будут постоянно мониторить репозитории, отслеживать изменения, анализировать патчи и сигнализировать о потенциально опасных правках ещё до того, как они попадут в продакшн.
Но самый важный вывод остаётся прежним: нельзя перекладывать ответственность за безопасность на модели. Они полезны ровно настолько, насколько интегрированы в продуманный процесс, где ключевые решения принимают специалисты, а ИИ остаётся мощной, но всё же вспомогательной частью системы.
