Атака через цепочку поставок: SolarWinds, трояны и как защититься

Быстрые ссылки

• Trojan Software
• The SolarWinds Breach
• Assessing Your Supply chain
• Other Steps To Take

Троянское программное обеспечение

Троян — это программа с скрытой вредоносной нагрузкой. Вы устанавливаете знакомое приложение, а вместе с ним попадает зловред. Или легитимное приложение оказывается скомпрометировано и начинает выполнять вредоносные действия.

Краткое определение: троян — законная на вид программа, содержащая скрытый вредоносный код.

Недавний пример: приложение-сканер штрихкодов, удалённое из Google Play. Приложение существовало несколько лет и имело около 10 миллионов установок. В конце 2020 года его купила новая команда, зарегистрированная в Украине под именем The Space Team.

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

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

Когда троян через обновления особенно опасен

• Большая база пользователей у приложения
• Автоматические обновления включены по умолчанию
• Высокие разрешения на устройстве или доступ к сетевым ресурсам
• Низкая бдительность пользователей и отсутствие проверки подписей

Компрометация SolarWinds

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

Как и в случае со сканером штрихкодов, сама платформа стала средством доставки вреда. SolarWinds Orion — полноценный инструмент мониторинга. Злоумышленники тайно модифицировали динамическую библиотеку (DLL)

SolarWinds.Orion.Core.BusinessLayer.dll

Заражённая DLL вошла в состав версий Orion 2019.4–2020.2.1 HF1, обновления вышли в период март–июнь 2020. Через обновления вредоносный модуль попал на сети заказчиков. Исследователи кибербезопасности присвоили вреду имя SUNBURST.

Сложность проникновения, изящность трояна, использование zero day уязвимостей и методы уклонения от обнаружения указывают на работу высококвалифицированной группы с государственной поддержкой, известной как APT.

Список жертв подтверждает версию о целенаправленной кампании: ведомства США, операторы критической инфраструктуры, международные организации и частные компании. Среди пострадавших — Министерство финансов США, Министерство внутренней безопасности, Госдепартамент, Министерство обороны и другие. Всего затронуты около 18 000 установок заражённого ПО.

После установки вредоносный компонент обычно спал примерно две недели. Затем он отправлял HTTP-запросы на командные серверы злоумышленников, получал команды и выполнял их. Это давало оппонентам постоянную «заднюю дверь» в сеть.

Трафик маскировался под протокол программы улучшения Orion Improvement Program (OIP), что снижало подозрительность. Троян также знал о множестве антивирусов и средств защиты конечных точек и умел их обходить.

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

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

Оценка рисков вашей цепочки поставок

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

Ключевые шаги для оценки:

1. Идентификация всех поставщиков программного и аппаратного обеспечения
2. Категоризация по уровню доступа к сети и критичности
3. Оценка способности поставщика управлять инцидентами и прозрачности
4. Проверка других клиентов поставщика: есть ли среди них высокорисковые объекты
5. Разработка плана действий и резервных поставок

Особое внимание уделяйте MSP и другим внешним операторам. Поставщик управляемых услуг имеет доступ ко многим клиентским средам. Если злоумышленники компрометируют MSP, они получают «ключи от королевства» для всех его клиентов.

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

Практическая методика аудита поставщиков

• Требуйте от поставщика перечень используемого ПО и версий
• Попросите сертификаты и соответствие стандартам безопасности
• Потребуйте отчёты об инцидентах и способах их разрешения
• Внедрите проверку целостности поставляемого ПО (подписи, контрольные суммы)
• Проводите аудит на месте для критичных поставщиков не реже раза в год
• Для удалённых поставщиков отправляйте детальный опросник и требуйте нотариальную или официальную аттестацию

Оценка последствия коллапса цепочки поставок

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

• Можно ли быстро переключиться на альтернативных поставщиков?
• Какие ниши трудно заменить и сколько времени потребуется на замену?
• Есть ли у вас запас критичных компонентов?

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

Другие шаги по снижению риска

Если вы клиент SolarWinds, следуйте официальному advisory SolarWinds и директивам Департамента внутренней безопасности США. Примите все предусмотренные меры и примените обновления безопасности.

SUNBURST использовал механизм доступа к сертификатам и генерации поддельной аутентификации. Специалисты поделились утилитами, которые помогают найти слабые места. Например, Trimarc Security опубликовала скрипт на PowerShell, который сканирует одно-доменный Active Directory и выдаёт отчёт о найденных слабостях. Применяйте такие инструменты в тестовой среде и следуйте внутренним правилам работы с конфиденциальными данными.

Чек-листы и обязанности ролей

Ниже приведены конкретные контрольные списки для ключевых ролей. Применяйте их как часть политики управления цепочкой поставок.

Для руководства по ИТ и безопасности

• Обеспечить политику аудита поставщиков
• Включить требования к шифрованию и подписыванию поставляемого ПО
• Утвердить периодические проверки MSP и критичных вендоров
• Назначить ответственного за карту поставщиков и план восстановления

Для команды по управлению рисками

• Проводить классификацию поставщиков по уровню риска
• Моделировать последствия потери поставщика
• Разрабатывать сценарии переключения поставщиков и тестировать их

Для операционной команды и администраторов

