Масштабная кампания вредоносных пакетов в репозиториях npm, PyPI и Crates.io вновь привлекла внимание к рабочим станциям разработчиков после того, как исследователи заявили, что атака была нацелена на рабочие процессы разработчиков и файлы, используемые помощниками по кодированию на базе ИИ.
Исследователи из Socket сообщили, что кампания, которую они отслеживают как TrapDoor, «охватывает более 34 вредоносных пакетов и 384+ связанных версий и артефактов» в трех экосистемах с открытым исходным кодом.
По данным Socket, пакеты были разработаны для кражи секретов разработчиков, включая учетные данные AWS, токены GitHub, SSH-ключи, данные браузера, переменные среды, криптокошельки и локальные файлы конфигурации разработки.
Полученные результаты указывают на более серьезную проблему, чем просто очередной инцидент с вредоносным пакетом. Среды разработки все чаще оказываются на пересечении исходного кода, облачной инфраструктуры, конвейеров CI/CD, инструментов кодирования на базе ИИ и привилегированных учетных данных. Таким образом, компрометация одной рабочей станции может дать злоумышленникам плацдарм за пределами машины разработчика.
Пакеты использовали точки выполнения, распространенные в обычных рабочих процессах разработки программного обеспечения. В npm вредоносное ПО использовало скрипты postinstall. В PyPI оно применяло выполнение во время импорта для получения и запуска удаленного JavaScript. В Crates.io злоупотребляли скриптами сборки Rust, которые выполняются во время компиляции. Это затрудняет обнаружение кампании с помощью средств контроля, ориентированных на один язык программирования или реестр пакетов.
Похоже, TrapDoor также отражает растущий интерес злоумышленников к средам разработки с поддержкой ИИ. Socket сообщила, что кампания пыталась изменить файлы, используемые инструментами кодирования на базе ИИ, включая .cursorrules и CLAUDE.md, с помощью скрытых инструкций Unicode.
Очевидная стратегия заключалась в том, чтобы обманом заставить ИИ-помощников выполнять рабочие процессы, похожие на сканирование безопасности, которые могли бы привести к обнаружению и эксфильтрации секретов.
Аналитики отмечают, что именно использование обычных механизмов разработки делает эту кампанию сложной для рассмотрения как обычный инцидент с вредоносным ПО.
«TrapDoor представляет собой сдвиг от оппортунистического злоупотребления пакетами к компрометации сред разработчиков на уровне рабочих процессов», — заявила Сакши Гровер, старший менеджер по исследованиям в IDC Asia Pacific Cybersecurity Services. «Предыдущие кампании обычно размещали вредоносный пакет, крали учетные данные при установке и двигались дальше. TrapDoor спроектирована вокруг всего рабочего процесса разработчика, а это означает, что атака выходит далеко за рамки реестра пакетов».
Гровер отметила, что кросс-реестровая структура кампании затрудняет ее обнаружение при просмотре одного экосистемы, поскольку вредоносные пакеты использовали нормальные механизмы выполнения npm, PyPI и Crates.io. Более серьезное беспокойство, по ее словам, вызывает то, что происходит после установки, когда вредоносное ПО пытается закрепиться на машине разработчика и потенциально использовать украденные SSH-ключи для проникновения глубже в инженерные системы.
«Одна скомпрометированная рабочая станция может незаметно стать точкой входа в конвейеры CI/CD и инфраструктуру сборки», — сказала Гровер. «Это не кража учетных данных. Это операция по первичному доступу».
Санчит Вир Гогиа, главный аналитик Greyhound Research, отметил, что кампания примечательна тем, что демонстрирует глубокое понимание того, как создается современное ПО.
«Она не останавливается на краже учетных данных из одной отравленной зависимости», — сказал Гогиа. «Она нацелена на более широкую рабочую среду разработчика: менеджеры пакетов, помощники по кодированию на базе ИИ, Git hooks, профили оболочки, отношения доверия SSH, сеансы браузера, облачные учетные данные, пути CI/CD и локальные артефакты рабочего процесса, которые разработчики и машины все чаще рассматривают как легитимный контекст».
Стратегии смягчения последствий
Гогиа заявил, что проблема теперь заключается не только в безопасности конечных точек, но и в контроле над системами и рабочими процессами, которые производят корпоративное ПО.
«Среды разработчиков должны рассматриваться как инфраструктура, смежная с производственной», — сказал Гогиа. «Они несут код, секреты, идентификацию, автоматизацию, облачный доступ и теперь контекст машинного рассуждения. Если злоумышленник завладеет средой разработчика, он не просто крадет пароль. Он сидит рядом с машиной, которая создает корпоративное ПО».
По словам Гровер, смягчение последствий начинается с усиления контроля над установкой зависимостей и поведением пакетов.
«Одних только локфайлов недостаточно для защиты», — сказала она. «Вам необходимо автоматизированное сканирование во время установки на предмет известных вредоносных пакетов и поведенческих сигналов, таких как неожиданные скрипты postinstall, получение удаленной полезной нагрузки или необычные сетевые вызовы».
Гровер добавила, что не менее важен принцип наименьших привилегий для учетных данных разработчиков, включая ограниченные по области действия, краткосрочные ключи и практики управления секретами, которые позволяют избежать оставления учетных данных в переменных среды или конфигурационных файлах.
«Если злоумышленник получает ключ, но не может перемещаться по сети, кампания останавливается», — добавила она.
Кит Прабху, основатель и генеральный директор Confidis, считает, что руководителям по информационной безопасности (CISO) также следует уделить первоочередное внимание укреплению конечных точек разработчиков, созданию белых списков пакетов, управлению инструментами ИИ и внедрению элементов нулевого доверия в локальных средах разработки.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Prasanth Aby Thomas
