Suicide
10.02.2021, 22:52
Представлен (https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) поразительный по своей простоте метод атаки на зависимости в приложениях, при разработке которых используются внутренние репозитории пакетов. Выявившие проблему исследователи смогли выполнить свой код на внутренних серверах 35 компаний, среди которых PayPal, Micrоsoft, Apple, Netflix, Uber, Tesla и Shopify. Взломы проводились в рамках программ Bug Bounty (https://hackerone.com/alexbirsan), согласованно с атакуемыми компаниями, и уже принесли авторам 130 тысяч долларов, выплаченных в форме вознаграждений за выявление уязвимостей (выплаты продолжают (https://hackerone.com/reports/925585) поступать).
Метод основан на том, что многие компании используют в своих внутренних приложениях зависимости из стандартных репозиториев NPM, PyPI и RubyGems, а также внутренние зависимости, которые не распространяются публично и загружаются из собственных репозиториев. Проблема в том, что пакетные менеджеры, такие как npm, pip и gem, пытаются загрузить внутренние зависимости компаний в том числе и из публичных репозиториев. Для атаки достаточно определить имена пакетов со внутренними зависимостями и создать собственные пакеты с такими же именами в публичных репозиториях NPM, PyPI и RubyGems. Проблема не специфична для NPM, PyPI и RubyGems, и также проявляется в других системах, таких как NuGet, Maven и Yarn.
Идея предложенного метода появилась после того, как исследователь случайно обратил внимание, что в публикуемом на GitHub общедоступном коде многие компании не очищают из manifest-файлов упоминание дополнительных зависимостей, применяемых во внутренних проектах или при реализации расширенной функциональности. Подобные следы были найдены в JavaScript-коде web-сервисов, а также Node.JS, Python и Ruby проектах многих компаний. Основные утечки были связаны со встраиванием содержимого файлов package.json в публично доступный JavaScript-код в процессе сборки проекта, а также использованием элементов реальных путей в вызовах require(), по которым можно судить об именах внутренних зависимостей.
https://www.opennet.ru/opennews/pics_base/0_1612947278.png (https://miro.medium.com/max/840/1*kXIpJ2pZhu40yT17cbwheg.png)
Сканирование нескольких миллионов корпоративных доменов позволило выделить несколько тысяч имён JavaScript-пакетов, отсутствующих в репозитории NPM. Собрав базу внутренних имён пакетов исследователь решился на эксперимент по взлому инфраструктуры компаний, участвующих в программах Bug Bounty. Результаты оказались неожиданно эффективными и исследователю удалось выполнить свой код на многих компьютерах разработчиков и серверах, отвечающих за сборку или тестирование на базе систем непрерывной интеграции.
При загрузке зависимостей пакетные менеджеры npm, pip и gem в первую очередь устанавливали пакеты из первичных публичных репозиториев NPM, PyPI и RubyGems, которые рассматривались как более приоритетные. Наличие аналогичных пакетов с теми же именами в приватных репозиториях компаний игнорировалось без вывода какого-либо предупреждения и не приводя к сбоям, которые бы привлекли внимание администраторов. В PyPI на приоритет загрузки влиял номер версии (независимо от репозитория загружалась наиболее свежая версия пакета). В NPM и RubyGems приоритет зависел только от репозитория.
Исследователь разместил в репозиториях NPM, PyPI и RubyGems пакеты, пересекающиеся с названиями найденных внутренних зависимостей, добавив в скрипт, запускаемый перед началом установки (preinstall в NPM), код для сбора информации о системе и отправки полученных сведений на внешний хост. Все опубликованные дубликаты пакетов был снабжены примечанием о проведении исследования. Для передачи сведений об успехе взлома в обход межсетевых экранов, блокирующих внешний трафик, использовался метод организации (https://github.com/veggiedefender/browsertunnel) скрытого канала связи поверх протокола DNS. Запускаемый код осуществлял резолвинг хоста в подконтрольном атакующему домене, что позволяло на DNS-сервере собирать информацию об успешных операциях. Передавались сведения о хосте, имени пользователя и текущем пути.
https://www.opennet.ru/opennews/pics_base/0_1612941567.png (https://miro.medium.com/max/1200/1*nTCUgLtONUx8EhnCTgunjQ.png)
75% от всех зафиксированных запусков кода были связаны с загрузкой NPM-пакетов, в основном из-за того, что имён внутренних JavaScript модулей было найдено значительно больше, чем имён зависимостей на Python и Ruby. Имена внутренних gem-пакетов были обнаружены всего у 8 компаний, из которых 4 удалось успешно атаковать через создание дубликата пакета в RubyGems. В том числе таким способом была атакована компания Shopify, сборочный сервер которой автоматически установил поддельный gem-пакет shopify-cloud спустя всего несколько часов после публикации. Поддельный Node.js-пакет idms-pmrpc был установлен на нескольких компьютерах во внутренней сети компании Apple, в том числе на сервере, связанном с сервиcом Apple ID.
В инфраструктуре Microsoft удалось выполнить Python-пакет, который был установлен на серверах, отвечающих за сборку платформы .NET Core, из публичного репозитория PyPI из-за подключения (https://github.com/dotnet/dotnet-buildtools-prereqs-docker/commit/56c6673d3aa6c6d9887a5a584b814b10da7b7177#diff-14d7481c475cdd006d8421a767a8af12330cd68de62b265516 44b3e05a3a3891L47) внутреннего репозитория при помощи опции "--extra-index-url", при которой источник загрузки определяет версия пакета. В проектах на Ruby похожий эффект достигается при использовании "gem install --source". В случае, если бы атака проводилась злоумышленниками, полученного доступа было бы достаточно для внедрения бэкдора в .NET Core.
Компания Microsoft опубликовала (https://azure.microsoft.com/en-us/resources/3-ways-to-mitigate-risk-using-private-package-feeds/) рекомендации (https://azure.microsoft.com/mediahandler/files/resourcefiles/3-ways-to-mitigate-risk-using-private-package-feeds/3%20Ways%20to%20Mitigate%20Risk%20When%20Using%20P rivate%20Package%20Feeds%20-%20v1.0.pdf) по защите сборочных систем от атак на зависимости:
В PyPI рекомендуется использовать опцию "--index-url" для переопределения приоритета обработки зависимостей, а не "--extra-index-url"
В NuGet в nuget.config в секции packageSources рекомендуется использовать запись для удаления наследуемых конфигураций и явно добавлять приватные репозитории через запись .
В Maven рекомендуется настроить одно общее зеркало при помощи опций * и перенаправлять в него все запросы к репозиториям. Другим вариантом является переопределение репозиториев по умолчанию при помощи настройки .
В NPM и Yarn в пакетах рекомендуется определить scopeprefix для привязки репозитория к каждому пакету (возможна привязка только одного репозитория).
Дополнение: Пакетный менеджер Cargo проблеме не подвержен (https://www.reddit.com/r/rust/comments/lgl7bf/is_cargo_vulnerable_to_this_supplychain_attack/), так как по умолчанию обрабатываются только пакеты с crates.io, а при использовании дополнительных репозиториев требуется явное их указание для каждой зависимости.
10.02.2021
https://www.opennet.ru/opennews/art.shtml?num=54566
Метод основан на том, что многие компании используют в своих внутренних приложениях зависимости из стандартных репозиториев NPM, PyPI и RubyGems, а также внутренние зависимости, которые не распространяются публично и загружаются из собственных репозиториев. Проблема в том, что пакетные менеджеры, такие как npm, pip и gem, пытаются загрузить внутренние зависимости компаний в том числе и из публичных репозиториев. Для атаки достаточно определить имена пакетов со внутренними зависимостями и создать собственные пакеты с такими же именами в публичных репозиториях NPM, PyPI и RubyGems. Проблема не специфична для NPM, PyPI и RubyGems, и также проявляется в других системах, таких как NuGet, Maven и Yarn.
Идея предложенного метода появилась после того, как исследователь случайно обратил внимание, что в публикуемом на GitHub общедоступном коде многие компании не очищают из manifest-файлов упоминание дополнительных зависимостей, применяемых во внутренних проектах или при реализации расширенной функциональности. Подобные следы были найдены в JavaScript-коде web-сервисов, а также Node.JS, Python и Ruby проектах многих компаний. Основные утечки были связаны со встраиванием содержимого файлов package.json в публично доступный JavaScript-код в процессе сборки проекта, а также использованием элементов реальных путей в вызовах require(), по которым можно судить об именах внутренних зависимостей.
https://www.opennet.ru/opennews/pics_base/0_1612947278.png (https://miro.medium.com/max/840/1*kXIpJ2pZhu40yT17cbwheg.png)
Сканирование нескольких миллионов корпоративных доменов позволило выделить несколько тысяч имён JavaScript-пакетов, отсутствующих в репозитории NPM. Собрав базу внутренних имён пакетов исследователь решился на эксперимент по взлому инфраструктуры компаний, участвующих в программах Bug Bounty. Результаты оказались неожиданно эффективными и исследователю удалось выполнить свой код на многих компьютерах разработчиков и серверах, отвечающих за сборку или тестирование на базе систем непрерывной интеграции.
При загрузке зависимостей пакетные менеджеры npm, pip и gem в первую очередь устанавливали пакеты из первичных публичных репозиториев NPM, PyPI и RubyGems, которые рассматривались как более приоритетные. Наличие аналогичных пакетов с теми же именами в приватных репозиториях компаний игнорировалось без вывода какого-либо предупреждения и не приводя к сбоям, которые бы привлекли внимание администраторов. В PyPI на приоритет загрузки влиял номер версии (независимо от репозитория загружалась наиболее свежая версия пакета). В NPM и RubyGems приоритет зависел только от репозитория.
Исследователь разместил в репозиториях NPM, PyPI и RubyGems пакеты, пересекающиеся с названиями найденных внутренних зависимостей, добавив в скрипт, запускаемый перед началом установки (preinstall в NPM), код для сбора информации о системе и отправки полученных сведений на внешний хост. Все опубликованные дубликаты пакетов был снабжены примечанием о проведении исследования. Для передачи сведений об успехе взлома в обход межсетевых экранов, блокирующих внешний трафик, использовался метод организации (https://github.com/veggiedefender/browsertunnel) скрытого канала связи поверх протокола DNS. Запускаемый код осуществлял резолвинг хоста в подконтрольном атакующему домене, что позволяло на DNS-сервере собирать информацию об успешных операциях. Передавались сведения о хосте, имени пользователя и текущем пути.
https://www.opennet.ru/opennews/pics_base/0_1612941567.png (https://miro.medium.com/max/1200/1*nTCUgLtONUx8EhnCTgunjQ.png)
75% от всех зафиксированных запусков кода были связаны с загрузкой NPM-пакетов, в основном из-за того, что имён внутренних JavaScript модулей было найдено значительно больше, чем имён зависимостей на Python и Ruby. Имена внутренних gem-пакетов были обнаружены всего у 8 компаний, из которых 4 удалось успешно атаковать через создание дубликата пакета в RubyGems. В том числе таким способом была атакована компания Shopify, сборочный сервер которой автоматически установил поддельный gem-пакет shopify-cloud спустя всего несколько часов после публикации. Поддельный Node.js-пакет idms-pmrpc был установлен на нескольких компьютерах во внутренней сети компании Apple, в том числе на сервере, связанном с сервиcом Apple ID.
В инфраструктуре Microsoft удалось выполнить Python-пакет, который был установлен на серверах, отвечающих за сборку платформы .NET Core, из публичного репозитория PyPI из-за подключения (https://github.com/dotnet/dotnet-buildtools-prereqs-docker/commit/56c6673d3aa6c6d9887a5a584b814b10da7b7177#diff-14d7481c475cdd006d8421a767a8af12330cd68de62b265516 44b3e05a3a3891L47) внутреннего репозитория при помощи опции "--extra-index-url", при которой источник загрузки определяет версия пакета. В проектах на Ruby похожий эффект достигается при использовании "gem install --source". В случае, если бы атака проводилась злоумышленниками, полученного доступа было бы достаточно для внедрения бэкдора в .NET Core.
Компания Microsoft опубликовала (https://azure.microsoft.com/en-us/resources/3-ways-to-mitigate-risk-using-private-package-feeds/) рекомендации (https://azure.microsoft.com/mediahandler/files/resourcefiles/3-ways-to-mitigate-risk-using-private-package-feeds/3%20Ways%20to%20Mitigate%20Risk%20When%20Using%20P rivate%20Package%20Feeds%20-%20v1.0.pdf) по защите сборочных систем от атак на зависимости:
В PyPI рекомендуется использовать опцию "--index-url" для переопределения приоритета обработки зависимостей, а не "--extra-index-url"
В NuGet в nuget.config в секции packageSources рекомендуется использовать запись для удаления наследуемых конфигураций и явно добавлять приватные репозитории через запись .
В Maven рекомендуется настроить одно общее зеркало при помощи опций * и перенаправлять в него все запросы к репозиториям. Другим вариантом является переопределение репозиториев по умолчанию при помощи настройки .
В NPM и Yarn в пакетах рекомендуется определить scopeprefix для привязки репозитория к каждому пакету (возможна привязка только одного репозитория).
Дополнение: Пакетный менеджер Cargo проблеме не подвержен (https://www.reddit.com/r/rust/comments/lgl7bf/is_cargo_vulnerable_to_this_supplychain_attack/), так как по умолчанию обрабатываются только пакеты с crates.io, а при использовании дополнительных репозиториев требуется явное их указание для каждой зависимости.
10.02.2021
https://www.opennet.ru/opennews/art.shtml?num=54566