Атака через поставщика или подрядчика глазами пентестера

Атака на Solar Winds в 2020 году привлекла особое внимание к теме supply chain. Кратко об атаке (ну вдруг кто-то не в курсе): злоумышленники получили доступ к системе сборки SolarWinds Orion и добавили «закладку» в один из DLL-файлов. Затем эта DLL была распространена среди клиентов SolarWinds через платформу автоматического обновления. После загрузки «закладка» подключалась к серверу управления и контроля (C2), чтобы получать «задания» для исполнения на заражённом компьютере.

В самой атаке нет ничего нового. Так, в 2016 году был взломан Linux Mint и в дистрибутив была установлена вредоносная закладка. Тогда на это особо не обратили внимание. Однако в случае с Solar Winds пострадало много компаний и организаций. Да и в целом атаки через поставщика или через подрядчика становятся все более популярными. А значит, есть смысл заранее подумать о мерах противодействия.

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

 Атаки через поставщика — когда сначала взламывают подрядчика, а затем атакуется связанная с ним целевая организация — можно разделить на два типа:

• supply chain — через цепочку поставки (в классификации MITRE ATT&CK — ID:1195);

• trusted relationship — через доверительные отношения (в классификации MITRE ATT&CK — ID:1199).

Эти атаки очень похожи, но имеют различные способы реализации.

Атака через цепочку поставки проводится с помощью программно-аппаратных средств. В само программно-аппаратное средство или в часть обновления внедряется имплант, который предоставляет прямой доступ к серверу, или устанавливает связь с центром управления (Command & Control, C2).  Такая атака, как правило, не является целенаправленной – ведь нельзя дать гарантию, что а) целевая организация установит нужное обновление и б) что сервер, на который устанавливается обновление, не имеет выхода в интернет и обновляется вручную. Если сервер получает обновление автоматически и правила файрволла ограничивают доступ только к серверу обновлений, то это не дает гарантий безопасности: злоумышленники могут контролировать этот сервер обновлений и перенаправлять трафик от импланта на C2.

 Атаки через доверительные отношения связанны с компрометацией доверенных каналов (например, VPN). Многие организации пользуются услугами подрядчиков, в том числе и малых организаций, работающих удаленно (и в подавляющем большинстве случаев слабо защищенных). Злоумышленники могут атаковать одного из подрядчиков и получить доступ в его сеть и в дальнейшем может довольно легко проникнуть в целевую инфраструктуру и, оставаясь незамеченным, развивать свою атаку – ведь никто не ждет подвоха со стороны доверенного партнера (по этой причине большой успех может иметь, например, «внутренний» фишинг). При всем при этом внутренняя инфраструктура обычно менее защищена, что тоже играет на руку хакерам.

Как можно себя обезопасить?

Выявлять такие атаки непросто. Анализ обновлений на наличие «закладок» — задача трудоемкая и дорогостоящая. Можно использовать поведенческий анализ для выявления аномалий. Сегментирование сети (что в общем-то должно быть нормой) также поможет снизить риски негативных последствий таких атак.

Что касается тестирования на проникновение, то будет достаточно сложно договориться между тремя сторонами о проведении таких работ. Подобные проекты могут выполнять головное и дочерние предприятия, но что делать с разными компаниями?

Частично проблему может решить тестирование методом предполагаемого нарушения (Assumed Breach). В этом случае легенда подразумевает, что подрядчик был скомпрометирован и целью злоумышленников является компания. Другими словами, предполагается, что у злоумышленников уже есть доступ во внутреннюю сеть организации. Такой вид тестирования способен продемонстрировать, что может произойти в случае наступления реальной атаки.

Как организовать тестирование методом Assumed Breach

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

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

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

Возможно несколько вариантов проведения тестирования в зависимости от модели потенциального злоумышленника:

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

 В целом в условиях, когда аутсорсинговых взаимодействий становится все больше, а контроль защищенности подрядчиков при этом никак не регламентируется законом и на практике вряд ли возможен, Assumed Breach – пожалуй, один из немногих относительно доступных инструментов, дающих компаниям понимание: 1) что будет в случае атаки через поставщика 2) насколько ИБ-специалисты готовы ее отражать 3) где стоит «подстелить соломку».  

Дмитрий Неверов, руководитель группы анализа защищенности "Ростелеком-Солар"