• Внедрять проверку цифровых подписей для обновлений
• Отключать ненужные сервисы и минимизировать права учётных записей
• Проводить мониторинг аномалий в трафике для выявления скрытой C2 активности

Для отдела закупок

• Запрашивать у поставщиков подтверждение процедур безопасности
• Включать SLA и требования по инцидентам в контракты
• Требовать прозрачности в цепочке субподрядчиков

План реагирования на инцидент и откат

Ниже пример упрощённого плана реагирования при обнаружении заражённого обновления.

1. Изоляция. Немедленно отключите подозрительные узлы и сегменты сети
2. Сбор артефактов. Снимите логи, снимки памяти, контрольные суммы файлов
3. Контакт с поставщиком. Уведомьте поставщика о проблеме и запросите доступные сведения
4. Оценка масштаба. Определите, какие системы были затронуты и какие данные — под угрозой
5. Откат. Восстановление из чистых бэкапов для критичных систем
6. Уведомление заинтересованных сторон. Регуляторы, партнёры, клиенты по контрактным требованиям
7. Постинцидентный аудит. Анализ корневой причины и обновление политики безопасности

Критерии приёмки восстановления:

• Все критичные сервисы работают в штатном режиме
• Бэкапы проверены и восстановлены без обнаружения следов компрометации
• Проведён анализ логов и подтверждена устранённость угрозы

Три уровня зрелости защиты цепочки поставок

1. Базовый. Отсутствие картирования поставщиков, реагирование по инциденту ad hoc
2. Средний. Регулярные аудиты, подписи обновлений, минимальные привилегии
3. Продвинутый. Проактивный мониторинг, независимое тестирование поставщиков, многоканальные поставки и детальные планы восстановления

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

Практические методы защиты и жесткое укрепление

• Внедрение принципа наименьших привилегий для сервисных аккаунтов
• Использование аппаратных модулей безопасности для хранения ключей (HSM)
• Обязательная цифровая подпись всех обновлений и проверка целостности на клиентах
• Сегментация сети для ограничения распространения заражения
• Мониторинг DNS и аномалий в исходящем трафике
• Регулярные упражнения по восстановлению и инцидент-репетиции

Ментальные модели и эвристики

• Модель поставщика как транслятора риска: если ваш поставщик обслуживает более рискованных клиентов, повышайте уровень контроля
• Правило цепочки: атаковать проще центральный звено, чем каждого по отдельности
• Разделение ответственности: вопрос безопасности надо рассматривать в закупках, не только в ИТ

Решение по приоритетам: матрица воздействия и усилий

• Высокое влияние / низкие усилия: проверка цифровых подписей, сегментация сети
• Высокое влияние / высокие усилия: аудит MSP, внедрение HSM
• Низкое влияние / низкие усилия: обновление политики, опросники поставщиков
• Низкое влияние / высокие усилия: полномасштабный аудит всех вторичных субподрядчиков

Примеры, когда подходы не работают

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

Диаграмма принятия решения

flowchart TD
  A[Обнаружено подозрительное обновление] --> B{Обновление цифрово подписано}
  B -- Да --> C{Подпись верифицирована поставщиком}
  B -- Нет --> D[Изолировать и ускоренно расследовать]
  C -- Да --> E{Патч из официального канала}
  C -- Нет --> D
  E -- Да --> F[Применить в тестовой среде и мониторить]
  F --> G[Развернуть в продуктиве при норме]
  D --> H[Оповестить команду инцидента и поставщика]

Краткий глоссарий

• APT — группа целевых, часто спонсируемых государством злоумышленников
• Цепочка поставок — совокупность поставщиков и услуг, необходимых для работы продукта
• MSP — поставщик управляемых ИТ-услуг
• OIP — протокол программы улучшения Orion
• SUNBURST — название вредоносного компонента, найденного в SolarWinds

Рекомендации по локализации и специфике для российского контекста

• Требуйте от международных поставщиков доказательства прохождения аудитов и соответствия стандартам, принятым в РФ и международным нормативам
• Учитывайте региональные особенности правовых требований к уведомлению о нарушениях
• Для государственных заказов используйте дополнительно требования по проверке источников поставок и закрытых каналов обновлений

Итог и действия на ближайшие 90 дней

1. Составьте карту всех поставщиков и пометьте критичность
2. Внедрите проверку цифровых подписей всех входящих обновлений
3. Проведите аудит MSP и критичных вендоров
4. Разработайте и протестируйте план быстрого отката и восстановления
5. Проведите обучение для ответственных специалистов по обнаружению признаков скрытой C2 активности

Важно: аудит и план восстановления эффективны только при регулярном обновлении и отработке сценариев. Без практики процессы остаются на бумаге.

Резюме

Атака через цепочку поставок использует доверительные процессы обновлений и взаимодействия с поставщиками. Примеры от заражённого приложения-сканера до SUNBURST показывают, что уязвимым может быть любой компонент, имеющий широкую базу установки или высокий уровень доступа. Ключевые меры защиты — картирование цепочки поставок, требования к проверке целостности и подписей, сегментация сети, аудит MSP и наличие планов восстановления. Регулярные учения и точное распределение ответственности превращают политику безопасности в рабочий инструмент, а не в декларацию.