Исследователи из StepSecurity, Aikido Security и Socket сообщили о необычной атаке на цепочку поставок, которая затронула популярные пакеты локализации Laravel Lang. Злоумышленники не публиковали новые вредоносные релизы и не переписывали код в официальных репозиториях — они подменили GitHub-теги и привязали их к коммитам из подконтрольных форков.

Атака затронула пакеты laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes и, вероятно, laravel-lang/actions. По данным специалистов Aikido, злоумышленники скомпрометировали 233 версии пакетов, а в Socket говорят примерно о 700 затронутых тегах.

Почему это опасно для разработчиков

Такая схема бьёт по доверию к привычной инфраструктуре. Composer загружает пакет, ориентируясь на тег, а не на чьи-то намерения, и в этот раз он получил уже подменённый релиз.

На практике это значит, что уязвимость сидит не в самом приложении, а в самом механизме доставки зависимостей. О похожих рисках мы уже писали в разборе атаки на GitHub-репозитории и в материале о том, как старая учётка открыла дорогу злоумышленникам.

Как сработала схема

По данным исследователей, вся операция заняла около 15 минут. Первые изменения появились вечером 22 мая, а к полуночи все четыре репозитория уже оказались под ударом.

Главная деталь — GitHub позволяет тегам ссылаться на коммиты из форков того же репозитория. Этим и воспользовались злоумышленники: они не создали новые версии, а «переназначили» уже существующие теги на вредоносные коммиты.

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

Что делала малварь

В пакеты добавили файл src/helpers.php, который Composer подгружал автоматически. Этот файл служил дроппером и скачивал вторую стадию атаки с домена flipboxstudio[.]info.

Финальная нагрузка — кроссплатформенный PHP-стилер для Windows, Linux и macOS. Он искал облачные ключи AWS, GCP и Azure, секреты Kubernetes, токены HashiCorp Vault, SSH-ключи, настройки Docker и Helm, данные CI/CD-систем, файлы .env, JWT, токены GitHub, Slack и Stripe, а также seed-фразы криптокошельков.

Отдельно вредонос собирал данные браузеров, менеджеров паролей и учётные данные разработчиков. Для поиска секретов он проходил по файлам и переменным окружения с помощью регулярных выражений.

На Windows атака выглядела ещё опаснее. PHP-скрипт вытаскивал встроенный exe-файл и запускал его из временной директории. Компонент под названием DebugElevator атаковал Chrome, Brave и Edge и пытался извлечь ключи App-Bound Encryption, чтобы расшифровать сохранённые пароли.

Кому это важно и что делать

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

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

Администрация Packagist после уведомления от исследователей удалила вредоносные версии и временно скрыла пострадавшие пакеты. Но это не отменяет главного вывода: атака прошла очень быстро, а значит, проверять нужно не только релизы, но и происхождение тегов.

Практический чек-лист

  • Проверьте, использует ли проект laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes или laravel-lang/actions.
  • Сверьте установленные версии с теми, что были доступны в период атаки.
  • Поменяйте токены, ключи и пароли, если пакет мог попасть в рабочую среду.
  • Проверьте логи на обращения к flipboxstudio[.]info.
  • Осмотрите .env, CI/CD, Kubernetes, cloud credentials и другие секреты, которые могли утечь.
  • Убедитесь, что теги и релизы в репозиториях проходят отдельную проверку перед установкой.
  • Ограничьте права на публикацию тегов и доступ к аккаунтам с привилегиями в GitHub.
  • Включите контроль зависимостей и ручную проверку подозрительных обновлений перед деплоем.
Поделиться: