Как защититься от mimikatz в домене windows

HTTP.sys

HTTP.sys поддерживает проверку подлинности Windows в режиме ядра с помощью Negotiate, NTLM или обычной проверки подлинности.

Добавьте службы проверки подлинности, вызвав AddAuthentication ( Microsoft.AspNetCore.Server.HttpSys пространство имен) в :

Настройте веб-узел приложения для использования HTTP.sys с проверкой подлинности Windows (Program.CS). UseHttpSys находится в пространстве имен Microsoft.AspNetCore.Server.HttpSys.

Примечание

HTTP.sys делегирует задачи в проверку подлинности в режиме ядра с помощью протокола проверки подлинности Kerberos. Проверка подлинности в режиме пользователя не поддерживается с Kerberos и HTTP.sys. Необходимо использовать учетную запись компьютера для расшифровки маркера/билета Kerberos, полученного из Active Directory и переадресованного клиентом на сервер для проверки подлинности пользователя. Зарегистрируйте имя субъекта-службы (SPN) для узла, а не пользователя приложения.

Примечание

HTTP.sys не поддерживается на сервере Nano Server версии 1709 или более поздней. Чтобы использовать проверку подлинности Windows и HTTP.sys с Nano Server, используйте контейнер Server Core (Microsoft/windowsservercore). Дополнительные сведения о Server Core см. в разделе что такое вариант установки Server Core в Windows Server?.

Сведения о хеше LM

Хеш LM (также известный как хэш LanMan или хэширование LAN Manager) представляет собой уязвимую функцию хеширования паролей, которая была основным хэшем, который версии Microsoft LAN Manager и Microsoft Windows до Windows NT использовали для хранения пользовательских паролей. Поддержка устаревшего протокола LAN Manager продолжалась в более поздних версиях Windows для обеспечения обратной совместимости, но была рекомендована Microsoft для отключения администраторами; начиная с Windows Vista, протокол по умолчанию отключен, но по-прежнему используется некоторыми non-Microsoft SMB-реализациями.

Обходные пути

Для устранения слабых мест безопасности, присущих схемам шифрования и аутентификации LM, Microsoft представила протокол NTLMv1 в 1993 году с Windows NT 3.1. Для хеширования NTLM использует поддержку Unicode, заменяя на , который не требует каких-либо дополнений или усечений, которые упростили бы ключ. С отрицательной стороны, тот же алгоритм DES использовался только с 56-битным шифрованием для последующих шагов аутентификации, и до сих пор нет соления. Кроме того, Windows-машины в течение многих лет настраивались по умолчанию для отправки и приема ответов, полученных как из хеша LM, так и из хэш-функции NTLM, поэтому использование хэша NTLM не обеспечивало дополнительной защиты, пока слабый хэш еще присутствовал. Также потребовалось время для искусственных ограничений длины пароля в инструментах управления, таких как диспетчер пользователей, которые должны быть отменены.

Хотя LAN Manager считается устаревшим, а текущие операционные системы Windows используют более надежные методы проверки подлинности NTLMv2 или Kerberos, системы Windows до Windows Vista / Windows Server 2008 по умолчанию включили хеш диспетчера LAN для обратной совместимости с устаревшими LAN Manager и Windows Me или более ранними клиентами, или устаревших приложений, поддерживающих NetBIOS. В течение многих лет считается хорошей практикой безопасности, чтобы отключить скомпрометированные протоколы проверки подлинности LM и NTLMv1 там, где они не нужны. Начиная с Windows Vista и Windows Server 2008, Microsoft отключила хэш LM по умолчанию; эта функция может быть включена для локальных учетных записей с помощью параметра политики безопасности и для учетных записей Active Directory путем применения того же параметра через групповую политику домена. Тот же метод можно использовать для отключения этой функции в Windows 2000, Windows XP и NT. Пользователи также могут предотвратить создание хэш-функции LM для собственного пароля, используя пароль длиной не менее пятнадцати символов.

