У команды Laravel-Lang* утром обнаружили странную картину: релизные теги в нескольких composer-пакетах внезапно начали указывать не на нужные коммиты. Для разработчиков это выглядело как обычное обновление зависимостей, но внутри тега уже сидел вредоносный код.

Похожая история уже разбиралась ранее в материале атака на Laravel Lang показала, как воруют секреты через пакеты. Этот случай снова напомнил: один скомпрометированный токен может превратить доверенный пакет в канал доставки вредоноса.

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

Речь идет об атаке на цепочку поставки — когда злоумышленник вмешивается не в сам продукт, а в путь, по которому его получают. Здесь целью стали composer-пакеты Laravel-Lang: Lang, Actions, Attributes и HTTP Statuses.

Схема выглядела просто и грязно. Сначала злоумышленник удалил легитимные теги, затем создал те же теги уже на своих коммитах. Репозитории при этом не трогали целиком — меняли именно метки релизов, на которые смотрит Composer.

Как это работало технически

В экосистеме PHP Composer ориентируется на теги версий. Если тег указывает на другой коммит, пакет подтянет уже не тот код, который ожидала команда проекта.

Именно это и случилось: вредоносный код мог запуститься во время composer update или установки свежей версии пакета. Для команды разработки это особенно опасно, потому что проблема прячется в обычном обновлении зависимостей, а не в каком-то подозрительном скрипте.

По данным расследования, злоумышленник получил доступ через Personal Access Token одного из участников проекта. Дальше ему хватило прав на смену тегов. Затем команду пришлось срочно отзывать доступы, отключать GitHub Actions на уровне организации и снимать пакет с публикации в Packagist.

Почему это опасно

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

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

Отдельный риск — утечки секретов. В подобных инцидентах вредонос часто ищет токены, ключи и конфиги, чтобы увести доступ к репозиториям, облаку или CI/CD. В таких ситуациях полезно сверяться и с общими разбором утечек, и с практикой проверки учетных данных, как в статье утечка секретов в CISA показала, как ломается защита.

Как понять, касается ли это вас

Если вы ставили или обновляли затронутые пакеты в окно риска, лучше считать среду потенциально затронутой. Особенно если в этот же период в проекте использовали свежие версии зависимостей через Composer.

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

Что делать прямо сейчас

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

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

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

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

  • Проверьте, не ставили ли вы затронутые пакеты в окно риска.
  • Запустите обновление зависимостей из доверенного источника и пересоберите проект.
  • Отзовите Personal Access Token и SSH-ключи, если они могли попасть в чужие руки.
  • Проверьте права на запись в репозитории и уберите лишний доступ.
  • Посмотрите настройки CI/CD и отключите все, что не нужно для работы.
  • Проверьте журналы на подозрительные изменения тегов и релизов.
  • Включите двухфакторную аутентификацию для всех учетных записей разработчиков.
  • Проверьте, не хранятся ли секреты в коде, переменных окружения и артефактах сборки.
Поделиться: