В экосистеме npm снова нашли вредоносные пакеты, связанные с утечкой Shai-Hulud. По данным исследователей, через заражённые загрузки атакующие крали учётные данные разработчиков, секреты, данные криптокошельков и сведения об аккаунтах, а один пакет ещё и превращал систему в узел DDoS-атаки.

За выходные специалисты OXsecurity заметили четыре опасных пакета, опубликованных от имени аккаунта deadcode09284814. Общая статистика загрузок у этой четвёрки — 2 678, так что речь идёт не о массовом, но уже вполне реальном инциденте для тех, кто успел поставить заражённые версии.

Что именно произошло

Исследователи описывают типичную атаку на цепочку поставок: злоумышленник выкладывает пакет с похожим названием, а разработчик ставит его по невнимательности. Здесь использовали typoquatting — подмену имени через опечатку. В списке заражённых пакетов были, например, chalk-tempalte, axois-utils и color-style-utils.

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

Что крали и зачем это важно

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

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

Как проверить себя

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

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

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

Что делать, если пакет уже поставили

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

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

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

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

  • Проверить список зависимостей на подозрительные или похожие названия.
  • Удалить пакеты, которые совпадают с описанными в инциденте.
  • Сменить токены, пароли и API-ключи на затронутых машинах.
  • Проверить журналы публикаций в GitHub и npm-аккаунтах.
  • Пересобрать проект из чистого состояния.
  • Просмотреть CI/CD-секреты и облачные ключи.
  • Убедиться, что в команде есть правило: ставить пакеты только после проверки источника и автора.
Поделиться: