CVE-2020-1472, или Zerologon, уже получила звание одной изсамых опасных уязвимостей, обнаруженных запоследние годы. Она позволяет атакующему скомпрометировать учетную запись машинного аккаунта контроллера домена иполучить доступ ксодержимому всей базы Active Directory. Для эксплуатации достаточно наличия сетевой связности сконтроллером домена организации.
Мыпровели собственное исследование Zerologon иразработали различные методы обнаружения ееэксплуатации: пособытиям журналов аудита Windows, посетевому трафику ипри помощи YARA-правил. Вэтой статье подробно остановимся накаждом изних.
Вчем суть уязвимости Zerologon
Zerologon это уязвимость впротоколе шифрования, который использует служба Netlogon. Протокол позволяет компьютерам проходить аутентификацию наконтроллере домена иобновлять пароль своего аккаунта вActive Directory. Именно эта особенность делает Zerologon опасной. Вчастности, уязвимость позволяет атакующему выдать себя законтроллер домена иизменить его пароль. Злоумышленник получает доступ кконтроллеру домена cнаивысшими привилегиями, аследовательно иккорпоративной сети. После смены пароля атакующий может использовать учетную запись контроллера домена для развития атаки, например, выполнив атаку DCSync (получение учетных записей Active Directory через механизм репликации).
Всентябре голландский исследователь безопасности Том Тервоорт изкомпании Secura опубликовал подробное описание уязвимости. Выяснилось, что Zerologon вызвана недостатком всхеме криптографической аутентификации, которую использует Netlogon Remote Protocol (MS-NRPC). Рукопожатие иаутентификация MS-NRPC предполагают использование режима AES-CFB8 (с8-битным режимом обратной связи пошифротексту). Это вариант блочного шифра AES, который предназначен для работы сблоками входных данных по8байт вместо обычных 16байт (128-бит).
Как обнаружил Тервоорт, применение шифрования AES-CFB8к состоящему изодних нулей открытому тексту приведет ктакомуже состоящему изодних нулей зашифрованному тексту. Это происходит из-за ошибки реализации для 1из256ключей.
Обычно клиентский компьютер, который хочет взаимодействовать ссервером Netlogon, таким как контроллер домена Windows, начинает сотправки восьми случайных байтов (то, что часто называют nonce, сокращая фразу number used once) насервер.
Вавгусте 2020 года врамках августовского вторника Microsoft выпустила исправление уязвимости. Этот патч сделал механизмы безопасности Netlogon (которые отключал Zerologon) обязательными для всех аутентификационных операций, что эффективно предотвращает атаки. Релиз второго патча, полностью закрывающего уязвимость, запланирован нафевраль 2021года.
Этапы эксплуатации Zerologon
Согласно техническому документу Secura, процесс эксплуатации Zerologon состоит изтрех этапов.
-
Отправка нулевых байтов. Вместо отправки восьми случайных байтов атакующий отправляет 8нулевых байтов. Злоумышленник повторяет отправку таких сообщений, пока сервер успешно непримет одно изних, итем самым обходит процесс аутентификации. Вслучае сZerologon для успешного соединения ссервером требуется всреднем 256 попыток отправки сообщения ClientChallenge, состоящего изодних нулей.
-
Отключение механизма RPC signing and sealing. MS-NRPC использует механизм RPC signing and sealing для шифрования транспортного уровня. Обычно шифрование обязательный процесс при передаче данных, новMS-NRPC этот механизм неявляется обязательным иуправляется клиентом. Сервер небудет отказывать вустановлении соединения клиентам, которые незапрашивают использование шифрования. Это означает, что выможете просто отключить шифрование взаголовке сообщения. Собственно, вторая стадия изаключается вотключении механизма RPC signing and sealing, чтобы сообщения отправлялись воткрытом виде иатакующий мог использовать методы протокола MS-NRPC.
-
Изменение пароля учетной записи. Третья стадия эксплуатации уязвимости Zerologon заключается визменении пароля для учетной записи контроллера домена, соединение отимени которого было установлено ранее. Атакующие при помощи метода NetrServerPasswordSet вMS-NRPC могут изменить пароль учетной записи компьютера. Самый простой способ использования этого метода заключается вудалении текущего пароля или, другими словами, установке пароля впустое значение. Также возможно изменить пароль, просто отправив запрос спредпочтительным новым паролем. После смены пароля атакующие могут использовать учетную запись контроллера домена для развития атаки, например, как упоминалось ранее, выполнить репликацию базы данных Active Directory.
PoC иэксплоиты
Первый PoC опубликовала компания Secura наGitHub. Скрипт попытается проэксплуатировать уязвимость Zerologon: после успешного установления соединения оннемедленно завершит работу инебудет выполнять никаких действий через Netlogon.
Что касается эксплоитов, намомент публикации этой статьи ихпоявилось уже много. Однако все они ведут себя одинаково: либо сбрасывают пароль, либо устанавливают его вопределенное пользователем значение.
Есть также альтернативный метод эксплуатации Zerologon, найденный исследователем безопасности Дирк-Яном Моллема. Ноониспользуется вместе сдругими уязвимостями изаслуживает отдельной статьи.
Методы обнаружения
Целью нашего исследования было найти все возможные методы обнаружения факта эксплуатации Zerologon. Мыразработали ипротестировали логику правил корреляции, сигнатур для сетевых IPS-\IDS-систем, атакже YARA-правило для выявления артефактов впамяти процесса LSASS.
Обнаружение сиспользованием журнала отладки Netlogon
Поскольку эксплуатируется уязвимость впротоколе Netlogon,
рассмотрим журнал событий Netlogon. Поумолчанию вжурналах Windows
аудиту подлежит лишь часть событий, однако можно включить режим
отладки Netlogon спомощью команды nltest
/dbflag:0x2080ffff, которая должна быть запущена отимени
администратора. После этого служба Netlogon будет сохранять большую
часть важных событий в файл журнала, который можно найти по пути
C:\Windows\debug\netlogon.txt. Затем необходимо
перезапустить службу Netlogon. Наскриншоте ниже несколько
интересных строк, которые были записаны службой Netlogon вжурнал
впроцессе эксплуатации уязвимости Zerologon.
Пример событий, записанных вотладочном журнале Netlogon входе
эксплуатации уязвимости Zerologon
При настроенном режиме отладки Netlogon вжурнале фиксируется каждый этап атаки идаже присутствует MD5-хеш пароля, который был установлен для учетной записи контроллера домена. MD5-хеш записывается вформате little-endian. Однако подобный способ мониторинга неочень удобный сточки зрения сбора событий вSIEM-систему, кроме того, онтребует включения режима отладки Netlogon навсех контроллерах домена.
Обнаружение артефактов, оставленных эксплоитами
Первая стадия процесса эксплуатации это фактически брутфорс.
Эксплоит множество раз пытается аутентифицироваться спомощью
Netlogon наконтроллере домена ссообщением ClientChallenge,
состоящим из8нулевых байт. Множественные неуспешные попытки
аутентификации приводят кгенерации события 5805на контроллере
домена: The session setup from the computer failed toauthenticate.
The following error occurred: Access isdenied (см. пример события
наскриншоте ниже).
Кроме того, если вэксплоите было указано неверное имя учетной
записи контроллера домена, топопытка аутентификации сневерной
учетной записью вызывает генерацию события 5723на контроллере
домена: The session setup from computer failed because the security
database does not contain atrust account referenced bythe specified
computer (наскриншоте ниже).
Вслучае эксплуатации Zerologon при помощи утилиты mimikatz или других эксплоитов, запущенных схоста сименем kali, всобытиях остаются артефакты (имя хоста сустановленной ОСKali Linux меняется крайне редко, поэтому иучитывается вправиле). Mimikatz снеизмененным исходным кодом оставляет артефакт ввиде подстроки mimikatz всобытиях 5805 и5723.
Врамках исследования мытакже рассмотрели различные вариации использования эксплоитов ивыявили случаи эксплуатации уязвимости Zerologon свиртуальной машины под управлением ОСKali Linux, при которых всобытиях 5805 и5723 оставался артефакт ввиде подстроки kali, указанной вкачестве хоста источника аутентификации.
Событие 5805. Ошибка аутентификации сессии схоста kali. Доступ
запрещен
Событие 5723. Ошибка установления сессии схоста mimikatz из-за
отсутствия вбазе данных безопасности аккаунта evildc
Таким образом, логика первого правила обнаружения попытки
эксплуатации уязвимости Zerologon будет выглядеть следующим
образом:
(EventID = 5805 OREventID = 5723) AND (Message contains
kali ORMessage contains mimikatz)
Обнаружение наосновании различий легитимной смены пароля отэксплуатации уязвимости
Теперь рассмотрим методы обнаружения, основанные наразличном наборе событий при периодическом легитимном обновлении пароля учетной записи компьютера ипри его смене при эксплуатации Zerologon.
Максимальный срок действия пароля учетной записи компьютера поумолчанию 30дней. Поистечении этого срока пароль будет изменен средствами операционной системы сиспользованием протокола Netlogon. Данное значение может быть изменено при помощи локальной или групповой политики:
Computer Configuration Policies Windows Settings Security Settings Local Policies Security Options Domain member: Maximum machine account password age.
При изменении пароля учетной записи компьютера вжурнале событий Security будет сгенерировано несколько событий. Первое изних это событие сEventID 4742 Acomputer account was changed, которое имеет TargetUserName, равное имени учетной записи контроллера домена, аPasswordLastSet установлено вдату смены пароля. Это событие означает, что пароль учетной записи компьютера контроллера домена был изменен.
Событие 4742. Пароль учетной записи DC$ был изменен
в5:46:34PM
Вжурнале событий System есть еще одно интересное событие сEventID 5823 The system successfully changed its password onthe domain controller. This event islogged when the password for the computer account ischanged bythe system. Itislogged onthe computer that changed the password. Это событие означает, что учетная запись компьютера была легитимно изменена системой.
Событие
5823. Пароль учетной записи контроллера домена был успешно изменен
системой в5:46:34PM
Таким образом, при легитимной смене пароля учетной записи контроллера домена будет сгенерировано два события: 5823 и4742. Однако при эксплуатации Zerologon событие 5823 будет отсутствовать вжурнале аудита.
Логика второго правила обнаружения эксплуатации уязвимости Zerologon может выглядеть следующим образом:
when bothof (EventID = 4742 AND TargetUserName INDomain_Controller_Accounts_List AND PasswordLastSet != -) and not (EventID = 5823) were detected onthe same host within 1minute
Реализованное поописанной выше логике правило позволит свысокой точностью обнаружить факты эксплуатации уязвимости Zerologon. Дополнительной настройки политики аудита для его работы непотребуется. Единственное, что потребуется, подготовить список контроллеров домена организации ипоместить его внабор Domain_Controller_Accounts_List.
Однако можно посмотреть напроцесс обнаружения эксплуатации уязвимости Zerologon под другим углом. Ранее мыписали, что первая стадия эксплуатации это брутфорс. Поэтому, если втечение одной минуты наодном контроллере домена будут обнаружены оба события 5805 и4742, это также будет свидетельствовать офакте успешной эксплуатации Zerologon.
Логика нашего третьего правила для обнаружения эксплуатации уязвимости Zerologon, может выглядеть следующим образом:
when bothof (EventID = 4742 AND TargetUserName INDomain_Controller_Accounts_List AND PasswordLastSet != -) and (EventID = 5805) were detected onthe same host within 1minute
Обнаружение эксплуатации наоснове сетевого трафика
Как мыупоминали вначале статьи, первый этап эксплуатации уязвимости подразумевает множественные попытки отправки ClientChallenge спредустановленным нулевым значением ключа для обхода аутентификации. Как показала практика, вподавляющем большинстве случаев для обхода механизма аутентификации необходимо неменее 10попыток. Такая аномалия может быть легко обнаружена всетевом трафике. Обращения попротоколу DCE/RPC сотправкой запросов наполучение ServerChallenge методом NetrServerReqChallenge ипопытками аутентификации методами NetrServerAuthenticate снулевым значением ClientChallenge осуществляются наRPC-интерфейс MS-NRPC.
Трафик Mimikatz версии 2.2.0-20200916 без шифрования нагрузки DCE/RPC при обходе аутентификации снулевым значением ключа содержит артефакт впеременной Computer Name метода NetrServerReqChallenge (Opnum4).
Трафик Mimikatz версии 2.2.0-20200916 при обходе
аутентификации
Трафик Mimikatz версии 2.2.0-20200918с шифрованием нагрузки DCE/RPC (посредством использования NTLMSSP суровнем аутентификации RPC_C_AUTHN_LEVEL_PKT_PRIVACY) несодержит уникальных артефактов. Однако атаку можно выявить помногократно повторяющимся методам NetrServerReqChallenge (Opnum4) иNetrServerAuthenticate2 (Opnum15) втрафике отединственного источника запромежуток времени внесколько секунд.
Зашифрованный трафик Mimikatz версии 2.2.0-20200918 при обходе
аутентификации
Посредством PoC отправка пар методов NetrServerReqChallenge иNetrServerAuthenticate осуществляется вотдельных TCP-сессиях. При этом концептуально подход квыявлению наоснове повторяющихся пар NetrServerReqChallenge иNetrServerAuthenticate остается темже.
Назаключительном этапе атаки при помощи метода NetrServerPasswordSet2 (Opnum30) споследовательностью из516 нулевых байтов для учетной записи компьютера контроллера домена устанавливается пустой пароль.
Трафик запроса насброс пароля методом
NetrServerPasswordSet2
Таким образом, обнаружить атаку Zerologon посетевому трафику возможно поаномально большому количеству запросов отединственного источника попротоколу DCE/RPC спарами методов NetrServerReqChallenge иNetrServerAuthenticate закороткий промежуток времени. При определенных условиях можно более точно идентифицировать активность, основываясь науникальных артефактах втрафике, аненастатистических аномалиях.
Обнаружение артефактов вадресном пространстве LSASS
Поскольку вовремя эксплуатации уязвимости Zerologon происходит
аутентификация наконтроллере домена сиспользованием MS-NRPC функции
hNetrServerAuthenticate2 (hNetrServerAuthenticate3),
впроцессе аутентификации задействуется сервис проверки подлинности
локальной системы (LSASS). Врезультате обращения ксерверу проверки
подлинности вадресное пространство процесса lsass.exe
попадает артефакт структура, содержащая параметры, переданные
вфункцию hNetrServerAuthenticate2
(hNetrServerAuthenticate3) (см. рисунок ниже).
server_auth = nrpc.hNetrServerAuthenticate3( rpc_con, '\\\\' + compname + '\\x00', #\\\\dc compname + '$\\x00', #dc nrpc.NETLOGON_SECURE_CHANNEL_TYPE.ServerSecureChannel, #6 compname + '\\x00', #dc ciphertext, #00000000 flags #0x212fffff)
Пример вызова функции hNetrServerAuthenticate3с передаваемыми ейаргументами
Фрагмент дампа адресного пространства процесса lsass
сартефактами после эксплуатации уязвимости Zerologon
Нафрагменте исходного кода одного изэксплоитов ифрагменте дампа адресного пространства процесса lsass сартефактами, оставшимися после эксплуатации, видна взаимосвязь. Переданные вфункцию аргументы остались впамяти, общая структура данных сохранилась. Если смотреть сконца, 4байта (0212fffff) представляют собой флаги Netlogon Negotiable Options. Перед ним располагаются 8нулевых байтов, представляющие собой нулевой шифротекст. Затем перед ними трижды записывается имя хоста DCв такомже виде ипорядке, вкотором аргументы были переданы вфункцию. Также впамяти виден байт, означающий тип безопасного канала Netlogon ServerSecureChannel (06).
Однако иногда понеустановленным причинам этот идругие байты
могут принимать различные значения, несвязанные сописанием выше.
Артефакты вадресном пространстве процесса lsass.exe
хранятся всегменте, который неподразумевает долговременного
хранения данных, имогут быть удалены влюбой момент после появления.
Наше исследование показало, что вбольшинстве случаев артефакты
остаются впамяти процесса lsass.exe недольше получаса,
после чего перезаписываются другими данными.
Основным маркером, позволяющим находить данный участок адресного пространства ииспользовать его для дальнейших проверок, являются флаги Netlogon Negotiable Options. Они представляют собой 32-битное число, которое формируется вбинарном виде изнабора различных параметров.
Поинформации изтехнического документа компании Secura, атакже других исследований данной уязвимости, второй этап эксплуатации Zerologon это отключение механизма RPC signing and sealing посредством отключения нужного бита вофлаге. Вовсех рассмотренных эксплоитах иисследованиях для отключения данного механизма используется значение флагов 0212fffff. Однако наше исследование показало, что единственный влияющий науспешную эксплуатацию параметр это 25-й бит, отвечающий завключение поддержки AES-CFB8 Supports Advanced Encryption Standard (AES) encryption (128 bit in8-bit CFB mode) and SHA2hashing. Для успешной эксплуатации уязвимости требуется лишь этот флаг, остальные могут быть установлены в1или0, это неповлияет нарезультат. Тем самым изменение нескольких бит вофлаге влечет засобой потерю искомого якоря вадресном пространстве lsass ввиде байт ffff2f21, содержащих всебе флаги, которые используют все протестированные вовремя исследования эксплоиты.
Помимо обхода детектирующей логики YARA-правил, окоторых расскажем ниже, использование некоторых флагов Netlogon Negotiable Options приводит ктому, что вадресном пространстве lsass неостается артефактов, покоторым возможно выявить факт эксплуатации уязвимости Zerologon. Один изтаких флагов 0312fffff. Так подтверждается гипотеза отом, что флаги, которые порезультатам исследований позволяют отключить механизм RPC signing and sealing, насамом деле для этого непредназначены.
Входе исследования мыпроанализировали различные YARA-правила (втом числе разработанное специалистами изкомпании Cynet), нацеленные наобнаружение следов эксплуатации уязвимости Zerologon впамяти системы. Мыустановили, что существующие правила неучитывают различных аномалий, связанных смодификацией некоторых значащих байт вадресном пространстве, ирешили реализовать новое YARA-правило, учитывающее эти аномалии.
Необходимо напомнить, что эксплуатация возможна при практически любом сочетании флагов Netlogon Negotiable Options, нопри этом именно флаги служат якорем для обнаружения артефактов впамяти. Поэтому мыприняли такое ограничение: использовать внашем YARA-правиле распространенное сочетание флагов 0212fffff. Впроцессе разработки мыпротестировали различные эксплоиты, втом числе модуль zerologon утилиты mimikatz. Полученное правило протестировано наОСWindows Server 2012R2 иWindows Server 2016.
YARA-правило, разработанное входе исследования, представлено ниже.
rule Zerologon_exploit{ meta: vulnerability = "CVE-2020-1472" description = "Memory detection of Zerologon exploits" reference = "<https://www.secura.com/blog/zero-logon>" reference = "<https://www.cynet.com/zerologon>" strings: $pattern = {00 ?? ?? (0? | 10 | 11) 00 00 00 00 00 00 00 (0? | 10 | 11) 00 00 00 (4? | 5? | 6? | 7? | 2D) 00 [1-27] 00 (24 | 00) 00 00 00 ( 00 00 | 06 00 | 06 00 00 00) (0? | 10) 00 00 00 00 00 00 00 (0? | 10) 00 00 00 (4? | 5? | 6? | 7? | 2D) 00 [1-27] 00 00 00 [8] FF FF 2F 21} condition: $pattern}
YARA-правило для обнаружения фактов эксплуатации Zerologon
Выводы
Описанные выше правила наоснове журналов событий Windows, сетевой телеметрии, атакже YARA-правило можно использовать как поотдельности, так ивместе, что позволит нетолько детектировать факты эксплуатации Zerologon, ноиповысить скорость классификации инцидента.
Новости отом, что информационные системы той или иной компании зашифрованы входе атаки сиспользованием Zerologon, появляются все чаще. Поэтому нестоит забывать, что одной лишь возможности обнаружить факты эксплуатации Zerologon для защиты недостаточно. Значительно снизить риски поможет установка закрывающих уязвимость обновлений безопасности отMicrosoft.
