Розбираємо чергове всёпропальческое-адмінській на тему утиліти mimikatz
В процесі недавньої атаки вірусу-здирника Петі досить багато уваги було приділено новому, з часів WannaCry, payload'у цього вірусу. Дійсно, новий зловредів оперував для захоплення влади на локальних хостах не однієї, а цілим набором вразливостей - стосуються не тільки ОС Windows, але і, наприклад, пакету Microsoft Office.
Особливу увагу привернув один з компонентів - т.зв. mimikatz.
Цьому модулю приписуються воістину чудодійні можливості, які змушують згадати золоті часи лінукссообществ для розумово обдарованих старшокласників, з експертною думкою виду:
будь-яку венду кароче одним пакетом кладе прорубує будь фаєрвол якщо тільки не під линем працює
Реакція адмінствующего Windows-спільноти, яка сповідує релігію все по дефолту розгорнути як в MS розповідають і нехай працює, сидимо та не парімся, а якщо що - так все треба просто перенакатіть з нуля, або ти найрозумніший чи що. втім, завдяки близьконульових розуміння матчастини, теж особливо не відрізнялася:
Мімікац пропонує здатися?
Що є mimikatz
Ми будемо розглядати доступну на момент написання статті версію 2.1.1 і обмежимося в опрацюванні питання саме тим функціоналом, який застосовує вірус Petya.A (lco). Тобто не будемо писати підручник із застосування mimikatz.
Технічна сторона тестування
Mimikatz - захоплення привілеї debug
Для виконання частини своїх дій mimikatz проводить "захоплення" привілеї debug. Завдяки цьому він може отримувати низькорівневий доступ до процесів, що запускаються від системних облікових записів (LocalSystem, він же SYSTEM, в NT 5.1 розщепити на варіанти LocalService / NetworkService).
В інтерфейсі це дія виконується командою privilege :: debug. в разі успішного завершення виводиться Privilege '20' OK. в разі невдачі - Remark: ERROR kuhl_m_privilege_simple; RtlAdjustPrivilege (20) c0000061.
Запобігання можливості отримання debug
Типово что в локальній політиці безпеки, що наприклад в Default Domain Controllers Policy привілей debug видається групі BUILTIN \ Administrators. Видається - це значить, що процес, який запускається в сеансі користувача, в маркері якого є SID цієї групи, може запросити "хочу налагодження" і отримати цей біт в рядок "привілеї" свого маркера доступу (в разі наявності UAC - а в класичному варіанті цей біт з'являється в маркері відразу після процедури logon).
Це абсолютно шкідлива настройка "за замовчуванням", тому що фактично привілей debug звичайними додатками не використовується. Більш того, навіть розробникам вона потрібна в окремих випадках - тому що навіть налагодження додатків, що запускаються від свого облікового запису, на платформі Windows ведуть без debug privilege. Тобто розробку прикладних або managed code-додатків можна без проблем проводити і без цього привілею. Вона потрібна - ще раз - тільки в сценарії "конкретного користувача потрібна можливість налагодження системних процесів".
Більш того - навіть якщо вона потрібна програмісту, саме для налагодження системного сервісу, але на іншому вузлі - є варіант kernel Secure Mode debugging. при якому програміст може проводити налагодження, але на системі, з якої підключається, дану привілей не отримує.
Вирішуємо ситуацію просто - в груповій політиці (якщо домен) або локальної (якщо мова про standalone-системі) додаємо новоствореного групу, членство в якій буде позначати, що даної Якщо не зазначено інакше облікового запису можна користуватися таким привілеєм. На жодну роботу ніякого ПО це не вплине в принципі - ні штатного бізнес-ПО, яке не може робити свої завдання без попутної налагодження ядра NT. Зате ось адміністраторів - що локальних, що доменних - яким права видані за логікою "а давайте гендиректора зробимо enterprise adminом, а то раптом у нього що-небудь не запрацює" - досить.
На скріншоті - локальна політика на DC, тому перевизначати прямо в ній я не буду, все одно параметр буде перекритий доменної політикою. Результат буде виглядати так:
Тепер mimikatz отримати debug-привілей не може:
При цьому ми залишилися і локальним адміністратором, і учасником груп Domain Admins і Enterprise Admins. Ми можемо виконувати всі ті ж самі (будь-які) завдання з Active Directory.
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 від підключень з боку сторонніх модулів
Чи включається цей режим просто - в гілці реєстру 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. Але будьте уважні, якщо у вас використовуються:
Всім їм після включення цього режиму треба бути або підписаними Microsoft, або вони не будуть завантажуватися, а в балках будуть події 3033 і 3036.
Тепер поговоримо про те, як позбутися від факту існування непотрібних хеш.
Скорочуємо кількість зберігаються варіантів облікових даних
Про те, як позбутися від старого LM-хеша, я написав в окремій статті про LM і NTLM. тому повторюватися не буду.
Якщо ви не використовуєте дайджест-аутентифікацію, то можна в явному вигляді сказати системі, щоб вона не займалася дурницями по частині генерації і зберігання оних.
Якщо навіть дайджест іноді і буде вимагатися, то просто у користувача буде частіше запитуватися інформація для логіна - тобто дана настройка відключає саме кешування в RAM, а не весь механізм digest. HTTP-ресурси, яким потрібен саме такий метод, продовжать бути доступні.
Якщо ви побоюєтеся, що є якась система, яка проводить аутентифікацію, послідовно погоджуючи методи, і ця система може так "доузгодити" до WDigest - то в тому ж ключі реєстру HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ SecurityProviders \ WDigest є значення Negotiate. теж DWORD32. яке можна явно виставити в нуль і тоді ніякі варіації negotiate НЕ будуть при переборі методів використовувати WDigest.
оборотне шифрування
У Active Directory зберігання CHAP-like даних (по суті - зашифрованих plaintext-паролів) реалізується через додатковий атрибут у security principal'а. Можна в явному вигляді сказати, щоб таке ніколи не робилося - для цього є настройка в груповій політиці:
Подібна настройка є і у кожної облікового запису користувача, але простіше вимкнути глобально.
Результат - сильно скорочена "поголів'я" невикористовуваних і вразливих способів подання аутентификационной інформації.
Очистка кешу тільки що пішли облікових записів
Якщо security principal припинив свій сеанс на системі, то його облікові дані живуть ще деякий час. Це не помилка - це треба для сценаріїв "запустив операцію і відключився".
Час, протягом якого в оперативній пам'яті lsass живуть облікові дані тільки що завершили сеанс облікових записів, можна налаштовувати.
У гілці реєстру HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa \ є параметр TokenLeakDetectDelaySecs. знову ж типу DWORD32. Виставлення його в мале значення (наприклад, 10 секунд) відсіче можливість атак класу "зламали файловий або RDP-сервер і забрали з процесу lsass всі дані всіх підключати, а тепер можна в офлайні NTLM-хеші спробувати атакувати".
Тепер про хибні припущення про mimikatz.
Mimikatz - Golden або Silver Ticket для Kerberos
Деякими "експертами" помилково декларується, що вірус Petya.A (lco) вміє "ламати домени Active Directory через дірку Golden Ticket".
Це не так - і не діра це, і не Active Directory, і вірус цього не робить, а mimikatz може спробувати.
Правда для цього необхідним є дотримання наступного списку умов:
- Потрібно знати пароль від RID 502, облікового запису krbtgt. доступною на якомусь з не-RODC (бо на RODC у кожного свій krbtgt).
- Потрібні права локального адміністратора на DC.
- Повинна бути відсутнім преаутентіфікація Kerberos.
Як бачите, не все так однозначно - зокрема те, навіщо щось ламати, якщо ти адмін на контролері домену.
Тепер трошки про панацеї.
Використання Protected Users
Один з показових моментів у всій галасу навколо Petya.A (lco) - це швидкий пошук панацеї. Притому чомусь в розрахунок не беруться дійсно швидкі і прості методи - наприклад, коректно роздавати права всередині домену і ставити критичні патчі через розумне час після їх виходу. Простіше ж чекати золоту кулю, яка вирішить всі питання. На цю посаду в даному випадку "експертні співтовариства" спішно призначили методику "просто додати всіх користувачів в Protected Users і не паритися".
Про те, що саме робить група Protected Users - фактично, включає цілу пачку і раніше існували захисних технологій - є в статті про LM і NTLM - у кожної з цих технологій є свої плюси і мінуси, побічні дії і особливості, тому сам підхід "разово натиснути спеціальну кнопку Зробити Все Добре "в даному випадку показовий.
Будьте розумнішими - вивчайте технології не поверхово, а серйозно. Це банально ефективніше з точки зору витрат часу і результуючого особистого комфорту.
Тому що в даному випадку, наприклад, при грамотній настройці політик (НЕ-видачі debug-привілеї всім адмінам) можна вже років так 18 поспіль як не давати ніякої можливості для описуваної атаки через mimikatz.