NT LAN Manager

редактировать

В сети Windows NT (Новая технология) LAN Manager (NTLM ) - это набор протоколов безопасности Microsoft, предназначенных для обеспечения аутентификации, целостности и конфиденциальности пользователей. NTLM является преемником протокола аутентификации в Microsoft LAN Manager (LANMAN), более раннем продукте Microsoft. Набор протоколов NTLM реализован в виде поставщика поддержки безопасности, который объединяет протокол аутентификации LAN Manager, протоколы сеансов NTLMv1, NTLMv2 и NTLM2 в одном пакете. То, используются ли эти протоколы или могут ли они использоваться в системе, регулируется параметрами групповой политики, для которых разные версии Windows имеют разные настройки по умолчанию. Пароли NTLM считаются ненадежными, потому что их можно очень легко подобрать с помощью современного оборудования.

Содержание

  • 1 Протокол
    • 1.1 NTLMv1
    • 1.2 NTLMv2
    • 1.3 Сеанс NTLM2
  • 2 Доступность и использование NTLM
    • 2.1 Использование поставщика поддержки безопасности NTLM
    • 2.2 Использование версий протокола
  • 3 Слабые стороны и уязвимости
  • 4 Совместимость с Linux
  • 5 См. также
  • 6 Ссылки
  • 7 Внешние ссылки

Протокол

NTLM - это протокол аутентификации запрос-ответ, который использует три сообщения для аутентификации клиента в среде, ориентированной на соединение (аналогично без установления соединения), и четвертое дополнительное сообщение, если требуется целостность.

  1. Сначала клиент устанавливает сетевой путь к сервер и отправляет NEGOTIATE_MESSAGE, объявляя свои возможности.
  2. Затем сервер отвечает CHALLENGE_MESSAGE, который используется для установления личности клиента.
  3. Наконец, клиент отвечает на запрос AUTHENTICATE_MESSAGE

Протокол NTLM использует одно или оба из двух хешированных значений пароля, оба из которых также хранятся на сервере. r (или контроллер домена), которые из-за отсутствия salting являются эквивалентом пароля, что означает, что если вы получите хеш-значение с сервера, вы можете пройти аутентификацию, не зная фактического пароля. Это два - LM Hash (функция на основе DES, применяемая к первым 14 символам пароля, преобразованного в традиционную 8-битную кодировку ПК для языка) и NT Hash (MD4 младшего байта UTF-16 Unicode пароль). Оба значения хеш-функции составляют 16 байтов (128 бит) каждое.

Протокол NTLM также использует одну из двух односторонних функций, в зависимости от версии NTLM. NT LanMan и NTLM версии 1 используют одностороннюю функцию LanMan на основе DES (LMOWF), тогда как NTLMv2 использует одностороннюю функцию на основе NT MD4 (NTOWF).

NTLMv1

Сервер аутентифицирует клиента, отправляя 8-байтовое случайное число, вызов. Клиент выполняет операцию, включающую вызов и секрет, совместно используемый клиентом и сервером, в частности, один из двух хэшей паролей, описанных выше. Клиент возвращает 24-байтовый результат вычисления. Фактически, в NTLMv1 вычисления обычно производятся с использованием обоих хэшей, и отправляются оба 24-байтовых результата. Сервер проверяет, что клиент вычислил правильный результат, и на основании этого делает вывод о владении секретом и, следовательно, подлинности клиента.

Оба хеш-значения производят 16-байтовые величины. Добавляются пять байтов нулей, чтобы получить 21 байт. 21 байт разделены на три 7-байтовых (56-битных) количества. Каждая из этих 56-битных величин используется как ключ для DES шифрования 64-битного запроса. Три шифрования запроса объединяются для формирования 24-байтового ответа. Как ответ, использующий хэш LM, так и хеш NT, возвращаются как ответ, но это можно настроить.

C = 8-байтовый запрос сервера, случайный K1 | K2 | K3 = NTLM-Hash | 5-байтовый ответ = DES (K1, C) | DES (K2, C) | DES (K3, C)

NTLMv2

NTLMv2, представленный в Windows NT 4.0 SP4, представляет собой протокол аутентификации типа запрос-ответ. Он задуман как криптографически усиленная замена NTLMv1.

NTLM версии 2 (NTLMv2), которая была представлена ​​в Windows NT 4.0 SP4 (и изначально поддерживается в Windows 2000), повышает безопасность NTLM за счет усиления защиты протокола от многих атак с подменой и добавления возможности сервера аутентифицироваться для клиента.

