Это первый эпизод в серии статей о наиболее распространенных видах атак на цепочки поставок программного обеспечения: тех, которые (ab) используют общедоступный реестр программных компонентов, предназначенных для проекты с открытым исходным кодом для загрузки артефактов, которыми можно поделиться с другими пользователями. Когда злоумышленники публикуют там вредоносное программное обеспечение, используя реестр в качестве средства распространения вредоносного ПО, мы имеем атаку на цепочку поставок, когда организации-жертвы устанавливают или запускают зараженный программный компонент.
Для упрощения обсуждения мы поговорим о пакеты программ:, комплектующие в упакованном виде производства третьих лиц. Сюда входят не только компоненты, используемые менеджерами пакетов, такими как NPM или Poetry, но и компоненты операционной системы включая библиотеки и исполняемые двоичные файлы, изображения контейнеров, и виртуальные машины или расширения инструментов для инструментов разработки, сборки и развертывания. Мы видели вредоносные пакеты повсюду. Киберпреступники не против: они в восторге от альтернатив, предоставляемых современными программными инфраструктурами, и используют реестр и инструмент, который лучше всего соответствует их намерениям. Поэтому, пожалуйста, помните, что программные пакеты — это сокращение для образов контейнеров, двоичных пакетов, репозиториев с открытым исходным кодом и расширений или плагинов всех видов (IDE, CI/CD системы, инструменты сборки). Все они регулярно подвергаются атакам.
В сериале будет 5 серий:
- В чем проблема с пакетами с открытым исходным кодом? Это тема этого поста. Почему преступники всех мастей публикуют вредоносные пакеты? Почему я должен беспокоиться?
- Анатомия вредоносных пакетов: каковы тенденции? В этом выпуске мы сосредоточимся на угрозе, которую изо дня в день отслеживаем с помощью нашей системы MEW. При большом фоновом шуме из-за большого количества вредоносных пакетов, использующих опечатки или путаницу зависимостей, меньший процент атак гораздо более коварен и представляет больший риск. Как изменилось поведение злоумышленников в отношении ОС в недавнем прошлом? Какие цифры? Какова используемая тактика, методы и процедуры, а также замеченные вредные действия?
- Защита от вредоносных пакетов с открытым исходным кодом: что (не) работает. Большинство профессионалов, знающих о безопасности, имеют идеи о том, как справиться с этой угрозой. Мы слышали, как менеджеры по безопасности говорили без колебаний, что SCA инструменты уже сообщают вам, когда версия пакета является вредоносным ПО. Или что они зависят от известных, тщательно проверенных программных компонентов, где любое вредоносное ПО будет быстро обнаружено и удалено. Они Что они используют открытые второстепенные/патч-версии для автоматического получения исправлений уязвимостей, и это правильный, рекомендуемый способ снизить риск для зависимостей с открытым исходным кодом, следуя принципу «исправлять рано, исправлять часто». В этом эпизоде мы рассмотрим, почему эти идеи неверны, и как такие заблуждения способствуют популярности этого механизма атаки и подавляющему риску, которому подвергаются организации. Мы закончим тем, что работает, и что требует усилий и ресурсов.
- Вредоносные пакеты с открытым исходным кодом: подход Xygeni. В этом выпуске мы представляем, какой стратегии мы придерживаемся в Xygeni в отношении нашей системы раннего предупреждения о вредоносных программах (MEW). Как эта многоэтапная система работает в режиме реального времени, когда публикуется новая версия пакета, как собираются доказательства из разных источников, как осуществляется сортировка, каким критериям классификации мы следуем и почему для подтверждения все еще необходим ручной анализ природа потенциального вредоносного пакета? Как обратная связь от наших внутренних команд и сотрудников реестра помогает системе учиться на прошлых фактах, собранных, чтобы свести ложноположительные результаты к минимуму. Мы объясним, как мы помогаем NPM, GitHub, PyPI и другим ключевым инфраструктурам в экосистемах с открытым исходным кодом сократить время ожидания..
- Использование открытого исходного кода: чего ожидать от плохих парней. В конце серии рассказывается о новейших действиях, которые предпринимают злоумышленники, чтобы сделать атаки более скрытными, труднее обнаружить, более нацеленными на конкретные отрасли и извлечь больше выгоды из этого класса атак. Будут ли с помощью этого транспортного средства осуществляться атаки с использованием программ-вымогателей? Как злоумышленники используют инструменты искусственного интеллекта для доставки более сложных вредоносных пакетов? Топ-популярные проекты в опасности? Это сделано для того, чтобы дать читателям представление об этой гонке вооружений и о том, чего ожидать в краткосрочной (вторая половина 2024 года) и среднесрочной перспективе (2025 год). Мы узнаем, как атаки, подобные недавней, Бэкдор XZ-Utilsили нападение живущих за счет земли на строитель электронов в марте 2024 года показывают, что нам следует внимательно следить за развитием противников.
Давайте начнем с первого эпизода: что происходит с вредоносными пакетами с открытым исходным кодом?
В чем проблема с пакетами с открытым исходным кодом?
В последние годы злоумышленники всех мастей использовали реестры программного обеспечения с открытым исходным кодом для реализации вредоносного поведения. Этим видам деятельности столько же лет, сколько и открытому исходному коду, но за последние три года их частота резко возросла.
Публикация вредоносных компонентов в публичные реестры (атаки на основе зависимостей) — это асимметричная партизанская война, которую злоумышленники используют для распространения вредоносного ПО, используя доверие, которое организации оказывают компонентам с открытым исходным кодом, исходящим от неизвестных разработчиков (помните зависимость xkcd комикс?). Поскольку вы доверяете пакетам и не против вручную просмотреть их содержимое и его зависимости, эти атаки чрезвычайно эффективны. А асимметрия возникает потому, что они могут быть в значительной степени автоматизированы, и злоумышленникам не нужно напрямую взаимодействовать с жертвой. Они просто загружают пакет в публичный реестр и отпускают его.
Вредоносные пакеты вырос в 6 раз в 2022 годуи продолжил расти в 2.5 раза в 2023 году. В прошлом году было обнаружено колоссальные 245,000 2021 вредоносных пакетов, что более чем вдвое превышает общее количество за предыдущие годы вместе взятые. Это экспоненциальный рост! Из удалений пакетов как подтвержденных вредоносных программ, исчислявшихся сотнями в 2022 году и тысячами в 2023 году, мы наблюдали гораздо больше фонового «шума» в XNUMX году, с такими же темпами в этом году. И на этом фоне, вызванном неискушенными киберпреступниками, идущими по «пути наименьшего сопротивления», небольшая часть громких атак попала в заголовки даже в обычных СМИ.
Почему это проблема такого масштаба? Есть превышение доверия по всей цепочке. Программное обеспечение с открытым исходным кодом распространяется вместе с исходным кодом и выпускается под определенной лицензией. Да, любой может проверить исходный код; но кто это делает в целом? Кто, проверив, что программное обеспечение не содержит вредоносного ПО, собирает программное обеспечение из исходных кодов? Кто перед передачей упакованного компонента (также известного как пакет) далее к менеджеру пакетов или инструменту сборки, проверяет, что пакет не пронизан вредоносным ПО и соответствует предполагаемому исходному коду, из которого он должен быть получен?
Почему инфраструктура допускает такие простые атаки?
Реестры пакетов открыты и часто требуют минимальной проверки личности издателя. «Любой желающий может публиковать здесь свое программное обеспечение!» Планка для злоумышленников установлена низкая: они используют одноразовые адреса электронной почты и одноразовые учетные записи GitHubgithub для создания сотен вредоносных пакетов в рамках коротких фишинговых кампаний. Только для целевых требуется более высокая сложность: мы видели даже создание надежного исходного репозитория GitHub со многими звездами и commitот нескольких фейковых участников и других показателей популярности и поддержки. Получающий звездочеты и репутация от фейковых вкладов не сложно автоматизировать. Мы видели злоупотребления в отношении открытых программных инфраструктур всех видов, а не только вредоносных программ, таких как инцидент с чайным протоколом.
Менеджеры пакетов были разработаны для простоты использования, а не для обеспечения безопасности.. Они могут запускать сценарии до и после установки (иногда требуется компиляция собственного кода библиотеки). Также, Менеджеры пакетов устанавливать пакеты из нескольких источников, а иногда по умолчанию используется общедоступные реестры. Они не проверяли несоответствие метаданных в запросе на публикацию и метаданных в самом пакете.
Зависимости вложены и образуют граф. В некоторых экосистемах, таких как Node (JavaScript), мелкие зависимости накапливаются сотнями или тысячами. Одно дело — иметь строгий контроль над прямыми зависимостями, заявленными в моих программных проектах, но транзитивные зависимости их труднее контролировать. Открытый исходный код последовал за «друзья моих друзей — мои друзья». Братство – это норма на диком Дальнем Востоке! Злоумышленники знают об этом и глубоко скрывают свое вредоносное поведение в неясных зависимостях, которые часто неизвестны. Так было с поток событий инцидент, направленный на Копай кошелек.
Именно так работало программное обеспечение с открытым исходным кодом с момента его создания. Это не сильно изменится. Некоторые реестры пакетов требуют в лучшем случае двухфакторной аутентификации, и часто только для самых популярных пакетов. Некоторые реестры предоставляют области действия — пространство имен, принадлежащее проверенной организации, но трагически другие не поддерживают его (PyPI) или делают его необязательным (NPM). Интересно отметить, что даже простая схема проверки (на основе контроля DNS или репозитория/организации GitHub, соответствующего идентификатору группы) и создания Подписи PGP обязательны для всех артефактов, кроме контрольных сумм, удаляет большую часть «шума», вредоносных пакетов, похожих на опечатки, и ограничивает большую часть путаница с зависимостями. Сложные атаки возможны, но гораздо сложнее, и лишь немногие из них похожи на com.github.codingandcoding:maven-компилятор-плагин известен Maven Central. И не все реестры Maven следуют одной и той же практике!
Меры безопасности в менеджерах пакетов могут обременять, но не препятствовать атакам на основе зависимостей. Проблема с многофакторной аутентификацией заключается в том, что для автоматизации производные учетные данные, такие как токены доступа или ключи APIapi, генерируются для учетных записей, которые будут использоваться в вызовах APIapi, выполненных из сценариев автоматизации, без поддержки интерактивного пользователя, предоставляющего второй фактор. MFA хорош для защиты учетных записей пользователей от утечки паролей, но сгенерированные токены доступа или ключи APIapi должны быть защищены, пока они активны, иначе злоумышленники будут выдавать себя за их владельца. Большая часть кампаний по цепочке поставок, основанных на пакетах, начинается с утечки ключа/токена. Просто помните такие случаи, как Ledger, 3CXи многие другие, где неинтерактивные учетные данные были впервые похищены в ходе предварительного взлома для запуска атаки на цепочку поставок.
Ответ на эту угрозу оказался недостаточно надежным. В третьем эпизоде мы сосредоточимся на том, что сработало, а что с треском провалилось. Отрасли необходимо работать сообща над standards, процессы, образование и инструменты для снижения рисков в глобальных цепочках поставок. Это не та проблема, которую может решить одна организация в одиночку.
В заключение этого раздела хотелось бы сказать о решающем недоразумении: мы говорим о злонамеренный пакеты, не жертвами те. Уязвимости возникают из-за ошибок проектирования или кодирования, случайно внесенных без злого умысла. Уязвимости могут быть использованы, но многие из них не используются. Вредоносные пакеты всегда создаются намеренно, и в случае их выполнения существует 100% вероятность использования. Никакого сопоставимого риска! Следовательно парадоксально видеть, сколько усилий затрачивается на обнаружение и устранение уязвимостей, а также отсутствие эквивалентных мер для вредоносных компонентов..
«Мы серьезно относимся к безопасности»
Давайте представим себе привычное Корпорация Акме. Acme, крупный поставщик WileCoyote.com, большую часть программного обеспечения предоставляет сторонние компании, причем более 80% — из проектов с открытым исходным кодом. Они производят программное обеспечение для внутреннего использования, но также предоставляют программное обеспечение своим партнерам, поставщикам и клиентам/конечным пользователям. У Acme есть программное обеспечение, написанное на Go, JavaScript, Java, C# и Python, и большая часть его программного обеспечения работает в облаке, в кластерах Kuberneteskubernetes. Acme создает свои собственные образы на основе базовых образов, взятых из Docker Hub и других реестров. Кроме того, они совместно используют несколько библиотек, пакетов и образов контейнеров в публичных реестрах.
Acme серьезно относится к безопасности. Они прекрасно осведомлены о проблеме open source securityи риск, который он несет. Все разработчики, системные менеджеры и инженеры DevOpsdevops используют эти милые маленькие криптоключи в качестве второго фактора аутентификации. Все commits для репозиториев кода подписаны, включена защита ветвей с обязательными проверками кода, CI/CD заперты, секреты хранятся в секретном хранилище, а внутренний реестр частично отражает внешние реестры, в которых хранятся только разрешенные компоненты из белого списка. Требуется, чтобы программное обеспечение, созданное Acme, брало сторонние зависимости из этого реестра.
Вероятно, большинство организаций соответствуют этому профилю. Дорогой читатель, твой наверняка подойдет, если ты еще здесь, не так ли?
И вот в один злополучный день важный фронтенд-разработчик в Акме побежал npm установить acme-cute-lib, забывая, что @acme/cute-lib — это зависимость с правильной областью действия. Точная ошибка не важна, многие вещи могут пойти не так, даже если предполагается полный контроль над жизненным циклом программного обеспечения. Наш разработчик не знал, что группа APT нацелена на Acme, и опубликовал вредоносный компонент под этим именем, причем таким хитрым способом, что вредоносное поведение активируется только тогда, когда программное обеспечение установлено на компьютерах Acme. Пакет не был обнаружен в течение нескольких недель после его публикации.
Запускается установочный скрипт, который ищет учетные данные (в ноутбуке нашего разработчика было много важных токенов доступа), разрешающий доступ к внутренним репозиториям программного обеспечения и вышеупомянутому внутреннему репозиторию, который, конечно, доступен только через VPN. Вредоносному коду удалось использовать существующее VPN-соединение и опубликовать вредоносный компонент второго уровня во внутреннем реестре, затронув общую библиотеку утилит, используемую большей частью программного обеспечения, поставляемого Acme.
Спустя несколько недель другие организации, использующие опубликованные инструменты Acme, начали замечать странный трафик в своих сетях: трафик, использующий протокол Acme, но направленный на хосты, напоминающие домен Acme. Трафик был зашифрован, но инструменты системного мониторинга обнаружили доступ к неожиданным файлам и выполнению процессов, которые выглядят как системные команды, но в конечном итоге запускают загруженные исполняемые файлы.
Остальное уже история: Acme сначала отрицала, что такое поведение было вменено им в вину и что были приняты все меры безопасности. Только после того, как средства массовой информации, занимающиеся кибербезопасностью, начали задаваться вопросом, почему источником обнаруженного поведения являются компоненты Acme, а анализ безопасности показал, насколько эти компоненты пронизаны скрытым вредоносным ПО, Acme пришлось распознать инцидент и вызвать фирму, занимающуюся реагированием на инциденты. Негативная маркетинговая кампания, за секунду подорвавшая с трудом заработанное доверие. «Acme был на расстоянии одной установки npm от disaster» был обычным заголовком. Затем последовали судебные иски и расторжение контрактов.
Видите ли вы сходства с известными прошлыми инцидентами? Acme упала до инцидента в цепочке поставок, состоящего из двух этапов, с использованием сочетания путаница в зависимостях/опечатки атаки, в которых рабочая станция разработчика использовалась в качестве плацдарма для заражения компонентов, которые в конечном итоге попали в программное обеспечение, используемое третьими сторонами. Как это можно предотвратить или смягчить?
Почему отравленные посылки так популярны
Этот гипотетический инцидент показывает, что даже при разумном подходе к безопасности с открытым исходным кодом организациям необходимы конкретные меры, чтобы не стать жертвой вредоносного ПО в компонентах с открытым исходным кодом. Схематично, злоумышленник может:
- Создайте новый пакет (следуя известным путям опечаток или путаницы зависимостей, это наиболее проходимый путь злоумышленников по объему);
- Попробуйте заразить существующий, либо внедрив его в исходный код, либо попытавшись замаскировать его под участника через pull requestили использовать социальную инженерию, чтобы стать сопровождающим (как это сделал «Джао Тан» в XZ Backdoor или right9ctrl Пользователь GitHub сделал это в поток событий инцидент осенью 2018 года) или получив учетные данные репозитория с открытым исходным кодом и выдав себя за сопровождающего;
- Внедрить вредоносное ПО во время сборки пакета, либо запустив вредоносный сценарий сборки.или вмешательство в загрузку пакетов с помощью перехвата «человек посередине» (к счастью, TLS теперь всегда требуется в большинстве реестров).
- Внедрите упакованный компонент непосредственно в реестр, обычно путем перехвата учетных данных реестра (предпочтительная альтернатива для многих сложных атак, таких как атака Acme, когда скомпрометированная рабочая станция на первом этапе имела внутренний токен доступа к реестру, например, в обычном режиме). .env or ~/.m2/settings.xml: плохие актеры знают, где искать секреты). Также использовались уязвимости в реестрах.
Отравление реестров вредоносным ПО является основой для атак на основе зависимостей. Ничего нового под солнцем: его распространенность резко возросла, но сейчас работают те же методы, что и пять лет назад.
Источник: Коллекция ножей предателя.
Вредоносный пакет может действовать во время установки, сборки программного обеспечения или во время выполнения. Поведение варьируется от кражи информации, например, извлечения секретов для второй фазы, до извлечения исходного кода и удаления дополнительных вредоносных программ. В следующем выпуске мы разберем вредоносные пакеты и способы их публикации.
Далее
Следующий эпизод Анатомия вредоносных пакетов: каковы тенденции? сосредоточимся на реальных случаях, которые мы день за днем отслеживаем с помощью нашей системы раннего предупреждения о вредоносных программах. Мы рассмотрим, какие типы вредоносных программ были замечены и какие тактики, методы и процедуры являются фаворитами. Мы рассмотрим запутывание и то, как они пытаются скрыться от потенциальных рецензентов, методы уклонения, чтобы избежать обнаружения, и как они развиваются с помощью телеметрии и бокового движения. Пожалуйста, не переключайтесь!
Референсы
- Коллекция ножей Backstabber: обзор атак на цепочку поставок программного обеспечения с открытым исходным кодом. М. Ом и др., май 2020 г.
- Защита от вредоносного ПО с открытым исходным кодом. Технический документ от Xygeni.
- Software Supply Chain Security Ретроспектива: формирование более безопасного 2024 года. Репортаж от Xygeni.
