1. Описание зафиксированной угрозы 

Эксперт в области безопасности из компании Fox-IT Dirk-jan Mollema опубликовал статью с описанием выявленной им уязвимости, приводящей к повышению привилегий любого аутентифицированного на Exchange Server пользователя до доменного администратора. Подвержены версии Exchange от 2013 и новее. Также был опубликован код Proof-of-Concept эксплойта.
Уязвимость возникает при сочетании нескольких условий:


  • наличие слишком высоких привилегий сервера Exchange в AD по умолчанию;
  • подверженность NTLM-протокола к атакам перенаправления (relay);
  • функция сервера Exchange, эксплуатация уязвимости в которой аутентифицирует сервер на компьютере атакующего с помощью машинного аккаунта сервера Exchange.
Указанным недостаткам, согласно статистическим данным автора, подвержены 90% типовых инсталляций Exchange. Высокие привилегии сервера Exchange обусловлены тем, что по умолчанию доменная группа Exchange Windows Permissions (в которую входит группа Exchange Trusted Subsystem, содержащая машинный аккаунт сервера Exchange), создаваемая автоматически при установке ПО Exchange, имеет разрешение WriteDacl. Данные ACL-настройки группы позволяют любому ее участнику модифицировать доменные привилегии любых объектов, включая разрешение на использование операций DCSync. Пользователи или компьютеры с данной привилегией могут выполнять действия по репликации информации из домена подобно контроллерам домена, т.е., например, скопировать все хешированные пароли всех доменных пользователей.
Атака перенаправления NTLM-аутентификации достаточно давно известна. В случае, если не применяются специальные контрмеры, например, подписывание SMB-пакетов, атакующий может перенаправить трафик NTLMаутентификации от компьютера-жертвы на другие компьютеры в сети и, тем самым, выдать себя за компьютер-жертву (атака SMB Relay). Особенно примечательна в контексте данной атаки возможность перенаправить аутентификацию по LDAP, модифицируя объекты в AD.
 Способ, с помощью которого можно заставить Exchange аутентифицироваться на атакующем по протоколу NTLM, был найден исследователями из Zero Day Initiative (ZDI) компании TrendMicro и описан в статье блога ZDI. Уязвимость (CVE-2018-8581) заключается в возможности сделать так, чтобы Exchange аутентифицировался по произвольному URL с помощью функции PushSubscription. Служба push-уведомлений на Exchange может выполнять отправку уведомлений периодически с интервалом, заданным атакующим.

2. Технические детали угрозы

Атака осуществляется следующим способом:

  • атакующий подключается к серверу Exchange через веб-службы (Exchange Web Services) с учетными данными доменного пользователя (любого с валидным почтовым ящиком) для запроса API вызова PushSubscription с указанием HTTP URL (ведущим на машину атакующего), на который должен прийти ответ от сервера;
  • после получения атакующим ответа от сервера Exchange аутентификация перенаправляется на контроллер домена по LDAP-протоколу;
  • используя некорректно настроенные ACL на группу Exchange Windows Permissions, атакующий назначает пользователю, под учетной записью которого была выполнена первичная аутентификация, права на выполнение операции DCSync с помощью машинного аккаунта сервера Exchange. Модифицируемый пользователь может быть любым аккаунтом пользователя или компьютера;
  • пользуясь вновь полученными правами, атакующий выполняет синхронизацию хешей паролей на свой компьютер. 
После получения хешей всех пользователей атакующий может развивать атаку дальше:

  • аутентифицироваться на любом сервисе, использующем NTLM или Kerberos, под видом пользователей, чьи хеши паролей были украдены;
  • создавать Golden Ticket’ы от имени аккаунта KRBTGT, чтобы представиться любым пользователем.

Перенаправление аутентификации из HTTP-протокола в LDAP-протокол становится возможным по причине того, что сервер Exchange 2013 и новее не выставляет флаги NTLMSSP_NEGOTIATE_SIGN и NTLMSSP_NEGOTIATE_SEAL по умолчанию при использовании NTLM-аутентификации по HTTP. Перенаправление пакетов аутентификации на контроллер домена по LDAP может не сработать, т.к. по умолчанию на актуальных версиях Windows используется Message Integrity Code (MIC) для NTLM. Однако т.к. MIC не является защищенной частью NTLM-сообщений, то его можно удалить из пересылаемых пакетов в случае, если флаг MsvAvFlags не выставлен в значение 0x00000002 (только NTLMv2). В случае, если атакующему не известен пароль от какой-либо учетной записи, для которой на Exchange есть почтовый ящик, он все равно может выполнить атаку. Условиями для осуществления атаки будут являться:

  • нахождение в одной сети с компьютером, который аутентифицируется на Exchange;
  • применение техник LLMNR-, NBNS- или MIMT6-спуфинга;
  • перенаправление пакетов аутентификации на Exchange (из SMB в HTTP или из HTTP в HTTP)

3. Рекомендации по устранению 

Рекомендуется выполнить следующие действия (одно или несколько в зависимости от применимости к ИТ-процессам организации) для закрытия уязвимости:

  • убрать излишние привилегии у группы Exchange Windows Permissions (WriteDacl), ИБ-сообществом разработан скрипт, автоматизирующий данную задачу (ВНИМАНИЕ! данный метод официально не поддерживается вендором и Jet CSIRT);
  • включить подписывание LDAP и LDAP Channel Binding, что предотвратит перенаправление аутентификаций в протоколы LDAP и LDAPS;
  • настроить правила межсетевого экрана, запрещающие серверу Exchange инициировать подключения до рабочих станций;
  • включить Extended Protection Authentication в IIS на узлах Exchange (но не на Exchange Back End);
  • применить воркэраунд для CVE-2018-8518 в виде удаления ключа реестра;
  • настроить подписывание SMB-пакетов для устранения возможности атаки на SMB;
  • отключить push/pull-подписки на EWS, выставив параметр EWSMaxSubscriptions в «0» в случае, если подписки не используются.

4. Ссылки