ИБ-эксперт Алекс Бирсан (Alex Birsan) рассказал о новой проблеме, которая представляет собой вариацию атаки на цепочку поставок, получившую название dependency confusion (путаница зависимостей) или substitution attack (атака на замещение). За обнаружение этого способа атак исследователь уже получил от различных компаний более 130 000 долларов по программам bug bounty. Дело в том, что, используя эту проблему, специалист сумел загрузить собственный (безвредный) код в системы Microsoft, Apple, PayPal, Shopify, Netflix, Yelp, Tesla, Uber и других компаний.

Суть dependency confusion проста: малварь из опенсорсных репозиториев (включая PyPI, npm и RubyGems) автоматически распределяется дальше по всей цепочке поставок, проникая во внутренние приложения компаний без какого-либо участия пользователей. Именно это отличает атаку от обычного тайпсквоттинга.

На эту простую идею Бирсана в прошлом году натолкнул его коллега, еще один ИБ-эксперт Джастин Гарднер (Justin Gardner). Тот поделился с Бирсаном файлом манифеста package.json из npm-пакета, используемого внутри PayPal. Оказалось, что некоторых пакетов из манифеста нет в общедоступном репозитории npm, это приватные пакеты, созданные инженерами PayPal, и они используются и хранятся только внутри компании.

Глядя на это, Бирсан задался вопросом, должен ли пакет с таким же именем существовать в общедоступном репозитории npm, и если да, то какой из них в итоге будет иметь приоритет? Чтобы проверить свою теорию, исследователь начал искать названия других приватных пакетов, которые можно обнаружить в файлах манифестов в репозиториях GitHub или в CDN известных компаний, но которых нет в общедоступных репозиториях.

Обнаружив несколько таких целей, Бирсан стал создавать фейковые проекты с такими же названиями в npm, PyPI и RubyGems (хотя Бирсан отмечает, уязвимы и другие менеджеры пакетов, в том числе JFrog и NuGet). Эксперт создавал эти фальшивки из-под своего аккаунта и сопровождал пояснением, что они предназначены исключительно для исследования безопасности и не содержат никакого полезного кода.

Этот эксперимент показал, что если пакет зависимостей, используемый приложением, существует как в общедоступном опенсорсном репозитории, так и частной сборке, публичный пакет в итоге получает приоритет и будет использован без каких-либо действий со стороны разработчика. Также оказалось, что в случае с пакетами PyPI пакет с более высокой версией имеет приоритет независимо от того, где он расположен.

Затем, используя ту же тактику, Бирсан осуществил успешные атаки на Microsoft, Apple, PayPal, Shopify, Netflix, Tesla, Yelp, Uber и другие крупные компании, просто опубликовав пакеты с такими же именами, как у пакетов, используемых внутри компаний.

«Такие уязвимости и недоработки в автоматизированных инструментах для сборки или установки могут привести к тому, что общедоступные зависимости будут ошибочно приниматься за внутренние зависимости с таким же именем», — рассказал изданию Bleeping Computer Бирсан.

Все тестовые пакеты исследователя содержали предустановленные скрипты, которые автоматически запускали скрипт для извлечения идентифицирующей информации с «зараженной» машины, сразу после пула пакетов. Понимая, что его скрипты будут устанавливать соединение из защищенных корпоративных сетей, Бирсан решил обойти механизмы безопасности, использовав DNS для извлечения данных.

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

Собрав таким образом данные и убедившись в своей правоте, исследователь начал сообщать о своих выводах уязвимым компаниями, получая вознаграждения в рамках программ bug bounty.  К примеру, PayPal уже обнародовала отчет эксперта на HackerOne и выплатила ему 30 000 долларов; Yelp тоже подтвердила выводы Бирсана и вознаградила его 15 000 долларов.

Но серьезнее всех к dependency confusion, пожалуй, отнеслась компания Microsoft. Данной проблеме был присвоен идентификатор CVE-2021-24105 (для Azure Artifactory), и компания не только выплатила эксперту 40 000 долларов, но и опубликовала собственный технический документ, где подробно описывает проблему и предлагает методы ее решения. В частности, инженеры Microsoft рекомендуют минимизировать риски, защищая приватные пакеты с помощью контролируемых областей в публичных репозиториях, а также путем использования верификации на стороне клиента (закрепление версий, проверка целостности).

Оставить мнение