ADG Оставить заявку
Блог Информационная безопасность 4 мин чтения

AnyDesk взломали: что делать с инструментами удалённого доступа в корпоративной сети

AnyDesk сообщила о компрометации производственных систем и отзыве сертификатов подписи кода. Рассказываем, как провели аудит RMM-агентов у клиентов.

Контекст момента

AnyDesk в феврале 2024 года подтвердила взлом производственных систем - скомпрометированы сертификаты подписи кода, компания отозвала ключи и потребовала обновления клиентского ПО

В начале февраля AnyDesk объявила о взломе производственных систем. Конкретика была скудной - компания сообщила, что атака затронула исходный код и сертификаты подписи кода, после чего сменила все учётные данные порталов и отозвала ключи, которыми подписывались релизы. Пользователей попросили обновить клиент до свежей версии, подписанной новым сертификатом, и сменить пароли от my.anydesk.com.

Детали атаки официально не раскрыты, но сочетание «скомпрометированный сертификат подписи кода плюс доступ к исходникам» - это не просто неприятность. Это возможность выпустить троянизированный инсталлятор, который устройства встретят как легитимный. Именно этот сценарий делает инцидент значимым, а не абстрактным корпоративным PR-кризисом.

Почему это нас касается

AnyDesk - один из самых распространённых инструментов удалённого доступа и в клиентских инфраструктурах, и у самих MSP-команд. На многих рабочих станциях он стоит в фоне, о нём никто не думает, учётка в my.anydesk.com заведена ещё в 2019-м и пароль с тех пор не менялся. Администраторы не всегда помнят, что вообще установили агент на конкретный сервер.

Сразу после новости мы пошли разбираться, что с этим делать у наших клиентов - в рамках аудита инфраструктуры.

Что мы делали

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

Поиск установленного ПО. Через SCCM, через Ansible, через простые скрипты по WMI - везде, где был доступ. Искали не только AnyDesk, но параллельно TeamViewer, Ammyy Admin, Remote Utilities, RMS и ещё несколько инструментов, которые в разное время ставились «на один раз» и остались. Результат у нескольких клиентов оказался неожиданным: агентов было заметно больше, чем кто-либо помнил.

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

Состояние учётных записей. Для сервисов, которые предполагают облачную учётку - AnyDesk, TeamViewer - проверяли: когда последний раз менялся пароль, подключён ли MFA. Почти везде MFA не был включён. В нескольких случаях пароль от корпоративной учётки был «общим» - один на всю команду, без привязки к конкретному администратору.

Политики на уровне периметра. Смотрели, куда эти инструменты ходят: AnyDesk использует собственные relay-серверы, и соединения проходят через них. Проверяли, есть ли правила фаервола, ограничивающие RMM-трафик хотя бы по направлениям. У части клиентов правил не было вообще - агент мог инициировать исходящее соединение откуда угодно.

Что обнаружили

Выводы примерно одинаковые во всех случаях.

RMM-агентов больше, чем нужно. Инструменты накапливаются: один ставится для клиентской поддержки, другой - потому что поставщик попросил, третий - «временно, для одной задачи». Убирать их никто не торопится. Часть из обнаруженных агентов оказалась нерабочей - учётки давно неактивны, но сам агент висит.

MFA нигде не был нормой. После инцидента с AnyDesk это стало очевидным пробелом: если злоумышленник получит учётные данные от облачного аккаунта RMM-инструмента, следующий шаг - полный доступ ко всем машинам, где агент установлен. Без второго фактора это одна операция.

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

Что сделали

По итогам - несколько конкретных шагов.

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

Второе - обновление до актуальных версий. AnyDesk и остальные инструменты обновили на все хосты, где решили оставить.

Третье - MFA везде, где есть облачная учётка. Для AnyDesk это my.anydesk.com, для TeamViewer - свой портал. Включили принудительно.

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

Пятое - правила на фаерволе. Для хостов, где RMM-агент действительно нужен, ограничили исходящие соединения по назначению. Не идеально, но лучше чем ничего.

Что это вообще было

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

Мы давно работаем с инструментами вроде Ivanti и TeamViewer - история с Ivanti CVE-2024-21887 свежа в памяти. Но если VPN-апплайнс хотя бы виден на периметре, RMM-агент на рядовой рабочей станции бухгалтерии может годами существовать вне поля зрения службы безопасности.

Это не катастрофа и не повод немедленно всё отключать. Но повод провести инвентаризацию - точно.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.