Хэши NTLM в свою очередь становятся уязвимыми в последние годы для различных атак, которые эффективно делают их сегодня слабыми, поскольку хэши LanMan были еще в 1998 году.

Пользователям запрещается доступ к развертыванию, которое использует Remote Credential Guard с несколькими брокерами подключений к удаленному рабочему столу

Эта проблема возникает в развертываниях с высоким уровнем доступности, в которых используются не менее двух брокеров подключений к удаленному рабочему столу и Remote Credential Guard в Защитнике Windows. Пользователям не удается войти на удаленные рабочие столы.

Эта проблема связана с тем, что Remote Credential Guard использует Kerberos для проверки подлинности, а также запрещает использовать NTLM. Но в конфигурации с высоким уровнем доступности и балансировкой нагрузки брокеры подключений к удаленному рабочему столу не могут поддерживать операции Kerberos.

Если нужно использовать конфигурации с высоким уровнем доступности и балансировкой нагрузки брокеров подключений к удаленному рабочему столу, эту проблему можно устранить, отключив Remote Credential Guard. Дополнительные сведения об управлении Remote Credential Guard в Защитнике Windows см. в статье (Защита учетных данных удаленного рабочего стола с помощью Remote Credential Guard в Защитнике Windows).

Расположение веб-сервера IIS и рабочих серверов 1С на разных машинах

В некоторых случаях, несмотря на корректно указанного пользователя операционной системы в пользователе информационной базы, при попытке входа в опубликованную базу через браузер аутентификация операционной системы не проходит. Такая ситуация может возникать, если веб-сервер IIS и сервер 1с находятся на разных машинах. В таком случае в технологическом журнале рабочего процесса можно наблюдать следующую картину:

56:39.487001-0,CONN,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Txt=Srvr: SrcUserName1: winserver1c$@DOMAIN701.COM56:39.487002-0,CONN,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Txt=Srvr: DstUserName1: testuser2@DOMAIN701.COM(DOMAIN701.COM\testuser2)56:39.596004-0,CONN,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Txt=Srvr: DstUserName2: NT AUTHORITY\ANONYMOUS LOGON(NT AUTHORITY\ANONYMOUS LOGON)56:39.659003-0,EXCP,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Exception=a01f465c-ed70-442e-ada5-847668d7a41c,Descr=’src\VResourceInfoBaseServerImpl.cpp(991):a01f465c-ed70-442e-ada5-847668d7a41c: Идентификация пользователя не выполненаНеправильное имя или пароль пользователя’

При возникновении такой ситуации необходимо проверить следующие настройки:

1) Убедиться, что процессы сервера 1С запущены от имени доменной учетной записи, входящей в группу Domain Users.

2) Убедиться, что веб-сервер IIS настроен корректно.

В публикации информационной базы найти настройки аутентификации

В настройках аутентификации отключить анонимную аутентификацию и включить Windows-аутентификацию. В Windows-аутентификации упорядочить доступных провайдеров так, чтобы на первом месте был Negotiate.

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

После изменения настроек перезапустить веб-сервер с помощью команды iisreset в командной строке.

3) Убедиться, что в контроллере домена в свойствах компьютера, на котором запущен веб-сервер, на вкладке делегирование установлено «Доверять компьютеру делегирование любых служб (только Kerberos)»

Для этого откройте оснастку Active Directory Users and Computers (dsa.msc), в компьютерах найдите веб-сервер, перейдите в его свойства и на вкладке Делегирование установить значение «Доверять компьютеру делегирование любых служб (только Kerberos)» и нажать применить.

4) Убедиться, что на клиенте в свойствах обозревателя разрешена встроенная проверка подлинности Windows.

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

Важно: аутентификации Windows при расположении веб-сервера IIS и рабочих серверов на разных машинах в тонком клиенте работает, начиная с версии 8.3.10.2620 (для тестирования)

Вопросы безопасности

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

Уязвимость

