Подмена тегов Laravel Lang превратила старые релизы в вредоносные

Что произошло#

Злоумышленники захватили теги релизов пакетов Laravel Lang и использовали их для распространения вредоносного ПО, крадущего учётные данные, через установки Composer.

Речь идёт о сторонних пакетах локализации, которые поддерживает организация Laravel Lang. Они не входят в официальный фреймворк Laravel. В публикациях упоминаются пакеты laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes и, возможно, laravel-lang/actions.

Ключевая особенность атаки — злоумышленники не выпустили новый вредоносный релиз. По данным исследователей, они переписали существующие GitHub-теги версий в репозиториях Laravel Lang так, чтобы те указывали на вредоносные коммиты.

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

BleepingComputer ссылается на исследования Aikido, Socket и StepSecurity. По данным Aikido, были затронуты 233 версии в трёх репозиториях. Socket сообщает примерно о 700 исторических версиях. Оценки различаются, поэтому разумно исходить из того, что компрометация затронула большое количество версий, а итоговые цифры зависят от методики подсчёта тегов и пакетов.

Согласно StepSecurity, переписывание тегов началось в 22:32 UTC в репозитории laravel-lang/lang и завершилось к 00:00 UTC в laravel-lang/actions. Также StepSecurity отмечает, что все четыре репозитория содержали одинаковую поддельную личность автора, схожие изменения файлов и одинаковое поведение полезной нагрузки. Это указывает на одного атакующего, использовавшего одну скомпрометированную учётную запись с правами записи на уровне организации.

Почему эта атака отличается от обычных компрометаций пакетов#

Большинство инцидентов в цепочке поставок ПО связаны с публикацией нового вредоносного релиза. Здесь целью стал сам указатель релиза.

Git-теги часто воспринимаются как надёжные ориентиры версий. Менеджер пакетов, CI-задача или разработчик могут загрузить зависимость только потому, что номер версии выглядит знакомым. Если тег перемещён, доверие к версии перестаёт что-либо гарантировать. Метка остаётся прежней, а код за ней — уже другой.

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

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

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

Что делало вредоносное ПО#

Вредоносное изменение добавляло файл src/helpers.php, который автоматически загружался через конфигурацию Composer.

Этот файл работал как загрузчик. Он связывался с управляющим доменом flipboxstudio[.]info и загружал вторую стадию вредоносного PHP-кода.

Исследователи описывают вторую стадию как крупный кроссплатформенный стилер для Linux, macOS и Windows. Среди его целей были облачные учётные данные, секреты Kubernetes, токены Vault, Git-учётные данные, секреты CI/CD, SSH-ключи, данные браузеров, криптокошельки, данные менеджеров паролей, конфигурации VPN и локальные файлы .env.

Вредоносное ПО также содержало набор регулярных выражений для поиска секретов в файлах и переменных окружения. Сообщается о попытках извлечения AWS-ключей, токенов GitHub, токенов Slack, секретов Stripe, учётных данных баз данных, JWT, приватных SSH-ключей и фраз восстановления криптокошельков.

В Windows PHP-полезная нагрузка содержала встроенный исполняемый файл, закодированный в base64. Он записывался в каталог %TEMP% под случайным именем с расширением .exe и запускался.

По данным анализа BleepingComputer, Windows-стилер назывался DebugElevator. Он атаковал Chrome, Brave и Edge, включая ключи App-Bound Encryption, используемые для расшифровки сохранённых учётных данных браузера. Встроенный путь PDB содержал имя учётной записи Windows Mero и упоминание claude, что может указывать на использование ИИ при разработке, однако это нельзя считать подтверждённой атрибуцией.

После сбора данных вредоносное ПО шифровало похищенную информацию и отправляло её на сервер управления злоумышленников.

Реакция и текущий статус#

Aikido сообщила об инциденте в Packagist. По имеющимся данным, сервис быстро удалил вредоносные версии и временно исключил затронутые пакеты из списка доступных, чтобы предотвратить дальнейшие установки.

Это снижает текущий риск через стандартные механизмы установки пакетов. Однако такой шаг не очищает системы, на которых вредоносный код уже был выполнен.

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

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

Что проверить#

Если используются пакеты Laravel Lang, сначала выясните, устанавливались или обновлялись ли они в период инцидента. В первую очередь проверьте:

• laravel-lang/lang
• laravel-lang/http-statuses
• laravel-lang/attributes
• laravel-lang/actions при наличии

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

Практические действия:

• Проверьте lock-файлы Composer и журналы установки на предмет версий Laravel Lang, загруженных в период атаки.
• Найдите файл src/helpers.php в каталогах затронутых пакетов, если его присутствие там не ожидается.
• Проанализируйте журналы прокси, DNS, EDR и межсетевых экранов на наличие исходящих соединений с flipboxstudio[.]info.
• Обновите учётные данные, которые могли находиться в файлах .env, переменных окружения, переменных CI, конфигурациях Git, облачных CLI-инструментах, конфигурациях Kubernetes, сессиях Vault, SSH-ключах и токенах менеджеров пакетов.
• Проведите аудит журналов GitHub, облачных платформ, CI/CD-систем и реестров пакетов на предмет подозрительного доступа после возможной компрометации.
• Пересоберите затронутые среды из доверенных источников, если выполнение вредоносного кода выглядит вероятным.

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

Чего не стоит утверждать#

Нет оснований заявлять, что был скомпрометирован сам Laravel. Все опубликованные материалы указывают на сторонние пакеты локализации Laravel Lang, а не на официальные пакеты фреймворка.

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

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

Количество затронутых версий по-прежнему оценивается по-разному. Aikido сообщает о 233 версиях в трёх репозиториях, Socket — примерно о 700 исторических версиях. В обоих случаях вывод одинаков: масштаб инцидента достаточен для проверки собственной инфраструктуры, а не для предположения, что риск вас не касается.

Главный вывод#

Этот инцидент показывает разницу между доверием к исходному коду и доверием к артефакту.

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

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

Эта атака сработала потому, что процесс установки выглядел полностью нормальным. Именно этот урок стоит запомнить.