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-агент на рядовой рабочей станции бухгалтерии может годами существовать вне поля зрения службы безопасности.
Это не катастрофа и не повод немедленно всё отключать. Но повод провести инвентаризацию - точно.