Первая часть "Ретрансляция NTLM"
Подпись сеанса
Принцип
Подпись является методом проверки подлинности и гарантирует, что информация не была подделана между отправкой и получением. Например, если пользователь jdoe посылает текст, I love hackndo, и подписывает этот документ в цифровом виде, то любой, кто получит этот документ и его подпись. Также, можно проверить, что редактировал его jdoe, и jdoe написал это предложение, а никто другой. Подпись гарантирует, что документ не был изменен.
Принцип подписи может быть применен к любому обмену, если протокол его поддерживает. Это, например, касается
Ссылка скрыта от гостей
,
Ссылка скрыта от гостей
и даже
Ссылка скрыта от гостей
. Но на практике подпись HTTP сообщений реализуется редко.
Но тогда, какой смысл подписывать пакеты? Ну, как обсуждалось ранее, сеанс и аутентификация - это два отдельных шага, когда клиент хочет использовать службу. Поскольку злоумышленник может использовать man-in-the-middle атаку, и тем самым, находиться между клиентов и сервером и ретранслировать сообщения об аутентификации, он может и выдавать себя за клиента, когда связывается с сервером.
Именно здесь важную роль играет подпись. Даже если злоумышленнику удалось аутентифицироваться на сервере в качестве клиента, он не сможет подписывать пакеты, независимо от аутентификации. Действительно, чтобы иметь возможность подписывать пакет, необходимо знать секрет клиента.
Во время NTLM ретрансляции, злоумышленник хочет притвориться клиентом, но не знает его секрета. Поэтому он не может ничего подписать от его имени. Из-за того что он не может подписать ни один пакет, сервер, получающий пакеты, увидит, что подписи нет, и отклонит запрос злоумышленника.
Поэтому, вы можете понять, что если пакеты обязательно должны быть подписаны после аутентификации, то злоумышленник больше не сможет как-то действовать, так как он не знает секрета клиента. Значит, атака провалится. Данная мера защиты очень эффективна.
Это все очень хорошо, но как клиент и сервер договариваются о том, подписывать пакеты или нет? Это отличный вопрос.
Существует две вещи, которые вступают в игру.
- Первое - указать, поддерживается ли подпись. Это узнается во время NTLM Negotiation, или NTLM Согласования.
- Второе, это указать, подпись required (или обязательна), optional (необязательна) или disabled (отключенна). Это настройка, которая выполняется на клиентском и серверном уровне.
NTLM Negotiation, NTLM Согласование
Это согласование позволяет узнать, поддерживает ли клиент и/или сервер подпись(среди прочих вещей), и происходит это во время NTLM exchange, NTLM обмена. Поэтому я соврал вам немного выше, по поводу аутентификация и сессия, на самом деле, они не являются полностью независимыми. (Кстати, я сказал, что поскольку они независимы, вы можете менять протокол при ретрансляции, но есть ограничения, которые мы рассмотрим в главе о MIC при NTLM-аутентификации).
На самом деле, в сообщениях NTLM есть и другая информация, кроме вызова и ответа, которыми обмениваются клиент и сервер. Есть также negotiation flags, или Negotiate Flags. Эти флаги указывают, что поддерживает посылающая сторона.
Существует несколько флагов, но только один из них представляет интерес - NEGOTIATE_SIGN.
Когда клиентом установлен флаг на 1, это означает, что клиент поддерживает подпись. Но будьте осторожны, это не значит, что он обязательно подпишет свои пакеты. Клиент подпишет только то, что он сможет подписать.
Аналогично, во время ответа сервера, если он поддерживает подпись, то флаг также будет установлен на 1.
Таким образом, эти переговоры позволяют каждой из двух сторон, клиенту и серверу, указывать друг другу, способны ли они подписывать пакеты. Для некоторых протоколов, даже если клиент и сервер поддерживают подпись, то не обязательно означает, что они подписывают пакеты.
Реализация
Теперь, когда мы узнали, как обе стороны указывают друг другу на свою способность подписывать пакеты, они должны подписать их. На этот раз решение принимается согласно протоколу. Так что решение будет принято по-другому для SMBv1, для SMBv2, или для LDAP. Но идея остается прежней.
В зависимости от протокола, обычно существуют 2 или даже 3 опции, которые могут быть установлены, для решения, какой будет подпись: принудительной или нет. Этими 3 опциями являются:
- Disabled: Означает, что подпись не управляется.
- Enabled: Опция указывает на то, что машина может управлять подписанием при необходимости, но не требует подписи.
- Mandatory: Наконец, это указывает на: подпись поддерживается, пакеты должны быть подписаны, чтобы продолжилась сессия.
SMB
Матрица подписей
Матрица предоставляется в
Ссылка скрыта от гостей
для определения того, подписываются ли SMB-пакеты на основе настроек, на стороне клиента и на стороне сервера. Я описал это в таблице ниже. Обратите внимание, что для SMBv2 и выше, подписание обязательно обрабатывается, параметра Disabled больше нет.
Есть разница, когда клиент и сервер имеют параметр Enabled(Включено). В SMBv1, параметром по умолчанию для серверов было Disabled (Отключено). Таким образом, весь SMB-трафик между клиентами и серверами не был подписан по умолчанию. Это позволило избежать перегрузки серверов, не позволяя им вычислять подписи каждый раз при отправке SMB-пакета. Поскольку статуса Disabled больше не существует для SMBv2, и серверы теперь включены по умолчанию, то есть имеют опцию Enabled, для того, чтобы сохранить эту нагрузку, поведение между двумя включёнными обьектами было изменено, и в этом случае подпись больше не требуется. Клиент и/или сервер должны обязательно требовать подпись для SMB пакетов.
Настройки
Чтобы изменить стандартные параметры подписи на сервере, ключи EnableSecuritySignature и RequireSecuritySignature должны быть изменены в разделе реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters.
Этот снимок экрана был сделан на контроллере домена. По умолчанию контроллеры домена требуют подписания SMB, когда клиент аутентифицируется на них. И это действительно так, GPO, примененный к контроллерам домена, содержит эту запись:
С другой стороны, на этом снимке мы видим, что над этой настройкой тот же самый параметр, применяемый к сетевому клиенту Microsoft, не применяется. Поэтому, когда контроллер домена действует в качестве сервера SMB, требуется подпись SMB, но если соединение приходит с контроллера домена на сервер, подпись SMB не требуется.
Структура
Теперь, когда мы знаем, где настроена SMB подпись, мы видим, что этот параметр применяется во время взаимодействия. Это делается непосредственно перед аутентификацией. На самом деле, когда клиент подключается к SMB серверу, происходит следующее:
- Согласование по версии SMB и требования к подписи
- Аутентификация
- SMB сессия с согласованными параметрами
Мы видим ответ сервера, указывающий, что он имеет параметр Enable, но не требует подписи.
Подводя итог, мы рассмотрим, как проходит согласование / аутентификация / сеанс :
- На этапе переговоров обе стороны указывают свои требования: Требуется ли подпись для одного из них?
- На этапе аутентификации обе стороны указывают, что они поддерживают. Способны ли они подписать?
- На этапе сессии, если возможности и требования совместимы, сессия проводится с применением того, что было согласовано.
DC01 указывает, что он не только поддерживает подпись, но и требует этого.
На этапе согласования, клиент и сервер устанавливают флаг NEGOTIATE_SIGN равным 1, так как оба пподдерживают подпись.
После завершения этой аутентификации сессия продолжается, и биржи малого и среднего бизнеса эффективно подписываются.
LDAP
Матрица подписи
Для LDAP также существуют три уровня:
- Disabled: Это означает, что подписание пакетов не поддерживается.
- Negotiated Signing(Согласованная подпись): Эта опция указывает на то, что машина может обрабатывать подпись, и если машина, с которой она взаимодействует, также обрабатывает его, то они будут подписаны.
- Required: Это, наконец, указывает на то, что подписание поддерживается, и пакеты должны быть подписаны, чтобы сессия продолжилась.
Поэтому для LDAP у нас есть матрица, аналогичная SMBv1, за исключением поведения по умолчанию.
Разница с SMB заключается в том, что в домене Active Directory все узлы имеют настройку Negotiated Signing. Контроллер домена не требует подписи.
Настройки
Для контроллера домена, ключ реестра ldapserverintegrity находится в HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters и может быть 0, 1 или 2 в зависимости от уровня. По умолчанию на контроллере домена установлено значение 1.
Для клиентов этот ключ реестра находится в HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ldap.
Для клиентов также установлено значение 1. Поскольку все клиенты и контроллеры домена имеют Negotiated Signing, все LDAP пакеты подписываются по умолчанию.
Структура
В отличие от SMB, в LDAP нет флага, который бы указывал, будут ли пакеты подписаны или нет. Вместо этого LDAP использует флаги, установленные в NTLM согласованиях. Нет необходимости в дополнительной информации. В случае если и клиент, и сервер поддерживают подписание LDAP, то будет установлен флаг NEGOTIATE_SIGN и пакеты будут подписаны.
Если одна сторона требует подписи, а другая не поддерживает, то сессия просто не начнется. Сторона, требующая подписания, проигнорирует неподписанные пакеты.
Итак, теперь мы понимаем, что, в отличие от SMB, если мы находимся между клиентом и сервером и хотим передать аутентификацию на сервер, используя LDAP, нам нужны две вещи:
- Сервер не должен требовать подписи пакетов, как это происходит для всех машин по умолчанию
- Клиент не должен устанавливать флаг NEGOTIATE_SIGN на 1, если он это сделает, то сервер будет ожидать подпись, а так как мы не знаем секрета клиента, мы не сможем подписывать наши созданные LDAP-пакеты.
Windows SMB делает это! По умолчанию невозможно передать SMB-аутентификацию в LDAP.
Так почему бы просто не поменять флаг NEGOTIATE_FLAG и не установить его на 0? Ну... NTLM сообщения также подписаны. И это мы рассмотрим в следующем параграфе.
Подписание аутентификации (MIC)
Мы видели, как сеанс можно защитить от mitm атаки. Теперь, чтобы понять интерес этой главы, давайте рассмотрим конкретный случай.
Edge case
Давайте представим себе, что злоумышленник умудряется попасть в положение man-in-the-middle, между клиентом и контроллером домена, и что он получает запрос на аутентификацию через SMB. Зная, что контроллер домена требует SMB подписи, злоумышленник не может передать эту аутентификацию через SMB. С другой стороны, можно изменить протокол, как мы видели выше, и злоумышленник решает перейти на протокол LDAPS, так как аутентификация и сеанс должны быть независимыми.
Ну, они почти независимы.
Почти потому, что мы видели, что в данных аутентификации был флаг NEGOTIATE_SIGN, который присутствовал, что бы указать, поддерживают ли клиент и сервер подпись. Но в некоторых случаях этот флаг учитывается, как мы видели в LDAP.
Для LDAPS этот флаг также учитывается сервером. Если сервер получает запрос на аутентификацию с флагом NEGOTIATE_SIGN, установленным на 1, он отклонит аутентификацию. Это происходит потому, что LDAPS является LDAP по TLS, и именно уровень TLS обрабатывает подписание (и шифрование) пакетов. Таким образом, у клиента LDAPS нет причин указывать, что он может подписывать свои пакеты, и если он утверждает, что может это сделать, сервер, в переносном значении, смеется над ним и хлопает дверью.
Теперь в нашей атаке клиент, которого мы ретранслируем, хочет аутентифицироваться через SMB, поэтому да, он поддерживает подписание пакетов, и да, установлен флаг NEGOTIATE_SIGN на 1. Но если мы ретранслируем его аутентификацию, ничего не меняя, через LDAPS, то LDAPS сервер увидит этот флаг, и завершит фазу аутентификации, без вопросов.
Мы могли бы просто изменить сообщение NTLM и удалить флаг, правильно? Если бы мы могли, то мы бы это сделали, это бы хорошо сработало. За исключением того, что на уровне NTLM также имеется подпись.
Эта подпись, она называется MIC, или Message Integrity Code (Код Целостности Сообщения).
MIC - Message Integrity Code
MIC - это подпись, которую отправляют только в последнем сообщении NTLM-аутентификации, в сообщении AUTHENTICATE. При этом учитываются другие 3 сообщения. MIC вычисляется функцией HMAC_MD5, используя в качестве ключа, который зависит от секрета клиента, называемого session key, ключом сеанса.
HMAC_MD5(Session key, NEGOTIATE_MESSAGE + CHALLENGE_MESSAGE + AUTHENTICATE_MESSAGE)Важно то, что ключ сеанса зависит от секрета клиента, поэтому злоумышленник не может создать MIC.
Вот пример MIC:
Таким образом, если только одно из 3 сообщений было изменено, то MIC больше не будет действительным, из-за несхожести конкатенации 3 сообщения. Поэтому вы не можете изменить флаг NEGOTIATE_SIGN, как это предлагается в нашем примере.
А что если мы просто удалим MIC? Потому что да, MIC необязателен.
Ну, и это не сработает, потому что есть еще один флаг, указывающий, что будет присутствовать MIC, msAvFlags. Он также присутствует в ответе NTLM, и если он равен 0x00000002, то тем самым утверждает серверу, что должен присутствовать MIC. Поэтому, если сервер не видит MIC, он будет знать, что что-то происходит, и завершит аутентификацию. Если флаг утверждает, что должен быть MIC, значит, MIC должен быть.
Хорошо, а если мы установим msAcFlags на 0 и удалим MIC, что случится? Так как больше нет MIC, мы не можем проверить, было ли изменено сообщение, не так ли?
…
Ну, мы можем. Получается, что NTLMv2 Hash, который является ответом на вызов, посланный сервером, представляет собой хэш, который учитывает не только вызов (очевидно), но и все флаги ответа. Как вы, возможно, догадались, флаг, указывающий на присутствие MIC, тоже является частью этого ответа.
Изменение или удаление этого флага сделает хэш NTLMv2 недействительным, так как данные будут изменены. Вот как это выглядит.
MIC защищает целостность 3 сообщений, msAvFlags защищает присутствие MIC, а NTLMv2 хэш защищает присутствие флага. Атакующий, не зная секрета пользователя, не сможет подсчитать этот хэш.
Так что, вы должны были понять, что в этом случае мы ничего не можем сделать, и это благодаря MIC.
Drop the MIC
Небольшой обзор недавней уязвимости, найденной
Ссылка скрыта от гостей
, который вы легко сейчас поймете.Это
Ссылка скрыта от гостей
, красиво названный "Drop the MIC". Эта уязвимость показала, что если MIC был просто удален, даже если флаг указывал на его присутствие, то сервер принимал аутентификацию без проблем. Очевидно, это была ошибка, которую, с тех пор, пофиксили.MIC был интегрирован в инструмент ntlmrelayx с помощью параметра --remove-mic.
Давайте рассмотрим наш пример ранее, но на этот раз с контроллером домена, который все еще уязвим. Вот как это выглядит на практике.
Наша атака работает. Отлично.
Для информации, еще одна уязвимость была обнаружена той же самой командой, и они назвали ее
Ссылка скрыта от гостей
.Ключ сеанса
Ранее мы говорили о подписи сеанса и аутентификации, говоря, что для того, чтобы подписать что-то, нужно знать секрет пользователя. В главе о MIC мы сказали, что на самом деле используется не секрет пользователя, а ключ, называемый ключом сеанса, который зависит от секрета пользователя.
Чтобы дать вам представление, вот как вычисляется ключ сеанса для NTLMv1 и NTLMv2.
Код:
# For NTLMv1
Key = MD4(Hash NT)
# For NTLMv2
Key = HMAC_MD5(NTLMv2 Hash, HMAC_MD5(NTLMv2 Hash, NTLMv2 Response + Challenge))Понять объяснения было бы не очень полезно, но очевидно, что в разных версиях есть разница в сложности. Повторяю, не используйте NTLMv1 в производственной сети.
Имея эту информацию, понимаем, что клиент может вычислить этот ключ на своей стороне, так как у него есть для этого вся информация.
Сервер, с другой стороны, не всегда может сделать это в одиночку. Для
Ссылка скрыта от гостей
нет никаких проблем, так как сервер знает NT хэш пользователя.С другой стороны, для
Ссылка скрыта от гостей
серверу придется попросить контроллер домена вычислить ключ сеанса для него и отправить его обратно. В pass-the-hash статье мы увидели, что сервер посылает запрос на контроллер домена в структуре
Ссылка скрыта от гостей
, а контроллер домена отвечает структурой
Ссылка скрыта от гостей
. Именно в этом ответе с контроллера домена отправляется ключ сеанса, если аутентификация прошла успешно.
Затем возникает вопрос о том, что мешает злоумышленнику сделать тот же запрос к контроллеру домена, что и к целевому серверу. Ну, до
Ссылка скрыта от гостей
, ничего!Очевидно, Майкрософт исправил эту ошибку. Для проверки того, что только сервер, на котором пользователь аутентифицируется, имеет право запросить ключ сеанса, контроллер домена убедится, что целевой компьютер в ответе AUTHENTICATE тот же самый, что и хост, делающий NetLogon запрос.
В ответе AUTHENTICATE мы подробно описали присутствие msAvFlags, указывающих на присутствие или отсутствие MIC, но есть и другая информация, например, Netbios название целевого компьютера.
Это имя сравнивается с именем хоста, выполняющего запрос NetLogon. Таким образом, если злоумышленник попытается сделать NetLogon запрос на ключ сеанса, так как имя злоумышленника не совпадает с именем целевого узла в ответе NTLM, контроллер домена отклонит запрос.
Наконец, как и в случае с msAvFlags, мы не можем изменить имя компьютера "на лету" в ответе NTLM, так как оно учитывается при расчете ответа NTLMv2.
Уязвимость, похожая на Drop the MIC 2, была недавно обнаружена группой безопасности Preempt. Вот
Ссылка скрыта от гостей
на их пост, если вам интересно.Channel Binding
Мы поговорим об одном последнем пункте. Несколько раз мы повторяли, что уровень аутентификации, т.е. NTLM сообщений, практически не зависит от прикладного уровня, используемого протокола (SMB, LDAP, ...). Я говорю "почти", потому что мы видели, что некоторые протоколы используют некие NTLM-флаги сообщений, чтобы узнать, должен ли сеанс быть подписан или нет.
В любом случае, как уже говорилось, злоумышленник вполне может получить NTLM-сообщение от протокола A и отправить его обратно по протоколу B. Это называется cross-protocol relay, межпротокольным реле, о чем мы уже говорили.
В целом, существует новая защита, противостоящая этой атаке. Это называется channel binding, или EPA (Enhanced Protection for Authentication). Принцип этой защиты заключается в «связывании» уровня аутентификации с используемым протоколом, даже с уровнем TLS, когда он существует (например, LDAPS или HTTPS). Общая идея заключается в том, что в последнем сообщении NTLM AUTHENTICATE помещается часть информации, которая не может быть изменена злоумышленником. Эта информация указывает на желаемую службу, а так же, возможно, содержит хэш сертификата целевого сервера.
Мы рассмотрим эти два принципа немного подробнее, но не волнуйтесь, все, в принципе, можно легко понять.
Service binding
Эту первую защиту легко понять. Если клиент желает аутентифицироваться на сервере для использования определенного сервиса, информация, идентифицирующая сервис, будет добавлена в ответ NTLM.
Таким образом, когда легитимный сервер получает эту аутентификацию, он может увидеть сервис, который был запрошен клиентом, и если он отличается от того, что было на самом деле запрошено, он не согласится предоставить сервис.
Так как имя сервиса находится в ответе NTLM, то оно защищено ответом NtProofStr, который является HMAC_MD5 этой информации, вызовом, и другой информацией, такой как msAvFlags. Это вычисляется с секретом клиента.
В примере, показанном на последней диаграмме, мы видим клиента, пытающегося аутентифицироваться по HTTP на сервере. За исключением того, что сервер является злоумышленником, и злоумышленник просто не может аутентифицироваться на легитимном сервере, чтобы получить доступ к сетевому ресурсу (SMB).
Кроме того, что клиент указал в своем ответе NTLM сервис, который он хочет использовать, и поскольку атакующий не может его модифицировать, он должен передать его как есть. Затем сервер получает последнее сообщение, сравнивает службу, запрошенную атакующим (SMB) со службой, указанной в сообщении NTLM (HTTP), и отказывает в соединении, обнаруживая, что эти две службы не совпадают.
Конкретно, то, что называется сервисом, на самом деле является SPN или Service Principal Name (Имя Руководителя Службы). Я посвятил
Ссылка скрыта от гостей
объяснению этого понятия.Вот скриншот клиента, посылающего SPN в своем NTLM ответе.
Мы видим, что это указывает на использование сервиса CIFS (эквивалент SMB, просто другая терминология). Передача этой информации на LDAP сервер, который учитывает эту информацию, приведет к хорошему Access denied с сервера.
Но, как вы видите, есть не только имя службы (CIFS), но и целевое имя, или IP-адрес. Это означает, что если злоумышленник передаст это сообщение на сервер, то сервер также проверит целевую часть и откажется от соединения, потому что IP-адрес, найденный в SPN, не соответствует его IP-адресу.
Поэтому если эта защита поддерживается всеми клиентами и всеми серверами, и требуется каждому серверу, то она отразит все попытки ретрансляции.
TLS Binding
На этот раз целью этой защиты является «связывание» уровня аутентификации, т.е. NTLM сообщений, с уровнем TLS, который может быть потенциально использован.
Если клиент хочет использовать протокол, инкапсулированный в TLS (HTTPS, LDAPS, например), он создаст TLS сеанс с сервером, и вычислит хэш-сертификата сервера. Этот хэш называется Channel Binding Token , или CBT. После вычисления, клиент поместит этот хэш в свой NTLM ответ. После этого легитимный сервер получит NTLM сообщение в конце аутентификации, прочитает предоставленный хэш и сравнит его с реальным хэшем своего сертификата. Если он отличается, значит, он не был первоначальным получателем NTLM обмена.
Опять же, поскольку этот хэш находится в NTLM ответе, он защищен ответом NtProofStr, как и SPN для Service Binding.
Благодаря этой защите, следующие две атаки больше не возможны:
- Если атакующий хочет передать информацию от клиента, использующего протокол без уровня TLS, на протокол с уровнем TLS (например, HTTP на LDAPS), он не сможет добавить хэш сертификата с целевого сервера в NTLM ответ, поскольку не сможет обновить NtProofStr.
- Если атакующий хочет переслать протокол с TLS на другой протокол с TLS (HTTPS на LDAPS), то при создании сеанса TLS между клиентом и атакующим, атакующий не сможет предоставить сертификат сервера, так как он не совпадает с идентификацией атакующего. Поэтому он должен будет предоставить самодельный сертификат, идентифицирующий злоумышленника. Затем клиент будет хэшировать этот сертификат, и когда злоумышленник передаст NTLM ответ легитимному серверу, хэш в ответе не будет совпадать с хэшем реального сертификата, поэтому сервер отвергнет аутентификацию.
Это показывает создание двух сессий TLS. Один между клиентом и атакующим (красным) и один между атакующим и сервером (синим). Клиент получит сертификат злоумышленника и вычислит хэш, сертификат хэша, который обозначен красным цветом.
В конце NTLM обменов этот хэш будет добавлен в NTLM ответ и будет защищен, так как он является частью зашифрованных данных NTLM ответа. Когда сервер получит этот хэш, он будет хэшировать свой сертификат, и, увидев, что это не тот же результат, он откажется от соединения.
Опять же, Preempt недавно
Ссылка скрыта от гостей
, которая была исправлена с тех пор.Что может быть передано?
Имея всю эту информацию, вы должны знать, какие протоколы можно передавать по каким протоколам. Мы видели, что невозможно осуществить ретрансляцию, например, с SMB на LDAP или LDAPS. С другой стороны, любой клиент, который не установил флаг NEGOTIATE_SIGN, может быть ретранслирован в LDAP.
Так как существует множество случаев, вот таблица, обобщающая некоторые из них.
Я думаю, что мы не можем ретранслировать LDAPS или HTTPS, поскольку у злоумышленника нет действительного сертификата, но, допустим, клиент разрешает использование недоверенных сертификатов. Могут быть добавлены и другие протоколы, такие как SQL или SMTP, но я должен признать, что не прочитал документацию по всем существующим протоколам.
Для gray box я не знаю, как HTTPS-сервер обрабатывает аутентификацию с флагом NEGOTIATE_SIGN, установленным на 1.
Перестаньте. Использовать. NTLMv1.
Вот небольшой "забавный факт", который
Ссылка скрыта от гостей
предложила мне добавить. Как мы обсуждали, NTLMv2 хэш учитывает вызов сервера, а также флаг msAvFlags, который указывает на наличие MIC поля, указывающего NetBios имя целевого узла во время аутентификации, SPN в случае привязки сервиса, и хэш сертификата в случае привязки TLS.В принципе, протокол NTLMv1 этого не делает. При этом учитывается только вызов сервера. Фактически, больше нет никакой дополнительной информации, такой как имя цели, msAvFlags, SPN или CBT.
Таким образом, если NTLMv1-аутентификация разрешена сервером, злоумышленник может просто удалить MIC и тем самым передать аутентификацию, например, LDAP или LDAPS.
Но что более важно, он может сделать NetLogon запросы на получение ключа сеанса. На самом деле, контроллер домена не имеет возможности проверить, имеет ли он на это право. А так как он не заблокирует производственную сеть, которая не полностью обновлена, он любезно передаст ее злоумышленнику, по причине "ретро-совместимости".
Как только у него будет ключ сеанса, он может подписать любой пакет, который захочет. Это означает, что даже если цель попросит подписать, он сможет это сделать.
Так и должно быть, и оно не может быть исправлено. Так что повторяю, не разрешайте NTLMv1 в производственной сети.
Заключение
Итак, было много информации.
Мы видели здесь подробности NTLM ретрансляции, зная, что аутентификация и следующая за ней сессия являются двумя различными понятиями, позволяющими во многих случаях выполнять межпротокольную ретрансляцию. Хотя протокол каким-то образом включает в себя данные аутентификации, он непрозрачен для протокола и управляется SSPI.
Мы также показали, как подписание пакетов может защитить сервер от атак типа man-in-the-middle. Для этого цель должна ждать подписанного пакета, идущего от клиента, иначе злоумышленник сможет притвориться кем-то другим, и без необходимости подписывать посылаемые им сообщения.
Мы увидели, что MIC очень важен для защиты NTLM-обменов, особенно флаг, указывающий, будут ли пакеты подписаны для определенных протоколов, или информация о привязке каналов.
Мы остановились на том, как привязка каналов может «связать» уровень аутентификации и сеансовый уровень, либо через имя службы, либо через ссылку с сертификатом сервера.
Я надеюсь, что эта статья дала вам понимание того, что происходит во время атаки на NTLM ретранслятор и как от этого защититься.
Поскольку эта статья весьма существенна, вполне вероятно, что некоторые ошибки проскользнули внутрь. Не стесняйтесь связаться со мной в
Ссылка скрыта от гостей
или на моем Discord Server, чтобы обсудить это.
Последнее редактирование:
