Раньше такие инциденты считались редкой проблемой для крупных библиотек. Теперь история с Laravel Lang показывает обратное: злоумышленникам хватает доступа к тегам релизов, чтобы протащить вредонос в цепочку поставок и добраться до секретов разработчиков.

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

Под удар попали сторонние пакеты локализации Laravel Lang: laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes и, по данным исследователей, вероятно, laravel-lang/actions. Эти пакеты не входят в официальный Laravel, но многие разработчики ставят их через Composer как удобное дополнение.

Атакующие не выпускали новую «левую» версию в лоб. Они переписали GitHub-теги релизов в нескольких репозиториях и заставили систему сборки подхватить уже «подписанный» на вид релиз, который на деле указывал на вредоносный коммит.

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

Схема опиралась на доверие к привычному процессу обновления. Когда разработчик устанавливал пакет через Composer, он получал код, который выглядел как обычный релиз Laravel Lang, хотя внутри уже лежал вредоносный файл src/helpers.php.

Этот файл автоматически подхватывался Composer и запускал загрузчик. Тот обращался к серверу управления и скачивал вторую стадию — PHP-код, заточенный под кражу данных. Исследователи отмечают, что вредонос работал на Linux, macOS и Windows, а на Windows дополнительно извлекал встроенный исполняемый файл и запускал его из папки %TEMP%.

Что именно крал вредонос

Набор целей у атаки широкий: облачные ключи, токены GitHub, Slack и Stripe, секреты CI/CD, SSH-ключи, данные из браузеров, кошельки криптовалют, пароли, токены Vault и локальные .env-файлы. Отдельно вредонос искал AWS-ключи, JWT, резервные фразы и другие строки, которые обычно хранят доступ к рабочим сервисам.

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

Похожий по логике инцидент мы уже разбирали в материале «Утечка секретов в CISA показала, как ломается защита»: проблема почти всегда начинается с одного доверенного канала, который никто не проверил отдельно.

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

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

Дальше одна заражённая машина может стать ключом ко всей компании. Если на ней лежали токены облака, секреты деплоя или доступ к репозиториям, злоумышленники получают шанс уйти глубже — в почту, CI/CD, внутренние сервисы и бэкапы.

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

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

На заражение могут указывать неожиданные исходящие соединения, новые файлы в %TEMP%, странные процессы php.exe или python.exe, а также пропавшие или скомпрометированные токены в репозиториях и CI/CD-системах. Если вы заметили, что входы в почту, GitHub или облако пошли с чужих устройств, реагировать нужно сразу.

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

Команда Aikido сообщила о проблеме в Packagist, после чего вредоносные версии убрали, а затронутые пакеты временно скрыли. Но этого мало: если пакет уже успели установить, остаётся проверить окружение руками и сменить доступы.

Для команд разработки полезно ввести отдельную проверку зависимостей и не полагаться только на привычные теги релизов. Если вы работаете с чувствительными данными вне офиса, имеет смысл заранее подготовить устройство и включить [дополнительный слой защиты для рабочих сессий]https://freedome.space) до выхода из дома, чтобы сократить риск утечки через открытые сети и чужие точки доступа.

Чек-лист

  • Проверьте, есть ли в проектах пакеты laravel-lang/* и какие версии стоят сейчас.
  • Сверьте теги релизов и историю зависимостей в Composer-окружении.
  • Смените все секреты, которые могли лежать на заражённой машине: ключи облака, токены GitHub, SSH-ключи, пароли.
  • Проверьте исходящие соединения на адрес flipboxstudio[.]info и любые похожие аномалии.
  • Осмотрите систему на новые файлы в %TEMP%, странные процессы и автозагрузку.
  • Ограничьте права токенов и уберите лишние секреты из локальных конфигов.
  • Включите проверку зависимостей и ручной контроль изменений в релизных тегах.
  • Для рабочих ноутбуков настройте отдельный профиль безопасности перед выездом из офиса.
Поделиться: