Ваш код не ваш, если разработчику не нравится ваша страна

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

Специалист ИБ из YADRO опубликовал статью с разбором нескольких хрестоматийных примеров. Самый известный — библиотека node-ipc, которая добавила в свои зависимости модуль "peacenotwar". При установке он проверял IP-адрес через геосервисы, и, если пользователь находился в России или Беларуси, заменял все файлы на диске на «символы мира» (сердечки). Причем код был обфусцирован, а вредоносная логика пряталась в хуках postinstall. Еще один случай — colors.js и faker.js. Тогда мейнтейнер внес бесконечный цикл с не-ASCII символами, который блокировал event loop Node.js, вызывая отказ в обслуживании. А es5-ext, который используется в webpack, получал проверку времени и локали. Если системное совпадало с российскими часовыми поясами или локаль была ru_RU, то запускалась 100% загрузка CPU в бесконечном цикле.

Технически protestware может прятаться где угодно. В коде времени исполнения, в хуках жизненного цикла npm, в скриптах сборки или даже в тестах. Активируется он тоже по-разному: геолокация по IP, системная локаль, часовой пояс, переменные окружения, hostname или просто дата и время. То есть злоумышленник может настроить бомбу так, чтобы она взорвалась только у конкретной компании или в конкретной стране.

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

Бороться с этим, к сожалению, нелегко. Автор предлагает композиционный анализ (SCA) и формирование SBOM, чтобы знать все зависимости, статический анализ кода на поиск конструкций, связанных с геолокацией (geoip, country, locale), удалением данных (rm -rf, delete, wipe) или выполнением внешних команд, динамический анализ в изолированной среде, мониторинг изменений в репозиториях (смена мейнтейнеров или необычно крупные коммиты перед релизом). Если подозрительный пакет обнаружен — изолировать его, заблокировать скомпрометированную версию и откатить к более ранней. В идеале — создать форк и сопровождать его самостоятельно.

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

@antiinfosec