Стартап Calif Research из Пало-Альто опубликовал демо WeWorm — первого zero-click червя, который распространяется через входящие звонки WeChat на iOS и Android. Жертва не берёт трубку. Жертва вообще не касается телефона. Эксплойт всё равно срабатывает. Команда нашла уязвимость и написала первый RCE-эксплойт (удалённое выполнение кода) примерно за два дня работы с AI, ещё неделя ушла на сам червь.

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

Как работает атака, которую не нужно принимать

Zero-click означает ровно то, что написано: ноль действий со стороны жертвы. Уязвимость живёт в обработчике входящего звонка WeChat — в коде, который запускается ещё до того, как пользователь видит экран вызова.

Calif нашла баг в слое обработки медиа (memory-corruption, то есть повреждение памяти). Именно там, где приложение разбирает аудио- или видеопоток до любого пользовательского взаимодействия. Атакующий звонит — устройство обрабатывает служебные пакеты — происходит переполнение буфера или use-after-free — выполняется произвольный код. Если жертва всё же берёт трубку, она слышит тишину. Эксплойт к этому моменту уже отработал.

Червь распространяется дальше: получив контроль над устройством, он звонит контактам из адресной книги. Цепочка самовоспроизводится без участия человека.

Что AI сделал за два дня

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

Конкретно это выглядело примерно так:

  1. Статический анализ кода WeChat — LLM просматривал декомпилированный или реверс-инжинированный код в поисках паттернов небезопасной работы с памятью.
  2. Генерация фаззинг-кейсов — модель предлагала входные данные, которые с высокой вероятностью триггерят граничные условия в парсере медиапакетов.
  3. Написание PoC-эксплойта — после того как баг был локализован, AI помог написать первый работающий proof-of-concept под конкретную архитектуру.
  4. Итерация по обходу защит — ASLR, stack canaries и прочие митигации (механизмы защиты) обходились итеративно: модель предлагала варианты, исследователи проверяли.

Именно итерационная скорость — главное, что дал AI. Цикл «гипотеза → тест → результат» сжался с часов до минут.

Что проверить в своём приложении прямо сейчас

Если ваше приложение принимает любые входящие данные до действия пользователя — push-уведомления, звонки, сообщения в фоне — поверхность атаки есть. Вот минимальный чеклист.

Проверьте обработку медиа и бинарных протоколов. Нативные библиотеки для аудио/видео (особенно форки libvpx, opus, ffmpeg) исторически богаты memory-corruption багами. Убедитесь, что используете актуальные версии.

bash
# Проверить версию встроенного ffmpeg в Android-проекте
grep -r "ffmpeg" ./app/build.gradle --include="*.gradle"
grep -r "libvpx\|libopus\|libwebrtc" ./app/src/main/jni/

Включите все доступные компиляторные защиты. Для Android NDK:

plain
# CMakeLists.txt
target_compile_options(your_lib PRIVATE
  -fstack-protector-strong
  -D_FORTIFY_SOURCE=2
  -fsanitize=address   # только для debug/CI-сборок
)
target_link_options(your_lib PRIVATE
  -Wl,-z,relro
  -Wl,-z,now
)

Запустите фаззинг на парсерах входящих данных. AFL++ или libFuzzer покрывают большинство сценариев. Точка входа — любая функция, которая принимает внешние байты до аутентификации пользователя.

bash
# Пример запуска libFuzzer для изолированного парсера
clang++ -fsanitize=fuzzer,address -o fuzz_parser fuzz_parser.cpp parser.cpp
./fuzz_parser -max_len=65536 -jobs=4 corpus/

Изолируйте обработку медиа в отдельный процесс. На Android это android:process в манифесте плюс минимальные разрешения через android:isolatedProcess="true". Если эксплойт сработает в изолированном процессе, он не получит доступ к контактам и хранилищу.

plain
<!-- AndroidManifest.xml -->
<service
    android:name=".MediaProcessingService"
    android:isolatedProcess="true"
    android:permission="android.permission.BIND_JOB_SERVICE" />

Где это ломается — подводные камни

Изоляция процессов не панацея. Ядерные эксплойты (privilege escalation) позволяют выбраться из изолированного процесса. WeWorm, судя по описанию, работает именно так — сначала RCE в контексте WeChat, потом расширение привилегий.

Фаззинг не найдёт логические баги. Он хорош для memory-corruption, но пропустит уязвимости в бизнес-логике или криптографии. Нужен ручной code review критических путей.

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

AI-ускорение работает в обе стороны. То, что Calif сделал за два дня, завтра сделает менее квалифицированный атакующий за четыре. Временной буфер между раскрытием уязвимости и массовой эксплуатацией сокращается.

Что попробовать дальше

Запустите OSS-Fuzz на открытых компонентах своего стека — Google бесплатно фаззит библиотеки с открытым кодом. Посмотрите на Semgrep с правилами для C/C++ memory-safety — он ловит паттерны небезопасного использования памяти на уровне статического анализа в CI. Если используете WebRTC или любой медиастек в нативном коде, изучите Memory-safe media processing — Google постепенно переписывает критические части Chromium на Rust именно из-за таких атак.

FAQ

Что такое zero-click атака и чем она опаснее обычной?

Zero-click не требует никаких действий от жертвы — ни перехода по ссылке, ни открытия файла. Уязвимость эксплуатируется в момент получения данных приложением, до любого взаимодействия с пользователем. Это делает социальную инженерию ненужной и защиту через «не кликай на подозрительное» — бесполезной.

WeWorm уже используется в реальных атаках?

Calif Research опубликовала демо в исследовательских целях. На момент публикации это proof-of-concept, а не инструмент в открытом доступе. Tencent (разработчик WeChat) должен был получить уведомление по стандартной процедуре ответственного раскрытия.

Как AI помогает находить такие уязвимости быстрее?

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

Что делать, если мой стек использует нативные медиабиблиотеки?

Первый шаг — аудит версий: убедитесь, что libvpx, opus, ffmpeg и WebRTC обновлены до последних стабильных релизов. Второй — изоляция: вынесите обработку медиа в отдельный процесс с минимальными привилегиями. Третий — фаззинг парсеров входящих данных в CI.

Применимо ли это к iOS так же, как к Android?

Да. Calif подтвердила работу WeWorm на обеих платформах. iOS ограничивает изоляцию процессов сильнее, но уязвимость в нативном коде WeChat работает независимо от ОС — приложение запускает один и тот же медиастек на обеих платформах.

Источники