Если установлено, что протокол проверки подлинности NTLM не должен использоваться в домене, так как для этого требуется использовать более безопасный протокол, например Kerberos, в домене может присутствовать трафик проверки подлинности NTLM. Если это так, и вы задаете сетевой безопасности: сетевой безопасности: Ограничение проверки подлинности NTLM: NTLM в этом домене для любого из вариантов отказа, любой запрос на проверку подлинности NTLM не удастся, так как проходной сервер-член будет блокировать запрос NTLM.

Если вы определите список исключений серверов в этом домене, на которые клиентские компьютеры могут использовать сквозную проверку подлинности NTLM, то трафик проверки подлинности NTLM будет продолжать поступать между этими серверами, что делает их уязвимыми к любой вредоносной атаке, которая использует слабые стороны безопасности в NTLM.

Противодействие

При использовании сетевой безопасности: Ограничение проверки подлинности NTLM: проверка подлинности NTLM в этом домене в режиме только аудита, вы можете определить, какие клиентские приложения делают запросы на проверку подлинности NTLM на сквозные серверы проверки подлинности. При оценке необходимо будет в индивидуальном порядке определить, соответствует ли проверка подлинности NTLM минимальным требованиям безопасности.

Возможное влияние

Определение списка серверов для этого параметра политики позволит обеспечить трафик проверки подлинности NTLM между этими серверами, что может привести к уязвимости безопасности.

Если этот список не определен, и служба сетевой безопасности: ограничение NTLM: проверка подлинности NTLM в этом домене включена, проверка подлинности NTLM не пройдет на этих проходных серверах в домене, который они ранее использовали.

Преобразования утверждений

При размещении с IIS AuthenticateAsync не вызывается внутренне для инициализации пользователя. Таким образом, реализация IClaimsTransformation, используемая для преобразования утверждений после каждой проверки подлинности, не активируется по умолчанию. Дополнительные сведения и пример кода, который активирует преобразования утверждений, см. в разделе .

При размещении в режиме обработки IIS AuthenticateAsync не вызывается внутренним образом для инициализации пользователя. Таким образом, реализация IClaimsTransformation, используемая для преобразования утверждений после каждой проверки подлинности, не активируется по умолчанию. Дополнительные сведения и пример кода, который активирует преобразования утверждений при размещении внутри процесса, см. в разделе .

Статистика пользователей

Остался последний этап — отображать красивую статистику посещений сайтов пользователями. Самый простой и красивый инструмент для этого — LightSquid.

Настраиваем Apache

Приводим файл /etc/apache2/conf-available/lightsquid.conf в такой вид (доступ на просмотр даем всем):

Alias   /lightsquid/    /usr/lib/cgi-bin/lightsquid/

<Location "/lightsquid/">
        Options +ExecCGI
        Require local
        Require ip 192.168.1.0/24
</Location>

Раскомментируем строку 219 в файле /etc/apache2/mods-enabled/mime.conf

AddHandler cgi-script .cgi .pl

Запускаем все это дело:

# a2enmod cgi
# a2enconf lightsquid
# service apache2 restart

Настраиваем LightSquid

Очень хочется чтобы в отчете фигурировало полное ФИО пользователя, а не доменное имя или IP-адрес. Для этого нужно заменить оригинальный файл /usr/share/lightsquid/ip2name/ip2name.squidauth следующим:

#contributor: esl
#specialy for squid with turned on user authentication
#simple version

use strict;
use warnings;
use Net::LDAP;
use Encode;

my $ldap;
my $message;
my %hDisplayName;

sub StartIp2Name() {
        my $server = "ldap://dc.mydomain.ru";
        $ldap = Net::LDAP->new( $server );
        return if(!defined $ldap);
        $message = $ldap->bind(q(MYDOMAIN.RU\LightSquid), password => "PASSWORD");
}