NTLMv2 отправляет два ответа на 8-байтовый запрос сервера. Каждый ответ содержит 16-байтовый хэш HMAC - MD5 запроса сервера, полностью / частично случайно сгенерированный запрос клиента и хэш HMAC-MD5 пароля пользователя и другие идентифицирующие данные. Информация. Два ответа различаются форматом запроса клиента. В более коротком ответе для этого запроса используется 8-байтовое случайное значение. Чтобы проверить ответ, сервер должен получить как часть ответа запрос клиента. Для этого более короткого ответа 8-байтовый клиентский запрос, добавленный к 16-байтовому ответу, составляет 24-байтовый пакет, который соответствует 24-байтовому формату ответа предыдущего протокола NTLMv1. В некоторой неофициальной документации (например, DCE / RPC Over SMB, Leighton) этот ответ называется LMv2.

Второй ответ, отправленный NTLMv2, использует клиентский запрос переменной длины, который включает (1) текущее время в формате NT Time, (2) 8-байтовое случайное значение (CC2 в формате поле ниже), (3) доменное имя и (4) некоторые элементы стандартного формата. Ответ должен включать копию этого клиентского запроса и поэтому имеет переменную длину. В неофициальной документации этот ответ называется NTv2.

И LMv2, и NTv2 хэшируют запрос клиента и сервера с помощью NT-хэша пароля пользователя и другой идентифицирующей информации. Точная формула должна начинаться с NT Hash, который хранится в SAM или AD, и продолжать хеширование с использованием HMAC - MD5, имя пользователя и доменное имя. В поле ниже X обозначает фиксированное содержимое поля форматирования.

SC = 8-байтовый запрос сервера, случайный CC = 8-байтовый запрос клиента, случайный CC * = (X, время, CC2, имя домена) v2-Hash = HMAC-MD5 (NT-Hash, пользователь имя, доменное имя) LMv2 = HMAC-MD5 (v2-Hash, SC, CC) NTv2 = HMAC-MD5 (v2-Hash, SC, CC *) response = LMv2 | CC | NTv2 | CC *

NTLM2 Session

Протокол NTLM2 Session аналогичен MS-CHAPv2. Он состоит из аутентификации из NTLMv1 в сочетании с безопасностью сеанса из NTLMv2.

Вкратце, применяется алгоритм NTLMv1, за исключением того, что 8-байтовый запрос клиента добавляется к 8-байтовому запросу сервера и хешируется MD5. Наименьшая 8-байтовая половина результата хеширования - это проблема, используемая в протоколе NTLMv1. Запрос клиента возвращается в одном 24-байтовом слоте ответного сообщения, 24-байтовый вычисленный ответ возвращается в другом слоте.

Это усиленная форма NTLMv1, которая поддерживает возможность использования существующей инфраструктуры контроллера домена, но позволяет избежать атаки по словарю со стороны мошеннического сервера. Для фиксированного X сервер вычисляет таблицу, в которой местоположение Y имеет значение K такое, что Y = DES_K (X). Без участия клиента в выборе задачи сервер может отправить X, найти ответ Y в таблице и получить K. Эта атака может быть осуществлена ​​с помощью радужных таблиц.

Однако существующая инфраструктура NTLMv1 позволяет это пара запрос / ответ не проверяется сервером, а отправляется контроллеру домена для проверки. Используя сеанс NTLM2, эта инфраструктура продолжает работать, если сервер заменяет вызов хешем сервера и вызовами клиента.

Клиент NTLMv1 <-Server: SC Client->Сервер: H (P, SC) Сервер->DomCntl: H (P, SC), SC-сервер <-DomCntl: да или нет Клиент сеанса NTLM2 <-Server: SC Client->Сервер: H ( P, H '(SC, CC)), CC Server->DomCntl: H (P, H' (SC, CC)), H '(SC, CC) Server <-DomCntl: yes or no

Доступность и использование NTLM

NTLM широко применяется даже в новых системах. Основная причина - поддерживать совместимость со старыми системами. Однако во многих ситуациях его нельзя использовать.

Microsoft больше не рекомендует NTLM в приложениях:

