Спам-пакеты в NPM: что это и чем опасно

С чем у вас ассоциируются слова баксо, сате и ренданг? Многие ответят, что ни с чем, гурманы опознают блюда индонезийской кухни, а люди, следящие за ИБ-новостями, вспомнят об атаке на экосистему Node Package Manager (NPM), позволяющую разработчикам использовать готовые пакеты — библиотеки — вместо написания всего кода проекта с нуля.

В середине ноября исследователь безопасности Пол Маккарти сообщил об обнаружении спам-кампании, направленной на засорение реестра NPM. Разумеется, бессмысленные пакеты в реестре появлялись и раньше, но в данном случае были найдены десятки тысяч не имеющих полезной функции модулей, единственный смысл которых заключался в добавлении совершенно ненужных зависимостей в проекты.

В именах пакетов фигурировали произвольно вставленные названия индонезийских блюд и связанных с кулинарией терминов (например, bakso, sate и rendang), из-за чего кампания и получила наименование IndonesianFoods. Масштаб происходившего впечатлял: на момент обнаружения было выявлено около 86 тысяч пакетов.

Как это произошло и чего хотели злоумышленники — рассказываем ниже.

Как устроена IndonesianFoods

На первый взгляд пакеты, опубликованные в рамках IndonesianFoods, не выглядели как явный мусор. Они имели стандартную структуру, корректные файлы конфигурации и даже хорошо оформленную документацию. По данным исследователей из Endor Labs, эта маскировка позволила пакетам оставаться в реестре NPM почти два года.

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

В небольшую часть мусорных пакетов был встроен механизм саморепликации: после установки они каждые семь секунд создавали и публиковали в реестр NPM новые пакеты со случайными названиями (тоже связанными с индонезийской кухней) и номерами версий. Разумеется, от имени жертвы.

В код других вредоносных пакетов была добавлена интеграция с блокчейн-платформой TEA. Проект TEA создан для вознаграждения создателей открытого ПО токенами в зависимости от популярности и использования их кода, то есть в теории работает по модели «доказательства вклада» (Proof of Contribution).

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

Зачем это злоумышленникам

Есть две основные версии. Самая очевидная — вся эта сложная спам-кампания была задумана для эксплуатации вышеупомянутого протокола TEA. По сути, не делая никакого полезного вклада в комьюнити софта с открытым исходным кодом, авторы атаки зарабатывают токены TEA, которые являются обычным цифровым активом и могут быть обменены на другую криптовалюту на биржах. Таким образом, злоумышленники притворяются обычными open-source-разработчиками и накручивают значимость и используемость своих пакетов при помощи сети зависимостей и механизма саморепликации. В README-файлах некоторых пакетов злоумышленники даже хвастаются своими доходами.

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

Почему вы не хотите, чтобы в ваших проектах содержался мусор

На первый взгляд опасность для организаций, занимающихся разработкой ПО, может быть и неочевидна: да, IndonesianFoods засоряет экосистему, но при этом непосредственной опасности вроде бы не несет (не грозит шифрованием данных или утечкой конфиденциальной информации). Однако лишние зависимости делают код более громоздким и тратят системные ресурсы разработчиков. Кроме того, мусорные пакеты, опубликованные уже от имени вашей организации, могут негативно сказаться на репутации компании в среде разработчиков ПО.

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

Как защитить организацию

Спам-пакеты сами в проект не попадают: чтобы их установить, требуется явное участие невнимательного разработчика. Поэтому мы рекомендуем регулярно повышать уровень осведомленности сотрудников (даже технически подкованных) о современных киберугрозах. С этим вам может помочь наша интерактивная обучающая платформа KASAP (Kaspersky Automated Security Awareness Platform).

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