bga68 (bga68) wrote,
bga68
bga68

Categories:

Mimikatz: предлагает сдаться? Часть 2

За месяц до атаки Petya.A наши админы ИТ-инфраструктуры, как дети, бегали, кричали и смеялись, что нашли потрясающую уязвимость Windows...
Только админы информационной безопасности устало отмахивались и про себя думали "Боже, какие дети!!!" потому, что это не уязвимость...
"Получение debug-привилегии mimikatz – это не взлом Windows, не несанкционированный доступ – это использование default-настройки времён 1999 года, т.е. стартового релиза Windows 2000. Возможность проведения таких действий – это проблема не ОС, а квалификации администраторов и инженеров."

Хотел об этом написать, но пока я думал, толковые ребята уже написали почти то, что я хотел

Привожу без сокращений:
Оригинал: https://www.atraining.ru/mimikatz-lsa-protection/

Часть 2. Назад к Части 1

Mimikatz – получаем доступ к различной аутентификационной информации

В ОС Windows в целях совместимости – притом не только со старыми версиями Windows, но и со сторонними технологиями (например, чтобы подключающиеся по PPP-протоколам могли использовать классический CHAP) может храниться несколько вариантов хэша пароля пользователя.

Этот список может включать в себя следующие пункты:


  • Plaintext – пароль в открытом виде.

  • WDigest – пароль после CHAP / MD5-преобразования.

  • LM-hash – хэш для старого LanManager.

  • NTLM-hash – хэш для NTLM и Kerberos.

Mimikatz выгружает хэши и учётные данные из работающего lsass командой lsadump::lsa /name:Administrator /inject:

Много выгрузил, да.

Начнём с возможности, которая есть на современных ОС, и которую проще всего сразу начать использовать на домашних и standalone-системах.

Защита LSASS от подключений со стороны сторонних модулей

Начиная с Windows 8.1 и Windows Server 2012 R2, появляется дополнительная возможность для защиты. Эта защита реализуется как специальный параметр для сервиса LSASS – если включаясь LSASS увидит этот параметр, то будет разрешать прямое взаимодействие с собой (например, чтение своей памяти) не просто процессам с нужным уровнем доступа (работающим от системной учётной записи), но и обязательно подписанным со стороны Microsoft. Не просто подписанным, а как у криптографических модулей – специальной подписью вендора.

Включается этот режим просто – в ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa создаётся значение RunAsPPL типа DWORD32 и выставляется в единицу.

При успешной обработке в System-журнале от лица WinInit будет событие:

LSASS.exe was started as a protected process with level: 4

Работая в защищённом режиме LSASS не будет подгружать неподписанные плагины. Если у вас они и не используются, то это эффективно отключит принципиальную возможность даже получив права LocalSystem добраться до оперативной памяти процесса LSA. Но будьте внимательны, если у вас используются:


  • Самописные фильтры паролей – например, для задания особых критериев сложности и проверки “чтобы в паролях не встречались логины и имена”;

  • Криптомодули, нужные для обработки какой-то специфичной авторизации – например, Kerberos на гос.криптографии;

  • Сторонние драйверы смарт-карт, добавляющие какой-то специфичный функционал;

Всем им после включения этого режима надо быть или подписанными Microsoft, или они не будут загружаться, а в логах будут события 3033 и 3036.

Впрочем, чаще всего расширения LSA не используются, так что данная мера является нужной и эффективной. Но действовать она, ещё раз, будет только у 8.1+ и 2012 R2+.

Теперь поговорим про то, как избавиться от факта существования ненужных хэшей.

Сокращаем число хранящихся вариантов учётных данных

LM-хэш

Про то, как избавиться от старого LM-хэша, я написал в отдельной статье про LM и NTLM, поэтому повторяться не буду.

WDigest

Если вы не используете дайджест-аутентификацию, то можно в явном виде сказать системе, чтобы она не занималась ерундой по части генерации и хранения оных.

В современных системах – Windows 8.1+ и Windows Server 2012 R2+ – это уже работает само по себе, а вот в предыдущих версиях надо предпринять определённые действия – добавить в ключ реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest значение UseLogonCredentialтипа DWORD32 и выставить его в нуль.

Если даже дайджест иногда и будет требоваться, то просто у пользователя будет чаще запрашиваться информация для логина – то есть данная настройка отключает именно кэширование в RAM, а не весь механизм digest. HTTP-ресурсы, которым нужен именно такой метод, продолжат быть доступны.

Если вы опасаетесь, что есть некая система, проводящая аутентификацию, последовательно согласовывая методы, и эта система может так “досогласоваться” до WDigest – то в том же ключе реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest есть значение Negotiate, тоже DWORD32, которое можно явно выставить в нуль и тогда никакие вариации negotiate не будут при переборе методов использовать WDigest.

Обратимое шифрование

