Служба netlogon отклонила уязвимое подключение rpc учетной записи компьютера
Обновлено: 07.07.2024
15 сентября 2020
В чем суть уязвимости Zerologon?
По большому счету, уязвимость CVE-2020-1472 заключается в несовершенстве схемы криптографической аутентификации Netlogon Remote Protocol. Этот протокол используется для аутентификации пользователей и машин в сетях, построенных на базе домена. В частности, Netlogon служит и для удаленного обновления паролей компьютеров. Уязвимость позволяет злоумышленнику выдать себя за компьютер-клиент и заменить пароль контроллера домена (сервера, контролирующего всю сеть, в том числе запускающего службы Active Directory). В результате атакующий может получить права администратора домена.
Кто уязвим?
Уязвимость CVE-2020-1472 актуальна для компаний, сети которых построены на базе контроллеров доменов под управлением операционных систем Windows.
В частности, злоумышленники могут захватить контроллер домена на базе:
- всех версий Windows Server 2019, Windows Server 2016;
- всех вариантов Windows Server версии 1909;
- Windows Server версии 1903;
- Windows Server версии 1809 (Datacenter, Standard);
- Windows Server 2012 R2;
- Windows Server 2012;
- Windows Server 2008 R2 Service Pack 1.
Правда, для успешной атаки злоумышленникам сначала необходимо проникнуть в корпоративную сеть, но это не такая большая проблема — мы уже неоднократно слышали и об инсайдерских атаках, и о проникновениях через забытые сетевые розетки в общедоступных помещениях.
К счастью, пока нет информации о том, что уязвимость Zerologon когда-либо использовали в реальных атаках. Однако после публикации исследования в блоге компании Secura вокруг этой проблемы поднялся ажиотаж, который, скорее всего, привлек и внимание злоумышленников. Несмотря на то что исследователи не опубликовали работающий proof of concept, они не сомневаются, что злоумышленники смогут его создать, основываясь на патчах.
Как защититься от атак с использованием Zerologon?
Компания Microsoft выпустила патчи, закрывающие эту уязвимость для всех затронутых систем. Они доступны с начала августа этого года, так что если вы еще не обновились, то лучше поспешить. Кроме того, компания рекомендует отслеживать все попытки логина по уязвимой версии протокола и выявлять устройства, которые не поддерживают новую версию. В идеале эксперты Microsoft считают необходимым перевести контроллер домена в режим, в котором все устройства должны использовать безопасный вариант протокола Netlogon.
Обновления не делают этого в принудительном порядке, потому что Netlogon Remote Protocol используется не только в Windows, — есть множество устройств на базе других ОС, которые также полагаются на этот протокол. И далеко не все из них поддерживают его защищенный вариант. Если сделать использование безопасной версии обязательным, эти устройства не смогут корректно работать.
Тем не менее 9 февраля 2021 года контроллеры доменов переведут в этот режим в обязательном порядке, так что администраторам придется как-то решать проблему со сторонними устройствами до этой даты — обновлять или вручную прописывать в исключение. Подробнее о том, что делает августовский патч и что изменится после февральского, можно найти в материале Microsoft наряду с подробными гайдлайнами.
Удаленный протокол Netlogon (другое название — MS-NRPC) — это интерфейс RPC, используемый только устройствами, подключенными к домену. MS-NRPC включает метод проверки подлинности и метод создания безопасного канала Netlogon. Эти обновления внедряют определенное поведение клиента Netlogon для применения безопасного удаленного вызова процедур (RPC) с помощью безопасного канала Netlogon между компьютерами участников и контроллерами домена (DC) Active Directory (AD).
Это обновление для системы безопасности устраняет уязвимость, принудительно внедряя безопасный RPC при использовании безопасного канала Netlogon в поэтапном выпуске, описанном в разделе Сроки выпуска обновлений для устранения уязвимости Netlogon CVE-2020-1472. Чтобы обеспечить защиту леса AD, все DC должны быть обновлены, так как они будут применять безопасный RPC с безопасным каналом Netlogon. Сюда относятся контроллеры домена только для чтения (RODC).
Дополнительные сведения об уязвимости см. в статье CVE-2020-1472.
Принятие мер
Чтобы защитить среду и предотвратить сбои, выполните следующие действия:
Примечание. Шаг 1 по установке обновлений за 11 августа 2020 г. или более поздней версии поможет устранить проблему безопасности, связанную с CVE-2020-1472, в доменах Active Directory и отношениях доверия между ними, а также на устройствах Windows. Чтобы минимизировать риск возникновения проблемы безопасности для сторонних устройств, необходимо выполнить все указанные действия.
Предупреждение. Начиная с февраля 2021 г. режим применения политик будет включен на всех контроллерах доменов Windows, чтобы блокировать уязвимые подключения на несоответствующих устройствах. Тогда вы не сможете отключить режим применения политик.
ОБНОВЛЕНИЕ контроллеров домена (обновление за 11 августа 2020 г. или более поздней версии).
ПОИСК устройств, которые используют уязвимые соединения, путем мониторинга журналов событий.
ИСПРАВЛЕНИЕ несоответствующих устройств, использующих уязвимые соединения.
ВКЛЮЧЕНИЕ режима применения политик для исправления CVE-2020-1472 в своей среде.
Примечание. Если вы используете Windows Server 2008 R2 с пакетом обновления 1 (SP1), для успешной установки обновления, устраняющего эту проблему, требуется лицензия на расширенные обновления безопасности (ESU). Дополнительные сведения о программе расширенных обновлений безопасности см. в статье Вопросы и ответы по жизненному циклу: расширенные обновления безопасности.
В этой статье:
Сроки выпуска обновлений для устранения уязвимости Netlogon CVE-2020-1472
Обновления будут выпущены в два этапа: начальный этап — обновления, выпущенные 11 августа 2020 г. и позже, и этап применения политик — обновления, выпущенные 9 февраля 2021 г. и позже.
11 августа 2020 г. — этап начального развертывания
Этап начального развертывания начинается с обновлений, выпущенных 11 августа 2020 г., и продолжается с последующими обновлениями до этапа применения политик. Эти и последующие обновления изменяют протокол Netlogon для защиты устройств с Windows по умолчанию, регистрируют события обнаружения несоответствующих устройств и добавляют возможность включения защиты для всех устройств, подключенных к домену, с явными исключениями. Этот выпуск:
Внедряет использование безопасного RPC для учетных записей компьютеров на устройствах с Windows.
Внедряет использование безопасного RPC для учетных записей доверия.
Внедряет использование безопасного RPC для всех контроллеров доменов (DC) Windows и других контроллеров доменов.
Включает новую групповую политику для разрешения несоответствующих учетных записей устройств (использующих уязвимые подключения безопасного канала Netlogon). Даже если DC работают в режиме применения политик или после этапа применения политик, разрешенным устройствам не будет отказано в подключении.
Раздел реестра FullSecureChannelProtection для включения режима применения политик DC во всех учетных записях компьютеров (этап применения политик обновит DC до режима применения политик DC).
Включает новые события в случае отказа учетных записей или ожидающегося отказа в режиме применения политик DC (с продолжением на этапе применения политик). Конкретные коды событий описаны ниже в этой статье.
Устранение рисков заключается в установке обновления на все DC и RODC, отслеживание новых событий и исправление проблем с несоответствующими устройствами, использующими уязвимые подключения безопасного канала Netlogon. Учетным записям компьютеров на несоответствующих устройствах может быть разрешено использовать уязвимые подключения безопасного канала Netlogon. Но следует их обновить для поддержки безопасного RPC для Netlogon и как можно скорее внедрить учетную запись для устранения риска атаки.
9 февраля 2021 г. — этап применения политик
Выпуск за 9 февраля 2021 г. знаменует переход на этап применения политик. Теперь DC будут находиться в режиме применения политик независимо от значения раздела реестра режима применения политик. Для этого на всех устройствах с Windows и других устройствах требуется использовать безопасный RPC с безопасным каналом Netlogon или явным образом разрешить учетную запись, добавив исключение для несоответствующих устройств. Этот выпуск:
Внедряет использование безопасного RPC для учетных записей компьютеров на устройствах без Windows, если отсутствует разрешение от групповой политики "Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon".
Запись журнала для события с кодом 5829 будет удалена. Так как все уязвимые подключения запрещаются, в журнале системных событий теперь будут отображаться только события с кодом 5827 и 5828.
Руководство по развертыванию: развертывание обновлений и обеспечение соответствия
(а) После устранения всех событий предупреждений можно включить полную защиту, развернув режим применения политик DC. (b) Все предупреждения следует устранить до обновления этапа применения политик от 9 февраля 2021 г.
Шаг 1. ОБНОВЛЕНИЕ
Развертывание обновлений за 11 августа 2020 г.
Разверните обновления за 11 августа для всех соответствующих контроллеров домена (DC) в лесу, включая контроллеры домена только для чтения (RODC). После развертывания этого обновления исправленные DC:
Начнут применять безопасный RPC во всех учетных записях устройств с Windows, учетных записях доверия и всех DC.
Регистрируют события с кодами 5827 и 5828 в журнале системных событий, если подключения запрещены.
Регистрируют события с кодами 5830 и 5831 в журнале системных событий, если подключения разрешены групповой политикой "Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon".
Шаг 2a. ПОИСК
Обнаружение несоответствующих устройств с помощью события с кодом 5829
После применения к DC обновлений за 11 августа 2020 г. в журналах событий DC могут собираться события, чтобы определить, какие устройства в вашей среде используют уязвимые подключения безопасного канала Netlogon (называемые в этой статье несоответствующими устройствами). Отслеживайте исправленные DC для событий с кодом 5829. Эти события будут содержать важные сведения для определения несоответствующих устройств.
Чтобы отслеживать события, используйте доступные программы мониторинга событий или сценарий для отслеживания своих DC. Пример сценария, который можно адаптировать к своей среде, см. в разделе Сценарий для отслеживания кодов событий, связанных с обновлениями Netlogon для CVE-2020-1472
Шаг 2b. ИСПРАВЛЕНИЕ
Исправление событий с кодами 5827 и 5828
Убедитесь, что на устройстве используется поддерживаемая версия Windows.
Полностью обновите устройство.
Для устройств без Windows, выступающих в роли DC, эти события регистрируются в журнале системных событий при использовании уязвимых подключений безопасного канала Netlogon. Если регистрируется одно из этих событий:
Рекомендация. Обратитесь к изготовителю устройства (OEM) или поставщику программного обеспечения, чтобы получить поддержку для безопасного RPC с безопасным каналом Netlogon
Если несоответствующий DC поддерживает безопасный RPC с безопасным каналом Netlogon, включите безопасный RPC на DC.
Если несоответствующий DC в настоящее время НЕ поддерживает безопасный RPC, обратитесь к изготовителю устройства (OEM) или поставщику программного обеспечения, чтобы получить обновление, поддерживающее безопасный RPC с безопасным каналом Netlogon.
Прекратите использование несоответствующего DC.
Уязвимость. Если несоответствующий DC не может обеспечить поддержку безопасного RPC с безопасным каналом Netlogon до перевода DC в режим применения политик, добавьте DC с помощью групповой политики "Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon", описанной ниже.
Предупреждение. Разрешение DC использовать уязвимые подключения с помощью групповой политики сделает лес уязвимым для атаки. Конечной целью должно быть исправление или удаление всех учетных записей из этой групповой политики.
Исправление события с кодом 5829
Событие с кодом 5829 создается, если на этапе начального развертывания разрешено уязвимое подключение. Такие подключения будут запрещены в режиме применения политик DC. Для этих событий нужно обратить внимание на имя компьютера, домен и версии ОС, идентифицированные для определения несоответствующих устройств, и на способы их исправления.
Способы исправления несоответствующих устройств:
Рекомендация. Обратитесь к изготовителю устройства (OEM) или поставщику программного обеспечения, чтобы получить поддержку для безопасного RPC с безопасным каналом Netlogon:
Если несоответствующее устройство поддерживает безопасный RPC с безопасным каналом Netlogon, включите безопасный RPC на устройстве.
Если несоответствующее устройство в настоящее время НЕ поддерживает безопасный RPC с безопасным каналом Netlogon, обратитесь к изготовителю устройства или поставщику программного обеспечения, чтобы получить обновление, разрешающее включить безопасный RPC с безопасным каналом Netlogon.
Прекратите использование несоответствующего устройства.
Уязвимость. Если несоответствующее устройство не может обеспечить поддержку безопасного RPC с безопасным каналом Netlogon до перевода DC в режим применения политик, добавьте устройство с помощью групповой политики "Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon", описанной ниже.
Предупреждение. Разрешение учетным записям устройств использовать уязвимые подключения с помощью групповой политики подвергнет эти учетные записи AD риску. Конечной целью должно быть исправление или удаление всех учетных записей из этой групповой политики.
Разрешение уязвимых подключений из сторонних устройств
Используйте групповую политику "Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon", чтобы добавить несоответствующие учетные записи. Это следует рассматривать только в качестве краткосрочного решения, пока несоответствующие устройства не будут исправлены, как описано выше. Примечание. Разрешение уязвимых подключений для несоответствующих устройств следует предоставлять с осторожностью, учитывая неизвестное влияние на безопасность.
Создание групп безопасности для учетных записей, которым будет разрешено использовать уязвимый безопасный канал Netlogon.
В групповой политике выберите "Конфигурация компьютера" > "Параметры Windows" > "Параметры безопасности" > "Локальные политики" > "Параметры безопасности"
Если имеется группа администраторов или любая другая группа, не созданная специально для использования с этой групповой политикой, удалите ее.
Добавьте группу безопасности, созданную специально для использования с этой групповой политикой, в дескриптор безопасности с параметром "Разрешить". Примечание. Параметр "Запретить" соответствует поведению без добавления учетной записи, то есть учетным записям будет запрещено создавать уязвимые безопасные каналы Netlogon.
После добавления групп безопасности групповая политика должна реплицироваться на каждый DC.
Периодически отслеживайте события 5827, 5828 и 5829, чтобы определить, какие учетные записи используют уязвимые подключения безопасного канала.
При необходимости добавляйте эти учетные записи компьютеров в группы безопасности. Рекомендация. Используйте группы безопасности в групповой политике и добавляйте учетные записи в группу, чтобы это участие реплицировались в рамках обычной репликации AD. Это позволит избежать частого обновления групповой политики и задержек репликации.
После исправления всех несоответствующих устройств вы можете перевести свои DC в режим применения политик (см. следующий раздел).
Предупреждение. Разрешение DC использовать уязвимые подключения для учетных записей доверия с помощью групповой политики сделает лес уязвимым для атаки. Учетные записи доверия обычно именуются по доверенному домену, например: DC в домене-a имеет отношение доверия с DC в домене-b. DC в домене-a внутри имеет учетную запись доверия "domain-b$", представляющую объект доверия для домена-b. Если DC в домене-а подвергает лес риску атаки, разрешая уязвимые подключения безопасного канала Netlogon из учетной записи доверия домена-b, администратор может использовать команду Add-adgroupmember –identity "Имя группы безопасности" -members "domain-b$", чтобы добавить учетную запись доверия в группу безопасности.
Шаг 3a. ВКЛЮЧЕНИЕ
Переход в режим применения политик до этапа применения политик в феврале 2021 г.
После исправления всех несоответствующих устройств путем включения безопасного RPC или разрешения уязвимых подключений с помощью групповой политики "Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon" присвойте разделу реестра FullSecureChannelProtection значение 1.
Примечание. Если вы используете групповую политику "Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon" убедитесь в репликации и применении групповой политики ко всем DC до настройки раздела реестра FullSecureChannelProtection.
После развертывания раздела реестра FullSecureChannelProtection контроллеры домена (DC) будут находиться в режиме применения политик. Этот параметр требует, чтобы все устройства, использующие безопасный канал Netlogon, отвечали одному из следующих условий:
Использование безопасного RPC.
Внимание! Сторонние клиенты, не поддерживающие безопасный RPC с подключениями безопасного протокола Netlogon, будут запрещены после развертывания раздела реестра режима применения политик DC, что может нарушить службы рабочей среды.
Шаг 3b. Этап применения политик
Развертывание обновлений за 9 февраля 2021 г.
Развертывание обновлений, выпущенных 9 февраля 2021 г. и позднее, включит режим применения политик DC. Режим применения политик DC — это состояние, при котором все подключения Netlogon должны использовать безопасный RPC или учетная запись должна быть добавлена в групповую политику "Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon". В этот момент раздел реестра FullSecureChannelProtection больше не нужен и больше не будет поддерживаться.
Групповая политика "Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon"
Рекомендуется использовать группы безопасности в групповой политике, чтобы участие реплицировались в рамках обычной репликации AD. Это позволит избежать частого обновления групповой политики и задержек репликации.
Путь политики и имя параметра
Путь политики: "Конфигурация компьютера" > "Параметры Windows" > "Параметры безопасности" > "Локальные политики" > "Параметры безопасности"
Имя параметра: "Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon"
Требуется перезагрузка? Нет
Этот параметр безопасности определяет, обходит ли контроллер домена безопасный RPC для подключений безопасного канала Netlogon для определенных учетных записей компьютеров.
Эту политику следует применить ко всем контроллерам домена в лесу, включив политику в OU контроллеров домена.
При настройке списка "Создание уязвимых подключений" (список разрешений):
Разрешить. Контроллер домена позволит определенным группам и учетным записям использовать безопасный канал Netlogon без безопасного RPC.
Запретить. Этот параметр соответствует поведению по умолчанию. Контроллер домена потребует, чтобы определенные группы и учетные записи использовали безопасный канал Netlogon с безопасным RPC.
По умолчанию: Эта политика не настроена. Никакие компьютеры и учетные записи доверия не исключаются явным образом из обязательного применения безопасного RPC с подключениями безопасного канала Netlogon.
Эта политика поддерживается в Windows Server 2008 R2 с пакетом обновления 1 (SP1) и более поздних версиях.
Ошибки в журнале событий Windows, связанные с CVE-2020-1472
Существует три категории событий.
1. События, регистрируемые при отказе в подключении из-за попыток уязвимого подключения безопасного канала Netlogon:
Ошибка 5827 (учетные записи компьютеров)
Ошибка 5828 (учетные записи доверия)
2. События, регистрируемые при разрешении подключения, так как учетная запись была добавлена в групповую политику "Контроллер домена: разрешить уязвимые подключения безопасного канала Netlogon":
Предупреждение 5830 (учетные записи компьютеров)
Предупреждение 5831 (учетные записи доверия)
3. События, регистрируемые в том случае, если подключение разрешено в исходном выпуске, но будет запрещено в режиме применения политик DC:
Предупреждение 5829 (учетные записи компьютеров)
Событие с кодом 5827
Событие с кодом 5827 регистрируется, если запрещено уязвимое подключение безопасного канала Netlogon из учетной записи компьютера.
CVE-2020-1472, или Zerologon, уже получила звание одной из самых опасных уязвимостей, обнаруженных за последние годы. Она позволяет атакующему скомпрометировать учетную запись машинного аккаунта контроллера домена и получить доступ к содержимому всей базы Active Directory. Для эксплуатации достаточно наличия сетевой связности с контроллером домена организации.
Мы провели собственное исследование Zerologon и разработали различные методы обнаружения ее эксплуатации: по событиям журналов аудита Windows, по сетевому трафику и при помощи YARA-правил. В этой статье подробно остановимся на каждом из них.
В чем суть уязвимости Zerologon
Zerologon — это уязвимость в протоколе шифрования, который использует служба Netlogon. Протокол позволяет компьютерам проходить аутентификацию на контроллере домена и обновлять пароль своего аккаунта в Active Directory. Именно эта особенность делает Zerologon опасной. В частности, уязвимость позволяет атакующему выдать себя за контроллер домена и изменить его пароль. Злоумышленник получает доступ к контроллеру домена c наивысшими привилегиями, а следовательно — и к корпоративной сети. После смены пароля атакующий может использовать учетную запись контроллера домена для развития атаки, например, выполнив атаку DCSync (получение учетных записей Active Directory через механизм репликации).
Как обнаружил Тервоорт, применение шифрования 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, рассмотрим журнал событий Netlogon. По умолчанию в журналах Windows аудиту подлежит лишь часть событий, однако можно включить режим отладки Netlogon с помощью команды nltest /dbflag:0x2080ffff , которая должна быть запущена от имени администратора. После этого служба Netlogon будет сохранять большую часть важных событий в файл журнала, который можно найти по пути C:\Windows\debug\netlogon.txt . Затем необходимо перезапустить службу Netlogon. На скриншоте ниже — несколько интересных строк, которые были записаны службой Netlogon в журнал в процессе эксплуатации уязвимости Zerologon.
Пример событий, записанных в отладочном журнале Netlogon в ходе эксплуатации уязвимости Zerologon
При настроенном режиме отладки Netlogon в журнале фиксируется каждый этап атаки и даже присутствует MD5-хеш пароля, который был установлен для учетной записи контроллера домена. MD5-хеш записывается в формате little-endian. Однако подобный способ мониторинга не очень удобный с точки зрения сбора событий в SIEM-систему, кроме того, он требует включения режима отладки Netlogon на всех контроллерах домена.
Обнаружение артефактов, оставленных эксплоитами
Кроме того, если в эксплоите было указано неверное имя учетной записи контроллера домена, то попытка аутентификации с неверной учетной записью вызывает генерацию события 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 может выглядеть следующим образом:
when both of (EventID = ’4742′ AND TargetUserName IN «Domain_Controller_Accounts_List» AND PasswordLastSet != ’-’) and not (EventID = ’5823′) were detected on the same host within 1 minute
Реализованное по описанной выше логике правило позволит с высокой точностью обнаружить факты эксплуатации уязвимости Zerologon. Дополнительной настройки политики аудита для его работы не потребуется. Единственное, что потребуется, — подготовить список контроллеров домена организации и поместить его в набор Domain_Controller_Accounts_List.
Однако можно посмотреть на процесс обнаружения эксплуатации уязвимости Zerologon под другим углом. Ранее мы писали, что первая стадия эксплуатации — это брутфорс. Поэтому, если в течение одной минуты на одном контроллере домена будут обнаружены оба события — 5805 и 4742, это также будет свидетельствовать о факте успешной эксплуатации Zerologon.
Логика нашего третьего правила для обнаружения эксплуатации уязвимости Zerologon, может выглядеть следующим образом:
when both of (EventID = ’4742′ AND TargetUserName IN «Domain_Controller_Accounts_List» AND PasswordLastSet != ’-’) and (EventID = ’5805′) were detected on the same host within 1 minute
Обнаружение эксплуатации на основе сетевого трафика
Как мы упоминали в начале статьи, первый этап эксплуатации уязвимости подразумевает множественные попытки отправки 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
Поскольку во время эксплуатации уязвимости Zerologon происходит аутентификация на контроллере домена с использованием MS-NRPC функции hNetrServerAuthenticate2 (hNetrServerAuthenticate3) , в процессе аутентификации задействуется сервис проверки подлинности локальной системы (LSASS). В результате обращения к серверу проверки подлинности в адресное пространство процесса lsass.exe попадает артефакт — структура, содержащая параметры, переданные в функцию hNetrServerAuthenticate2 (hNetrServerAuthenticate3) (см. рисунок ниже).
Пример вызова функции hNetrServerAuthenticate3 с передаваемыми ей аргументами
Фрагмент дампа адресного пространства процесса lsass с артефактами после эксплуатации уязвимости Zerologon
На фрагменте исходного кода одного из эксплоитов и фрагменте дампа адресного пространства процесса lsass с артефактами, оставшимися после эксплуатации, видна взаимосвязь. Переданные в функцию аргументы остались в памяти, общая структура данных сохранилась. Если смотреть с конца, 4 байта (0×212fffff) представляют собой флаги — Netlogon Negotiable Options. Перед ним располагаются 8 нулевых байтов, представляющие собой нулевой шифротекст. Затем перед ними трижды записывается имя хоста DC в таком же виде и порядке, в котором аргументы были переданы в функцию. Также в памяти виден байт, означающий тип безопасного канала Netlogon ServerSecureChannel (06).
Однако иногда по неустановленным причинам этот и другие байты могут принимать различные значения, не связанные с описанием выше. Артефакты в адресном пространстве процесса lsass.exe хранятся в сегменте, который не подразумевает долговременного хранения данных, и могут быть удалены в любой момент после появления. Наше исследование показало, что в большинстве случаев артефакты остаются в памяти процесса lsass.exe не дольше получаса, после чего перезаписываются другими данными.
Основным маркером, позволяющим находить данный участок адресного пространства и использовать его для дальнейших проверок, являются флаги Netlogon Negotiable Options. Они представляют собой 32-битное число, которое формируется в бинарном виде из набора различных параметров.
Помимо обхода детектирующей логики 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, но и повысить скорость классификации инцидента.
В сети появился эксплоит для уязвимости CVE-2020-1472, или Zerologon, которая представляет опасность для доменных компьютеров Microsoft AD и Samba и позволяет захватить контроллера домена. Microsoft совместно с компанией Secura уже обнаружили три варианта подходящей ей публичной эксплоиты SharpZeroLogon.exe.
Эксперты Angara Professional Assistance напоминают, что CVE-2020-1472 – это уязвимость системной службы Netlogon, приводящая к несанкционированному повышению привилегий. Она возникает, когда злоумышленник устанавливает уязвимое соединение безопасного канала Netlogon с контроллером домена с помощью протокола Netlogon Remote Protocol (MS-NRPC) и установки нулей в определенные параметры аутентификации. Злоумышленник, успешно воспользовавшийся этой уязвимостью, может получить учетную запись администратора домена на устройстве и выполнить запуск приложений, поэтому уязвимость получила высший уровень критичности по шкале CVSS – 10 баллов.
Microsoft планирует устранить уязвимость в двухэтапном исправлении. Доступные сейчас обновления устраняют уязвимость, изменяя способ обработки сервисом безопасных каналов Netlogon. На файловых серверах Samba также рекомендуется произвести установку обновления.
Также доступны виртуальные исправления от многих наших партнеров на случай невозможности оперативной установки обновлений (Trend Micro, McAfee и др.). На Github компания Secura опубликовала утилиту для проверки подверженности контроллера домена этой проблеме.
Это не первая уязвимость Netlogon сервиса, позволяющая нарушителю, действующему удаленно, обойти существующие ограничения безопасности с помощью специально сформированного запроса. Уязвимости сервисов аутентификации в совокупности с частыми упрощениями паролей пользователями для их лучшего запоминания на фоне необходимости частой смены – связка, создающая проблемы для любой ИБ-службы. Одним из действенных архитектурных изменений подхода к решению этой проблемы является переход на системы Single Sign-On (SSO) с возможным использованием биометрии. Таким образом, уменьшается количество взаимодействий с пользователями и необходимость в запоминании паролей, внедряется системный контроль за процессом аутентификации в бизнес-приложениях предприятия.
Другим более радикальным подходом эксперты ИБ считают переход на протокол FIDO2. FIDO – Fast IDentity Online / Быстрая Авторизация Онлайн – это технологический консорциум, основанный в 2013 году для нахождения решений, которые помогают пользователям работать с устройствами надежной авторизации, преимущественно в Web-среде. FIDO2 основан на двух стандартах аутентификации: WebAuth и CTAP. При аутентификации используется устройство пользователя (смартфон, смартчасы или аппаратный токен) и, как вариант, биометрическая аутентификация. Стандарт является открытым и гибким и поддерживает многие типы коммуникации: USB, Bluethoot, NFC и др. Популярность его в онлайн-сервисах стремительно растет. Так, он уже внедрен в Google учетных записях, браузерах Chrome и Mozilla Firefox, ОС Windows 10.
Используя продукты Контура, специалисты делают внутренний контроль бизнеса систематизированным, снижают объем ручной работы и эффективно предупреждают нарушения.
Читайте также: