Обещал рассказать про самые громкие последние атаки на цепочку поставок, а обещание нужно выполнять. Погнали 🫡
На днях в npm ненадолго появились две вредоносные версии популярнейшей JavaScript-библиотеки axios: 1.14.1 и 0.30.4 (на секундочку это одна из самых популярных библиотек для HTTP-запросов в JS, я про нее и в прошлом посте говорил). То есть, этот пакет используется в огромном количестве абсолютно разного ПО и разными разработчиками. А атака на такой пакет автоматически означает, что через него можно атаковать и то самое ПО, в котором он был использован
Самое интересное в этой атаке то, что в сам исходный код axios злоумышленники почти не лезли. Вместо этого в релиз подмешали левую зависимость plain-crypto-js@4.2.1 (то есть, до разработчиков она летела транзитивно), которая вообще не нужна для работы axios. Этой зависимости нужно было отработать на этапе установки через postinstall и незаметно установить на машину RAT (троян удаленного доступа)
В итоге у нас получается такой вот сценарий: разработчик или CI/CD просто делает npm install. Ничего не запускает руками, ничего не открывает, никаких файлов дополнительно не скачивает. Пакетный менеджер сам тянет зависимость, а та выполняет вредоносный скрипт. Все. Компрометация происходит на этапе установки. Просто потому, что изначально было доверие к официальному популярному пакету 😏
Исходя из анализа исследователей (по которому я в том числе и этот пост пишу), вредоносная цепочка была кроссплатформенной и работала против macOS, Windows и Linux. Дальше дроппер связывался с C2-сервером и уже подтягивал второй этап, который зависил от платформы. Причем после запуска вредонос пытался подчистить следы за собой (он удалял артефакты установки и маскировал свое поведение)
Почему я решил рассказать именно про кейс с axios? Потому что он очень хорошо ломает иллюзию контроля. У нас может быть нормальный SSDLC, SAST, SCA, код-ревью, хорошие разработчики, безопасники и тд. А потом одна компрометированная публикация в npm... и наш пайплайн сам приносит злоумышленнику доступ в инфраструктуру. Немного неловко даже (и обидно)
Как от такого защититься?
- Во-первых, никогда нельзя жить на автоподтягивании зависимостей через диапазоны версий. Нельзя использовать latest. Это небезопасно. Определяете версию пакета и используете только ее.
- Во-вторых, фиксируем lockfile и ставим зависимости через воспроизводимую установку. Чем меньше сюрпризов на этапе
install, тем лучше будет спаться (в ином случае — спиваться). - В-третьих, по возможности ограничивать или вообще отключать выполнение postinstall, где это допустимо. Очень много грязи в цепочке поставок приходит именно через них.
- В-четвертых, мониторить аномалии в самих пакетах и их странное поведение в рантайме... хотя про это я расскажу отдельно на докладе Merge Conf (а позже и здесь).
- Ну и последнее, самое практическое. Если у вас в момент инцидента могли установиться
axios@1.14.1илиaxios@0.30.4, проверяйте, разбирайтесь, ну и это, не болейте что-ли :) Проверять места установки, сетевую активность, следы postinstall-скриптов и посторонние файлы; как можно быстрее перевыпустить и заменить секреты, токены, ключи и тд, которые могли быть доступны на этих хостах.
P.S. Увидимся с вами на Merge Conf уже в эту субботу. Там я расскажу про CBOM и то, как сейчас важно ограничивать поведение самих пакетов в рантайме. Как раз случай с axios вышел очень показательный 🧐
#информационная_безопасность
