Бэкдор в комплекте: как осуществляются Software Supply Chain Attacks

Киберпреступникам не обязательно ломать систему защиты компании, чтобы проникнуть в ее инфраструктуру. Они используют более изощренный метод — атаку на цепочку поставок программного обеспечения. В статье расскажем, что такое Software Supply Chain Attacks (SSC) и как защититься от такого вида атак.

Цепочка поставок ПО: что это и как ее атакуют

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

Дмитрий Овчинников

Главный специалист отдела комплексных систем защиты информации компании «Газинформсервис»

Свободно распространяемое ПО имеет как свои плюсы, так и минусы. К минусам относится то, что злоумышленники могут внедрить внутрь этого программного обеспечения скрытый функционал. Однако если ПО популярное, то такая махинация вскроется достаточно быстро. Самый лучший способ использовать подобное ПО — это устанавливать только стабильные версии, обновление производить под контролем, а поведение конечных точек анализировать и контролировать. Это позволит снизить угрозы при использовании OpenSource решений.

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

Этим и пользуются злоумышленники. Они проникают в системы, атакуя менее защищенные элементы цепочки поставок организации — поставщиков третьих лиц или репозитории ПО. Или заражают применяемые разработчиками компоненты вирусом, что позволяет им получить доступ к готовому продукту. А дальше схема работает так:

• заказчик покупает готовый продукт с «сюрпризом»;
• интегрирует его в свою инфраструктуру;
• через подготовленный доступ злоумышленники проникают в инфраструктуру заказчика.

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

Например, все помнят эпидемию шифровальщика ExPetr, также известного как NotPetya, Petya, PetrWra. Один из методов распространения этого вредоносного программного обеспечения демонстрирует атаку через цепочку поставок. Злоумышленники скомпрометировали систему автоматического обновления программы M.E.Doc для банковской отчетности, внедрив в нее шифровальщик и распространяя его среди всех клиентов. ExPetr принес значительные убытки, заражая, как крупные компании, так и малый бизнес.

Еще один случай связан с программой CCleaner — популярным инструментом для очистки системного реестра.Однажды CCleaner оказался под угрозой — злоумышленники скомпрометировали среду разработки программы, добавив в несколько версий бэкдор. Эти скомпрометированные версии были распространены через официальные каналы с подлинной цифровой подписью компании, их скачали более чем 2,27 миллиона раз. При этом обнаружить Software Supply Chain Attacks совсем непросто.

Михаил Черешнев

Руководитель группы безопасности виртуализации и контейнеризации Swordfish Security

Определить конкретные признаки компрометации цепочки поставки практически невозможно. Это сложная и многоуровневая операция. На сегодняшний день нам неизвестны ни комплексные решения для обнаружения таких инцидентов, ни математический аппарат, которым можно было бы оперировать для обнаружения факта компрометации цепочки поставок, а также определения «точки входа» в эту цепочку. Из основных причин отмечаем — неизвестные источники кода и артефактов, «негерметичность» процесса сборки ПО, отсутствие в компаниях отлаженного стандартизированного процесса сборки и тестирования безопасности ПО.

Если в ваши процессы внедрены такие практики, как OSA/SCA, Подписи и Аттестации, можно определить факт расхождения заверений, что не всегда это указывает на факт компрометации, так как это может быть особенностью некоторых производственных процессов. И все же, постараемся дать несколько признаков, которые можно идентифицировать как факт компрометации:

• аномальное поведение рабочих нагрузок в средах эксплуатации;
• сильные расхождения в SBOM файлах на всех циклах разработки;
• ранее не идентифицированные сетевые потоки на машинах/системах сборки;
• изменение комплектов ПО на машинах/системах сборки.

Это не исчерпывающий список и даже не референс. Все сильно зависит от ваших технологических процессов, а также используемых подходов и систем.

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

Методы компрометации цепочки поставок

В цепочках поставок программного обеспечения используются различные методы компрометации. Например: 

1. Социальная инженерия — атаки, основанные на манипуляции людьми, часто с целью обмана или получения доступа к конфиденциальным данным путем обмана сотрудников компаний или поставщиков ПО.
2. Вредоносный код — внедрение вредоносного программного обеспечения в компоненты ПО на различных этапах цепочки поставок, что может привести к компрометации систем и утечке данных.
3. Компрометация поставщиков — злоумышленники могут направить атаки на поставщиков ПО, чтобы затем внедрить вредоносный код или модифицировать компоненты ПО перед их поставкой заказчикам.

Есть и другие угрозы — фишинг, DDoS-атаки на сбой инфраструктуры поставщиков, уязвимости в стороннем программном обеспечении, использование поддельных сертификатов и другие техники нападения.

Евгений Тодышев

Руководитель направления безопасной разработки УЦСБ

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

