Атака на цепочки поставок

Атака на цепочки поставок (англ. supply chain attack) — это тип кибератаки, при котором злоумышленник проникает в целевую систему не напрямую, а через компрометацию менее защищённого звена в цепочке поставок (поставщика программного обеспечения, аппаратного обеспечения, услуг или данных). Целью атаки является использование доверительных отношений между организациями для получения доступа к конечной жертве, распространения вредоносного кода или кражи информации.

История

Концепция атаки на цепочки поставок известна с начала 2000-х годов, но широкое распространение получила в 2010-х годах с ростом сложности и взаимосвязанности ИТ-инфраструктур. Первые значимые инциденты были связаны с компрометацией дистрибутивов программного обеспечения. Например, в 2012 году атака на дистрибутив Linux Mint привела к загрузке вредоносного ISO-образа пользователями.

Переломным моментом стала атака на компанию SolarWinds в 2020 году, которая считается одной из крупнейших в истории. Злоумышленники внедрили вредоносное обновление в программное обеспечение Orion, которое затем было установлено тысячами организаций, включая правительственные учреждения США. Этот инцидент продемонстрировал масштаб ущерба, который может нанести компрометация одного поставщика.

В последующие годы атаки на цепочки поставок участились. В 2021 году произошла атака на программное обеспечение Kaseya, затронувшая сотни компаний через MSP-провайдеров. В 2022 году атака на платформу CircleCI привела к утечке ключей доступа клиентов. В 2023 году атака на файловый менеджер 3CX позволила злоумышленникам распространить вредоносное ПО через обновление продукта.

Классификация атак на цепочки поставок

Атаки на цепочки поставок классифицируются по типу компрометируемого звена:

Компрометация программного обеспечения

• Внедрение в исходный код: злоумышленник получает доступ к репозиторию кода и вносит изменения в легитимное программное обеспечение.
• Компрометация процесса сборки: вредоносный код внедряется в процессе компиляции или сборки приложения.
• Атака на обновления: злоумышленник перехватывает или подменяет механизм обновления, распространяя вредоносные версии через доверенный канал.
• Использование уязвимостей в зависимостях: атака через открытые библиотеки и пакеты (например, в репозиториях npm, PyPI, Maven), когда злоумышленник публикует вредоносный пакет с похожим именем (typosquatting) или компрометирует популярный пакет.

Компрометация аппаратного обеспечения

• Внедрение аппаратных закладок: установка вредоносных микросхем или модификация компонентов на этапе производства.
• Подмена оборудования: замена легитимного оборудования на поддельное или модифицированное на этапе логистики.
• Компрометация прошивки: внедрение вредоносного кода в прошивку устройств (например, жёстких дисков, сетевых карт, материнских плат).

Компрометация услуг и данных

• Атака на облачных провайдеров: компрометация инфраструктуры облачного сервиса для доступа к данным клиентов.
• Компрометация MSP (Managed Service Providers): атака на компании, предоставляющие ИТ-услуги, для последующего доступа к их клиентам.
• Атака на цепочки поставок данных: внедрение ложных или вредоносных данных в информационные потоки (например, в финансовые отчёты, данные аналитики).

Механизм атаки

Типичная атака на цепочки поставок состоит из нескольких этапов:

1. Разведка: злоумышленник изучает целевую организацию и выявляет её поставщиков, подрядчиков, используемое программное обеспечение и зависимости.
2. Выбор цели для компрометации: выбирается наиболее уязвимое звено — поставщик с низким уровнем безопасности, разработчик популярного пакета, компания, предоставляющая услуги.
3. Компрометация звена: злоумышленник проникает в инфраструктуру выбранного поставщика, используя фишинг, эксплуатацию уязвимостей, кражу учётных данных или социальную инженерию.
4. Внедрение вредоносного компонента: в легитимный продукт или услугу вносится вредоносный код, который затем распространяется через обычные каналы поставки.
5. Распространение на конечных жертв: доверяя поставщику, конечные организации устанавливают обновление, используют скомпрометированное оборудование или подключаются к заражённому сервису.
6. Активация и выполнение вредоносной нагрузки: вредоносный код активируется, предоставляя злоумышленнику доступ к внутренним системам, позволяя красть данные, устанавливать бэкдоры, шифровать файлы (ransomware) или проводить шпионаж.

