Вредоносная ветка Packagist выявила реальную угрозу цепочки поставок

Socket сообщил о нахождении обфусцированного JavaScript-малвари в разработческой версии легитимного Laravel-пакета на Packagist. Важно не то, что в реестре пакетов оказался вредоносный код, а то, что dev/test-ветка, выставленная как устанавливаемая версия, может проникнуть в цепочку поставок, даже если стабильная линия чиста.

Socket связывает активность с Famous Chollima, кластером из КНДР, известным операциями на тему разработчиков и найма. Случай классифицируют как потенциальный Contagious Interview-улов, но это не подтверждено: источник пишет «возможно».

Изменения#

Socket обнаружил вредоносный JavaScript в файле dev-версии dev-drewroberts/feature/test-case пакета Laravel, поддерживаемого Drew Roberts. По оценке Socket, вредоносный код ограничен этой веткой, которую Packagist сделал устанавливаемой.

Это важно: пакет не создавался специально для атаки. Скорее всего, это компрометация разработчика или репозитория. Стабильная линия не показывает этих признаков.

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

После деобфускации JavaScript ведёт себя как загрузчик малвари: восстанавливает Node.js-интерны, обращается к blockchain и публичным RPC, получает шифрованный payload, расшифровывает XOR-ключами и выполняет в Node.js, включая скрытый дочерний процесс.

Packagist указал ветку как устанавливаемую. Socket сообщил о проблеме, Packagist удалил вредоносную версию. Maintainer уведомлён через GitHub и контакт по безопасности, ветка помечена в GitHub Security.

Почему это важно для цепочки поставок#

Риск — доверие к веткам. Разработчики думают в категориях «официальный пакет» vs «рандомный пакет». Атакующему это не важно: открытая dev-ветка или скомпрометированный workflow позволяет распространять код с репутацией проекта без защиты стабильной версии.

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

Дизайн загрузчика показывает, что allowlist и поверхностный код-ревью не спасают. Blockchain-инфраструктура служит мёртвым drop: TRON и Aptos дают указатели на payload, BNB Smart Chain RPC возвращает шифрованные данные транзакций. Запросы видны через общедоступные сервисы, что усложняет блокировку и triage.

Для PHP команд урок не «избегать Packagist», а «рассматривать dev-версии и ветки как потенциальный риск», особенно при тестовых задачах, contractor handoff или чужих workflow. Наличие пакета в реестре ≠ безопасная версия.

Это типичный паттерн OSS-безопасности: слабое место — не код, а путь релиза, доступ maintainer, видимость ветки, scope токенов, CI, разрыв между тем, что разработчик думает, и тем, что реально установлено. См. также: https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational

Что проверить перед действием#

Начните с разрешения зависимостей. Для PHP через Composer проверяйте, нет ли dev-веток, на которые вы не хотели полагаться. Dev-constraints не обязательно вредоносны, но требуют внимания.

Практика:

• Ищите в composer.json и lock-файлах dev- constraints, имена веток, необычные репозитории, прямые VCS-ссылки.
• Проверяйте недавние установки Packagist через dev-ветки, а не стабильные версии.
• Осматривайте config-файлы Node.js, особенно простые вроде Tailwind.
• Форматируйте подозрительный JS перед ревью: большие пробелы скрывают код от глаз, но не от инструментов.
• Следите за неожиданными Node.js child process при установке, сборке, тестах.
• Контролируйте исходящие запросы к публичным RPC, blockchain, paste, file-sharing, short-link.
• Тестовые проекты и репозитории интервью-тасков — как untrusted code, если не в disposable-среде.

Maintainers должны проверить видимость веток через метаданные реестра и доступность dev-веток для установки. Проверяйте доступ к репозиторию, токены, секреты CI, workflow публикации. Используйте trusted publishing и stronger provenance, если возможно.

Security teams не ждут идеальной атрибуции. Проверки одинаковы для Famous Chollima, других state-linked групп или финансовых атакующих: версия пакета, ветка, подозрительный Tailwind, поведение выполнения. Атрибуция может быть provisional.

Что не стоит преувеличивать#

Socket не утверждает, что весь пакет был вредоносным: код ограничен dev/test-веткой. Стабильная линия чиста.

Packagist как реестр не доказано небезопасен. Критика конкретнее: registry может экспонировать опасные dev-версии, которые разработчики не отделяют от стабильных. Packagist удалил версию после проверки.

Famous Chollima и Contagious Interview — возможная рамка, но с неуверенностью. Важно: ветка, malware family, indicators, доставка через trusted developer. Это поддерживает осторожную оценку.

Вывод практический, не театральный: компрометация ветки достаточна. Атакующему нужен один доверенный путь в одну dev машину или CI job.

Практический вывод#

Доверие к реестру — по версии, а не по пакету. Стабильные релизы, dev-ветки, GitHub-ветки и локальные скрипты — разные поверхности риска, даже под одним проектом.

Для серьезной OSS-безопасности политика должна сочетаться с tooling: запрещать или тщательно проверять dev-зависимости в production, запускать незнакомые задачи в disposable-среде, видеть доступ к веткам и maintainer, логировать сетевую активность во время сборки. Не позволяйте имени знакомого пакета перевесить данные в реальных файлах.

Атака Socket узкая, но слабость общая.