Краят на юни 2017 г. беше запомнен от ИТ общността за масовото заразяване на много от най-големите компании и правителствени агенции в Русия, Украйна и други страни с новия вирус за износ на Petya (NotPetya). В повечето случаи, след като проникна в корпоративната мрежа, Petya незабавно се разпространи във всички компютри и сървъри на домейни, парализирайки до 70-100% от цялата инфраструктура на Windows. Въпреки че един от методите за разпространение на Petya между компютри в мрежата беше използването на експлоатацията EternalBlue (както беше в случая с WannaCry), това не беше основният канал за разпространение на ransomware. За разлика от WCry, който беше разпространен единствено поради уязвимости в SMBv1, NotPetya първоначално беше затворен за корпоративни мрежи. След като системата беше заразена, шифрорът, използващ публичната програма Mimikatz, получи идентификационните данни (пароли, хеши) на компютърни потребители и ги използва за по-нататъшно разпространение в мрежата, използвайки WMI и PsExec, до пълен контрол над домейна. Съответно, за да се защитят всички системи, не беше достатъчно да се инсталира актуализацията MS17-010.
В тази статия ще обсъдим основните методи за защита на системите на Windows в домейн на Active Directory от атаки с помощта на инструменти, подобни на Mimikatz..
полезност Mimikatz използвайки модула sekurlsa, той ви позволява да извличате пароли и хеши на оторизирани потребители, съхранявани в паметта на системния процес LSASS.EXE (Локална подсистема за сигурност ). Вече имахме статия с пример за използване на mimikatz за получаване на паролите на потребителите в ясен текст (от WDigest, LiveSSP и SSP).
Съдържание:
- Предотвратяване на грешки
- Деактивиране на WDigest
- LSA защита срещу модули на трети страни
- Деактивиране на LM и NTLM
- Забрана на използването на обратимо криптиране
- Използване на групата на защитените потребители
- Не използвайте запазени пароли
- Отказ от доверително кеширане
- Поверителна охрана
- данни
Предотвратяване на грешки
Статията от връзката по-горе показва как използването на привилегията за отстраняване на грешки позволява на Mimikatz достъп до системния процес на LSASS и извличане на пароли от него.
По подразбиране разрешенията за отстраняване на грешки се предоставят на локалната група администратори (BUILTIN \ Administrators). Въпреки че в 99% от случаите тази привилегия абсолютно не се използва от администраторите (обикновено е необходима от системните програмисти), съответно поради съображения за сигурност възможността за използване на привилегии SeDebugPrivilege по-добре. Това става чрез групова политика (локална или домейна). Отидете в секцията Конфигурация на компютъра -> Настройки на Windows -> Настройки за защита -> Местни политики -> Присвояване на права на потребителя и активирайте политиката Програма за отстраняване на грешки. В него трябва да добавите група от потребители на потребители, които може да се нуждаят от права за отстраняване на грешки (обикновено разработчици) или да оставите тази група празна, така че никой да няма това право.
Сега, ако се опитате да получите грешка чрез mimikatz, се появява грешка:
EROOR kuhl_m_privilege_simple; RtlAdjustPrivilege (20) c0000061
Деактивиране на WDigest
Протоколът WDigest се появи в Windows XP и се използва за извършване на HTTP Digest Authentication (HTTP Digest Authentication), характеристика на която беше да се използва паролата на потребителя в ясна форма. Windows 8.1 и Server 2012 R2 добавиха възможността напълно да забранят съхраняването на пароли в чист текст в LSASS. Да се забрани съхранението на WDigest в паметта в тези операционни системи в клона на системния регистър HKEY_LOCAL_MACHINE \ Система \ CurrentControlSet \ Control \ SecurityProviders \ WDigest вече има име DWORD32 параметър UseLogonCredential и стойност 0.
Ако трябва напълно да деактивирате метода за удостоверяване на WDigest, в същия клон (HKEY_LOCAL_MACHINE \ Система \ CurrentControlSet \ Control \ SecurityProviders \ WDigest) задайте стойността на ключа преговарям в 0.
За да поддържате тази функция в Windows 7, 8 и Windows Server 2008 R2 / 2012, трябва да инсталирате специална актуализация - KB2871997 и след това да зададете същите ключове на системния регистър. В среда на домейн, настройките на системния регистър са най-лесни за разпространение чрез групови правила.
LSA защита срещу модули на трети страни
Windows 8.1 и Windows Server 2012 R2 представиха възможността да активират LSA защита, която защитава LSA паметта и предотвратява възможността за свързване към нея от несигурни процеси. За да активирате тази защита, трябва в клона на системния регистър HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ LSA създаване на параметър RunAsPPL със стойност 1.
След като приложи този параметър, атакуващият няма да има достъп до LSA паметта и mimikatz ще издаде грешка с командата securlsa :: logonpassword
ГРЕШКА kuhl_m_securlsa_acquireLSA: Работа с памет (0x00000005).
Деактивиране на LM и NTLM
Остарелият протокол за автентификация на LM и съответно съхранението на LM хешовете трябва да бъдат деактивирани с помощта на политиката на групата за сигурност на мрежата: Не съхранявайте Hash Value на мениджъра на LAN при следваща промяна на паролата (на ниво политика на домейна по подразбиране).
След това трябва да се откажете от използването на поне протокола NTLMv1 (правилото под Конфигурация на компютъра -> Политики -> Настройки на Windows -> Настройки за защита -> Локални политики -> Опции за защита - Мрежова сигурност: Ограничете NTLM: NTLM удостоверяване в този домейн), и като максимум и NTLMv2
И ако отхвърлянето на NTLMv1 обикновено е безболезнено, тогава отхвърлянето на NTLMv2 ще трябва да работи усилено. По принцип в големите инфраструктури стигат до сценарий за максимално ограничаване на използването на NTLMv2. Т.е. където е възможно трябва да се използва автентификация на Kerberos (като правило, ще бъде необходимо допълнително време за конфигуриране на удостоверяване на Kerberos за IIS и SQL), а за останалите системи - NTLMv2.
Забрана на използването на обратимо криптиране
Трябва да бъде изрично забранено съхраняването на потребителски пароли в AD в текстова форма. За целта активирайте политиката за домейна Съхранявайте паролата, използвайки обратимо криптиране за всички потребители в домейна в Конфигурация на компютъра -> Настройки на Windows -> Настройки за защита -> Политики на акаунта -> Раздел Политика за паролата, като зададете стойността й на Disabled.
Използване на групата на защитените потребители
При използване на функционалното ниво на домейна на Windows Server 2012 R2 е възможно да се използва специалната защитена група Защитени потребители за защита на привилегированите потребители. По-специално, тези акаунти са защитени от компрометиране поради факта, че членовете на тази група могат да влизат само чрез Kerberos (без NTLM, WDigest и CredSSP) и т.н. (подробности на връзката по-горе). Препоръчително е да добавите към тази група акаунти на администратори на домейни, сървъри и т.н. Тази функционалност работи на сървъри и ще работи на Windows Server 2012 R2 (за Windows Server 2008 R2 трябва да инсталирате допълнителната актуализация, спомената по-горе KB2871997)
Не използвайте запазени пароли
Можете да попречите на потребителите на домейни да запазват паролите си за достъп до мрежовите ресурси в Credential Manager.
За целта активирайте политиката Достъп до мрежа: Не позволявайте съхранение на пароли и идентификационни данни за удостоверяване на мрежата под Конфигурация на компютъра -> Настройки на Windows -> Настройки за защита -> Местни политики -> Опции за защита.
Отказ от доверително кеширане
Една от характеристиките на mimikats е да получи хеш на потребителски пароли от клона на системния регистър HKEY_LOCAL_MACHINE \ SECURITY \ Кеш, в които се съхраняват хешовете за пароли на последните 10 (по подразбиране) потребители на домейн, които са влезли в системата. Тези хеши обикновено могат да се използват за упълномощаване на потребители в системата, когато контролерът на домейна не е наличен.
Препоръчително е да се забрани използването на кеширано задържане на данни чрез активиране на политиката интерактивен Logon: номер от предишен logons за кеш (в случай домейн контрольор е не наличен) под Компютърна конфигурация -> Настройки на Windows -> Локална политика -> Опции за защита, променяйки стойността на нейния параметър на 0.
Освен това, за да ускорите почистването на паметта на процеса lsass от потребителски акаунти, които са завършили сесията, е необходимо в клона HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa трябва да създадете ключ DWORD с името TokenLeakDetectDelaySecs и стойност 30. Т.е. паметта ще бъде изчистена 30 секунди след логото на потребителя. В Windows 7, 8 / Server 2008R2, 2012, за да работи този ключ, трябва да инсталирате споменатата по-рано актуализация KB2871997.
Поверителна охрана
В Windows 10 Enterprise, Windows Server 2016, е добавен нов компонент Credential Guard, който да изолира и защитава системния процес LSASS от неоторизиран достъп. Подробности тук.
данни
Обсъдените по-горе мерки значително ще намалят възможностите на mimikatz и подобни помощни програми за получаване на пароли и хеши на администратори от LSASS процеса и регистъра. Във всеки случай, когато вземате решение за прилагането на тези политики и методи, те трябва да бъдат въведени на етапи със задължително тестване..
В следващата статия ще обсъдим най-добрите практики за подобряване на сигурността на Windows мрежа чрез ограничаване на използването на администраторски акаунти, които на техническо и организационно ниво трябва да подобрят защитата на домейн на Windows от подобни атаки. Продължавайте да се настройвате!