sub Ip2Name($$$) {
  # $Lhost,$user,$Ltimestamp
  my $Lhost=shift;
  my $user =shift;
  $user    =URLDecode($user); #decode user name
  return $Lhost if ($user eq "-");
  return $user if (!defined $ldap);
  return $user if ($message->code());

  if (!defined $hDisplayName{$user})
  {
    my $result = $ldap->search(
    base        => "dc=MYDOMAIN,dc=RU",
    filter      => "(&(objectCategory=person)(objectClass=user)(sAMAccountName=" . $user . "))",
    );

my $first_entry = $result->entry(0);
if (!defined $first_entry)
  {
    return $Lhost;
  }

my $pure_displayName = $first_entry->get_value("displayName");
$pure_displayName =~ s/ /_/g;
Encode::from_to($pure_displayName, 'utf-8', 'windows-1251');

  $hDisplayName{$user}=$pure_displayName;
  }

  return $hDisplayName{$user};
}

sub StopIp2Name() {
        return if (!defined $ldap);
        $message = $ldap->unbind;
}

#warning !!!
1;

В этом файле исправляем нижеуказанные строки на свои:

...
        my $server = "ldap://dc.mydomain.ru";
...
        $message = $ldap->bind(q(MYDOMAIN.RU\LightSquid), password => "PASSWORD");
...
    base        => "dc=MYDOMAIN,dc=RU",
...

Теперь в /etc/lightsquid/lightsquid.cfg включаем преобразование логина в ФИО:

$ip2name="squidauth"

Запускаем /usr/share/lightsquid/check-setup.pl и если все хорошо, можно запускать /usr/share/lightsquid/lightparser.pl

В папке /var/lib/lightsquid/report должны появиться отчеты, которые можно поглядеть по адресу: http://192.168.1.1/lightsquid/

Ссылки [ править ]

^ , Спецификация протокола аутентификации NT LAN Manager (NTLM) , Microsoft , получено 15 августа 2010 г.
^ , Спецификация протокола аутентификации NT LAN Manager (NTLM) , Microsoft , получено 15 августа 2010 г.
^ Takahashi, T ( декабря 2009 г.), , блог FrequencyX , IBM Internet System Security (ISS), заархивировано из 31 декабря 2009 г. , извлечено 14 августа 2010 г.
, MSDN , Microsoft , получено 15 августа 2010 г.
, Спецификация протокола аутентификации NT LAN Manager (NTLM) , Microsoft , получено 15 августа 2010 г.
, NT LAN Manager (NTLM) Authentication Protocol Specification (3.1.5.1 ed.), Microsoft , получено 15 августа 2010 г.
, NT LAN Manager (NTLM) Authentication Protocol Specification (3.1.5.2 ed.), Microsoft , получено 15 августа 2010 г.
, NT LAN Manager (NTLM) Authentication Protocol Specification (2.2.1.1 ed.), Microsoft , получено 15 августа 2010 г.
, NT LAN Manager (NTLM) Authentication Protocol Specification (2.2.1.2 ed.), Microsoft , получено 15 августа 2010 г.
, NT LAN Manager (NTLM) Authentication Protocol Specification (2.2.1.3 ed.), Microsoft , получено 15 августа 2010 г.
^ , NT LAN Manager (NTLM) Authentication Protocol Specification (3.3.1 ed.), Microsoft , получено 15 августа 2010 г.
, NT LAN Manager (NTLM) Authentication Protocol Specification (3.3.1 ed.), Microsoft , получено 15 августа 2010 г.
, Поддержка, Microsoft, 25 января 2007 г. , получено 14 августа 2010 г.
^ , Руководство по усилению безопасности Microsoft Windows 2000 , TechNet, Microsoft , получено 14 августа 2010 г.
Гласс, Эрик, «NTLM», , Source forge
Варугезе, Сэм (февраль 2006 г.). . Палисад. Архивировано из на 2010-06-01 . Проверено 14 августа 2010 .
, Спецификация протокола аутентификации NT LAN Manager (NTLM) , Microsoft , получено 16 августа 2010 г.
. Архивировано из на 2014-10-06 . Проверено 5 октября 2014 .
. Библиотека TechNet . Microsoft . Проверено 2 ноября 2015 года .
. Библиотека TechNet . Microsoft . Проверено 2 ноября 2015 года .
. Библиотека MSDN . Microsoft . Проверено 2 ноября 2015 года .
. Библиотека TechNet . Microsoft. 29 июня 2011 . Проверено 2 ноября 2015 года .
Джеспер Йоханссон. . Журнал TechNet . Microsoft . Проверено 2 ноября 2015 года .
HD Мур. .
Курт Грюцмахер (2008-08-08). . Дефкон 16.
Эрнана Очоа и Агустин Azubel (2010-07-28). . Blackhat USA 2010.
Эрнан Очоа и Агустин Азубель. .
Гудин, Дэн (2012-12-10). . Ars Technica . Проверено 23 ноября 2020 .
Claburn, Томас (14 февраля 2019). . www.theregister.co.uk . Проверено 26 ноября 2020 .
hashcat (13.02.2019). . @hashcat . Проверено 26 февраля 2019 .
. Mail-archive.com . Проверено 2 декабря 2018 .