«Разработчики должны знать, что NTLM не поддерживает какие-либо недавние криптографические методы, такие как AES или SHA-256. Он использует циклическую проверку избыточности (CRC) или сообщение дайджест-алгоритмы (RFC1321) для обеспечения целостности, и он использует RC4 для шифрования.

Получение ключа из пароля описано в RFC1320 и FIPS46-2. Поэтому приложениям обычно рекомендуется не использовать NTLM ».

Microsoft добавила хэш NTLM к своей реализации протокола Kerberos для улучшения взаимодействия (в частности, типа шифрования RC4-HMAC). По мнению независимого исследователя, это конструктивное решение позволяет обманом заставить контроллеры домена выдать злоумышленнику билет Kerberos, если известен хэш NTLM.

Microsoft приняла Kerberos в качестве предпочтительного протокола аутентификации. для Windows 2000 и последующих доменов Active Directory. Kerberos обычно используется, когда сервер принадлежит домену Windows Server. Microsoft рекомендует разработчикам не использовать напрямую Kerberos или поставщика поддержки безопасности NTLM (SSP).

Ваше приложение не должно напрямую обращаться к пакету безопасности NTLM; вместо этого следует использовать пакет безопасности Negotiate. Negotiate позволяет вашему приложению использовать преимущества более продвинутых протоколов безопасности, если они поддерживаются системами, участвующими в аутентификации. В настоящее время пакет безопасности Negotiate выбирает между Kerberos и NTLM. Negotiate выбирает Kerberos, если он не может использоваться одной из систем, участвующих в проверке подлинности.

Использование поставщика поддержки безопасности NTLM

NTLM SSP используется в следующих ситуациях:

  • Клиент аутентифицируется на сервере, который не принадлежит домену, или домен Active Directory не существует (обычно называется «рабочая группа» или «одноранговая сеть»)
    • На сервере должна быть включена функция «Совместное использование, защищенное паролем», которая не включена по умолчанию и является взаимоисключающей с домашней группой на некоторые версии Windows.
    • Если сервер и клиент принадлежат к одной и той же HomeGroup, вместо NTLM будет использоваться протокол, аналогичный Kerberos. Домашняя группа - это, вероятно, самый простой способ совместного использования ресурсов в небольшой сети, требующий минимальной настройки, даже по сравнению с настройкой нескольких дополнительных пользователей, чтобы иметь возможность использовать защищенный паролем общий доступ, что может означать, что он используется гораздо больше, чем защищенный паролем общий доступ в небольших сетях и домашние сети.
  • Если сервер - это устройство, которое поддерживает SMB, например устройства NAS и сетевые принтеры, NTLM SSP может предложить единственный поддерживаемый метод аутентификации. Некоторые реализации SMB или более старых дистрибутивов, например Samba может заставить Windows согласовывать NTLMv1 или даже LM для исходящей аутентификации с сервером SMB, позволяя устройству работать, хотя оно может быть загружено устаревшим и небезопасным программным обеспечением, независимо от того, было ли это новое устройство.
  • Если сервер является членом домена, но Kerberos использовать нельзя.
    • Клиент аутентифицируется на сервере, используя IP-адрес (и обратное разрешение имени недоступно)
    • Клиент аутентифицируется на сервере, который принадлежит другому Лес Active Directory с устаревшим доверием NTLM вместо транзитивного доверия между лесами
    • Если брандмауэр в противном случае ограничивал бы порты, требуемые Kerberos (обычно TCP 88)

Использование версий протокола

После того, как разработчик приложения или поставщик услуг согласования решит, что NTLM SSP будет использоваться для аутентификации, групповая политика диктует возможность использования каждого из протоколов, которые реализует NTLM SSP. Существует пять уровней аутентификации.

  • Отправлять ответы LM и NTLM : клиенты используют аутентификацию LM и NTLM и никогда не используют сеансовую безопасность NTLMv2; Контроллеры домена принимают аутентификацию LM, NTLM и NTLMv2.
  • Отправить LM и NTLM - использовать сеансовую безопасность NTLMv2, если согласовано : клиенты используют LM и NTLM-аутентификацию и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее; Контроллеры домена принимают аутентификацию LM, NTLM и NTLMv2.
  • Отправлять только ответ NTLM : клиенты используют только аутентификацию NTLM и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее; Контроллеры домена принимают аутентификацию LM, NTLM и NTLMv2.
  • Отправлять только ответ NTLMv2 : клиенты используют только аутентификацию NTLMv2 и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее; Контроллеры домена принимают аутентификацию LM, NTLM и NTLMv2.
  • Отправлять только ответ NTLMv2 \ отклонять LM : клиенты используют только аутентификацию NTLMv2 и используют безопасность сеанса NTLMv2, если сервер поддерживает ее; Контроллеры домена отказываются от LM (принимают только аутентификацию NTLM и NTLMv2).
  • Отправлять только ответ NTLMv2 \ отклонять LM NTLM : клиенты используют только аутентификацию NTLMv2 и используют безопасность сеанса NTLMv2, если сервер поддерживает ее; Контроллеры домена отвергают LM и NTLM (принимают только аутентификацию NTLMv2).

