Руслан Рахметов, Security Vision
Одной из основных функций информационной безопасности является аутентификация пользователей, администраторов, сервисных учетных записей и иных сущностей, которые выполняют определенные действия в информационных системах. Аутентификация означает проверку системой подлинности предъявляемых пользователями учетных данных (логины, пароли, одноразовые коды доступа, иные аутентификаторы). Аутентификация отличается от идентификации - процесса представления пользователя системе без подтверждения своей подлинности, а также от авторизации - процесса предоставления пользователю полномочий в системе после его успешной аутентификации. В современных корпоративных инфраструктурах используются два основных протокола аутентификации - NTLM (в среде Windows) и Kerberos (в средах Windows и Linux), о которых мы поговорим в данной статье.
Итак, протокол NTLM (аббревиатура от "New Technology LAN Manager", при этом LAN Manager - это название устаревшей ОС, которая разрабатывалась Microsoft более 30 лет назад) используется в Windows-среде для аутентификации пользователей, устройств и сервисов в доменной и недоменной инфраструктуре. В случае доменной инфраструктуры NTLM-аутентификация основывается на доверии всех членов домена (пользователей, устройств, сервисов) контроллеру домена, поэтому пользователь аутентифицируется в домене единожды при входе в ОС и затем не вводит логин и пароль при доступе к разнообразным сетевым сервисам (например, сетевым папкам, веб-службам, сетевым принтерам). Контроллер домена обладает сведениями о секретных ключах пользователей (хэши паролей NT-Hash, расскажем о них далее), которые используются для их аутентификации; данные сведения вместе с данными о пользователях хранятся в файле NTDS.dit, который расположен на контроллере домена в каталоге "C:\Windows\NTDS\". В случае недоменной среды предполагается, что пользователь знает пароль для доступа к сервису, на котором аутентифицируется; секретные ключи (хэши NT-Hash) локальных пользователей и сервисов хранятся в файле "C:\Windows\System32\config\SAM", который отображается в реестре Windows по пути "HKEY_LOCAL_MACHINE\SAM".
В настоящий момент считаются устаревшими все версии протокола NTLM, кроме второй (NTLMv2), поэтому в рамках данной статьи будем рассматривать именно NTLMv2. Ключевой особенностью NTLM-аутентификации является то, что в ней используются не пароли в чистом виде, а хэши паролей: хэши паролей типа "NT-Hash" для локальной аутентификации и хэши паролей типа "Net-NTLMv2" для доменной (сетевой) аутентификации.
Хэши паролей типа "NT-Hash" формируются как результат хэширования пароля с использованием алгоритма MD4:
NT-Hash = MD4 (password)
Сформированный NT-Hash представляет из себя последовательность из 128 бит, знание которой позволяет атакующим имперсонировать пользователя, т.е. совершать все действия от имени скомпрометированной учетной записи, включая доступ к сетевым ресурсам. Такие атаки называются Pass-The-Hash и реализуются с помощью различных утилит, например Mimikatz или SecretsDump, которые получают доступ к данным процесса Lsass.exe, в котором хранятся NT-Hash залогиненных пользователей, а также получают доступ к данным, сохраненным в "Windows Credential Manager" ("Управление учетными данными") и к данным локальных пользователей (файл SAM). Данный тип хэша достаточно легко поддается брутфорсу.
Хэш типа Net-NTLMv2 формируется на основе NT-Hash с использованием алгоритма формирования HMAC-имитовставки с MD5-хэшированием:
NTLMv2 Hash = HMAC-MD5 (NT-Hash, user name, domain name)
Итоговый хэш Net-NTLMv2 представляет собой комбинацию полученного значения NTLMv2 Hash (длиной 128 бит) и служебных данных (challenge-запросов пользователя и сервера). Данный тип хэша Net-NTLMv2 нельзя использовать для атак типа Pass-The-Hash, но можно применять при реализации атак типа Hash Relay (например, SMB Relay Attack, NTLM Relay Attack, LDAP Relay Attack), которые выполняются с помощью утилит Responder или Impacket (ntlmrelayx / smbrelayx). Данный тип хэша поддается брутфорсу, который, однако, занимает больше времени по сравнению с брутфорсом хэшей NT-Hash.
Алгоритм аутентификации NTLMv2 заключается в выполнении следующих шагов (на основе данных ресурсов Microsoft и организации SANS):
1. Клиент посылает серверу запрос на подключение, который содержит имя своей учетной записи, а также список поддерживаемых клиентом функций.
2. Сервер отвечает клиенту перечнем поддерживаемых им функций, а также передает ему challenge-запрос сервера (также называется nonce-строка) из 8 случайных байт.
3. Клиент выполняет операции:
3a. Рассчитывает NTLMv2 Hash как функцию HMAC-MD5 от имени пользователя и имени сервера с указанием его домена, где в качестве секретного ключа для HMAC-алгоритма используется значение NT-Hash:
NTLMv2 Hash = HMAC-MD5 (NT-Hash, user name, domain name)
3b. Формирует набор данных (temp), содержащих текущую метку времени и challenge-запрос клиента из 8 случайных байт: метка времени используется для предотвращения атаки повторного воспроизведения (replay attack с накоплением и повторным использованием устаревших данных аутентификации), а challenge-запрос - для повышения криптостойкости используемой схемы аутентификации и взаимной аутентификации сервера перед клиентом.
3c. Полученный на этапе 3b набор temp объединяется с challenge-запросом сервера, а затем проводится через алгоритм HMAC-MD5, где в качестве секретного ключа для HMAC-алгоритма используется значение NTLMv2 Hash, рассчитанное на этапе 3a:
NTProofStr = HMAC-MD5 (NTLMv2 Hash, server challenge + temp)
3d. Итоговый NTLMv2 Response, который и будет являться хэшем Net-NTLMv2 (нефиксированной длины), представляет собой объединение полученного на этапе 3c значения NTProofStr и набора temp:
NTLMv2 Response = NTProofStr + temp
Net-NTLMv2 = NTLMv2 Response
4. Клиент отправляет серверу полученный NTLMv2 Response.
5. Сервер выполняет следующие действия:
5a. Если используется локальная аутентификация, то сервер самостоятельно вычисляет значение NTLMv2 Response (т.к. обладает всеми необходимыми для этого данными, включая хранящийся локально NT-Hash от пароля пользователя), а затем проверяет соответствие вычисленного им значения NTLMv2 Response и значения NTLMv2 Response, которое переслал ему клиент. Если данные значения совпадают, то клиент аутентифицируется сервером, далее происходит расчет ключа шифрования KeyExchangeKey длиной 128 бит, который используется для криптографической защиты передаваемых данных между клиентом и сервером:
KeyExchangeKey = HMAC-MD5 (NTLMv2 Hash, NTProofStr)
5b. Если используется доменная аутентификация, то сервер пересылает контроллеру домена полученное от клиента значение NTLMv2 Response вместе с именем аутентифицируемого пользователя и challenge-запросом сервера (который был отправлен клиенту на этапе 2). Контроллер домена самостоятельно вычисляет значение NTLMv2 Response (т.к. знает имя аутентифицируемого пользователя и обладает доступом к NT-Hash от его пароля), а затем проверяет соответствие вычисленного им значения NTLMv2 Response и вычисленного клиентом значения NTLMv2 Response, которое переслал ему сервер. Если данные значения совпадают, то контроллер домена сообщает серверу, что клиент аутентифицирован, и передает серверу рассчитанный ключ шифрования SessionBaseKey длиной 128 бит, который будет использоваться для криптографической защиты передаваемых данных между клиентом и сервером:
SessionBaseKey = HMAC-MD5 (NTLMv2 Hash, NTProofStr)
Как видно из описания протокола NTLM, надежность аутентификации в значительной мере зависит от сложности пароля пользователя, который затем используется для расчета NT-Hash и далее используется во всей схеме аутентификации NTLM. Эффективным способом атаки остается брутфорс полученных локально хэшей NT-Hash и перехваченных по сети хэшей Net-NTLMv2. Также не теряют актуальности атаки типа Hash Relay, которые основываются на внедрении в процесс аутентификации стороннего атакующего сервера, который перехватывает весь трафик от клиента к легитимному серверу, а затем имперсонирует клиента после получения хэша Net-NTLMv2. Для снижения вероятности реализации атак подобного типа следует ограничить и контролировать использование в корпоративной сети ненадежных протоколов, таких как LLMNR, NBT-NS, mDNS, минимизировать риски атак внедрения недоверенной информации для протоколов DNS и ARP, а также использовать рекомендуемые Microsoft методы защиты: подпись SMB и LDAP (SMB / LDAP signing), задействование технологии Extended Protection for Authentication (EPA), а также полный переход на более надежный протокол аутентификации Керберос.
Протокол Керберос разрабатывается Массачусетским технологическим институт (MIT), последней актуальной версией является Kerberos 5 Release 1.21.2. Данный протокол основывается на доверии всех участников аутентификации единому центру аутентификации. Протокол Керберос можно использовать в гетерогенных средах, в нем применяется симметричное шифрование, используется единая аутентификация для работы с различными сервисами в пределах Керберос-домена, а также выполняется взаимная аутентификация клиента и сервера. Для работы Керберос каждое устройство и сервис должны обладать зарегистрированными на контроллере домена SPN-именами (атрибут servicePrincipalName), включающими в себя DNS-имя устройства (например, PC01.corp.local или DC01.corp.local) и название сервиса (например, WSMAN, TERMSRV, CIFS и т.д.). Керберос-аутентификация работает при доступе к удаленным ресурсам по их DNS-именам и не работает при доступе по их IP-адресам.
В Windows-среде аутентификация Керберос поддерживается с использованием двух видов шифронаборов:
1. RC4_HMAC_MD5 - более старая реализация, в которой применяется алгоритм потокового шифрования RC4 и алгоритм HMAC-MD5 для аутентификации и контроля целостности, где в качестве секретного ключа для HMAC используется значение NT-Hash (оно же используется и для NTLM-аутентификации):
NT-Hash = MD4 (password)
2. AES128_HMAC_SHA1 и AES256_HMAC_SHA1 - более новые реализации, в которых используется алгоритм стандарта AES с длиной ключа 128 или 256 бит, где для выработки ключа шифрования используется PBKDF2-функция с алгоритмом HMAC-SHA1, в которую передается сочетание пароля, значения "salt" (переменная, формирующаяся как сочетание вида «ИМЯПКимяпользователя», например, CORP.LOCALuser1), а также двух дополнительных констант (iter_count, keylength).
В схеме аутентификации Керберос используются следующие компоненты:
1. KDC (key distribution center) - содержит в себе закрытые ключи пользователей и сервисов, которые доверяют KDC. При этом KDC является единой точкой отказа, он должен быть всегда доступен для подключения. Зачастую в корпоративных сетях для отказоустойчивости используются сразу несколько контроллеров домена, выполняющих роль KDC, с репликацией данных между ними.
2. AS (authentication service) - компонент KDC, который принимает запросы от пользователей.
3. TGS (ticket granting service) - компонент KDC, который принимает запросы на сессионные ключи (TGS-билеты) и выдаёт их. TGS-билеты имеют срок жизни 10 часов по умолчанию.
4. TGT (ticket granting ticket) - билет, который выдаётся AS'ом в зашифрованном виде клиенту на некоторое время (по умолчанию на 10 часов), далее клиент его использует для подтверждения того, что он уже был аутентифицирован.
Описание процесса аутентификации с использованием Керберос:
1. Клиент обращается к AS для получения TGT. Клиент пересылает данные (идентификатор клиента, метку времени, случайным образом сгенерированную nonce-метку и идентификатор сервера) в сообщении, которое называется KRB_AS_REQ. Передаваемая клиентом метка времени шифруется с использованием хэша от пароля пользователя (NT-Hash или значение PBKDF2-функции) в качестве ключа шифрования. Метка времени шифруется только в случае, когда для учетной записи пользователя установлен признак «Требуется предварительная аутентификация» (Kerberos preauthentication). Метка времени используется для предотвращения атаки повторного воспроизведения (replay attack с накоплением и повторным использованием устаревших данных аутентификации), для этого требуется, чтобы на клиенте было установлено точное время (допустимая рассинхронизация настраивается, по умолчанию она составляет не более 5 минут).
2. AS расшифровывает запрос клиента (связываясь с KDC для получения секретного ключа клиента); если его удается расшифровать, то AS возвращает клиенту TGT-билет, зашифрованный ключом TGS'а (который представляет собой хэш от пароля служебного доменного пользователя KRBTGT), а также зашифрованные ключом клиента сессионный ключ связи «клиент/TGS», время действия TGT-билета и nonce-метку. Это сообщение называется KRB_AS_REP. Билет TGT может быть открыт и прочитан только сервисом KRBTGT, однако подвержен брутфорс-атакам в случае его перехвата атакующими. Проверка nonce-метки используется для предотвращения replay-атак и для сопоставления клиентом отправленных им запросов и полученных от сервера ответов.
3. Когда клиент хочет использовать какой-либо сервис (например, почтовый сервер или принт-сервер), то клиент шлёт в TGS свой TGT, SPN-идентификатор сервиса и свой зашифрованный сессионным ключом «клиент/TGS» аутентификатор (имя клиента, временная метка), а также случайным образом сгенерированную nonce-метку. Это сообщение называется KRB_TGS_REQ.
4. TGS отвечает клиенту, передавая ему:
4a. TGS-билет, который зашифрован секретным ключом сервиса (т.е. хэшем от пароля учетной записи сервиса, к которому клиент хочет получить доступ) и содержит имя клиента, метку времени KDC, время действия TGS-билета, сессионный ключ «клиент/сервис»;
4b. Сессионный ключ «клиент/сервис» и nonce-метку, зашифрованные сессионным ключом «клиент/TGS».
Это сообщение называется KRB_TGS_REP.
5. Клиент отправляет сервису этот TGS-билет и свой новый аутентификатор (метка времени и имя клиента, зашифрованные сессионным ключом «клиент/сервис»). Это сообщение называется KRB_AP_REQ.
6. Сервис расшифровывает полученный TGS-билет своим закрытым ключом, извлекает сессионный ключ «клиент/сервис», потом полученным сессионным ключом «клиент/сервис» расшифровывает аутентификатор клиента. Далее, чтобы себя аутентифицировать перед клиентом, сервис отправляет клиенту ранее полученное значение «метка времени клиента», зашифрованное сессионным ключом «клиент/сервис». Это сообщение называется KRB_AP_REP.
7. Клиент расшифровывает «метку времени», проверяет её совпадение, и в случае успеха начинается обмен информацией между клиентом и сервисом.
Несмотря на то, что Керберос является протоколом аутентификации, в него заложена возможность выполнения проверки полномочий клиента - это осуществляется с помощью структуры PAC (Privilege Attribute Certificate, сертификат атрибута привилегий), которая включается в зашифрованные билеты TGT и TGS, передающиеся в сообщениях KRB_AS_REP и KRB_TGS_REP. В PAC-структуре указаны привилегии пользователя, которые сервис может проверить, обратившись в KDC. Одна из известных уязвимостей в реализации Керберос компанией Microsoft имеет идентификатор CVE-2014-6324 - она заключалась в отсутствии корректной проверки атрибутов PAC, что позволяло обычному пользователю повысить привилегии до максимальных в домене.
Основными типами атак на Керберос являются:
Pass The Ticket - возможность использования пользовательского TGS или TGT-билета Керберос для получения доступа к ресурсам из-под его учетной записи. Атака реализуется, например, путем доступа к памяти процесса lsass.exe, в которой хранятся Керберос-билеты.
Golden Ticket - возможность выдавать себя за любого пользователя в домене, используя хэш учетной записи KRBTGT и выдавая любые TGT-билеты кому угодно.
Silver Ticket - возможность использования хэша от пароля сервисной учетной записи для создания TGS-билета и получения доступа к ресурсам из-под этой учетной записи.
Kerberoasting - возможность брутфорса и получения пароля сервисной учетной записи в офлайне без риска блокировки аккаунта. Возможность атаки также связана с тем, что пароли для сервисных аккаунтов либо не меняются вовсе, либо меняются крайне редко.
ASREPRoast - возможность брутфорса и получения пароля пользователя в случае отсутствия требования Kerberos preauthentication.
Overpass The Hash - возможность получения TGT пользователя при наличии хэша от его пароля.
