Всем привет! Меня зовут Руслан, я инженер в отделе развития процессов безопасности в YADRO. В прошлой статье я рассказывал о рисках транзитивных зависимостей в open source: один неблагонадежный пакет во всей цепочке  — и продуктовая сборка скомпрометирована. Таким пакетом может быть protestware — это вид ПО или библиотек, в которые разработчики (мейнтейнеры) намеренно внедряют деструктивный, изменяющий логику работы или политизированный код. Он так же опасен, как уязвимости в зависимостях, компрометации репозиториев и атаки класса Dependency Confusion.

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

Ниже разберемся, как эта функциональность попадает в инфраструктуру и open source, как ее обнаружить и какие меры предпринять, чтобы защитить свой проект.

Чем protestware угрожает проекту

Начнем с главного: protestware — это не «идейный» баннер или сообщения, которые всплывают на экране и раздражают пользователей (хотя и это неприятно). Код злоумышленников может заблокировать работу всего приложения, а заодно:

• повредить или удалить данные;

• саботировать бизнес-процессы;

• ограничить работу пользователей из определенных регионов;

• распространить несогласованные сообщения.

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

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

Размещение и триггеры 

В protestware вредоносная логика может размещаться:

• в коде времени исполнения — активируется при вызове функции;

• хуках жизненного цикла npm — запускаются при установке пакета;

• скриптах сборки;

• тестах (тест-скриптах);

• метаданных пакета (загрузка из package.json и динамическое получение инструкций с удаленного сервера).

А вот что запускает активацию:

• геолокация по IP: запросы к ipinfo.io, ip-api.com, geoip-базы;

• системная локаль, часовой пояс, язык клавиатуры;

• переменные окружения: process.env.USER, process.env.HOME, NODE_ENV, внедренные CI-переменные типа GITLAB_CI;

• hostname, домен сети, username OS;

• дата и время.

Многие организации рассматривают protestware как риск, который может затронуть только отдельные страны и категории пользователей. На самом деле серьезные последствия могут быть для продукта в целом — например, это отказ критических сервисов, нарушение работы CI/CD-конвейеров, повреждение или удаление данных, остановка бизнес-процессов, в том числе нарушение SLA. Сюда же репутационные потери и дополнительные затраты на расследование инцидента и восстановление систем.

Если хотите проектировать и разрабатывать телеком-решения, ждем вас в нашей команде. Сейчас ищем:

— инженера по тестированию на проникновение;
— инженера по сетевой безопасности;
— инженера по внедрению и обслуживанию СЗИ.

Все открытые вакансии можно посмотреть на карьерном сайте.

Как protestware попадает в контур разработки

Распространенный сценарий — обновление уже используемого пакета. Новая версия одной из транзитивных зависимостей может автоматически попасть в сборку через механизмы управления пакетами — npm, pip, get, а в результате вредоносный код окажется внутри без участия разработчиков. То же самое может произойти во время обновления или установки инструментов разработки (плагинов, линтеров) и инструментов для CI/CD-конвейеров.

В Open Source protestware может попасть при компрометации аккаунта мейнтейнера проекта: получив доступ к репозиторию или реестру пакетов, злоумышленник может опубликовать новую версию библиотеки с вредоносным кодом. Еще вариант — успешная атака Dependency Confusion: злоумышленник публикует пакет с именем, совпадающим с названием внутренней зависимости. При определенных настройках менеджера пакетов или репозитория зависимостей система может предпочесть внешний пакет внутреннему — тогда код будет взят из непроверенного источника.

Как обнаружить

По этим действиям можно заподозрить, что вредоносный компонент попал в ваш продукт:

• Подозрительные проверки географического расположения пользователя. Если вы видите такие проверки в коде, это еще не доказывает, что вы столкнулись с protestware, но вам точно нужен дополнительный анализ.

• Необъяснимые сетевые запросы: обращения к неизвестным API, геолокационным сервисам или внешним ресурсам, не связанным с функциональностью библиотеки. Здесь тоже нужен анализ.

