Эта история начинается, когда Себастьен Лорбер, сопровождающий Docusaurus, проекта документации с открытым исходным кодом на основе React, замечает изменение запроса на включение в манифест пакета. Вот изменение, предложенное для популярного пакета cliui npm:

В частности, обращаем наше внимание на изменение зависимостей npm, использующих незнакомый синтаксис:

  "dependencies": {
    "string-width": "^5.1.2",
    "string-width-cjs": "npm:string-width@^4.2.0",
    "strip-ansi": "^7.0.1",
    "strip-ansi-cjs": "npm:strip-ansi@^6.0.1",
    "wrap-ansi": "^8.1.0",
    "wrap-ansi-cjs": "npm:wrap-ansi@^7.0.0"

Большинство разработчиков ожидают увидеть диапазон версий semver в значении пакета или, возможно, URL-адреса Git или файла. Однако в этом случае существует специальный синтаксис префикса npm:. Что это значит?

Что такое псевдонимы пакетов npm?

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

Итак, в случае изменения, предложенного в этом запросе на включение, пакет string-width-cjs будет преобразован в пакет string-width в версиях ^ 4.2.0. Это означает, что будет запись каталога node_modules для string-width-cjs, но с содержимым string-width@^4.2.0 и аналогичным поведением в файле блокировки (package-lock.json).

Псевдонимы пакетов — это функция менеджера пакетов npm, которую можно использовать, например, для поддержки ESM и CJS.

При этом псевдонимами пакетов можно злоупотреблять. В статье и раскрытии информации о безопасности, датированной 2021 годом, Нишант Джайн, посол Snyk, продемонстрировал, как официальный реестр npmjs можно обмануть, чтобы он дезинформировал информацию о зависимостях на основе псевдонимов пакетов как часть путаницы зависимостей и проблем безопасности цепочки поставок.

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

Обнаружение подозрительного поведения в файлах блокировки npm, касающихся вредоносных модулей

Чтобы проверить запрос на включение, Себастьен использовал lockfile-lint. Этот инструмент проверяет файлы блокировки, такие как package-lock.json или Yarn.lock, на наличие признаков взлома, гарантируя, что вредоносные пакеты не были внедрены вместо исходного пакета npm.

Запуск инструмента показал следующие предупреждения:

npx lockfile-lint --path package-lock.json --allowed-hosts yarn npm --validate-https --validate-package-names

detected resolved URL for package with a different name: string-width-cjs
    expected: string-width-cjs
    actual: string-width

detected resolved URL for package with a different name: strip-ansi-cjs
    expected: strip-ansi-cjs
    actual: strip-ansi

detected resolved URL for package with a different name: wrap-ansi-cjs
    expected: wrap-ansi-cjs
    actual: wrap-ansi

 ✖ Error: security issues detected!

Отказ от ответственности: lockfile-lint — это инструмент, который я разработал в 2019 году после моей публикации, в которой раскрыты проблемы безопасности, связанные с файлами блокировки: почему файлы блокировки npm могут быть слепой зоной безопасности для внедрения вредоносных модулей.

Внимание: популярные пакеты-двойники на npm

Учитывая приведенные выше результаты lockfile-lint, Себастьен поискал эти имена пакетов в npm и с удивлением обнаружил, что они действительно существуют в общедоступном реестре npm:

• https://www.npmjs.com/package/string-width-cjs
• https://www.npmjs.com/package/strip-ansi-cjs
• https://www.npmjs.com/package/wrap-ansi-cjs

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

В пакете npm Strip-ansi-cjs нет ни README, ни репозитория исходного кода. Однако существует множество законных и популярных пакетов, демонстрирующих такое же поведение.

На самом деле, именно этот пакет популярен, о чем мы можем судить по 529 его зависимостям (другим пакетам, зависящим от этого) и 7 274 загрузкам в неделю.

Если посмотреть на код Strip-ansi-cjs, то видно, что в этом пакете есть только один файл — файл манифеста пакета package.json.

Итак, почему пакет, который ничего не делает, получает так много загрузок и почему от него зависит так много других пакетов?

Давайте проверим автора этих пакетов npm.

Все три пакета принадлежат hisanshutester002, и все их пакеты были опубликованы в прошлом году с программными номерами версий. Несколько интересных наблюдений, на которые стоит обратить внимание:

• Пакет isaacs-cliui npm потенциально является попыткой опечатки собственного ответвления Исаака проекта cliui и законного пакета npm под их пространством имен: @isaacs/cliui.
• Пакет azure-sdk-for-net npm потенциально является попыткой кампании по путанице зависимостей для атаки на частные пакеты с тем же именем.
• Пакет link-deep npm использует популярную возможность, связанную с пакетами утилит, такими как lodash и другие.

Вы также можете отметить, что пользователь hisanshutester002 не имеет идентифицируемой информации на странице профиля пользователя на npmjs.

Ранее мы отмечали, что npm-пакет Strip-ansi-cjs имеет более 500 других пакетов, которые его используют, поэтому это потенциально положительный показатель популярности. Давайте посмотрим на них:

Это может показаться правдоподобным, поскольку оно включено в список, но так ли это на самом деле?
Например, такие имена, как clazz-transformer или response-native-multiply или, может быть, gh-monoproject-cli, кажутся законными, но так ли это?

Вот страница пакета react-native-multiply npm:

Этот пакет практически не загружается, а его автор — анонимный пользователь npm, не имеющий идентифицируемой информации. Исходный репозиторий URL-адресов, на который перенаправляется этот пакет, — это несуществующий https://github[.]com/hasandader/react-native-multiply. Профиль пользователя GitHub также выглядит очень подозрительно и лишен практической активности.

Хотя пакет npm, по-видимому, содержит исходный код, при ближайшем рассмотрении выясняется, что это образец сгенерированного кода для прототипа приложения «Hello World».

Вы также должны задаться вопросом: если этот пакет является просто библиотекой умножения, то зачем ему нужны 776 зависимостей, чтобы сделать следующее:

import { multiply } from 'react-native-multiply';
const result = await multiply(3, 7);

Хотя некоторые шутят о том, что JavaScript способствует созданию астрономического дерева вложенных пакетов из-за чрезмерного использования зависимостей, проект с 776 прямыми зависимостями неоправданно велик.

Среди всех этих зависимостей есть три подозрительных пакета npm, с которых началась наша история: string-width-cjs, Strip-ansi-cjs и Wrap-ansi-cjs:

Мы упоминали, что одна из зависимостей Strip-ansi-cjs называлась clazz-transformer. Давайте посмотрим на это:

Давайте объясним, что здесь происходит. Пакет npm clazz-transformer намеренно неправильно назван с заголовком class-transformer на странице README. Кроме того, его репозиторий исходного кода https://github[.]com/typestack/class-transformer не соответствует имени пакета, что вызывает опасения по поводу его легитимности.

Связанный репозиторий typstack/class-transformer на GitHub имеет файл package.json следующего вида:

В файле package.json на GitHub нет объявления зависимостей, но если мы проверим исходный код фактического пакета на npmjs, мы увидим 437 зависимостей, с которыми упакован этот clazz-трансформер. Опять же, они очень удобно объединяют три подозрительных пакета *-cjs:

Дальнейшие мысли о результатах подозрительных пакетов npm

Прежде чем сделать дальнейшие выводы, важно упомянуть некоторые особенности пакетов npm, которые мы наблюдали выше:

• Похоже, что пакеты React Native созданы на основе инструмента создания шаблонов create-react-native-library. Этот инструмент также содержит пример функции умножения по умолчанию как часть исходного кода, созданного для нового проекта.
• Пакеты имеют структуры каталогов и файлов, а также зависимости, которые могут быть получены из стартового шаблона Next.js 14, например, созданного с помощью npx create-next-app@14.

Наши коллеги из Sonatype ранее уже отмечали подобные случаи переполнения реестров с открытым исходным кодом пакетами. В этих случаях конечной целью разработчиков было вознаграждение себя токенами Tea — платформой Web3 для монетизации программного обеспечения с открытым исходным кодом.

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

Ранее в этом году, 14 апреля 2024 года, пользователь чайного форума опубликовал комментарий, который еще раз подтверждает обеспокоенность по поводу злоупотребления чаем:

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

Что происходит с string-width-cjs?

На данный момент я полностью уверен, что смогу продолжить поиск дыр в остальных пакетах, которые предположительно зависят от string-width-cjs, чтобы найти очень сомнительные индикаторы подлинной легитимности.

Я предполагаю, что все эти зависимые пакеты и увеличение количества загрузок ведут к единственной цели — создать ложную легитимность для пакетов 3 *-cjs, чтобы в свое время, при наличии подходящей жертвы, эти поддельные пакеты были быть установлен, а затем появится новая вредоносная версия.

Чтобы помочь вам оставаться в безопасности при работе с программным обеспечением с открытым исходным кодом, я настоятельно рекомендую принять меры безопасности и, в частности, следующие дополнительные образовательные ресурсы:

• Почему файлы блокировки npm могут стать слепой точкой безопасности для внедрения вредоносных модулей
• Рекомендации по безопасности 10 npm
• Безопасность NPM: предотвращение атак на цепочку поставок

Удалось ли нам обнаружить кампанию по обеспечению безопасности цепочки поставок на фоне их нечестной игры, или все дело в денежных следах, и поэтому их можно отнести к спаму и злоупотреблению публичными реестрами, такими как npm и GitHub, для майнинга токенов Tea?

Что бы ни случилось, будьте бдительны.