Как пример можно рассмотреть нашумевший бекдор CVE-2024-3094, позволяющий злоумышленникам попадать в системы через SSH. Злоумышленник два года коммитил в разработку open source пакета xz, добился доверия мейнтейнеров и получил доступ к прямому коммиту в репозиторий, стал постепенно внедрять бекдор.

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

Open Source самое слабое звено в цепочке поставок?

Использование компонентов Open Source позволяет значительно сокращать сроки разработки продуктов, а само программное обеспечение с открытым кодом распространяется бесплатно. Поэтому популярность и спрос на Open Source растет во всем мире и в России. Но среди почитателей Open Source есть и хакеры, потому что ПО с открытым кодом позволяет заходить через «черный ход» без особых усилий. 

Кай Михайлов

Руководитель направления информационной безопасности iTPROTECT

Полностью безопасного способа использовать Open Source не существует. Но можно снизить риски и сократить количество векторов атаки. Лучшей практикой является автоматизация всех процессов, связанных с разработкой с цифровыми подписями результатов. Каждый этап генерирует некий артефакт, будь то исходный код или скомпилированная библиотека. Этот артефакт необходимо подписывать и сверять эту подпись перед дальнейшим использованием. Таким образом, разработчики подтверждают доверие к источнику контейнеров/библиотек перед использованием их в своем коде.

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

Даже в случае, если для разработки используется чистый образ контейнера или Open Source проект, который на первый взгляд не содержит уязвимостей, он всё равно может быть вредоносным. Например, такой образ может содержать обфусцированный скрипт с загрузкой и запуском вредоносной библиотеки уже после того, как он был проверен и успешно развернут в корпоративном окружении. В качестве профилактики необходимо следить за правами для этого кода (например, в случае контейнеров) и иметь средства изоляции приложений.

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

Чего ждать в будущем

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

Владимир Арышев

Эксперт по комплексным ИБ-проектам STEP LOGIC

В ближайшем будущем можно ожидать роста кибератак на цепочки поставок. Из возможных тенденций стоит отметить:

1. Наряду с классическими массовыми способами (социальная инженерия, вредоносное ПО) компрометации поставщиков услуг будет расти применение более сложных атак (APT, уязвимости нулевого дня, уязвимости в зависимостях кода и т. д.). А также использование цепи компрометации, когда для взлома компрометируют поставщика более низкой ступени, предоставляющего услуги поставщику целевой организации.
2. Искусственный интеллект — это тенденция для всех аспектов и процессов. Он будет, как помогать защищаться, так и проводить атаки, а также являться целью атак. Сервисы ИИ интегрируются и становятся поставляемыми услугами. Для реализации подобных сервисов могут поставляться как вычислительные платформы, так и данные для обучения — и все это потенциально цели и каналы атак.
3. Геополитические риски. Недавние события показали, что атаки на цепочку поставок — это не только компрометация сервиса организации. Можно нарушить доступность базового сервиса или даже кабеля, из-за чего остановится работа многих ключевых сервисов и организаций. Это также своего рода атака на цепочку поставок, которая с учетом глобальных взаимосвязей становится значимой угрозой и рычагом давления мирового масштаба.

Для подготовки к подобным сценариям необходим комплексный подход, который совместит технические и организационные меры.

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

Защита от атак на цепочки поставок ПО

Лучшая атака SSC — та, что не состоялась. Поэтому лучшей защитой в данном случае будет пресечение атаки на раннем этапе, до того как злоумышленник успеет закрепиться внутри инфраструктуры и нанести ущерб.

Дмитрий Калинин

Руководитель департамента по работе с уязвимостями и инцидентами ИБ компании «Бастион»

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

• Предварительное тестирование ПО в тестовой среде или на ограниченном количестве систем с тщательным мониторингом на предмет подозрительной активности.
• Организовать процесс резервного копирования на случай, если ПО окажется зараженным.
• Использовать ПО только от партнеров с высоким уровнем доверия.

Одной из наиболее действенных мер, но в то же время достаточно ресурсоемкой и сложной в реализации является внедрение модели нулевого доверия (0-trust).

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

Сергей Липов

Директор по информационным технологиям EdgeЦентр

Методы обнаружения и предотвращения атак на цепочки поставок ПО развиваются в направлении применения искусственного интеллекта и машинного обучения.

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

Но не стоит забывать и о старых добрых методах защиты — антивирусном ПО и программах для сканирования кода на уязвимости. Эти инструменты помогают обнаруживать потенциальные проблемы и угрозы, которые могут быть не видны при обычном просмотре кода. Также полезно применять принцип «запрещено все, что не разрешено» в отношении сетевых подключений. Это означает, что если какое-то подключение или доступ не требуется для функционирования ПО, то его лучше отключить. Это помогает минимизировать возможные точки входа или отправку информации из вашего контура злоумышленнику и повышает общую безопасность системы.

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

Заключение

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

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