• Неожиданные операции с файловой системой. Любые операции удаления или модификации пользовательских данных должны соответствовать назначению компонента.

• Обфускация кода. Для большинства библиотек обфусцированный код можно рассматривать как дополнительный фактор риска.

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

Вот некоторые из них:

• Анализ используемого open source (OSA). Предварительный анализ open source, который планируется использовать в продукте, позволяет снизить возможные риски для продукта. Так, можно проверить, что выбранного open source нет в списках «токсичных» репозиториев на github. Авторы таких репозиториев могут быть хактивистами.

• Композиционный анализ (SCA) и формирование Software Bill of Materials (SBOM). Позволяют получить полный перечень компонентов, входящих в состав программного продукта, провести анализ состава зависимостей, отслеживать новые версии компонентов, выявлять известные вредоносные пакеты и анализировать возможные риски цепочки поставок.

• Статический анализ исходного кода. Поиск конструкций, связанных с геолокацией или региональными настройками (например, geoip, country, locale, ip-api), удалением данных (например, rm -rf, delete, destroy, wipe, overwrite), выполнением внешних команд или динамической загрузкой кода. Ориентирован на типичные признаки protestware и помогает определить участки, где нужен глубокий анализ.

• Динамический анализ. Контроль файловой активности, создаваемых сетевых соединений и процессов, обращений к системным ресурсам. Во время динамического анализа приложения рекомендуется запускать в изолированной среде (контейнерах, виртуальных машинах, специализированных sandbox-решениях) — один этот шаг уже снижает риск проникновения protestware. 

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

Что делать, если обнаружили

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

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

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

Что потом? Если компонент критически важен, можно создать форк и сопровождать его в дальнейшем. Для такого подхода потребуются дополнительные ресурсы, зато вы будете меньше зависеть от внешних участников проекта. Если такой вариант не подходит, можно задуматься о полной замене компонента с protestware.

Как защитить проект от угрозы

Эти действия помогут защитить ваш продукт от protestware: 

• Принципы Zero Trust для зависимостей. Подтверждайте происхождение и безопасность любого внешнего компонента независимо от его популярности и репутации.

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

• Контроль версий. Старайтесь использовать фиксированные версии зависимостей — это снизит вероятность неожиданных изменений во время сборки.

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

• Подписание артефактов. Это поможет подтвердить происхождение программных компонентов и усложнит распространение поддельных пакетов.

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

Выстраивая процессы защиты, рекомендую ориентироваться на такие документы и фреймворки:

• NIST Secure Software Development Framework (SSDF) — описывает набор практик безопасной разработки, включая управление зависимостями, контроль происхождения компонентов, защиту процесса сборки и управление уязвимостями.

• SLSA (Supply-chain Levels for Software Artifacts) — предлагает модель зрелости безопасности цепочки поставок и позволяет постепенно повышать уровень доверия к процессам разработки и сборки программного обеспечения. Ключевые направления: защита конвейера сборки, контроль происхождения артефактов, воспроизведение сборки и криптографическая верификация компонентов.

• OpenSSF (Open Source Security Foundation) — объединяет крупнейших участников open source-сообщества и разрабатывает рекомендации по повышению безопасности программного обеспечения. Фреймворк OpenSSF Scorecard оценивает практики безопасности репозитория: Code Review, подпись коммитов, защиту веток и так далее.

Очевидно, что популярность проекта, количество звезд в репозитории или размер сообщества — не гарантии безопасности. Чтобы защититься от protestware и других угроз на цепочку поставок программного обеспечения, контролировать нужно весь сторонний код, независимо от его известности и происхождения. Причем подход должен быть комплексным: анализ open source, композиционный, статический и динамический анализ, контроль происхождения артефактов, организационные меры по управлению зависимостями. 

Несложно проследить, что вредоносная функциональность может появляться в доверенных open source компонентах, которые используются разными компаниями в разных странах. Это еще одно напоминание о том, как сильно безопасность современного ПО связана с используемыми зависимостями.