DC означает контроллер домена, но использование этого термина сбивает с толку. Любой компьютер, выступающий в качестве сервера и аутентифицирующий пользователя, выполняет роль контроллера домена в этом контексте, например компьютер Windows с локальной учетной записью, такой как администратор, когда эта учетная запись используется во время входа в сеть.

До Windows NT 4.0 Service Pack 4 поставщик общих служб согласовывал NTLMv1 и возвращался к LM, если другая машина его не поддерживала.

Начиная с Windows NT 4.0 Service Pack 4, поставщик общих служб будет согласовывать сеанс NTLMv2 всякий раз, когда и клиент, и сервер будут его поддерживать. До Windows XP включительно на компьютерах за пределами США использовалось 40- или 56-битное шифрование, поскольку в то время в США были жесткие ограничения на экспорт технологий шифрования. Начиная с Windows XP SP3, 128-битное шифрование может быть добавлено путем установки обновления, а в Windows 7 128-битное шифрование будет по умолчанию.

В Windows Vista и более поздних версиях LM отключен для входящей аутентификации. Операционные системы на базе Windows NT, вплоть до Windows Server ™ 2003, хранят два хэша паролей, хэш LAN Manager (LM) и хэш Windows NT. Начиная с Windows Vista ™, есть возможность сохранять и то, и другое, но по умолчанию один из них отключен. Это означает, что проверка подлинности LM больше не работает, если компьютер под управлением Windows Vista выступает в роли сервера. Предыдущие версии Windows (вплоть до Windows NT 4.0 с пакетом обновления 4) можно было настроить таким образом, но это не было по умолчанию.

Слабые стороны и уязвимости

NTLM остается уязвимым для передают хэш-атаку, которая является вариантом атаки отражения, которая была устранена с помощью обновления безопасности Microsoft MS08-068. Например, Metasploit можно использовать во многих случаях для получения учетных данных с одной машины, которые можно использовать для получения контроля над другой машиной. Набор инструментов Squirtle можно использовать для усиления атак межсайтового скриптинга веб-сайтов для атак на близлежащие ресурсы через NTLM.

В феврале 2010 года Amplia Security обнаружила несколько недостатков в реализации Windows Механизм аутентификации NTLM, который нарушил безопасность протокола, позволяя злоумышленникам получить доступ для чтения / записи к файлам и удаленное выполнение кода. Одна из представленных атак включала способность предсказывать псевдослучайные числа и запросы / ответы, генерируемые протоколом. Эти недостатки присутствовали во всех версиях Windows 17 лет. Рекомендации по безопасности, объясняющие эти проблемы, включали полностью работающие экспериментальные эксплойты. Все эти недостатки были исправлены в MS10-012.

В 2012 году было продемонстрировано, что любую возможную перестановку хэша пароля NTLM из 8 символов можно взломать менее чем за 6 часов.

В 2019 году это время было сокращено примерно до 2,5 часов за счет использования более современного оборудования

Обратите внимание, что хэши, эквивалентные паролю, используемые в атаках с передачей хэша и взломе паролей, должны быть сначала «украдены» (например, например, путем компрометации системы с разрешениями, достаточными для доступа к хешам). Кроме того, эти хэши не совпадают с «хешем» NTLMSSP_AUTH, передаваемым по сети во время обычной аутентификации NTLM.

Совместимость с Linux

Реализации NTLM для Linux включают Cntlm и (часть Samba ). Это позволяет приложениям Linux использовать прокси NTLM.

FreeBSD также поддерживает хранение паролей через Crypt (C) в небезопасной форме NT-Hash.

См. Также

Ссылки

Внешние ссылки

Последняя правка сделана 2021-05-31 07:28:28
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте