Не все атаки на цепочку поставок программного обеспечения одинаковы. Вот методы, которые в настоящее время используют злоумышленники для повреждения легального программного обеспечения через третьих лиц.
ОГЛАВЛЕНИЕ
Общий термин «атака цепочки поставок» охватывает любой случай, когда злоумышленник вмешивается или захватывает процесс производства программного обеспечения (жизненный цикл разработки программного обеспечения), так что это наносит ущерб множеству потребителей готового продукта или услуги. Это может произойти, когда библиотеки кода или отдельные компоненты, используемые в сборке программного обеспечения, испорчены, когда двоичные файлы обновлений программного обеспечения являются троянскими, украдены сертификаты подписи кода или даже когда сервер, на котором размещается программное обеспечение как услуга (SaaS), скомпрометирован.
При любой атаке на цепочку поставок программного обеспечения злоумышленники вмешиваются либо в восходящий, либо в промежуточный поток, чтобы донести свои вредоносные действия и их последствия до многих пользователей. Таким образом, по сравнению с изолированным нарушением безопасности успешные атаки на цепочку поставок имеют гораздо больший масштаб с далеко идущими последствиями.
Здесь мы исследуем шесть различных методов, использованных в недавних реальных успешных атаках на цепочку поставок программного обеспечения.
1. Компрометация вышестоящего сервера: атака Codecov
В большинстве атак цепочки поставок программного обеспечения злоумышленник взламывает вышестоящий сервер или репозиторий кода и внедряет вредоносную полезную нагрузку (например, вредоносную строку кода или троянские обновления). Эти полезные данные затем распределяются по нисходящему потоку для многих пользователей. Однако с технической точки зрения это не всегда так.
Атака на цепочку поставок Codecov - один из таких примеров. Хотя инцидент сравнивают с взломом SolarWinds, между этими двумя атаками есть существенные различия. Нарушение цепочки поставок SolarWinds было делом рук изощренных злоумышленников, которые изменили законный двоичный файл обновления, SolarWinds.Orion.Core.BusinessLayer.dll, который был частью продукта Orion для мониторинга производительности ИТ SolarWinds.
Как было ранее проанализировано FireEye, вредоносный код, содержащийся в методе RefreshInternal () поддельной DLL, показан ниже. Этот метод вызывает бэкдор на основе HTTP, когда Orion загружает плагин Inventory Manager:
Версия 2019.4.5200.9083 библиотеки DLL с бэкдором с вредоносным методом RefreshInternal
Однако восходящая атака SolarWinds обрела полную силу только тогда, когда измененный двоичный код распространился вниз по течению к более чем 18 000 клиентов SolarWinds Orion, включая правительственные учреждения США.
В случае с Codecov, однако, вредоносный код не распространялся ниже по потоку, но распространялись последствия атаки. Злоумышленники Codecov получили учетные данные из некорректного процесса создания образа Docker, которые можно было использовать для изменения Codecov Bash Uploader в соответствии с официальными рекомендациями по безопасности. Затем злоумышленники модифицировали загрузчик Codecov Bash, размещенный на самом сервере Codecov, чтобы собирать переменные среды, загружаемые из сред непрерывной интеграции / непрерывной доставки (CI / CD) клиентов:
Модифицированная строка программы Codecov Bash Uploader, которая собирала переменные среды и отправляла их на IP-адрес злоумышленника
Модифицированная строка Bash Uploader от Codecov, которая собирала переменные среды и отправляла их на IP-адрес злоумышленника.
Хотя сценарий Codecov Bash Uploader жил (и продолжает существовать) на самом сервере Codecov в codecov [.] Io / bash, тысячи репозиториев уже указывали на ссылку для отправки информации из своих сред CI / CD в этот Bash Uploader. Таким образом, вредоносный код оставался только на (скомпрометированном) вышестоящем сервере без какого-либо последующего распространения кода, поскольку так называемые подчиненные репозитории уже указывали на сервер Codecov, на котором размещался сценарий Bash Uploader. Тем не менее, эти нижестоящие репозитории были затронуты этой атакой, поскольку они были настроены для загрузки своих данных в загрузчик Bash от Codecov:
Фактически, как сообщается, злоумышленники Codecov взломали сотни клиентских сетей, используя учетные данные, полученные от взломанного Bash Uploader. Вскоре после этого HashiCorp сообщила, что инцидент с Codecov привел к раскрытию ее закрытого ключа GPG, используемого для подписи и проверки пакетов программного обеспечения. Twilio также сообщила о некотором влиянии атаки, и другие компании выступают с аналогичными заявлениями.
2. Компрометация промежуточного уровня для рассылки вредоносных обновлений.
Термин «промежуточное звено» здесь вольно применяется для обозначения случаев, когда злоумышленники скомпрометируют промежуточные функции обновления программного обеспечения или инструмент CI / CD, а не исходную базу исходного кода восходящего потока. В прошлом месяце Click Studios, разработчики корпоративного менеджера паролей Passwordstate, используемого многими компаниями из списка Fortune 500, уведомили клиентов об атаке на цепочку поставок. Злоумышленники скомпрометировали функцию Passwordstate «Обновление на месте», чтобы распространять вредоносные обновления среди пользователей Passwordstate.
Незаконное обновление содержало измененный файл DLL с названием Moserware.SecretSplitter.dll, небольшая часть которого показана ниже:
В рекомендациях по безопасности Click Studios говорится:
Эта атака на цепочку поставок имела не только технический аспект (т. е. вмешательство в процесс обновления), но и аспект социальной инженерии. В поддельном zip-файле обновления, размер которого превышает 300 МБ, я обнаружил, что злоумышленникам удалось изменить руководства пользователя, файлы справки и сценарии сборки PowerShell, чтобы они указывали на свой сервер сети распространения вредоносного контента (CDN):
Один из документов справочного руководства, в котором вредоносный сервер CDN указан как официальный
Сценарий установки PowerShell, содержащий вредоносные ссылки на сервер CDN
Аспект социальной инженерии этой атаки также демонстрирует еще одну слабость: люди (особенно новые разработчики или потребители программного обеспечения) не всегда могут подозревать ссылки на сети распространения контента (CDN), независимо от того, являются они подозрительными или нет. Это связано с тем, что сети CDN законно используются программными приложениями и веб-сайтами для доставки обновлений, сценариев и другого контента.
Интернет кредитных карт атака скимминг, такие как Magecart еще один пример такого рода цепочка поставок атаки. В некоторых атаках корзины CDN Amazon CloudFront были скомпрометированы для распространения вредоносного кода JavaScript на большее количество веб-сайтов, использующих такие CDN.
3. Атаки путаницы зависимости
В 2021 году ни одна часть атак на цепочки поставок не может быть завершена без упоминания путаницы в зависимостях, особенно из-за упрощенного и автоматизированного характера этой атаки. Атаки на основе путаницы зависимостей работают с минимальными усилиями со стороны злоумышленника и в автоматическом режиме из-за присущих им конструктивных недостатков, обнаруженных во многих экосистемах с открытым исходным кодом.
Проще говоря, путаница с зависимостями (или путаница с пространством имен) работает, если ваша программная сборка использует частную, внутренне созданную зависимость, которой нет в общедоступном репозитории с открытым исходным кодом. Злоумышленник может зарегистрировать зависимость с тем же именем в публичном репозитории с более высоким номером версии. Тогда весьма вероятно, что (общедоступная) зависимость злоумышленника с более высоким номером версии будет включена в вашу сборку программного обеспечения, в отличие от вашей внутренней зависимости.
Иллюстрация слабости, связанной с путаницей зависимостей, озадачивающей несколько экосистем
Используя эту простую слабость в широко используемых экосистемах, включая PyPI, npm и RubyGems, этичный хакер Алекс Бирсан смог взломать 35 крупных технологических фирм и получить вознаграждение за баг-баунти на сумму более 130 000 долларов.
Через несколько дней после открытия исследования Бирсана тысячи пакетов-подражателей путаницы зависимостей начали наводнять PyPI, npm и другие экосистемы. Хотя большинство этих подражателей были созданы другими честолюбивыми охотниками за ошибками, некоторые зашли слишком далеко, злонамеренно нацелившись на известные компании.
Существует несколько способов устранить путаницу с зависимостями, включая регистрацию (резервирование) имен всех ваших частных зависимостей в общедоступных репозиториях до того, как это сделает злоумышленник, и использование автоматизированных решений, таких как брандмауэр жизненного цикла разработки программного обеспечения (SDLC), который предотвращает ввод конфликтующих имен зависимостей. ваша цепочка поставок.
Владельцы репозиториев с открытым исходным кодом могут применить более строгий процесс проверки и ввести в действие пространство имен / область видимости. Например, для публикации пакетов в пространстве или области имен «CSO» репозиторий с открытым исходным кодом может проверить, имеет ли разработчик, загружающий пакет, права на это под именем «CSO».
Репозиторий компонентов Java Maven Central использует простую проверку на основе домена для проверки владения пространством имен - практику, которую можно легко смоделировать в других экосистемах.
Точно так же пакеты, опубликованные в репозитории пакетов Go, называются по URL-адресу их репозитория GitHub, что делает атаки путаницы зависимостей гораздо более сложными, если не полностью невозможными.
4. Украденные сертификаты SSL и подписи кода.
С увеличением количества веб-сайтов HTTPS сертификаты SSL / TLS теперь присутствуют повсеместно и защищают ваши онлайн-коммуникации. Таким образом, компрометация закрытого ключа сертификата SSL может поставить под угрозу безопасную связь и надежность, обеспечиваемую сквозным шифрованным соединением для конечных пользователей.
В январе 2021 года Mimecast сообщила, что сертификат, используемый ее клиентами для подключения к службам Microsoft 365 Exchange, был скомпрометирован, что может повлиять на связь примерно 10% пользователей Mimecast. Хотя Mimecast явно не подтвердил, был ли это сертификат SSL, как подозревают некоторые исследователи, в основном это так .
В то время как скомпрометированный сертификат SSL проблематичен, украденный сертификат подписи кода (т. е. скомпрометированный закрытый ключ) может иметь гораздо более серьезные последствия для безопасности программного обеспечения. Злоумышленники, получившие закрытый ключ для подписи кода, потенциально могут подписать свое вредоносное ПО как подлинное программное обеспечение или обновление, поставляемое уважаемой компанией.
Хотя Stuxnet остается ярким примером изощренной атаки, в которой злоумышленники использовали украденные закрытые ключи от двух известных компаний, чтобы подписать свой вредоносный код как «доверенный», такие атаки процветали до Stuxnet и продолжаются даже годы спустя. Вот почему вышеупомянутый пример раскрытия секретного ключа GPG HashiCorp в атаке цепочки поставок Codecov является проблематичным. Хотя пока нет никаких указаний на то, что взломанный ключ HashiCorp использовался злоумышленниками для подписи вредоносного ПО, такой инцидент был реальной возможностью до тех пор, пока скомпрометированный ключ не был отозван.
5. Ориентация на инфраструктуру CI / CD разработчиков.
Sonatype недавно наблюдала многогранную атаку на цепочку поставок программного обеспечения, которая не только опиралась на внедрение вредоносных запросов на вытягивание в проект GitHub пользователя, но также использовала инфраструктуру автоматизации CI / CD GitHub, GitHub Actions, для добычи криптовалюты. GitHub Actions предоставляет разработчикам возможность планировать автоматические задачи CI / CD для репозиториев, размещенных на GitHub.
Атака состояла в том, что злоумышленники клонировали законные репозитории GitHub, которые использовали GitHub Actions, немного изменили сценарий GitHub Action в репозитории и отправили владельцу проекта запрос на перенос, чтобы внести это изменение обратно в исходный репозиторий.
Злоумышленник (edgarfox1982) отправляет запрос на перенос законному владельцу проекта для объединения измененного кода
Если владелец проекта случайно утвердит измененный запрос на вытягивание, атака на цепочку поставок будет успешной, но это даже не было предварительным условием здесь. Вредоносный запрос на вытягивание содержал изменения в ci.yml, которые автоматически запускались GitHub Actions, как только злоумышленник отправил запрос на вытягивание. Модифицированный код по сути злоупотребляет серверами GitHub для добычи криптовалюты.
Такая атака убивает двух зайцев одним выстрелом: она обманом заставляет разработчика принять злонамеренный запрос на вытягивание, а в случае неудачи он злоупотребляет имеющейся автоматизированной инфраструктурой CI / CD для проведения злонамеренных действий.
Точно так же исследователи, которые успешно взломали домены Организации Объединенных Наций (ООН) и получили доступ к более чем 100 000 сотрудников ЮНЕП, могли сделать это в основном потому, что они обнаружили в этих доменах открытые папки Git и файлы «git-credentials». Злоумышленник, получивший доступ к учетным данным Git, может не только клонировать частные репозитории Git, но и потенциально внедрить вредоносный код в восходящий поток, чтобы инициировать атаку цепочки поставок, которая будет иметь гораздо более суровые последствия.
Основное внимание тех, кто стремится предотвратить атаки на цепочку поставок, было направлено на то, чтобы рекомендовать разработчикам методы безопасного кодирования или использовать инструменты автоматизации DevSecOps в средах разработки. Однако защита конвейеров CI / CD (например, серверов Jenkins), облачных контейнеров и дополнительных инструментов и инфраструктуры разработчика теперь стала не менее важной.
6. Использование социальной инженерии для удаления вредоносного кода.
Как известно любому специалисту по безопасности, безопасность настолько сильна, насколько сильна ее самое слабое звено. Поскольку человеческий фактор остается самым слабым звеном, эксплуатация может происходить там, где ее меньше всего ожидают. Linux Foundation недавно запретил исследователям из Университета Миннесоты, которые предлагали преднамеренно исправлять ошибки, которые, в свою очередь, вносили уязвимости в исходный код ядра Linux.
Хотя экземпляр был пойман и теперь с ним разбирались, он демонстрирует несколько простых фактов: разработчики разбросаны по размеру и не всегда могут иметь пропускную способность для проверки каждой отдельной фиксации кода или предлагаемого изменения кода, которое может быть ошибочным или откровенно вредоносным. Что еще более важно, социальная инженерия может поступать из наименее подозреваемых источников - в данном случае из надежных университетских исследователей с адресом электронной почты «.edu».
Другой недавний пример включает в себя то, как любой соавтор, участвующий в проекте GitHub, может изменить выпуск даже после его публикации. И здесь владелец проекта ожидает, что большинство участников отправят код и добросовестно примут участие в своем проекте. Достаточно одного сотрудника, чтобы обмануть и поставить под угрозу безопасность цепочки поставок для многих.
За последний год, злоумышленники создают Typosquatting и brandjacking программных пакетов неоднократно целевых разработчиков с открытым исходным кодом, чтобы ввести вредоносный код в их верховьях строит, который затем распространяется для многих потребителей.
Все эти примеры из реальной жизни демонстрируют различные слабые стороны, векторы атак и методы, которые злоумышленники используют для успешных атак на цепочку поставок. Поскольку эти атаки продолжают развиваться и создавать проблемы, для обеспечения безопасности программного обеспечения требуются более инновационные решения и стратегии.
ОГЛАВЛЕНИЕ
- 1. Компрометация вышестоящего сервера: атака Codecov
- 2. Компрометация промежуточного уровня для рассылки вредоносных обновлений.
- 3. Атаки путаницы зависимости
- 4. Украденные сертификаты SSL и подписи кода.
- 5. Ориентация на инфраструктуру CI / CD разработчиков.
- 6. Использование социальной инженерии для удаления вредоносного кода.
Общий термин «атака цепочки поставок» охватывает любой случай, когда злоумышленник вмешивается или захватывает процесс производства программного обеспечения (жизненный цикл разработки программного обеспечения), так что это наносит ущерб множеству потребителей готового продукта или услуги. Это может произойти, когда библиотеки кода или отдельные компоненты, используемые в сборке программного обеспечения, испорчены, когда двоичные файлы обновлений программного обеспечения являются троянскими, украдены сертификаты подписи кода или даже когда сервер, на котором размещается программное обеспечение как услуга (SaaS), скомпрометирован.
При любой атаке на цепочку поставок программного обеспечения злоумышленники вмешиваются либо в восходящий, либо в промежуточный поток, чтобы донести свои вредоносные действия и их последствия до многих пользователей. Таким образом, по сравнению с изолированным нарушением безопасности успешные атаки на цепочку поставок имеют гораздо больший масштаб с далеко идущими последствиями.
Здесь мы исследуем шесть различных методов, использованных в недавних реальных успешных атаках на цепочку поставок программного обеспечения.
1. Компрометация вышестоящего сервера: атака Codecov
В большинстве атак цепочки поставок программного обеспечения злоумышленник взламывает вышестоящий сервер или репозиторий кода и внедряет вредоносную полезную нагрузку (например, вредоносную строку кода или троянские обновления). Эти полезные данные затем распределяются по нисходящему потоку для многих пользователей. Однако с технической точки зрения это не всегда так.
Атака на цепочку поставок Codecov - один из таких примеров. Хотя инцидент сравнивают с взломом SolarWinds, между этими двумя атаками есть существенные различия. Нарушение цепочки поставок SolarWinds было делом рук изощренных злоумышленников, которые изменили законный двоичный файл обновления, SolarWinds.Orion.Core.BusinessLayer.dll, который был частью продукта Orion для мониторинга производительности ИТ SolarWinds.
Как было ранее проанализировано FireEye, вредоносный код, содержащийся в методе RefreshInternal () поддельной DLL, показан ниже. Этот метод вызывает бэкдор на основе HTTP, когда Orion загружает плагин Inventory Manager:
Версия 2019.4.5200.9083 библиотеки DLL с бэкдором с вредоносным методом RefreshInternal
Однако восходящая атака SolarWinds обрела полную силу только тогда, когда измененный двоичный код распространился вниз по течению к более чем 18 000 клиентов SolarWinds Orion, включая правительственные учреждения США.
В случае с Codecov, однако, вредоносный код не распространялся ниже по потоку, но распространялись последствия атаки. Злоумышленники Codecov получили учетные данные из некорректного процесса создания образа Docker, которые можно было использовать для изменения Codecov Bash Uploader в соответствии с официальными рекомендациями по безопасности. Затем злоумышленники модифицировали загрузчик Codecov Bash, размещенный на самом сервере Codecov, чтобы собирать переменные среды, загружаемые из сред непрерывной интеграции / непрерывной доставки (CI / CD) клиентов:
Модифицированная строка программы Codecov Bash Uploader, которая собирала переменные среды и отправляла их на IP-адрес злоумышленника
Модифицированная строка Bash Uploader от Codecov, которая собирала переменные среды и отправляла их на IP-адрес злоумышленника.
Хотя сценарий Codecov Bash Uploader жил (и продолжает существовать) на самом сервере Codecov в codecov [.] Io / bash, тысячи репозиториев уже указывали на ссылку для отправки информации из своих сред CI / CD в этот Bash Uploader. Таким образом, вредоносный код оставался только на (скомпрометированном) вышестоящем сервере без какого-либо последующего распространения кода, поскольку так называемые подчиненные репозитории уже указывали на сервер Codecov, на котором размещался сценарий Bash Uploader. Тем не менее, эти нижестоящие репозитории были затронуты этой атакой, поскольку они были настроены для загрузки своих данных в загрузчик Bash от Codecov:
Фактически, как сообщается, злоумышленники Codecov взломали сотни клиентских сетей, используя учетные данные, полученные от взломанного Bash Uploader. Вскоре после этого HashiCorp сообщила, что инцидент с Codecov привел к раскрытию ее закрытого ключа GPG, используемого для подписи и проверки пакетов программного обеспечения. Twilio также сообщила о некотором влиянии атаки, и другие компании выступают с аналогичными заявлениями.
2. Компрометация промежуточного уровня для рассылки вредоносных обновлений.
Термин «промежуточное звено» здесь вольно применяется для обозначения случаев, когда злоумышленники скомпрометируют промежуточные функции обновления программного обеспечения или инструмент CI / CD, а не исходную базу исходного кода восходящего потока. В прошлом месяце Click Studios, разработчики корпоративного менеджера паролей Passwordstate, используемого многими компаниями из списка Fortune 500, уведомили клиентов об атаке на цепочку поставок. Злоумышленники скомпрометировали функцию Passwordstate «Обновление на месте», чтобы распространять вредоносные обновления среди пользователей Passwordstate.
Незаконное обновление содержало измененный файл DLL с названием Moserware.SecretSplitter.dll, небольшая часть которого показана ниже:
В рекомендациях по безопасности Click Studios говорится:
Неудивительно, что вскоре последовали фишинговые атаки на пользователей Click Studios, когда злоумышленники поместили в эти электронные письма незаконные ссылки на обновленную версию вредоносного ПО.
Эта атака на цепочку поставок имела не только технический аспект (т. е. вмешательство в процесс обновления), но и аспект социальной инженерии. В поддельном zip-файле обновления, размер которого превышает 300 МБ, я обнаружил, что злоумышленникам удалось изменить руководства пользователя, файлы справки и сценарии сборки PowerShell, чтобы они указывали на свой сервер сети распространения вредоносного контента (CDN):
Один из документов справочного руководства, в котором вредоносный сервер CDN указан как официальный
Сценарий установки PowerShell, содержащий вредоносные ссылки на сервер CDN
Аспект социальной инженерии этой атаки также демонстрирует еще одну слабость: люди (особенно новые разработчики или потребители программного обеспечения) не всегда могут подозревать ссылки на сети распространения контента (CDN), независимо от того, являются они подозрительными или нет. Это связано с тем, что сети CDN законно используются программными приложениями и веб-сайтами для доставки обновлений, сценариев и другого контента.
Интернет кредитных карт атака скимминг, такие как Magecart еще один пример такого рода цепочка поставок атаки. В некоторых атаках корзины CDN Amazon CloudFront были скомпрометированы для распространения вредоносного кода JavaScript на большее количество веб-сайтов, использующих такие CDN.
3. Атаки путаницы зависимости
В 2021 году ни одна часть атак на цепочки поставок не может быть завершена без упоминания путаницы в зависимостях, особенно из-за упрощенного и автоматизированного характера этой атаки. Атаки на основе путаницы зависимостей работают с минимальными усилиями со стороны злоумышленника и в автоматическом режиме из-за присущих им конструктивных недостатков, обнаруженных во многих экосистемах с открытым исходным кодом.
Проще говоря, путаница с зависимостями (или путаница с пространством имен) работает, если ваша программная сборка использует частную, внутренне созданную зависимость, которой нет в общедоступном репозитории с открытым исходным кодом. Злоумышленник может зарегистрировать зависимость с тем же именем в публичном репозитории с более высоким номером версии. Тогда весьма вероятно, что (общедоступная) зависимость злоумышленника с более высоким номером версии будет включена в вашу сборку программного обеспечения, в отличие от вашей внутренней зависимости.
Иллюстрация слабости, связанной с путаницей зависимостей, озадачивающей несколько экосистем
Используя эту простую слабость в широко используемых экосистемах, включая PyPI, npm и RubyGems, этичный хакер Алекс Бирсан смог взломать 35 крупных технологических фирм и получить вознаграждение за баг-баунти на сумму более 130 000 долларов.
Через несколько дней после открытия исследования Бирсана тысячи пакетов-подражателей путаницы зависимостей начали наводнять PyPI, npm и другие экосистемы. Хотя большинство этих подражателей были созданы другими честолюбивыми охотниками за ошибками, некоторые зашли слишком далеко, злонамеренно нацелившись на известные компании.
Существует несколько способов устранить путаницу с зависимостями, включая регистрацию (резервирование) имен всех ваших частных зависимостей в общедоступных репозиториях до того, как это сделает злоумышленник, и использование автоматизированных решений, таких как брандмауэр жизненного цикла разработки программного обеспечения (SDLC), который предотвращает ввод конфликтующих имен зависимостей. ваша цепочка поставок.
Владельцы репозиториев с открытым исходным кодом могут применить более строгий процесс проверки и ввести в действие пространство имен / область видимости. Например, для публикации пакетов в пространстве или области имен «CSO» репозиторий с открытым исходным кодом может проверить, имеет ли разработчик, загружающий пакет, права на это под именем «CSO».
Репозиторий компонентов Java Maven Central использует простую проверку на основе домена для проверки владения пространством имен - практику, которую можно легко смоделировать в других экосистемах.
Точно так же пакеты, опубликованные в репозитории пакетов Go, называются по URL-адресу их репозитория GitHub, что делает атаки путаницы зависимостей гораздо более сложными, если не полностью невозможными.
4. Украденные сертификаты SSL и подписи кода.
С увеличением количества веб-сайтов HTTPS сертификаты SSL / TLS теперь присутствуют повсеместно и защищают ваши онлайн-коммуникации. Таким образом, компрометация закрытого ключа сертификата SSL может поставить под угрозу безопасную связь и надежность, обеспечиваемую сквозным шифрованным соединением для конечных пользователей.
В январе 2021 года Mimecast сообщила, что сертификат, используемый ее клиентами для подключения к службам Microsoft 365 Exchange, был скомпрометирован, что может повлиять на связь примерно 10% пользователей Mimecast. Хотя Mimecast явно не подтвердил, был ли это сертификат SSL, как подозревают некоторые исследователи, в основном это так .
В то время как скомпрометированный сертификат SSL проблематичен, украденный сертификат подписи кода (т. е. скомпрометированный закрытый ключ) может иметь гораздо более серьезные последствия для безопасности программного обеспечения. Злоумышленники, получившие закрытый ключ для подписи кода, потенциально могут подписать свое вредоносное ПО как подлинное программное обеспечение или обновление, поставляемое уважаемой компанией.
Хотя Stuxnet остается ярким примером изощренной атаки, в которой злоумышленники использовали украденные закрытые ключи от двух известных компаний, чтобы подписать свой вредоносный код как «доверенный», такие атаки процветали до Stuxnet и продолжаются даже годы спустя. Вот почему вышеупомянутый пример раскрытия секретного ключа GPG HashiCorp в атаке цепочки поставок Codecov является проблематичным. Хотя пока нет никаких указаний на то, что взломанный ключ HashiCorp использовался злоумышленниками для подписи вредоносного ПО, такой инцидент был реальной возможностью до тех пор, пока скомпрометированный ключ не был отозван.
5. Ориентация на инфраструктуру CI / CD разработчиков.
Sonatype недавно наблюдала многогранную атаку на цепочку поставок программного обеспечения, которая не только опиралась на внедрение вредоносных запросов на вытягивание в проект GitHub пользователя, но также использовала инфраструктуру автоматизации CI / CD GitHub, GitHub Actions, для добычи криптовалюты. GitHub Actions предоставляет разработчикам возможность планировать автоматические задачи CI / CD для репозиториев, размещенных на GitHub.
Атака состояла в том, что злоумышленники клонировали законные репозитории GitHub, которые использовали GitHub Actions, немного изменили сценарий GitHub Action в репозитории и отправили владельцу проекта запрос на перенос, чтобы внести это изменение обратно в исходный репозиторий.
Злоумышленник (edgarfox1982) отправляет запрос на перенос законному владельцу проекта для объединения измененного кода
Если владелец проекта случайно утвердит измененный запрос на вытягивание, атака на цепочку поставок будет успешной, но это даже не было предварительным условием здесь. Вредоносный запрос на вытягивание содержал изменения в ci.yml, которые автоматически запускались GitHub Actions, как только злоумышленник отправил запрос на вытягивание. Модифицированный код по сути злоупотребляет серверами GitHub для добычи криптовалюты.
Такая атака убивает двух зайцев одним выстрелом: она обманом заставляет разработчика принять злонамеренный запрос на вытягивание, а в случае неудачи он злоупотребляет имеющейся автоматизированной инфраструктурой CI / CD для проведения злонамеренных действий.
Точно так же исследователи, которые успешно взломали домены Организации Объединенных Наций (ООН) и получили доступ к более чем 100 000 сотрудников ЮНЕП, могли сделать это в основном потому, что они обнаружили в этих доменах открытые папки Git и файлы «git-credentials». Злоумышленник, получивший доступ к учетным данным Git, может не только клонировать частные репозитории Git, но и потенциально внедрить вредоносный код в восходящий поток, чтобы инициировать атаку цепочки поставок, которая будет иметь гораздо более суровые последствия.
Основное внимание тех, кто стремится предотвратить атаки на цепочку поставок, было направлено на то, чтобы рекомендовать разработчикам методы безопасного кодирования или использовать инструменты автоматизации DevSecOps в средах разработки. Однако защита конвейеров CI / CD (например, серверов Jenkins), облачных контейнеров и дополнительных инструментов и инфраструктуры разработчика теперь стала не менее важной.
6. Использование социальной инженерии для удаления вредоносного кода.
Как известно любому специалисту по безопасности, безопасность настолько сильна, насколько сильна ее самое слабое звено. Поскольку человеческий фактор остается самым слабым звеном, эксплуатация может происходить там, где ее меньше всего ожидают. Linux Foundation недавно запретил исследователям из Университета Миннесоты, которые предлагали преднамеренно исправлять ошибки, которые, в свою очередь, вносили уязвимости в исходный код ядра Linux.
Хотя экземпляр был пойман и теперь с ним разбирались, он демонстрирует несколько простых фактов: разработчики разбросаны по размеру и не всегда могут иметь пропускную способность для проверки каждой отдельной фиксации кода или предлагаемого изменения кода, которое может быть ошибочным или откровенно вредоносным. Что еще более важно, социальная инженерия может поступать из наименее подозреваемых источников - в данном случае из надежных университетских исследователей с адресом электронной почты «.edu».
Другой недавний пример включает в себя то, как любой соавтор, участвующий в проекте GitHub, может изменить выпуск даже после его публикации. И здесь владелец проекта ожидает, что большинство участников отправят код и добросовестно примут участие в своем проекте. Достаточно одного сотрудника, чтобы обмануть и поставить под угрозу безопасность цепочки поставок для многих.
За последний год, злоумышленники создают Typosquatting и brandjacking программных пакетов неоднократно целевых разработчиков с открытым исходным кодом, чтобы ввести вредоносный код в их верховьях строит, который затем распространяется для многих потребителей.
Все эти примеры из реальной жизни демонстрируют различные слабые стороны, векторы атак и методы, которые злоумышленники используют для успешных атак на цепочку поставок. Поскольку эти атаки продолжают развиваться и создавать проблемы, для обеспечения безопасности программного обеспечения требуются более инновационные решения и стратегии.
Last edited:
