В августе 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:
- Windows Server 2019, Windows Server 2016;
- Windows Server 2004, 1909, 1903 ;
- Windows Server 2012 R2/2012;
- Windows Server 2008 R2 SP 1.
На данный момент в публичном доступе есть несколько работающих эксплоитов 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 файлы вручную.
- Windows Server 2019 (KB4565349), Windows Server 2016 (KB571694);
- Windows Server 2004 (4566782), 1909 (KB4565351), 1903 (KB4565351);
- Windows Server 2012 R2 (KB4571723), Windows Server 2012 (KB4571702).
Как защитить домен Active Directory от уязвимости ZeroLogon?
Обновления, закрывающие уязвимость Zerologon, были выпущены еще в августе 2020 года. Чтобы защитить ваши сервера, вам необходимо установить августовское (или более позднее) кумулятивное обновление для вашей версии Windows Server на всех контроллерах домена.
Но на самом деле все не заканчивается с установкой этого патча.
Microsoft планирует исправить уязвимость Zerologon в два этапа, позволяющих относительно плавно перейти на безопасный удаленный вызов процедур (RPC) в Netlogon:
- Первый этап. Августовский патч представляет собой экстренную заплатка для контроллеров домена от известного сценария атаки. Но это не полноценно устранение уязвимости (возможны и другие сценарии атаки на DC через Netlogon). Устаревшие системы, которые не поддерживают новую, безопасную версию протокола RPC для Netlogon, все еще могут подключиться к контроллеру домену;
- Второй этап. Следующее обновление запланировано на 9 февраля 2021 года. После установки этого обновления все сервера должны отклонять подключения, выполняемые через старую версию протокола Netlogon (впрочем, для legacy систем можно сделать исключения с помощью GPO, об этом чуть ниже).
После установки первого обновления в журналах контроллеров домена вы можете обнаружить события подключения по небезопасной версии Netlogon RPC. Кроме того, если у вас не осталось legacy устройств, вы можете заранее, не дожидаясь 2021 года, отключить на DC поддержку старой версии Netlogon RPC (с помощью параметра реестра FullSecureChannelProtection).
После установки обновлений безопасности, в журналах контроллеров домена станут фиксироваться событии подключения компьютеров с помощью уязвимой версии протокола Netlogon. Нужно обращать внимание на следующие EventID от источника NETLOGON в журнале Event Viewer -> Windows Logs -> System:
- EventID 5827 и 5828 —
The Netlogon service denied a vulnerable Netlogon secure channel connection from a machine account
. Данное сообщение говорит о том, что для данного компьютера запрещено подключение по уязвимой версии протокола Netlogon (до февраля 2021 года это событие информационное, реальных действий по запрету подключений не выполняется);Можно сохранить все события в CSV файл и проанализировать имена подключающихся к DC устройств с помощью PowerShell команды:
Get-EventLog -LogName System -InstanceId 5827 -Source NETLOGON|Select-Object message| Export-Csv c:\ps\5827.csv -Encoding utf8
- EventID 5829 — разрешено подключение по уязвимой версии Netlogon
EventID 583, 5831 – подключение по уязвимой версии Netlogon разрешено благодаря за счет наличия устройства в политике «Domain controller: Allow vulnerable Netlogon secure channel connections».
До февраля 2021 вам нужно установить актуальные обновляя безопасности на всех обнаруженных устройствах. На Windows достаточно установить актуальное кумулятивное обновление. На других устройствах, использующих Netlogon Remote Protocol, нужно запросить обновление у вендора.
В феврале будет выпущено отдельно обновление безопасности, которое в обязательном порядке переведет контроллер домена в режим, в котором все подключающиеся устройства в обязательном порядке должны использовать безопасную версию протокола Netlogon. При этом устройства, указанные в событии 5829 (не поддерживает защищенную версию Netlogon) не смогут корректно работать в домене. Такие устройства придется вручную добавлять в исключения GPO
Групповые политики для Zerologon
Если в вашей сети не осталось устройств, поддерживающих только небезопасную версию, вы можете создать отдельную GPO политику, которая принудительно переведет все DC в сети на использование безопасной версии протокола Netlogon не дожидаясь 9 февраля 2021 года (когда будет выпущено обновление второго этапа, запрещающее подключаться по небезопасной версии Netlogon). Для этого нужно с помощью GPO распространить следующий ключ реестра на все DC:
- Ветка
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
- Тип параметра:
DWORD
- Имя параметра:
FullSecureChannelProtection
Возможные значения:
-
1
— запрет на использование уязвимой версии Netlogon для установки соединения с DC. Данный ключ не действует на аккаунты, добавленные в политику “Domain controller: Allow vulnerable Netlogon secure channel connections» (см ниже); -
0
– разрешить DC принимать подключения с уязвимой версией Netlogon с не-Windows устройств;
Как разрешить подключение к DC через Netlogon со сторонних устройств?
В групповых политиках появился отдельный параметр, позволяющий разрешить определенным устройствам/аккаунтам использовать уязвимую версию Netlogon для подключения к DC. Эта политика называется Domain controller: Allow vulnerable Netlogon secure channel connections и находится в разделе Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options.
Вам нужно создать группы безопасности в AD, добавить в нее аккаунты/устройства, которым нужно разрешить устанавливать безопасный канал с контролером домена без использования новой версии Netlogon RPC.
Включите политику для DC (на уровне Default Domain Controller policy), нажмите кнопку Define Security и укажите группу, которой разрешено использовать небезопасный Netlogon (Create Vulnerable Connection -> Allow).
Добрый день!
Опечатка:
Windows Server 2004 (4566782), 1909 (KB4565351), 1903 (KB4565351);
Хотя,нет все верно)
Точно на Windows 7 будет генериться событие? У меня вообще нет ни одного события с этими ID. Обновления, естественно, на двух КД установленные уже давно. В домене есть Windows 7, 8, 10. Даже одна Windows Server 2003 есть.
У меня Win7 точно выдавали это предупреждение. Но не все, похоже там просто обновления не стоят.
Сергей, разобрались почему нет событий? У меня тоже логи чистые.
Если честно не разбирался. Обновления всегда ставлю. Логи отправляются в graylog, как только появятся события, если появятся, сразу узнаю. Нет событий может быть из-за версии КД Windows 2012. Других нет, чтобы проверить.
От версии ОС не должно зависеть. Уязвимости подвержены все версии. Обновления, которые включают сообщения в логах, вышли и для Windows server 2012.
С 7ой смущает немного.
Обновления стоят, в логах записей нет, хотя 98% клиентов — 7ки, обновленные до упора
Нашли причину?
1. перезагружать контроллер домена надо после установки августовского?
2. Можно ли указать конкретные айпишники, с которых возможно небезопасное соединение или только на уровне обьекта компьютер и пользователь?
1. Нужно
2. Можно указать только объекты AD
У меня тоже нет событий 5829 на контроллерах домена.
Проверял также скриптом от microsoft
Должны быть.
А где можно скачать обновления, если нет расширенной поддержки для windows Server 2008 r2, может найдутся добрые люди кто поделится kb, а то шифровальщики не дремлют, когда оплатят расширенную поддержку не понятно.
С расширенной поддержкой все не так просто. Обновления в рамках ESU доступны для загрузки через WSUS или каталог обновлений Mirosoft. Но при установке этого обновления система проверяет, что она активирована специальным купленным на 1 год ESU ключом (вот тут это описывал https://winitpro.ru/index.php/2019/10/21/windows-7-okonchanie-podderzhki/)
После некоторого гугления нашел тему на реддите, где у многих так же нет событий как и у меня.
После отключениz в политике данных пунктов:
Domain member: Digitally encrypt or sign secure channel data (always)
Domain member: Digitally encrypt secure channel data (when possible)
Domain member: Digitally sign secure channel data (when possible)
У меня c Windows 8.1 генерится событие 5827. Если включить данные пункты, то события нет. На КД у меня политикой включены пункты касательно Domain Controller. У меня на клиентах они включены по умолчанию, даже на Windows Server 2003. Вот и не понятно, особенно с 2003 виндой, у которой обновлений не было уже сто лет, что она оказывается «умеет» в безопаный netlogon ))
Добрый день.
Есть сеть в которой множество компьютеров под управлением Windows XP, Windows 7.
Правильно ли я понимаю, что для того, чтобы они работали после февраля 2021 необходимо будет держать контроллеры домена уязвимыми (не обновленными)? И, в случае обновления КД, клиенты со старыми ПК не смогут авторизоваться ?
Порядок действий:
1) Обновить dc последними апдейтами на сегодняшний день. Обновления усложнят использование уязвимости, но не закроют ее на 100%.
2) После обновлений, в журналах безопасности на dc должны записываться сообщения с указанием клиентов, которые используют уязвимую версию протокола. По этим сообщениям надо составить список клиентов, которым надо разрешить использовать уязвимой версии протокола.
3) Создать GPO с разрешением на подключение с помощью протокола с уязвимостью, накатить политику на клиентов, которых определили ранее.
4) Дождаться февральских обновлений, которые отключать старую версию, кроме клиентов из списка. Можно не ждать февраля и вручную отключить.
На DC обновления однозначно ставить.
От клиентов с XP уже пора избавляться. Если совсем никак, компьютеры с XP в отдельную группу, для которой разрешить использование старой версии протокола.
Но вы как администратор домена рискуете, поэтому я бы не делал исключений кроме как для специализированных устройств.
Просьба к тем, кто получает указанные события. Можете включить политикой вот эти пункты?
Domain member: Digitally encrypt or sign secure channel data (always)
Domain member: Digitally encrypt secure channel data (when possible)
Domain member: Digitally sign secure channel data (when possible)
Как я писал выше, я не получаю данных событий, так как данные пункты у меня включены. Отключаешь, события есть. Можете проверить у себя?
Но ведь эти параметры включены по дефолту. Сообщения в журнале должны быть и так.
Как говорится должны, но не обязаны )). Не я один с такой ситуацией. Буду ждать февраля, тогда и посмотрим.
Подтверждаю. Эти пункты стояли по умолчанию — событий 5827 в журнале не было. После отключения этих трех пунктов ГП — в журнале событий начали появляться события 5827. Сеть состоит в основном из Windows XP и немножко Windows 7
Кто-нибудь установил обновления? Какие результаты?
Добрый день. Расскажите о проблемах, которые возникли при установке обновлений, вылетали ил какие-то сервисы, службы? Старые ОС(XP, Win7) в принципе не поддерживают авторизацию после обновления DC?
После установки обновлений МФУ Kyocera перестали сканировать в SMB-папку. Будьте внимательны.
Здравствуйте. Как решили?
ricoh тоже перестали сканировать в SMB