Примеры известных атак

Атака на SolarWinds (2020)

Злоумышленники, предположительно связанные с APT-группой (предположительно, группировка Cozy Bear, связанная с Россией, по данным правительства США), внедрили вредоносное ПО в обновление платформы Orion. Обновление было подписано цифровой подписью SolarWinds и распространялось через официальный сайт. Вредоносное ПО, получившее название SUNBURST, устанавливало бэкдор, позволяющий удалённый доступ. Атака затронула около 18 000 организаций, включая правительственные учреждения США (Министерство финансов, Министерство энергетики, Пентагон). Расследование длилось несколько лет, и полный масштаб ущерба до сих пор не установлен.

Атака на Kaseya (2021)

Группировка REvil (организация признана экстремистской и запрещена в РФ) использовала уязвимость в программном обеспечении VSA компании Kaseya, которое используется MSP-провайдерами для управления ИТ-инфраструктурой клиентов. Злоумышленники распространили вредоносное ПО, которое шифровало файлы на компьютерах клиентов MSP-провайдеров. Атака затронула более 1500 организаций по всему миру, включая школы, супермаркеты и муниципальные учреждения.

Атака на 3CX (2023)

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

Атака на Codecov (2021)

Злоумышленники получили доступ к скрипту Bash Uploader сервиса Codecov, используемого для анализа покрытия кода. Они изменили скрипт, чтобы он передавал учётные данные и токены доступа клиентов, которые использовали сервис. Атака затронула тысячи организаций, включая крупные технологические компании.

Меры защиты

Для организаций-потребителей

• Инвентаризация цепочки поставок: ведение полного списка поставщиков, используемого программного обеспечения, библиотек и зависимостей.
• Оценка безопасности поставщиков: проведение аудитов, требование сертификаций (например, SOC 2, ISO 27001), анализ политик безопасности.
• Минимизация доверия: использование принципа наименьших привилегий, ограничение доступа поставщиков к критическим системам.
• Мониторинг и обнаружение: внедрение систем обнаружения аномалий, анализ логов, мониторинг целостности файлов и обновлений.
• Тестирование обновлений: изоляция тестовой среды для проверки обновлений перед развёртыванием в производственной среде.
• Управление зависимостями: использование инструментов анализа уязвимостей (SBOM — Software Bill of Materials), регулярное обновление библиотек, мониторинг репозиториев на предмет вредоносных пакетов.

Для поставщиков

• Усиление безопасности процесса разработки: внедрение безопасного жизненного цикла разработки (SDLC), контроль доступа к репозиториям, многофакторная аутентификация.
• Защита процесса сборки: использование изолированных сред сборки, подписание кода, проверка целостности артефактов.
• Мониторинг и реагирование: внедрение систем обнаружения вторжений, регулярное сканирование на уязвимости, план реагирования на инциденты.
• Прозрачность: публикация SBOM, предоставление клиентам информации о зависимостях и изменениях.

Критика и сложности

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

Основные сложности:

• Сложность контроля: современные цепочки поставок могут включать сотни и тысячи зависимостей, поставщиков и подрядчиков, что делает полный контроль практически невозможным.
• Доверие как уязвимость: механизмы доверия (цифровые подписи, доверенные обновления) могут быть использованы злоумышленниками для распространения вредоносного ПО.
• Недостаток стандартов: отсутствие единых стандартов безопасности для цепочек поставок, хотя в последние годы предпринимаются попытки их создания (например, Executive Order 14028 в США, инициативы NIST).
• Глобальный характер: атаки могут исходить из юрисдикций, где сложно проводить расследования и привлекать к ответственности.

Правовое регулирование в России

В Российской Федерации атаки на цепочки поставок рассматриваются в контексте кибербезопасности и защиты критической информационной инфраструктуры (КИИ). Федеральный закон № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» обязывает субъекты КИИ принимать меры по защите от компьютерных атак, включая контроль цепочек поставок. Указ Президента РФ № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации» (2022 год) вводит требования к использованию доверенного программного обеспечения и оборудования, а также к импортозамещению в сфере ИТ. Нарушение этих требований может повлечь административную и уголовную ответственность.