На закуску несколько идей и фактов

При осутствии интеграции с docker патчинг можно запускать как postbuild target.
Существуют NTLM-прокси, например, CNTLM. Альтернативный путь с настройкой NTLM-прокси внутри контейнера также имеет перспективы и более универсален, а готовый настроенный образ будет достоен выкладки на Docker Hub.
Гипотетически можно попробовать править хедер авторизации WWW-Authentication, который приходит от WCF-сервиса. Нужно переопределить поведение WCF-клиента через IEndpointBehavior и метод AfterReceiveReply. Однако, это сработает только в случае, если preauthentication запрос выключен, т.к. AfterReceiveReply его не поймает.
Если вы используете/имеете доступ к HttpClient, то вот на workaround для похожей проблемы с NTLM.
Пропатчить CurlHandler при помощи Сecil не получится: System.Net.Http.dll — это mixed mode assembly (т.е. либа с managed и native кодом), и такой вариант в Cecil пока что не поддерживается.
Подмена указателя на метод в рантайме, описанная в статье, не работает, не пытайтесь.
Под линуксом в .NET Core нет поддержки function breakpoints.

Основные особенности

Одна из основных целей NT — аппаратная и программная переносимость. Были выпущены различные версии операционных систем семейства NT для различных архитектур процессоров, первоначально IA-32 , MIPS и DEC Alpha , с поддержкой PowerPC , Itanium , x86-64 и ARM в более поздних версиях. Первоначальная идея заключалась в том, чтобы иметь общую кодовую базу с настраиваемым уровнем аппаратной абстракции (HAL) для каждой платформы. Однако позже в Windows 2000 поддержка MIPS, Alpha и PowerPC была прекращена . Первоначально широкая совместимость программного обеспечения была достигнута за счет поддержки нескольких «личностей» API , включая Windows API , POSIX и OS / 2 API — последние два были прекращены, начиная с Windows XP. Частичная совместимость MS-DOS и Windows с 16-разрядной версией достигается на IA-32 через интегрированную виртуальную машину DOS, хотя эта функция недоступна на других архитектурах.

NT поддерживает списки управления доступом для каждого объекта (файла, функции и роли), что позволяет применять широкий набор разрешений безопасности к системам и службам. NT также поддерживает сетевые протоколы Windows, наследуя предыдущую сеть OS / 2 LAN Manager , а также сеть TCP / IP (для которой Microsoft использовала стек TCP / IP, полученный сначала из стека на основе STREAMS от Spider Systems , затем позже переписан собственными силами).

Windows NT 3.1 была первой версией Windows, в которой использовалась 32-разрядная адресация плоской виртуальной памяти на 32-разрядных процессорах. Его сопутствующий продукт, Windows 3.1, использует сегментированную адресацию и переключается с 16-битной на 32-битную адресацию на страницах.

