На прошлой неделе Microsoft выпустила внеплановые исправления для нескольких критических уязвимостей в локальных версиях Exchange Server – 2013, 2016 и 2019. Связку дыр (среди них CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065) уже эксплуатируют в реальных атаках. Это не теоретический риск: злоумышленник, у которого есть сетевой доступ к порту 443, получает выполнение кода на сервере без аутентификации. Для большинства российских организаций Exchange стоит на периметре и смотрит в интернет – значит, под ударом каждый, кто не успел обновиться.

Чем опасна именно эта цепочка

Отдельная уязвимость – это неприятность. Цепочка из четырёх – это полный сценарий компрометации. Сначала SSRF в компоненте Exchange позволяет обратиться к серверу от его же имени и обойти проверку прав. Дальше атакующий пишет произвольный файл на диск и устанавливает веб-шелл – небольшой скрипт, через который он управляет машиной. С этого момента почтовый сервер перестаёт быть почтовым сервером и становится плацдармом: чтение любой переписки, выгрузка ящиков, разведка внутри домена, продвижение к контроллеру Active Directory.

Опасность в том, что Exchange по своей роли имеет высокие привилегии в каталоге. Захватив его, атакующий оказывается не на краю сети, а в её центре. Поэтому относиться к инциденту как к «проблеме почты» – ошибка. Это компрометация инфраструктуры.

Что сделать в ближайшие дни

Порядок действий понятный, и тянуть нельзя:

  • Установить мартовские патчи на все локальные Exchange. Это первоочередная задача, а не пункт в квартальном плане.
  • Проверить факт взлома. Патч закрывает дыру, но не выгоняет того, кто уже внутри. Microsoft опубликовала индикаторы компрометации и скрипты проверки – ищите подозрительные .aspx в каталогах веб-приложений и аномалии в журналах IIS.
  • Закрыть внешний доступ к панели управления и нестандартным путям Exchange, оставив наружу только то, что действительно нужно пользователям.
  • Сменить учётные данные сервисных и привилегированных учёток, если есть хоть малейшие признаки доступа.

Если своей команды реагирования нет, разбор инцидента и защиту периметра от подобных атак разумнее доверить тем, кто делает это ежедневно – счёт идёт на часы, а не на недели.

Почему пора пересмотреть периметр

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

Отдельный разговор – где вообще держать почту и данные. Перенос части нагрузки в управляемую среду снимает с вас гонку патчей, и многие компании уже идут этим путём – мы писали про рост гибридных облаков и про то, как меняется подход к корпоративным инструментам в материале о self-service BI. Для госсектора добавляется регуляторная рамка: курс на импортозамещение и предустановку российского ПО делает зависимость от одного зарубежного почтового стека ещё и стратегическим риском, а не только техническим.

Вывод

Поставьте патчи сегодня и проверьте, не побывал ли кто-то внутри. Это минимум. Максимум – пересмотреть архитектуру периметра так, чтобы следующая критическая уязвимость в одном продукте не означала автоматический доступ ко всей сети. Безопасность – это не разовый патч, а постоянная дисциплина.