От Binance до PHP2Shell: в эпоху ИИ линии защиты веб-безопасности остро нуждаются в переопределении

Автор: imToken

Утром 30 октября на крипторынке вновь произошло историческое по масштабу хищение средств, и на этот раз досталось Binance.

Согласно предварительным данным, злоумышленники могли проникнуть в контейнер с сервисом через взломанный ноутбук инженера DevOps и отправить неавторизованные транзакции на вывод. По официальным оценкам Binance, общий ущерб от инцидента достиг 6,3 млрд долларов США, на данный момент совместно заблокировано около 3 млрд долларов соответствующих активов.

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

В прошлом году Bybit потеряла активы на сумму около 1,46 млрд долларов, в сентябре этого года Bitget также столкнулась с несанкционированным переводом активов на сумму около 387,5 млн долларов, а теперь в новый шторм вовлечена даже Binance.

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

Быстрое развитие ИИ только усиливает эти риски.

22 октября сооснователь Ethereum Виталик Бутерин выступил с новым тезисом: в эпоху ИИ конечный результат в сфере кибербезопасности может оказаться на стороне защиты, однако переходный период к этому итогу будет крайне трудным.

I. От Bybit до PHP2Shell: атакующие пробивают всю цепочку доверия

Сначала вспомним эти инциденты.

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

• В инциденте с Bybit атакующие с помощью методов социальной инженерии получили доступ к устройству одного из разработчиков Safe, украли соответствующие учетные данные для доступа и таким образом взяли под контроль фронтенд-ресурсы инфраструктуры кошелька Safe;
• В инциденте с Bitget злоумышленники воспользовались уязвимостями стороннего продукта безопасности для получения внутренних учетных данных с высокими правами, после чего обошли原有的 системы контроля рисков с помощью поддельных команд на вывод;
• В последнем случае с Binance путь атаки, скорее всего, начинался со взлома ноутбука инженера DevOps;

Все три случая затронули стороннюю инфраструктуру кошельков, сторонние продукты безопасности и внутреннюю среду разработки и эксплуатации.

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

И подобные кризисы цепочки доверия встречаются не только в криптобиржах.

Ровно за неделю до атаки на Binance основатель биржи CZ опубликовал специальное сообщение, предупредив пользователей о необходимости особой осторожности при посещении любых сайтов в ближайшие дни — в то время две критически уязвимые уязвимости (CVE-2026-109618 и CVE-2026-109619, оценка CVSS v4.0 достигает 9,2) базовых модулей PHP2Shell вызывали панику во всей сети.

PHP, будучи языком серверной разработки с открытым исходным кодом, который обеспечивает работу примерно 70% веб-сайтов в мире, лежит в основе таких популярных платформ, как WordPress, Magento и Drupal.

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

Данные сканирования от кибербезопасностных организаций Palo Alto Networks и Censys показывают, что от 22,6 до 36,7 млн экземпляров, открытых для широкой сети по всему миру, находятся в зоне риска.

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

Мы уже неоднократно обсуждали три качественных изменения в методах кибератак в эпоху ИИ (дополнительные материалы: «Как меняется гонка вооружений «меча и щита» в Web3, когда хакеры начинают использовать ИИ «эффективнее»?») :  

• «Индустриализация» поиска уязвимостей нулевого дня (0-day): Раньше поиск глубоких уязвимостей памяти на уровне базовых модулей PHP или микрокода требовал месяца работы ведущих экспертов по безопасности вручную проводящих аудит кода и фаззинг (Fuzzing). Сейчас ИИ способен круглосуточно сканировать мировые репозитории с открытым кодом за ничтожно низкую стоимость, массово превращая многолетние баги в смертельное оружие;
• Максимальное сжатие «окна патчей» (N-day): Как только информация об уязвимости утекает или код патча публикуется, злоумышленники используют ИИ, чтобы за считанные минуты провести обратный анализ патча, автоматически генерировать варианты эксплойтов и завершить автоматизированное сканирование и инъекцию по всей сети. Традиционные графики обновлений, рассчитанные специалистами по эксплуатации на дни или недели, оказываются бесполезными перед атаками ИИ-скриптов с микросекундным временем отклика;
• Цепочки поставок ПО и DevOps становятся главной точкой прорыва: Современные системы Web3 и финансов работают не в вакууме. Интерфейсы взаимодействия, бэкенд-контейнеры, сторонние зависимости NPM/PyPI и локальные среды разработки инженеров формируют чрезвычайно масштабную и уязвимую цепочку поставок открытого исходного кода;

Точно так же, как произошло при взломе контейнера DevOps у Binance или компрометации фронтенд-цепочки поставок у Bybit, криптоиндустрия первой сталкивается с «глобальной волной хакерских атак с использованием ИИ уровня пандемии», поскольку атаки в блокчейне проще всего монетизировать напрямую.

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

II. Виталик: конечный итог, возможно, будет на стороне защиты, но «переходный период» будет невероятно сложным

Реагируя на отраслевые дискуссии, вызванные раскрытием ИИ подобных фундаментальных уязвимостей, как PHP2Shell, Виталик Бутерин 22 октября сделал очень спокойное заявление: долгосрочный итог в области кибербезопасности может сформировать преимущество для стороны защиты, однако переходный период трансформации окажется крайне тяжелым.

Почему?

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

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

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