В Windows NT 3.1 было основное ядро, обеспечивающее системный API, работающее в режиме супервизора (кольцо 0 в x86; в Windows NT называемое «режимом ядра» на всех платформах), и набор сред пользовательского пространства с собственными API, которые включала новую среду Win32, среду текстового режима OS / 2 1.3 и среду POSIX. Полное вытесняющее многозадачное ядро могло прерывать выполнение задач для планирования других задач, не полагаясь на то, что пользовательские программы добровольно откажутся от управления процессором, как в приложениях Windows 3.1 Windows (хотя приложения MS-DOS были вытеснительно многозадачными в Windows, начиная с ).

Примечательно, что в Windows NT 3.x несколько подсистем драйверов ввода-вывода, такие как видео и печать, были подсистемами пользовательского режима . В Windows NT 4 подсистемы диспетчера очереди видео, сервера и принтера были переведены в режим ядра. На первый графический интерфейс Windows NT сильно повлиял (и был программно совместим с ним) графический интерфейс Windows 3.1; Интерфейс Windows NT 4 был переработан, чтобы соответствовать интерфейсу новой Windows 95 , с переходом от диспетчера программ к дизайну оболочки Windows .

NTFS , журналируемая, безопасная файловая система, является основной функцией NT. Windows NT также позволяет использовать другие устанавливаемые файловые системы; начиная с версии 3.1 NT может быть установлена в файловых системах FAT или HPFS .

Windows NT представила свою собственную модель драйвера, модель драйвера Windows NT, и несовместима со старыми структурами драйверов. В Windows 2000 модель драйвера Windows NT была расширена до модели драйвера Windows , которая была впервые представлена в Windows 98 , но была основана на модели драйвера NT. В Windows Vista добавлена встроенная поддержка Windows Driver Foundation , которая также доступна для Windows XP , Windows Server 2003 и, в некоторой степени, Windows 2000 .

Что такое CBT (маркер привязки канала)?

Маркер привязки канала (CBT) является частью расширенной защиты для проверки подлинности. CBT — это механизм привязки внешнего защищенного канала TLS к внутренней проверке подлинности канала, например Kerberos или NTLM.

CBT — это свойство внешнего безопасного канала, используемого для привязки проверки подлинности к каналу.

Расширенная защита выполняется клиентом, который сообщает с помощью SPN и CBT на сервере с помощью защиты от взлома. Сервер проверяет расширенные сведения о защите в соответствии со своей политикой и отклоняет попытки проверки подлинности, для которых он не считает себя целевой целью. Таким образом, два канала становятся криптографически связаны друг с другом.

Расширенная защита теперь поддерживается в Windows XP, Windows Vista, Windows Server 2003 и Windows Server 2008.

Бонус-трек

Мы не остановились на достигнутом. Если внимательно посмотреть на логи, то видно, что один WCF запрос-ответ включает в себя несколько запросов-ответов HTTP, и один из ответов стабильно возвращается с . В чем дело?

Для ошибочного запроса используется метод . И действительно, такое же поведение легко эмулируется с . В libcurl это соответствует опции . В corefx эта опция используется при отправке реквестов.
Поднимаемся по стеку выше в WCF. Видим, что в методе отправляется для авторизации, а все ошибки просто игнорируются:

Здесь явно напрашивается флаг, подобный , чтобы не запускать запрос, заранее обреченный на 400.

Раз уж о нас не позаботились, значит, будем резать.

Метод асинхронный, поэтому его патчинг может привести к красноглазию в слишком раннем возрасте. Если оглядеться по сторонам, то можно заметить простой и неприхотливый . Очевидно, если он будет возвращать всегда false, то и не будет запускаться .

Приступаем к операции.

Добавляем в решение новый проект WcfPreauthPatch. Теперь ставим Cecil, при помощи которого полезем в IL-код. Нужна бета-версия, чтобы работало под .NET Core.

Код такой:

В Dockerfile допишем

Запускаем сервис и убеждаемся, что в логах одним запросом стало меньше.