Критическая уязвимость Active Directory Zerologon (CVE-2020-1472)
В августе 2020 года Microsoft выпустила обновление, закрывающее критическую уязвимость в Active Directory — CVE-2020-1472 (более известную, как Zerologon), которое еще 2 месяца назад было успешно установлено на всех DC. Но не все администраторы знают, что этим обновлением для контролеров домена история не закончится. В этой статье мы рассмотрим особенности уязвимости Zerologon, как защитить от нее контроллеры домена AD, почему в феврале будет еще одно обновление Zerologon и что со всем этим делать администратору домена.
В чем особенность уязвимости CVE-2020-1472 (ZeroLogon)?
Критическая уязвимость CVE-2020-1472 в Active Directory на всех версиях Windows Server (2008 R2, 2012, 2016, 2019) позволяет неаутентифицированному атакующему удаленно получить права администратора домена. За счет ошибки в реализации протокола шифрования AES-CFB8 в Netlogon Remote Protocol (MS-NRPC) атакующий, имеющий доступ по сети к контроллеру домена, может эскалировать свои привилегии и изменить пароль учетной записи контроллера домена в AD. После этого атакующий может авторизоваться на DC с правами SYSTEM и получить полный доступ к базе Active Directory (сбросить пароли администраторов домена, или любые другие действия в AD).
Для реализации уязвимости Zerologon атакующему нужно установить соединение через Netlogon (используются порты RPC локатора TCP/135, динамический диапазон RPC и протокол SMB по порту TCP/445) с помощью определенной последовательности, начинающейся с нулей (zero). Уязвимость в Netlogon позволяет выдать себя за легитимный компьютер домена, а эскалация привилегий позволяет сменить пароль аккаунта DC.
Данной уязвимости присвоен максимальный рейтинг CVSS – 10 из 10 баллов.
Уязвимости подвержены все версии Windows Server:
На данный момент в публичном доступе есть несколько работающих эксплоитов Zerologon (в том числе модуль zerologon был добавлен в mimikatz).
Есть и Python скрипт для тестирования ваших DC на zerologon уязвимость — https://github.com/SecuraBV/CVE-2020-1472.
Обновления Windows Server для защиты от критической уязвимости Zerologon
В связи с тем, что срок расширенной поддержки Windows Server 2008 R2 завершен в начале этого года, Microsoft не выпустила общедоступное исправление для этой версии ОС. Однако если вы приобрели годовую платную подписку Extended Security Updates (ESU), вы можете получить и установить обновление 4571729.
Для остальных версий Windows Server обновления доступны через Windows Update, WSUS или вы можете скачать их в Microsoft Update Catalog и установить msu файлы вручную.
Как защитить домен Active Directory от уязвимости ZeroLogon?
Обновления, закрывающие уязвимость Zerologon, были выпущены еще в августе 2020 года. Чтобы защитить ваши сервера, вам необходимо установить августовское (или более позднее) кумулятивное обновление для вашей версии Windows Server на всех контроллерах домена.
Но на самом деле все не заканчивается с установкой этого патча.
Microsoft планирует исправить уязвимость Zerologon в два этапа, позволяющих относительно плавно перейти на безопасный удаленный вызов процедур (RPC) в Netlogon:
После установки первого обновления в журналах контроллеров домена вы можете обнаружить события подключения по небезопасной версии Netlogon RPC. Кроме того, если у вас не осталось legacy устройств, вы можете заранее, не дожидаясь 2021 года, отключить на DC поддержку старой версии Netlogon RPC (с помощью параметра реестра FullSecureChannelProtection).
До февраля 2021 вам нужно установить актуальные обновляя безопасности на всех обнаруженных устройствах. На Windows достаточно установить актуальное кумулятивное обновление. На других устройствах, использующих Netlogon Remote Protocol, нужно запросить обновление у вендора.
В феврале будет выпущено отдельно обновление безопасности, которое в обязательном порядке переведет контроллер домена в режим, в котором все подключающиеся устройства в обязательном порядке должны использовать безопасную версию протокола Netlogon. При этом устройства, указанные в событии 5829 (не поддерживает защищенную версию Netlogon) не смогут корректно работать в домене. Такие устройства придется вручную добавлять в исключения GPO
Групповые политики для Zerologon
Если в вашей сети не осталось устройств, поддерживающих только небезопасную версию, вы можете создать отдельную GPO политику, которая принудительно переведет все DC в сети на использование безопасной версии протокола Netlogon не дожидаясь 9 февраля 2021 года (когда будет выпущено обновление второго этапа, запрещающее подключаться по небезопасной версии Netlogon). Для этого нужно с помощью GPO распространить следующий ключ реестра на все DC:
Как разрешить подключение к DC через Netlogon со сторонних устройств?
Вам нужно создать группы безопасности в AD, добавить в нее аккаунты/устройства, которым нужно разрешить устанавливать безопасный канал с контролером домена без использования новой версии Netlogon RPC.
Security Week 40: патч для уязвимости Zerologon в Windows
Главная тема недели в области кибербезопасности — уязвимость в протоколе Netlogon, обнаруженная и закрытая в серверных версиях Windows еще 11 августа. Баг CVE-2020-1472, также известный как Zerologon, — это «суперуязвимость», критическая дыра с рейтингом CVSS в 10 баллов из 10.
При наличии сетевого доступа к контроллеру домена в корпоративной сети атакующий может сменить пароль на сервере и получить полный контроль над корпоративной инфраструктурой. Возможна и многоступенчатая атака на менее критичные Windows-серверы с тем же конечным результатом. Неофициальное название — Zerologon — уязвимость получила из-за специфики атаки: она начинается с попыток установить соединение, используя последовательность данных из одних нулей. Некорректная реализация алгоритма шифрования AES позволяет авторизоваться на сервере максимум с 256-й попытки, что на практике занимает пару секунд.
На прошлой неделе уязвимостью занялись за пределами Microsoft. Вышел неофициальный патч для Windows Server 2008 R2. Для этой ОС существует и официальная заплатка, но с января этого года она установится только у тех, кто приобрел пакет расширенной поддержки старого релиза.
Кроме того, решать проблему пришлось в коде Samba. Уязвимость актуальна только для тех инсталляций, где сервер Samba используется в качестве контроллера домена. Так как данная конструкция предполагает следование спецификациям протокола Netlogon (а ошибка именно в них, это не случайный софтверный баг), Samba также оказалась в числе пострадавших.
Источники:
Авторизация двух систем по протоколу Netlogon предполагает обмен двумя произвольными числами длиной 8 байт, так называемыми ключами сессии. В процессе шифрования AES-CFB8 используются эти рандомные ключи и вектор инициализации (initialisation vector, IV) — еще одна уникальная последовательность из 16 байт. Точнее, она должна быть уникальной: в спецификациях Netlogon указано, что IV всегда состоит из нулей.
Исследователь Том Терворт обнаружил следующее: если дать алгоритму на вход ключ сессии из восьми нулей и сделать 256 попыток входа, в одной из них комбинация нулевого ключа и нулевого вектора инициализации даст нулевой ClientCredential. Зная это, мы можем авторизоваться на сервере, как любой компьютер, состоящий в домене. На этом этапе атакующий по-прежнему не может обмениваться зашифрованными данными, но это и не обязательно: сервер без проблем установит сессию без шифрования, видимо, с целью поддержки старых ОС. В итоге появляется возможность авторизоваться как администратор атакуемого сервера и поменять пароль в Active Directory.
На практике процесс атаки требует дополнительных шагов, но при наличии сетевого доступа к контроллеру домена (при доступе в локальную сеть) они достаточно простые. Две недели назад эксплойт для уязвимости был выложен в публичный доступ, и уже есть сообщения о реальных атаках на серверы под управлением Windows.
Судя по данным из инструкции Microsoft для администраторов, уязвимость будут закрывать в два этапа. На первом, начиная с 11 августа (если вы установили патч, конечно), старые системы, способные подключаться к домену только по уязвимому протоколу, смогут это сделать. При этом ломается известный метод атаки, но, возможно, существуют другие, более сложные способы. На втором этапе, с 9 февраля 2021 года, поддерживаемые серверы будут сбрасывать подключения без шифрования данных по умолчанию. Иными словами, в некоторых организациях администраторам добавится головной боли по выявлению и обновлению устаревших систем. В любом случае закрывать уязвимость надо, уж слишком высока цена взлома.
Warning: 27 years from now, a bug in this function will be used by EternalBlue.
The Windows XP source code leak is a welcome surprise. pic.twitter.com/M1MQpuyugm
Утекли исходные коды Windows XP и других старых ОС Microsoft. Архив объемом 43 гигабайта появился в общем доступе на прошлой неделе. Полноту и качество утечки пока толком не оценили. Возможно, это приведет к обнаружению новых критических уязвимостей в Windows XP, которые уже никто не будет закрывать. С другой стороны, даже известные баги этой ОС делают ее небезопасной, утечка в данном случае ничего не меняет.
Критическая уязвимость в Firefox для Android позволяет удаленно запускать браузер, который откроет произвольный URL. Релиз десктопного Firefox 81 и ESR 78.3 закрывает другую пачку критических багов.
Обнаружен троян для Android, перехватывающий сообщения с одноразовыми кодами авторизации и крадущий данные для доступа к мессенджеру Telegram и сервисам Google. Другой банковский троян для Android использует TeamViewer для удаленного контроля над устройством.
Специалисты Sophos исследуют мошенническую кампанию, предлагающую «ранний доступ» к iPhone 12. Скам начинается с переписки в iMessage, а заканчивается кражей денег с кредитной карты.
Компания Check Point Software опубликовала исследование о критической уязвимости в приложении Instagram для iOS и Android. Выполнение произвольного кода стало возможно благодаря багу в библиотеке, декодирующей изображения в формате JPEG.
Microsoft начала принудительно устанавливать патч против уязвимости Zerologon
Стало известно о том, что Microsoft начала распространять принудительное обновление, которое устранит опасную уязвимость Zerologon в устройствах на базе Windows. Согласно имеющимся данным, обновление будет автоматически применено на всех устройствах, получивших февральский патч безопасности, который был выпущен на этой неделе в рамках программы Patch Tuesday.
Напомним, Zerologon отслеживается под идентификатором CVE-2020-1472 и представляет собой уязвимость службы Netlogon в Windows Server, эксплуатация которой позволяет скомпрометировать машинный аккаунт контроллера домена с последующим получением доступа к полной базе Active Directory. Проще говоря, эксплуатация данной уязвимости позволяет злоумышленнику получить права администратора домена.
Исправление уязвимости Zerologon выпущено в два этапа в рамках обновления безопасности, распространение которого началось в августе 2020 года. Патч обеспечивает безопасное соединение с применением удалённого вызова процедур Remote Procedure Call для учётных записей пользователей, использующих компьютеры с Windows, доверительных учётных записей, а также для всех контроллеров доменов Windows.
Источник отмечает, что режим автоматической установки патча активирован на всех поддерживаемых контроллерах домена. Исключение составляют контроллеры домена, добавленные администраторами вручную в выделенную группу безопасности, которая разрешает уязвимые соединения безопасного канала Netlogon.
«Microsoft настоятельно рекомендует пользователям установить февральские обновления, чтобы полностью защититься от этой уязвимости. Клиентам, которые используют компьютеры с Windows, настроенные на автоматическое получение обновлений, не нужно предпринимать каких-либо дополнительных действий», — говорится в сообщении Microsoft.
Проблема Zerologon может помочь захвату корпоративной сети
Реверс малвари
На этой неделе выяснилось, что в прошлом месяце компания Microsoft исправила серьезнейшую уязвимость. Проблема имеет идентификатор CVE-2020-1472 и носит имя Zerologon. Баг позволяет захватывать Windows-серверы, работающие в качестве контроллеров домена в корпоративных сетях.
В августе 2020 года эту проблему описывали как повышение привилегий в Netlogon, набравшую 10 баллов из 10 возможных по шкале оценки уязвимостей CVSS. Однако тогда детали уязвимости не разглашались.
Теперь специалисты голландской компании Secura BV, исходно обнаружившие баг, опубликовали отчет с его детальным описанием, и стало ясно, что проблема Zerologon не зря получила такую оценку. К отчету экспертов не приложен PoC-эксплоит, но приложен Python-скрипт, который можно использовать для проверки корректности настройки контроллера домена.
В сущности, уязвимость Zerologon опирается на слабый криптографический алгоритм, используемый в процессе аутентификации Netlogon. Проблему назвали Zerologon, так как атака осуществляется через добавление нулей в определенные аутентификационные параметры Netlogon, как видно на иллюстрации выше. В результате баг позволяет злоумышленнику манипулировать аутентификацией,а именно:
Исследователи подчеркивают, что такая атака может занимать максимум три секунды. Кроме того, практически никаких ограничений у атаки нет: к примеру, злоумышленник может выдать себя за контроллер домена и изменить пароль, что позволит ему захватить всю корпоративную сеть.
К счастью, Zerologon нельзя использовать удаленно, то есть атакующему сначала нужно каким-то образом проникнуть в сеть компании и закрепиться там. Однако если это произошло, Zerologon несет огромный риск. К примеру, такой баг может очень пригодиться операторам шифровальщиков, которые зачастую начинают атаку с заражения всего одного компьютера в сети компании, а затем стремятся распространить свое влияние на всю сеть.
«Эта атака имеет огромное влияние, — пишут эксперты Secura BV. — По сути, она позволяет любому злоумышленнику в локальной сети (например, инсайдеру или тому, кто подключил устройство к локальному сетевому порту), полностью скомпрометировать домен Windows».
Выпуск патчей для Zerologon оказался непростой задачей для Microsoft. Дело в том, что инженерам компании пришлось изменить способ, который миллиарды устройств используют для подключения к корпоративным сетям. В итоге процесс исправления бага был разделен на два этапа: первый этап уже завершился в августе 2020 года, когда Microsoft выпустила временное исправление. Этот временный патч сделал механизмы безопасности Netlogon (которые отключал Zerologon) обязательными для всех аутентификационных операций, что эффективно предотвращает атаки.
Релиз более полноценного патча для Zerologon запланирован на февраль 2021 года, на тот случай, если злоумышленники все же найдут способ обойти августовские исправления. К сожалению, специалисты Microsoft ожидают, что второй патч неминуемо вызовет проблемы с аутентификацией на некоторых устройствах.
Охота на Zerologon
Авторы: Демьян Соколин (@_drd0c), Александр Большаков (@spacepatcher), Ильяс Игисинов (@ph7ntom), Хрыков Вадим (@BlackMatter23)
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 состоит из трех этапов.
PoC и эксплоиты
Первый PoC опубликовала компания Secura на GitHub. Скрипт попытается проэксплуатировать уязвимость Zerologon: после успешного установления соединения он немедленно завершит работу и не будет выполнять никаких действий через Netlogon.
Что касается эксплоитов, на момент публикации этой статьи их появилось уже много. Однако все они ведут себя одинаково: либо сбрасывают пароль, либо устанавливают его в определенное пользователем значение.
Есть также альтернативный метод эксплуатации Zerologon, найденный исследователем безопасности Дирк-Яном Моллема. Но он используется вместе с другими уязвимостями и заслуживает отдельной статьи.
Методы обнаружения
Целью нашего исследования было найти все возможные методы обнаружения факта эксплуатации Zerologon. Мы разработали и протестировали логику правил корреляции, сигнатур для сетевых IPS-\IDS-систем, а также YARA-правило для выявления артефактов в памяти процесса LSASS.
Обнаружение с использованием журнала отладки Netlogon
Пример событий, записанных в отладочном журнале Netlogon в ходе эксплуатации уязвимости Zerologon
При настроенном режиме отладки Netlogon в журнале фиксируется каждый этап атаки и даже присутствует MD5-хеш пароля, который был установлен для учетной записи контроллера домена. MD5-хеш записывается в формате little-endian. Однако подобный способ мониторинга не очень удобный с точки зрения сбора событий в SIEM-систему, кроме того, он требует включения режима отладки Netlogon на всех контроллерах домена.
Обнаружение артефактов, оставленных эксплоитами
Первая стадия процесса эксплуатации — это фактически брутфорс. Эксплоит множество раз пытается аутентифицироваться с помощью Netlogon на контроллере домена с сообщением ClientChallenge, состоящим из 8 нулевых байт. Множественные неуспешные попытки аутентификации приводят к генерации события 5805 на контроллере домена: «The session setup from the computer failed to authenticate. The following error occurred: Access is denied» (см. пример события на скриншоте ниже).
Кроме того, если в эксплоите было указано неверное имя учетной записи контроллера домена, то попытка аутентификации с неверной учетной записью вызывает генерацию события 5723 на контроллере домена: «The session setup from computer ’’ failed because the security database does not contain a trust account ’’ referenced by the 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′ OR EventID = ’5723′) AND (Message contains ’kali’ OR Message 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 «A computer account was changed», которое имеет TargetUserName, равное имени учетной записи контроллера домена, а PasswordLastSet установлено в дату смены пароля. Это событие означает, что пароль учетной записи компьютера контроллера домена был изменен.
Событие 4742. Пароль учетной записи DC$ был изменен в 5:46:34 PM
В журнале событий System есть еще одно интересное событие с EventID 5823 — «The system successfully changed its password on the domain controller. This event is logged when the password for the computer account is changed by the system. It is logged on the computer that changed the password». Это событие означает, что учетная запись компьютера была легитимно изменена системой.
Событие 5823. Пароль учетной записи контроллера домена был успешно изменен системой в 5:46:34 PM
Таким образом, при легитимной смене пароля учетной записи контроллера домена будет сгенерировано два события: 5823 и 4742. Однако при эксплуатации Zerologon событие 5823 будет отсутствовать в журнале аудита.
Логика второго правила обнаружения эксплуатации уязвимости Zerologon может выглядеть следующим образом:
Реализованное по описанной выше логике правило позволит с высокой точностью обнаружить факты эксплуатации уязвимости Zerologon. Дополнительной настройки политики аудита для его работы не потребуется. Единственное, что потребуется, — подготовить список контроллеров домена организации и поместить его в набор Domain_Controller_Accounts_List.
Однако можно посмотреть на процесс обнаружения эксплуатации уязвимости Zerologon под другим углом. Ранее мы писали, что первая стадия эксплуатации — это брутфорс. Поэтому, если в течение одной минуты на одном контроллере домена будут обнаружены оба события — 5805 и 4742, это также будет свидетельствовать о факте успешной эксплуатации Zerologon.
Логика нашего третьего правила для обнаружения эксплуатации уязвимости Zerologon, может выглядеть следующим образом:
Обнаружение эксплуатации на основе сетевого трафика
Как мы упоминали в начале статьи, первый этап эксплуатации уязвимости подразумевает множественные попытки отправки ClientChallenge с предустановленным нулевым значением ключа для обхода аутентификации. Как показала практика, в подавляющем большинстве случаев для обхода механизма аутентификации необходимо не менее 10 попыток. Такая аномалия может быть легко обнаружена в сетевом трафике. Обращения по протоколу DCE/RPC с отправкой запросов на получение ServerChallenge методом NetrServerReqChallenge и попытками аутентификации методами NetrServerAuthenticate с нулевым значением ClientChallenge осуществляются на RPC-интерфейс MS-NRPC.
Трафик Mimikatz версии 2.2.0-20200916 без шифрования нагрузки DCE/RPC при обходе аутентификации с нулевым значением ключа содержит артефакт в переменной Computer Name метода NetrServerReqChallenge (Opnum 4).
Трафик Mimikatz версии 2.2.0-20200916 при обходе аутентификации
Трафик Mimikatz версии 2.2.0-20200918 с шифрованием нагрузки DCE/RPC (посредством использования NTLMSSP с уровнем аутентификации RPC_C_AUTHN_LEVEL_PKT_PRIVACY) не содержит уникальных артефактов. Однако атаку можно выявить по многократно повторяющимся методам NetrServerReqChallenge (Opnum 4) и NetrServerAuthenticate2 (Opnum 15) в трафике от единственного источника за промежуток времени в несколько секунд.
Зашифрованный трафик Mimikatz версии 2.2.0-20200918 при обходе аутентификации
Посредством PoC отправка пар методов NetrServerReqChallenge и NetrServerAuthenticate осуществляется в отдельных TCP-сессиях. При этом концептуально подход к выявлению на основе повторяющихся пар NetrServerReqChallenge и NetrServerAuthenticate остается тем же.
На заключительном этапе атаки при помощи метода NetrServerPasswordSet2 (Opnum 30) с последовательностью из 516 нулевых байтов для учетной записи компьютера контроллера домена устанавливается пустой пароль.
Трафик запроса на сброс пароля методом NetrServerPasswordSet2
Таким образом, обнаружить атаку Zerologon по сетевому трафику возможно по аномально большому количеству запросов от единственного источника по протоколу DCE/RPC с парами методов NetrServerReqChallenge и NetrServerAuthenticate за короткий промежуток времени. При определенных условиях можно более точно идентифицировать активность, основываясь на уникальных артефактах в трафике, а не на статистических аномалиях.
Обнаружение артефактов в адресном пространстве LSASS
Пример вызова функции hNetrServerAuthenticate3 с передаваемыми ей аргументами
Фрагмент дампа адресного пространства процесса lsass с артефактами после эксплуатации уязвимости Zerologon
На фрагменте исходного кода одного из эксплоитов и фрагменте дампа адресного пространства процесса lsass с артефактами, оставшимися после эксплуатации, видна взаимосвязь. Переданные в функцию аргументы остались в памяти, общая структура данных сохранилась. Если смотреть с конца, 4 байта (0×212fffff) представляют собой флаги — Netlogon Negotiable Options. Перед ним располагаются 8 нулевых байтов, представляющие собой нулевой шифротекст. Затем перед ними трижды записывается имя хоста DC в таком же виде и порядке, в котором аргументы были переданы в функцию. Также в памяти виден байт, означающий тип безопасного канала Netlogon ServerSecureChannel (06).
Однако иногда по неустановленным причинам этот и другие байты могут принимать различные значения, не связанные с описанием выше. Артефакты в адресном пространстве процесса lsass.exe хранятся в сегменте, который не подразумевает долговременного хранения данных, и могут быть удалены в любой момент после появления. Наше исследование показало, что в большинстве случаев артефакты остаются в памяти процесса lsass.exe не дольше получаса, после чего перезаписываются другими данными.
Основным маркером, позволяющим находить данный участок адресного пространства и использовать его для дальнейших проверок, являются флаги Netlogon Negotiable Options. Они представляют собой 32-битное число, которое формируется в бинарном виде из набора различных параметров.
По информации из технического документа компании Secura, а также других исследований данной уязвимости, второй этап эксплуатации Zerologon — это отключение механизма RPC signing and sealing посредством отключения нужного бита во флаге. Во всех рассмотренных эксплоитах и исследованиях для отключения данного механизма используется значение флагов 0×212fffff. Однако наше исследование показало, что единственный влияющий на успешную эксплуатацию параметр — это 25-й бит, отвечающий за включение поддержки AES-CFB8 «Supports Advanced Encryption Standard (AES) encryption (128 bit in 8-bit CFB mode) and SHA2 hashing». Для успешной эксплуатации уязвимости требуется лишь этот флаг, остальные могут быть установлены в 1 или 0, это не повлияет на результат. Тем самым изменение нескольких бит во флаге влечет за собой потерю искомого якоря в адресном пространстве lsass в виде байт ff ff 2f 21, содержащих в себе флаги, которые используют все протестированные во время исследования эксплоиты.
Помимо обхода детектирующей логики YARA-правил, о которых расскажем ниже, использование некоторых флагов Netlogon Negotiable Options приводит к тому, что в адресном пространстве lsass не остается артефактов, по которым возможно выявить факт эксплуатации уязвимости Zerologon. Один из таких флагов — 0×312fffff. Так подтверждается гипотеза о том, что флаги, которые по результатам исследований позволяют отключить механизм RPC signing and sealing, на самом деле для этого не предназначены.
В ходе исследования мы проанализировали различные YARA-правила (в том числе разработанное специалистами из компании Cynet), нацеленные на обнаружение следов эксплуатации уязвимости Zerologon в памяти системы. Мы установили, что существующие правила не учитывают различных аномалий, связанных с модификацией некоторых значащих байт в адресном пространстве, и решили реализовать новое YARA-правило, учитывающее эти аномалии.
Необходимо напомнить, что эксплуатация возможна при практически любом сочетании флагов Netlogon Negotiable Options, но при этом именно флаги служат якорем для обнаружения артефактов в памяти. Поэтому мы приняли такое ограничение: использовать в нашем YARA-правиле распространенное сочетание флагов 0×212fffff. В процессе разработки мы протестировали различные эксплоиты, в том числе модуль zerologon утилиты mimikatz. Полученное правило протестировано на ОС Windows Server 2012R2 и Windows Server 2016.
YARA-правило, разработанное в ходе исследования, представлено ниже.
YARA-правило для обнаружения фактов эксплуатации Zerologon
Выводы
Описанные выше правила на основе журналов событий Windows, сетевой телеметрии, а также YARA-правило можно использовать как по отдельности, так и вместе, что позволит не только детектировать факты эксплуатации Zerologon, но и повысить скорость классификации инцидента.
Новости о том, что информационные системы той или иной компании зашифрованы в ходе атаки с использованием Zerologon, появляются все чаще. Поэтому не стоит забывать, что одной лишь возможности обнаружить факты эксплуатации Zerologon для защиты недостаточно. Значительно снизить риски поможет установка закрывающих уязвимость обновлений безопасности от Microsoft.