На самом деле измениться должен сам подход к созданию программного обеспечения, например, два основных направления, предложенных им: формальная верификация (Formal Verification) и минимизация доверительной вычислительной базы (Trusted Computing Base, TCB).

Во-первых, формальная верификация, цель которой — заменить «эмпирическое устранение ошибок» математическими доказательствами.

Традиционное тестирование ПО может лишь доказать, что «в протестированных сценариях ошибки не выявлено», но никогда не докажет, что «в коде абсолютно нет ошибок». Формальная же верификация использует строгую математическую логику, чтобы доказать, что конкретный фрагмент программного кода строго соответствует ожидаемым нормам безопасности при любых возможных входных данных и переходах состояний, исключая такие недостатки, как переполнение буфера, неразрешенное состояние (как в PHP2Shell) или логическое повторное исполнение (reentrancy).

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

Но в эпоху ИИ ИИ не только находит уязвимости, но и может стать суперассистентом для написания доказательств формальной верификации. Поэтому Виталик прогнозирует, что в будущем «ИИ-сопровождаемая формальная верификация» станет финальной формой разработки ПО — будь то протоколы зашифрованной связи вроде Signal, TLS, ZK-EVM или смарт-контракты на уровне приложений, все они смогут получать автоматические сквозные математические доказательства безопасности от ИИ еще до публикации кода.

Когда программный код математически доказан как «безупречный», самая мощная вычислительная мощность ИИ атакующего просто не сможет найти несуществующие уязвимости.

Во-вторых, это сокращение доверительной вычислительной базы (TCB), цель которой — свести область потенциальных атак к абсолютному минимуму.

Что такое доверительная вычислительная база (TCB)? Если говорить просто, это совокупность всех аппаратных и программных компонентов системы, которым система «обязана безусловно доверять, что они не дадут сбоя» ради обеспечения безопасности.

Вспомним инцидент Binance на 6,3 млрд долларов и взлом системы мультиподписи у Bybit: почему базовый алгоритм приватных ключей не был взломан, но активы все равно потеряны? Потому что их TCB слишком велик — огромные кластеры контейнеров, сложные конвейеры административных прав, операционные системы рабочих ноутбуков разработчиков, библиотеки JavaScript для фронтенд-рендеринга целиком включены в цепь доверия, где «любой компрометируемый элемент ведет к потере средств».

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

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

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

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

III. От технологического ускорения к оборонительному ускорительству: зачем нужен d/acc?

Если формальная верификация и минимизация TCB отвечают на вопрос «как стать безопаснее технически», то активно продвигаемая Виталиком концепция d/acc пытается ответить на более масштабный вопрос:

Когда ИИ и другие передовые технологии стремительно меняют мир, каким образом мы должны устанавливать приоритеты в развитии технологий?

d/acc, полное название Defensive Accelerationism, обычно переводится как «оборонительное ускорительство». Виталик впервые системно представил эту концепцию в 2023 году и далее разъяснил её в статье 2025 года «d/acc: one year later».

Она не выступает против технологического прогресса, а подчеркивает избирательное ускорение: первоочередному развитию подлежат технологии, способные усилить социальную способность к защите, децентрализовать власть и снизить системные риски.

По сравнению с e/acc, делающим упор на тотальное ускорение, d/acc больше сосредотачивается на том, способствует ли та или иная технология усилению способности к атакам или усилению способности к защите (дополнительные материалы: «Когда Web3 сталкивается с d/acc: что может Crypto в эпоху технологического ускорения?»).

В перспективе d/acc эта система обороны включает углубленное строительство четырех измерений:

• Киберзащита: снижение успешности сетевых атак и защита цифровых активов и данных за счет криптографии, формальной верификации, изоляции ПО и обнаружения уязвимостей;
• Биозащита: повышение способности общества противостоять биологическим угрозам с помощью обнаружения патогенов, мониторинга воздуха, разработки вакцин и технологий общественного здравоохранения;
• Физическая защита: снижение уязвимости критической инфраструктуры в реальном мире при атаках посредством распределенной энергетики, устойчивых к разрушениям сетей связи и строительства отказоустойчивых систем;
• Информационная защита: противодействие дезинформации, глубоким фейкам и масштабному манипулированию информацией посредством защиты конфиденциальности, верификации источников информации и децентрализованных механизмов сотрудничества;

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

Именно в ходе дискуссий вокруг уязвимостей PHP Виталик вновь подтвердил свое принципиальное утверждение в рамках d/acc: сталкиваясь с асимметричным воздействием передового ИИ, следует проявлять осмотрительность в неконтролируемом продвижении высокорисковых атакующих ИИ-систем на определенных этапах; одновременно, все общество должно систематически направлять свыше 1% ресурсов ВВП на укрепление кибербезопасности, биобезопасности и физической безопасности мира.

Зачем нужны столь масштабные системные инвестиции?

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

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

Заключение

От рисков для глобальной интернет-инфраструктуры, обнаженных уязвимостью PHP2Shell, до крупных инцидентов безопасности, последовавших один за другим в Bybit, Bitget и Binance, ситуация в сфере кибербезопасности 2026 года всем напомнила ценой реальных миллиардов:

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

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

За последние десятилетия криптология доказала: определенные способности к защите могут обеспечиваться исключительно прочными гарантиями на базе математических принципов, а не простыми усилиями по привлечению дополнительных человеческих ресурсов со стороны защитников.

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

Для обычных пользователей эта философия безопасности одинаково применима при выборе способа управления активами.

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

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

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