SolarWinds Orion и SUNBURST: инвентаризируем мониторинг после самого громкого взлома 2020-го

В конце декабря, когда большинство коллег доедали оливье, мы разбирали клиентские запросы примерно одного содержания: «У нас стоит SolarWinds Orion - что делать?». По крайней мере трое написали в первые дни после публикации FireEye и Microsoft. Это неплохой знак - значит, клиенты читают новости. Но хорошего в самой истории мало.

Что случилось

Если коротко: злоумышленники получили доступ к сборочной инфраструктуре SolarWinds и внедрили в официальные обновления Orion (версии 2019.4 - 2020.2.1) бэкдор SUNBURST. Примерно с марта по июнь 2020-го обновления с троянским компонентом рассылались через легитимные каналы дистрибуции. По данным самого вендора - потенциально затронуто около 18 000 организаций, из которых часть получила активную эксплуатацию. В числе жертв - американские госведомства, крупные технологические компании, европейские структуры.

Что делает эту атаку особенной - и особенно неприятной для обсуждения с клиентами - это то, что стандартные защитные практики не помогли бы. Обновление подписано легитимным сертификатом SolarWinds. Оно пришло с официального сервера. В контрольных суммах - всё сходится. Классический антивирус на это не среагировал бы. EDR - скорее всего тоже, потому что поведение SUNBURST первые две недели после активации намеренно имитировало легитимный трафик Orion.

Инвентаризация: что стоит у нас и у клиентов

Первое, что мы сделали - прошлись по инфраструктурам, которые ведём. Вопрос простой: есть ли где-то SolarWinds Orion?

Хорошая новость: у нас в инфраструктурах Orion не используется. Из мониторинг-инструментов в проектах - преимущественно Zabbix, Prometheus + Grafana, в нескольких местах PRTG и CheckMK. У одного клиента была лицензия на PRTG Enterprise и вопрос «а нет ли у нас заодно Orion» - оказалось, нет, но человек был уверен что есть, потому что «там какой-то SolarWinds стоит в оценке три года назад». Три года назад в оценке - не значит стоит сейчас. Это хороший пример того, почему инвентаризация нужна не по памяти.

Чуть менее хорошая новость: выяснилось, что у части клиентов реестр установленного ПО не обновлялся от слова совсем. Один проект - инфраструктура больше 200 узлов - обнаружил в ходе проверки два инструмента мониторинга, о существовании которых текущая команда не знала. Не Orion, но сам факт показательный.

Что проверяли в ходе инвентаризации:

• Установленный Orion - поиск по реестру Windows, процессам, службам (SolarWinds.BusinessLayerHost.exe, SolarWinds Collector Service и другие).
• Версии - затронутые версии: 2019.4 через 2020.2.1 HF1. Если Orion есть - критично понять точную версию.
• Сетевой трафик от Orion-хостов - SUNBURST для C2 использовал DNS-запросы к поддомену avsvmcloud.com; этот домен уже синкхолирован, но смотреть исторические DNS-логи стоит.
• Аккаунты с расширенными правами - Orion часто ставится с сервисным аккаунтом в локальных администраторах или даже в доменных. Это отдельная зона риска.

Доверяй, но проверяй - теперь к вендорскому апдейту

У нас была привычка - и мы её клиентам транслировали - обновлять мониторинг-агенты и инфраструктурный софт в рамках планового патч-цикла, но без паранойи. Обновление от вендора, подписанное его сертификатом - это достаточный уровень доверия для большинства контекстов. SolarWinds эту формулу сломал.

Это не значит, что нужно прекратить обновляться - это было бы хуже. Но несколько вещей стоит пересмотреть.

Сегрегация мониторинг-инфраструктуры. Orion по дизайну требует широкого доступа - ему нужно видеть всё, что он мониторит. Это делает сервер Orion очень привлекательной точкой для pivot. Если мониторинг-система стоит в том же сегменте, что и критичные системы, и имеет к ним прямой доступ без ограничений - это архитектурный долг, который SUNBURST сделал очень видимым. Мы и раньше писали про принципы zero trust применительно к удалёнке - но те же принципы применимы к внутренним инструментам.

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

Мониторинг самого мониторинга. Звучит рекурсивно, но суть простая: поведение Orion-сервера - его сетевые соединения, запускаемые процессы, аутентификации от его имени - должно логироваться и попадать в SIEM так же, как поведение любой другой системы. Если Orion-хост начинает делать DNS-запросы к странным доменам или аутентифицироваться там, где раньше не аутентифицировался - это должно попасть в алерт.

Где мы сейчас

Прямого попадания по клиентским инфраструктурам нет - Orion у нас не используется. Но работа не закончена: инвентаризация выявила несколько мест, где реестр ПО устарел и требует актуализации, а аудит сервисных аккаунтов мониторинг-систем встал отдельным пунктом в план на январь.

Один вывод, который мы сделали для себя твёрдо: supply-chain атака - это не экзотика из отчётов о государственных APT, это реальный вектор, который нужно учитывать в архитектуре. Не через параноидальный запрет обновлений, а через сегрегацию, минимальные привилегии и мониторинг поведения инструментов. История с SolarWinds хорошо иллюстрирует, что периметровая защита не помогает, когда угроза приходит изнутри доверенного обновления.