В Active Directory хранение CHAP-like данных (по сути – зашифрованных plaintext-паролей) реализуется через дополнительный атрибут у security principal’а. Можно в явном виде сказать, чтобы такое никогда не делалось – для этого есть настройка в групповой политике:

Выключаем reversible encryption

Подобная настройка есть и у каждой учётной записи пользователя, но проще выключить глобально.

Результат – сильно сокращённое “поголовье” неиспользуемых и уязвимых способов представления аутентификационной информации.

Автоочистка кэша только что ушедших учётных записей

Если security principal прекратил свой сеанс на системе, то его учётные данные живут ещё некоторое время. Это не ошибка – это надо для сценариев “запустил операцию и отключился”.

Время, на протяжении которого в оперативной памяти lsass живут учётные данные только что завершивших сеанс учётных записей, можно настраивать.

В ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ есть параметр TokenLeakDetectDelaySecs, опять же типа DWORD32. Выставление его в малое значение (например, 10 секунд) отсечёт возможность атак класса “взломали файловый или RDP-сервер и забрали из процесса lsass все данные всех подключавшихся, а теперь можно в офлайне NTLM-хэши попробовать атаковать”.

Теперь про ошибочные предположения о mimikatz.

Mimikatz – Golden или Silver Ticket для Kerberos

Абонемент – это очень хорошо. Тут самое место для рекламы нашего абонемента на посещение онлайн-курсов и вебинаров, а также доступу к архиву всех записей – Knowledge Assurance – но вот нельзя сказать, что Knowledge Assurance предоставляет возможность добавления произвольных SID в TGT, плюс выставление огромного срока жизни у билетов.

Данному механизму подделки kerberos tickets – уже несколько лет, его детальное описание опубликовано в 2014 году.

Некоторыми “экспертами” ошибочно декларируется, что вирус Petya.A(lco) умеет “ломать домены Active Directory через дыру Golden Ticket”.

Это не так – и не дыра это, и не Active Directory, и вирус этого не делает, а mimikatz может попробовать.

Правда для этого нужно выполнение следующего списка условий:


  • Нужно знать пароль от RID 502, учётной записи krbtgt, доступной на каком-нибудь из не-RODC (потому что на RODC у каждого свой krbtgt).

  • Нужны права локального администратора на DC.

  • Должна отсутствовать преаутентификация Kerberos.

Как видите, не всё так однозначно – в частности то, зачем что-то ломать, если ты админ на контроллере домена.

Противодействие этой атаке также достаточно тривиально – дважды (именно дважды, чтобы произошла инвалидация тикетов) сделать reset password у доменного krbtgt, выставив оный на произвольный стойкий пароль, а также использовать FAST (который Kerberos Armoring, защищает фазу преаутентификации и ошибочно считается возможностью Windows Server 2012, хотя может использоваться и на Windows Server 2008). Ну и не давать права админа на DC кому попало, да.

Теперь немножко про панацеи.

Использование Protected Users

Один из показательных моментов во всей шумихе вокруг Petya.A(lco) – это быстрый поиск панацеи. Притом почему-то в расчёт не берутся действительно быстрые и простые методы – например, корректно раздавать права внутри домена и ставить критические патчи через разумное время после их выхода. Проще же ждать золотую пулю, которая решит все вопросы. На эту должность в данном случае “экспертные сообщества” спешно назначили методику “просто добавить всех пользователей в Protected Users и не париться”.

Про то, что именно делает группа Protected Users – фактически, включает целую пачку и ранее существовавших защитных технологий – есть в статье про LM и NTLM – у каждой из этих технологий есть свои плюсы и минусы, побочные действия и особенности, поэтому сам подход “разово нажать специальную кнопку Сделать Всё Хорошо” в данном случае показателен.

Ситуация в том, что суммарное время на разгребание последствий после подобных быстрых действий обычно превышает то, которое тратится на последовательное улучшение защиты домена. Безусловно понятно что те, кто не разбираются в технологиях, будут искать поверхностное решение “что там надо нажать, какой скрипт на повершелле скачать и запустить, чтобы всё норм стало” – и в этом им помогут такие же, но по факту будет затрачено больше времени и сил, а знания как отсутствовали, так и продолжат отсутствовать. Ведь от подобных методов ни понимания технологий, ни навыков – больше не становится. Отсюда и все рассказы вида “просто домен в 2012 R2 надо переключить и вопрос решён” и подобное.

Будьте умнее – изучайте технологии не поверхностно, а серьёзно. Это банально эффективнее с точки зрения затрат времени и результирующего личного комфорта.

Потому что в данном случае, например, при грамотной настройке политик (не-выдаче debug-привилегии всем админам) можно уже лет этак 18 подряд как не давать никакой возможности для описываемой атаки через mimikatz.

Удач!


Tags: administrator, network, security, user, virus, администратор, администрирование, антивирус, вирус, информационная безопасность
Subscribe

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 0 comments