Какой протокол windows наиболее защищен от подбора

1.4.7 Защита Windows nt и Unix от подбора паролей

Одна из главных задач системного администратора Windows NT состоит в защите от несанкционированного доступа той информации, которая хранится в базе данных SAM. С этой целью ему, прежде всего, необходимо ограничить физический доступ к компьютерам сети и прежде всего — к контроллерам доменов. Дополнительно, при наличии соответствующих программно-аппаратных средств, следует установить пароли BIOS на включение компьютеров и на изменение настроек BIOS. Затем, используя настройки BIOS, рекомендуется отключить загрузку компьютеров с гибких и компакт-дисков. А для обеспечения контроля доступа к файлам и папкам операционной системы Windows NT системный раздел жесткою диска должен иметь формат NTFS.

Каталог \winnt_root\repair нужно средствами операционной системы закрыть для доступа всех пользователей, включая администраторов, и разрешать к ней доступ только во время работы утилиты RDISK, создающей в этом каталоге архивные копии системного реестра Windows NT. Системные администраторы также должны внимательно следить за тем, где и как хранятся дискеты аварийного восстановления (Emergency Repair Disks) и архивные копии на магнитных лентах, если на последних присутствует дубликат системного реестра Windows NT.

Если компьютер с операционной системой Windows NT входит в домен, то по умолчанию имена и хэшированные пароли последних 10-ти пользователей, регистрировавшихся на этом компьютере, сохраняются (кэшируются) в его локальном системном реестре (в разделе SECURITY\Policy\Secrets куста HKEY LOCAL_MACHINE). Чтобы отменить кэширование паролей на компьютерах домена, нужно с помощью утилиты REGEDT32 в раздел Micro-soft\WindowsNT\CurrentVersion\Winlogon раздела HKEY_LOCAL MACHINE добавить параметр CashedLogonsCount, установив его значение равным нулю, а тип — REG_SZ.

Для защиты базы данных SAM можно применить утилиту SYSKEY, входящую в состав пакета обновления Windows NT Service Pack 3. Эта утилита позволяет включить режим дополнительного шифрования информации о паролях, которая хранится в базе данных SAM. Уникальный 128-битовый ключ для дополнительного шифрования паролей (так называемый ключ шифрования паролей — Password Encryption Key, РЕК) автоматически сохраняется в системном реестре для дальнейшего использования [56].

Перед помещением в системный реестр ключ РЕК шифруется при помощи другого 128-битового ключа, который называется системным ключом (System Key), и может храниться либо в системном реестре, либо в файле с именем STARTUP.KEY в корневом каталоге на отдельной дискете. Можно не сохранять системный ключ на магнитном носителе, и тогда каждый раз при запуске операционной системы он будет вычисляться с помощью алгоритма MD5 на основе пароля, набираемого на клавиатуре в диалоговом окне утилиты SYSKEY. Последние два способа хранения системного ключа обеспечивают максимальную защиту паролей в базе данных SAM, однако приводят к невозможности автоматической перезагрузки операционной системы, поскольку для завершения процесса перезагрузки потребуется либо вставить дискету с системным ключом и подтвердить ее наличие в дисководе путем нажатия кнопки ОК в появившемся диалоговом окне, либо вручную ввести системный ключ с клавиатуры.

Для повышения стойкости паролей пользователей операционной системы Windows NT к взлому рекомендуется с помощью утилиты Диспетчер пользователей (User Manager) задать минимальную длину пользовательских паролей равной не менее 8 символов и включить режим устаревания паролей, чтобы пользователи периодически их обновляли. Чем выше вероятность атак на парольную защиту Windows NT, тем короче должен быть срок такого устаревания. А чтобы пользователи не вводили свои старые пароли повторно, необходимо включить режим хранения некоторого числа ранее использовавшихся паролей.

Утилита PASSPROP из состава Windows NT Resource Kit, запущенная с ключом /COMPLEX, заставляет пользователей вводить более устойчивые пароли, которые или сочетают буквы в разном регистре, или буквы с цифрами, или буквы со специальными символами. Более строгие правила фильтрации нестойких паролей можно задать после установки любого из пакетов обновления Windows NT, начиная с Service Pack 2. Тогда специальная библиотека PASSFJLT.DLL, находящаяся в каталоге \winnt_root\System32, будет следить за тем, чтобы каждый пользовательский пароль состоял не менее чем из 5 символов, не содержал имени пользователя, включал символы, по крайней мере, трех наборов из четырех возможных, составленных из прописных букв, строчных букв, цифр и специальных символов (знаков препинания и т. д.) соответственно. Чтобы задать такой режим проверки паролей пользователей, необходимо в раздел HKEY_LOCAL_MACHINE\SYSTEM\CurrentControISet\Control\Lsa системного реестра с помощью программы REGEDT32 добавить параметр Noti fi cation Packages типа REG_MULTI_SZ и вписать в него строку PASSFILT. Если этот параметр уже имеется, то новую строку следует дописать после уже существующей.

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

Для противодействия атаки типа подбора паролей, в ОС UNIX введен механизм так называемого «затенения» (shadowing) файла паролей — он перемещается в другое место и становится недоступным обычным пользователям по чтению. Но это не сильно эффективное средство, что связано с идеологией UNIX, и вызов функции getpwent() иногда позволяет получить пароли пользователей в классическом виде. Также, иногда функция crypt() заменяется на другую (еще более медленную) хэш-функцию, и запуск старых программ-вскрывателей ни к чему не приводит. Обычно это алгоритм MD5, скорость которого в 50 раз меньше, чем crypt().

2 Атаки реализующие сканирование портов

2.1 Особенности протоколов, используемых при

сканировании портов

2.1.1 Протокол UDP

UDP (User Datagram Protocol, стандарт RFC-768) фактически не выполняет каких-либо особых функций дополнительно к функциям сетевого уровня (протокола IP), кроме (де)мультиплексирования пакетов с прикладными данными — то есть направления данных тому или иному приложению в зависимости от номера порта. Протокол UDP используется либо при пересылке коротких сообщений, когда накладные расходы на установление сеанса и проверку успешной доставки данных оказываются выше расходов на повторную (в случае неудачи) пересылку сообщения, либо в том случае, когда сама организация процесса-приложения обеспечивает установление соединения и проверку доставки пакетов (например, NFS) [30].

Пользовательские данные, поступившие от прикладного уровня, предваряются UDP-заголовком, и сформированное таким образом сообщение UDP отправляется на уровень IP. Получившаяся IР-датаграмма имеет структуру, показанную на рисунке 2.1.

NTLM и корпоративные сети

То, что в последние годы проблемы безопасности протокола 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 на выходе).

Какой протокол windows наиболее защищен от подбора

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

Для начала внесем ясность в термины. Многие путают понятия аутентификации и авторизации, хотя это различные процедуры.

Аутентификация — происходит от английского слова authentication, которое можно перевести как идентификация или проверка подлинности. Это полностью отражает суть процесса — проверка подлинности пользователя, т.е. мы должны удостовериться, что пользователь, пытающийся получить доступ к системе именно тот, за кого себя выдает.
Авторизация — перевод слова authorization означает разрешение, т.е. проверка прав доступа к какому-либо объекту. Процесс авторизации может быть применен только к аутентифицированному пользователю, так как перед тем, как проверять права доступа, мы должны выяснить личность объекта, которому мы собираемся предоставить какие-либо права.

Чтобы проще представить себе этот процесс проведем простую аналогию. Вы находитесь за границей и вас останавливает полицейский, вы предъявляете свой паспорт. Полицейский проверяет данные в паспорте и сверяет фотографию — это процесс аутентификации. Убедившись, что вы это вы, полицейский просит показать визу — это процесс авторизации, т.е. вашего права здесь находиться.

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

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

Локальная аутентификация

Прежде всего начнем с локальной аутентификации, когда пользователь хочет войти непосредственно на рабочую станцию, не входящую в домен. Что происходит после того, как пользователь ввел свой логин и пароль? Сразу после этого введенные данные передаются подсистеме локальной безопасности (LSA), которая сразу преобразует пароль в хэш, хэширование — это одностороннее криптографическое преобразование, делающее восстановление исходной последовательности невозможным. В открытом виде пароль нигде в системе не хранится и не фигурирует, пользователь — единственный кто его знает.

Затем служба LSA обращается к диспетчеру учетных записей безопасности (SAM) и сообщает ему имя пользователя. Диспетчер обращается в базу SAM и извлекает оттуда хэш пароля указанного пользователя, сгенерированный при создании учетной записи (или в процессе смены пароля).

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

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

LAN Manager (LM)

Протокол LAN Manager возник на заре зарождения локальных сетей под управлением Windows и впервые был представлен в Windows 3.11 для рабочих групп, откуда перекочевал в семейство Windows 9.х. Мы не будем рассматривать этот протокол, так как в естественной среде он уже давно не встречается, однако его поддержка, в целях совместимости, присутствует до сих пор. И если современной системе поступит запрос на аутентификацию по протоколу LM, то, при наличии соответствующих разрешений, он будет обработан.

Что в этом плохого? Попробуем разобраться. Прежде всего разберемся, каким образом создается хэш пароля для работы с протоколом LM, не вдаваясь в подробности обратим ваше внимание на основные ограничения:

Пароль регистронезависимый и приводится к верхнему регистру.
Длина пароля — 14 символов, более короткие пароли дополняются при создании хэша нулями.
Пароль делится пополам и для каждой части создается свой хэш по алгоритму DES.

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

А теперь самое интересное, LM-хэш, в целях совместимости, создается при вводе пароля и хранится в системах по Windows XP включительно. Это делает возможной атаку, когда системе целенаправленно присылают LM-запрос и она его обрабатывает. Избежать создания LM-хэша можно изменив политику безопасности или используя пароли длиннее 14 символов. В системах, начиная с Windows Vista и Server 2008, LM-хэш по умолчанию не создается.

NT LAN Manager (NTLM)

Новый протокол аутентификации появился в Windows NT и благополучно, с некоторыми изменениями, дожил до наших дней. А до появления Kerberos в Windows 2000 был единственным протоколом аутентификации в домене NT.

Сегодня протокол NTLM, точнее его более современная версия NTLMv2, применяются для аутентификации компьютеров рабочих групп, в доменных сетях Active Directory по умолчанию применяется Kerberos, однако если одна из сторон не может применить этот протокол, то по согласованию могут быть использованы NTLMv2, NTLM и даже LM.

Принцип работы NTLM имеет много общего с LM и эти протоколы обратно совместимы, но есть и существенные отличия. NT-хэш формируется на основе пароля длиной до 128 символов по алгоритму MD4, пароль регистрозависимый и может содержать не только ACSII символы, но и Unicode, что существенно повышает его стойкость по сравнению с LM.

Как происходит работа по протоколу NTLM? Рассмотрим следующую схему:

Допустим локальный компьютер хочет получить доступ к некоторому файловому ресурсу на другом ПК, который мы будем считать сервером, при этом совсем не обязательно наличие на этом ПК северной ОС или серверных ролей. С точки зрения протокола NTLM клиент это тот, кто обращается, сервер — к кому обращаются.

Чтобы получить доступ к ресурсу клиент направляет серверу запрос с именем пользователя. В ответ сервер передает ему случайное число, называемое запросом сервера. Клиент в свою очередь шифрует данный запрос по алгоритму DES, используя в качестве ключа NT-хэш пароля, однако, несмотря на то, что NT-хэш 128-битный, в силу технических ограничений используется 40 или 56 битный ключ (хеш делится на три части и каждая часть шифрует запрос сервера отдельно).

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

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

В случае получения доступа к третьим ресурсам схема также немного изменяется:

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

Как видим, хэш пароля ни при каких обстоятельствах по сети не передается. Хэш введенного пароля хранит служба LSA, хэши паролей пользователей хранятся либо в локальных хранилищах SAM, либо в хранилищах контроллера домена.

Но несмотря на это, протокол NTLM на сегодняшний день считаться защищенным не может. Слабое шифрование делает возможным достаточно быстро восстановить хэш пароля, а если использовался не только NTLM, а еще и LM-ответ, то и восстановить пароль.

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

NTLMv2

Осознавая, что протокол NTLM не соответствует современным требованиям безопасности, с выходом Windows 2000 Microsoft представила вторую версию протокола NTLMv2, который был серьезно доработан в плане улучшений криптографической стойкости и противодействия распространенным типам атак. Начиная с Windows 7 / Server 2008 R2 использование протоколов NTLM и LM по умолчанию выключено.

Сразу рассмотрим схему с контроллером домена, в случае его отсутствия схема взаимодействия не меняется, только вычисления, производимые контроллером домена, выполняются непосредственно на сервере.

Как и в NTLM, клиент при обращении к серверу сообщает ему имя пользователя и имя домена, в ответ сервер передает ему случайное число — запрос сервера. В ответ клиент генерирует также случайное число, куда, кроме прочего, добавляется метка времени, которое называется запрос клиента. Наличие метки времени позволяет избежать ситуации, когда атакующий первоначально накапливает перехваченные данные, а потом с их помощью осуществляет атаку.

Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш. После чего от данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу.

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

Сервер, получив NTLMv2-ответ и запрос клиента, объединяет последний с запросом сервера и также вычисляет HMAC-MD5 хэш, затем передает его вместе с ответом контроллеру домена. Тот извлекает из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом. В случае совпадения серверу возвращается ответ об успешной аутентификации.

При этом, как вы могли заметить, NTLMv2, также, как и его предшественник, не осуществляет взаимную проверку подлинности, хотя в некоторых материалах в сети это указывается.

Настройки безопасности

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

За выбор протокола аутентификации отвечает локальная или групповая политика. Откроем редактор политик и перейдем в Конфигурация компьютера — Конфигурация Windows — Политики безопасности — Локальные политики — Параметры безопасности, в этом разделе найдем политику Сетевая безопасность: уровень проверки подлинности LAN Manager.

В этом же разделе находится политика Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля, которая запрещает создание LM-хэша, по умолчанию активна начиная с Vista / Server 2008.

В нашей же политике мы видим широкий выбор значений, очевидно, что сегодня безопасными могут считаться политики начиная с Отправлять только NTLMv2-ответ и ниже по списку.

Эти же значения можно задать через реестр, что удобно в сетях уровня рабочей группы, для этого в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa нужно создать параметр DWORD с именем LmCompatibilityLevel, который может принимать значения от 0 до 5. Рассмотрим их подробнее:

Наименование настройки	Клиентский компьютер	Контроллер домена	Lm Compatibility Level
Отправлять LM- и NTLM-ответы	Клиентские компьютеры используют LM и NTLM аутентификацию , и никогда не используют сеансовую безопасность NTLMv2.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	0
Отправлять LM- и NTLM- использовать сеансовую безопасность NTLMv2	Клиентские компьютеры используют LM и NTLM аутентификацию, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	1
Отправлять только NTLM-ответ	Клиентские компьютеры используют проверку подлинности NTLMv1, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	2
Отправлять только NTLMv2-ответ	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	3
Отправлять только NTLMv2-ответ. Отказывать LM.	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена отказываются принимать аутентификацию LM, и будут принимать только NTLM и NTLMv2.	4
Отправлять только NTLMv2-ответ. Отказывать LM и NTLM.	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена отказываются принимать аутентификацию LM и NTLM, и будут принимать только NTLMv2.	5

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

После того, как клиент пройдет аутентификацию формируется ключ сеанса, который используется для подтверждения подлинности при дальнейшем взаимодействии. Ключ сеанса NTLM основан только на NT-хэше и будет одинаковым до тех пор, пока клиент не поменяет пароль пользователя. Какие угрозы безопасности это несет пояснять, нам кажется, не надо. Сеансовая безопасность NTLMv2 подразумевает вычисление ключа сеанса с использованием не только NT-хэша, но и запросов сервера и клиента, что делает ключ уникальным и гораздо более стойким к возможным атакам. При этом данная возможность может быть использована совместно с NTLM или LM аутентификацией.

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

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Старые протоколы Windows: как с ними бороться

Microsoft давно уже отошла от слабой защиты
паролей и сейчас системы компании взломать
не так то и просто. С подключением новых
протоколов аутентификации типа NTLMv2 или
Kerberos, Microsoft вполне обезопасила вашу сеть.
Проблема в использовании ОС MS на самом деле
состоит в том, что им по наследству
достались и старые уязвимые протоколы типа
Lan Manager или NT Lan Manager. И даже если они не
используются в работе они по прежнему
доступны и на большинстве систем хешируют
пароли, просто на случай соединения со
старым компьютеров. Это открывает
определенную брешь в обороне вашего
компьютера и в этой статье мы покажем как ее
закрыть.

Microsoft поддерживает целый сонм протоколов
аутентификации. Как уже было сказано,
старые реализации никуда не деваются, а
сохраняются ради совместимости. Так,
например, Windows Server 2003 может работать как с
протоколом Lаn Mаnager и NTLM, так и с современным
Kerberos. В проектировании сети важно понять
что делает каждый из протоколов и какими
особенностями он выделяется. Необходимо
так же знать какие операционные системы
какие протоколы юзают, ведь даже если
протокол и слаб в своей основе, возможно он
необходим для работы с другими
компьютерами, существующими в окружении. Ну
и напоследок, если необходимость
использования слабого протокола все же
существует то необходимо продумать меры
навесной защиты.

Lan Manager

LM один из самых старых протоколов
аутентификации, используемых Microsoft. Впервые
он появился еще в Windows 3.11 и в целом не
слишком безопасен. Посмотрим описание:

Хеши зависят от регистра
В пароле можно использовать 142 символами
Хеш разделяется на последовательности в
2-7 символов. Если пароль короче 14 символов,
то он дополняется нулями до 14 знаков
Результирующее значение — 128 битное
Хеш необратим

NT Lan Manager

NTLM стал последователем LM и впервые был
представлен в Windows NT 3.1. Причина его
появление — внедрение новой системы
каталогов в операционной системе,
контролируемой всем известными доменами.
NTLM требует, что бы domain controller хранил хеши
всех пользователей самого домена.
Особенности этого протокола похожи на LM,
только реализованы несколько иначе.

Стоит отметить, что этот протокол не был
выпущен одновременно с какой либо ОС, а
появился в 4-ом сервиспаке для Windows NT 4. В нем
Microsoft попыталась все ошибки предыдущих
протоколов и выглядит он так:

Пароль может быть до 128 символов
Взаимная аутентификация клиента и
сервера
Более длинные ключи для улучшенной
защиты хеша

Это уже не разработка MS, а индустриальный
стандарт, описанный в RFC 1510. Microsoft добавила в
него несколько незначительных фишек и
начала использовать в Windows. В Active Directory
протокол выглядит так:

Взаимная аутентификация с
использованием билетов
Процесс опознавания в основном ложится
на плечи клиента, что уменьшает нагрузку
на сервер
Контролер домена несет на себе Kerberos
Distribution Center
Пароли не передаются по сети
Kerberos защищен от перехвата пакетов

Windows 95, 98 и Me по умолчанию не поддерживают
NTLMv2 и Kerberos, а соответственно работают
только с LM или NTLM. Это ставит их в разряд
самых уязвимых систем, однако и тут конечно
есть решение. Называется оно Active
Directory Client Extensions, что позволит
использовать NTLMv2, Kerberos же использовать в
семействе 9х никак не получится.

Как уже было сказано ранее, изначально ОС
этого семейства работали так же ,как и 9х.
Однако в SP4 появился NTLMv2.

Ясно, что эти системы уже работают со
всеми четырьмя протоколами — LM, NTLM, NTLMv2 и
Kerberos. При работе с AD и компьютерами,
входящими в AD, используется Kerberos. В рабочих
группах в ход вступает NTLMv2, ну а для работы с
устаревшими операционками уже
используется LM и NTLM.

Борьба со стариной

Если вы еще не поняли, то все компьютеры в
вашей Windows-сети поддерживают эти два
устаревших протокола. Что можно с ними
сделать?

1. По умолчанию LM и NTLM хеши посылаются по
сети в процессе аутентификации, причем это
случается даже когда ХР коннектится,
например, к домену на Windows 2003. Для выключения
лезем в Group Policy Object и запрещаем передачу
хешей по сети:

В политике возможен выбор из 6 вариантов:

Самый безопасный вариант — последний.

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

Немедленного эффекта эта опция не даст,
она сработает только при изменении пароля.

3. Если все же в вашей сети есть устройства
или компьютеры работающие с LM можно обойти
хранение хеша применением пароля длиннее 14
символов. В таком варианте хеш не
сохраняется.

Совсем запретить использование протокола
пока невозможно, так как он используется
для работы групп в Windows 2000 и более новых
операционных системах. Однако, как обычно,
возможно предпринять ряд шагов для защиты
от взлома хешей.

1. Чем длиннее и сложнее пароль тем лучше,
правило по умолчанию.

2. Надо заставить пользователей чаще
менять пароли:

3. Предложите использовать фразы вместо
пароля. Согласитесь, что запомнить @3*()!b&
труднее, чем «Я живу в Москве». К тому же
использование фраз обезопасит от перебора,
ибо брутфорсом в приемлемые сроки никакой
пароль не сломать.

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

HackWare.ru

Этичный хакинг и тестирование на проникновение, информационная безопасность

Взлом сетевой аутентификации Windows

Аутентификация в Windows по сети

В Windows реализовано много разнообразных протоколов аутентификации и различных сетевых служб.

Самые распространённые примеры сетевой аутентификации Windows это:

вход на совместную сетевую папку
вход в компьютер с учётной записью Microsoft

Для входа на другие компьютеры в сети Windows используются такие методы аутентификации как NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP — думаю, даже пользователям Windows с многолетним стажем эти термины непонятны. В этой статье с помощью программы Responder мы будем перехватывать хеши, используемые при аутентификации в Windows. Программа Responder весьма эффективна и для базового использования не требует знания и понимания методов аутентификации и сетевых служб Windows. Поэтому мы начнём с практики — с перехвата хеша аутентификации и его расшифровки, благодаря чему получим имя пользователя и пароль в операционных системах Windows. Тем не менее в конце статьи будет дана характеристика способов аутентификации и сетевых служб.

Кстати про сетевые службы. Responder использует принципы атаки «человек-посередине», когда атакующий выступает в роле посредника, ретранслятора процесса аутентификации между жертвой и сервером. Responder вместо привычного и хорошо знакомого многих ARP спуфинга эксплуатирует такие сетевые службы Windows как: LLMNR, NBT-NS и MDNS. Опять же, далеко не всем знакомы эти термины и принципы работы этих служб, но, к счастью, Responder и не требует их глубокого понимания, а их краткая характеристика также будет в конце статьи.

Responder это инструмент для выполнения атаки человек-посередине в отношении методов аутентификации в Windows. Эта программа включает в себя травитель LLMNR, NBT-NS и MDNS благодаря которому перенаправляется трафик с запросами и хешами аутентификации. Также в программу встроены жульнические серверы аутентификации HTTP/SMB/MSSQL/FTP/LDAP, которые поддерживают такие методы аутентификации как NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP и базовую HTTP аутентификацию, для которых Responder выполняет роль ретранслятора.

Итак, Responder умеет перенаправлять трафик жертвы на компьютер атакующего и выступает посредником во время аутентификации пользователя. Также Responder имеет встроенные сервера аутентификации.

Сбор информации о компьютерах Windows и их сетевых службах в локальной сети

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

У Responder есть модуль Режима анализа. Этот модуль позволяет вам видеть NBT-NS, BROWSER, LLMNR, DNS запросы в сети без их травления какими либо ответами. Также вы можете пассивно составить карту доменов, серверов MSSQL и рабочих станций, увидеть, будет ли атака ICMP Редиректы иметь успех в вашей сети.

То есть мы сможем видеть сообщения сетевых служб Windows, но не будет отправлять в ответ на них фальшивые ответы для перенаправления трафика — мы будем только наблюдать.

Режим анализа включается опцией -A. Также в своих командах я буду использовать опцию -v для более подробного вывода.

Ещё нужно указать имя сетевого интерфейса — имена всех сетевых интерфейсов на своём компьютере можно посмотреть командой

Интерфейс нужно указывать с опцией -I, я буду использовать сетевой интерфейс с именем wlo1, следовательно, моя команда следующая:

На первом экране нам показана сводка, какие именно травители, сервера аутентификации и опции включены:

Рассмотрим некоторые записи:

Подтверждает, что Responder в режиме анализа и на запросы NBT-NS, LLMNR, MDNS не будут отправляться спуфленные данные для выполнения перенаправления трафика.

В следующей записи

говориться, что в этой сети будет работать ICMP Redirect.

В следующей записи:

говориться, что получен запрос от протокола NBT-NS. Слово ignoring говорит о том, что никаких действий предпринято не было — то есть атакующим не был отправлен ответ.

Информация о запросе по протоколу LLMNR:

В следующих строках:

говориться, что благодаря устаревшему протоколу LANMAN обнаружена рабочая группа с именем WORKGROUP, и что в этой рабочей группе найдены следующие рабочие станции и серверы: HACKWARE-MIAL, HACKWARE-SERVER, RT-N66U, VYACHESLAV — это имена компьютеров Windows в сети.

Пример записи о поступившем запросе по протоколу MDNS:

Для остановки программы нажмите CTRL+c.

Перехват имени пользователя и пароля Windows по сети

Теперь приступим к захвату хеша и затем его расшифровке.

Запускаем responder с набором опций -r -P -v -f, также указываем опцию -I с именем сетевого интерфейса:

Далее атака не требует каких-либо действий с нашей стороны.

Фраза Poisoned answer sent to означает, что был отправлен спуфленный ответ на запрос, результатом которого должно стать перенаправление трафика через наш компьютер. Примеры для всех трёх протоколов:

Пример удачно перехваченного хеша:

Из этих строк следует, что при подключении пользователя к сетевой общей папке по протоколу SMB использовалась аутентификация по протоколу NTLMv2-SSP. Имя компьютера HACKWARE-MIAL, а имя пользователя MiAl. Также дан перехваченный хеш, при расшифровке которого мы получим пароль пользователя.

Анализ результатов responder

Необязательно следить за выводом в консоль и копировать из неё хеши — все данные сохраняются в логи.

Файлы журналов располагаются в папке "logs/". Хеши будут сохранены и напечатаны только один раз на одного пользователя на один тип хеша. Будет выведен каждый хеш, если вы используете Вербальный режим, то есть если вы указали опцию -v.

Вся активность будет записана в файл Responder-Session.log

Режим анализа запишет свой журнал в Analyze-Session.log

Травление будет записано в файл Poisoners-Session.log

В Kali Linux и BlackArch эти файлы размещены в директории /usr/share/responder/logs/.

С помощью команды

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

покажет захваченные хеши.

Обратите внимание, NTLMV2 хеши перечислены после фразы

А NTLMv1 идут после фразы NTLMv1:

Некоторые хеши начинаются на имя пользователя, а затем через два двоеточия идёт имя компьютера:

В некоторых хешах после имени пользователя идёт имя рабочей группы — видимо, в том случае, если не получилось определить имя компьютера:

Для аккаунтов Microsoft в качестве имени пользователя указывается email, а затем через два двоеточия идёт срока «MicrosoftAccount»:

Как взломать хеш NTLMv1/NTLMv2/LMv2

Нам необходимо взломать следующий хеш:

На странице примера хешей, хеш NetNTLMv1 / NetNTLMv1+ESS (режим hashcat 5500) показан так:

А NetNTLMv2 (режим hashcat 5600) показан так:

Мой хеш заметно длиннее, и хотя responder-dumphash поместила этот хеш в группу NTLMV2, у меня возникли некоторые сомнения.

Проверяем ещё одной программой:

То есть всё таки это хеш NetNTLMv2, режим Hashcat равен 5600.

Hashcat поддерживает следующие родственные хеши:

Для запуска атаки по маске для взлома NetNTLMv2 в Hashcat нужно выполнить команду вида:

Пример моей реальной команды:

hashcat — имя исполнимого файла. В Windows это может быть hashcat64.exe, например.
—force — игнорировать предупреждения
—hwmon-temp-abort=100 — установка максимальной температуры, после которой будет прерван перебор, на 100 градусов Цельсия
-m 5600 — тип хеша NetNTLMv2
-D 1,2 — означает использовать для взлома и центральный процессор, и видеокарту
-a 3 — означает атаку по маске
-i — означает постепенно увеличивать количество символов в генерируемых паролях
—increment-min 1 — означает начать с длины маски равной единице
—increment-max 10 — означает закончить перебор при длине маске равный десяти
'ShareOverlord::WORKGROUP:24108cef8a9dc2c9:6CFD8A3D59D93ECF6551933F06AD24A6:0101000000000000F2AFFC5B40CAD5017A22CEB2169142F40000000002000E004E004F004D00410054004300480001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D00420031003200080030003000000000000000000000000000000007A5ED001DCD99403D273D180B6FBE7AC1AE2550011A910EA5B717776F355F630A0010000000000000000000000000000000000009001E0063006900660073002F0056005900410043004800450053004C004100560000000000' — хеш для взлома
?a?a?a?a?a?a?a?a?a?a — маска
?a в маске означает все символы из следующих наборов:
abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789
!"#$%&'()*+,-./:;<=>?@[\]^_`

Обратите внимание на запредельную скорость брутфорса этого алгоритма: 276.9 MH/s. За примерно 0 секунд (программа не показывает доли секунды) перебрано 9,375,744 паролей. Это результат на ноуте с GeForce GTX 1050 Ti — на настольных компьютерах с топовой видеокартой результаты будут ещё более впечатляющими. Можно констатировать — если хеш перехвачен, то он практически наверняка будет взломан, причём довольно быстро.

Для взлома NTLMv2 по словарю в Hashcat запустите команду вида:

Новое в этой команде:

-a 0 — означает атаку по словарю
/ПУТЬ/ДО/СЛОВАРЯ

Проблемы запуска responder

check permissions or other servers running

При запуске Режима анализа вы могли увидеть на скриншоте надпись:

Дело в том, что Responder для выполнения функций ретранслятора прослушивает ряд портов, а именно следующие порты: UDP 137, UDP 138, UDP 53, UDP/TCP 389,TCP 1433, UDP 1434, TCP 80, TCP 139, TCP 445, TCP 21, TCP 3141,TCP 25, TCP 110, TCP 587, TCP 3128 и Multicast UDP 5553.

Соответственно, эти порты не должны быть заняты. У меня был запущен веб-сервер, который прослушивал 80й порт, поэтому и возникла эта ошибка. Убедитесь, что в вашей системе все эти порты свободны.

Если на вашей системе запущена Samba, остановите smbd и nmbd и все другие службы, прослушивающие указанные порты.

В Ubuntu по умолчанию запущена служба, которая прослушивает 53 порт, для исправления откройте для редактирования файл /etc/NetworkManager/NetworkManager.conf и закомментируйте строку:

Затем остановите dnsmasq командой:

ValueError: invalid literal for int() with base 10

Если в /etc/resolv.conf в качестве DNS серверов указаны IPv6 адреса, например:

то при запуске Responder в режиме анализа, например:

Для её исправления откройте файл LLMNR.py (в Kali Linux и в BlackArch этот файл размещён по пути /usr/share/responder/poisoners/LLMNR.py), найдите там строку

и замените её на строку:

Продвинутые возможности Responder

Мы рассмотрели такую функцию Responder как перехват хеша аутентификации. У программы имеются и другие функции и, возможно, будет написана вторая часть этой инструкции. Вы можете самостоятельно ознакомится с другими опциями и инструментами входящими в Responder на странице https://kali.tools/?p=1679

Изменить настройки программы вы можете в файле /usr/share/responder/Responder.conf

Сетевые технологии Windows

Протоколы аутентификации Windows

NTLMv1

NTLM (NT LAN Manager) — протокол сетевой аутентификации, разработанный фирмой Microsoft для Windows NT.

NTLM — это результат дальнейшего развития LANMAN.

Никакой официальной информации о нём не поступало, но многое выяснила группа разработчиков Samba во время разработки своей программы.

Для передачи на сервер аутентификации (англ. Primary Domain Controler (PDC) — главный контроллер домена) имени пользователя, хэша пароля и мандата домена в Windows 98 применяется протокол LANMAN, а в Windows NT — протокол NTLM. Windows 2000 и Windows XP по умолчанию делают попытку аутентификации Kerberos (только в случае, когда станция является членом домена), в то же время они сохраняют обратную совместимость с аутентификацией NTLM.

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

1. Пользователь устанавливает подключение(сетевой путь) к серверу и отправляет NEGOTIATE_MESSAGE со своими возможностями.

2. Сервер отвечает сообщением CHALLENGE_MESSAGE, которое используется для идентификации (установления личности) клиента.

3. Клиент отвечает на сообщение при помощи AUTHENTICATE_MESSAGE.

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

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

Проверка подлинности NTLM по-прежнему поддерживается и обязательна для использования на системах, работающих под управлением Windows NT Server 4.0 или более ранних версий, а также для компьютеров, настроенных как члены рабочих групп. Проверка подлинности NTLM также используется для проверки подлинности при аутентификации на изолированных системах. Начиная с Windows 2000, проверка подлинности Kerberos версии 5 является предпочтительным методом проверки подлинности для сред Active Directory.

NTLMv2

NTLMv2 (NTLM версии 2) — встроенный в операционные системы семейства Microsoft Windows протокол сетевой аутентификации. Широко применяется в различных сервисах на их базе. Изначально был предназначен для повышения безопасности аутентификации путём замены устаревших LM и NTLM v1. NTLMv2 был введён начиная с Windows NT 4.0 SP4 и используется версиями Microsoft Windows вплоть до Windows 10 включительно. С самого изобретения протоколы NTLMv1 и NTLMv2 подвергались множеству нападений и демонстрировали широкий спектр серьёзных уязвимостей.

В схеме аутентификации, реализованной при помощи SMB или SMB2 сообщений, вне зависимости от того, какой вид диалекта аутентификации будет использован (LM, LMv2, NTLM, NTLM2, NTLMv2), процесс аутентификации происходит следующим образом:

Клиент пытается установить соединение с сервером и посылает запрос, в котором информирует сервер, на каких диалектах он способен произвести аутентификации, например: LM, NTLM, NTLM2, NTLMv2. Следовательно, диалект аутентификации LMv2 между клиентом и сервером исключается.
Сервер из полученного от клиента списка диалектов (по умолчанию) выбирает наиболее защищённый диалект (например, NTLMv2), затем отправляет ответ клиенту.
Клиент, определившись с диалектом аутентификации, пытается получить доступ к серверу и посылает запрос NEGOTIATE_MESSAGE.
Сервер получает запрос от клиента и посылает ему ответ CHALLENGE_MESSAGE, в котором содержится случайная (random) последовательность из 8 байт. Она называется Server Challenge.
Клиент, получив от сервера последовательность Server Challenge, при помощи своего пароля производит шифрование этой последовательности, а затем посылает серверу ответ AUTHENTICATE_MESSAGE, который содержит 24 байта.
Сервер, получив ответ, производит ту же операцию шифрования последовательности Server Challenge, которую произвёл клиент. Затем, сравнив свои результаты с ответом от клиента, на основании совпадения разрешает или запрещает доступ.

LMv2

LM-хеш, или LAN Manager хеш, — один из форматов, используемых Microsoft LAN Manager и версиями Microsoft Windows до Windows Vista для хранения пользовательских паролей длиной менее 15 символов. Это единственный вид хеширования, используемый в Microsoft LAN Manager, откуда и произошло название, и в версиях Windows до Windows Me. Он также поддерживается и более поздними версиями Windows для обратной совместимости, хотя в Windows Vista его приходится включать вручную.

Эволюция алгоритмов аутентификации LM и NTLM: LM → LMv2 → NTLM → NTLM2 → NTLMv2

Сетевые службы Windows

Теперь рассмотрим сетевые службы Windows, эксплуатируя которые становится возможным выполнить перенаправление трафика на компьютер атакующего.

LLMNR

Link-Local Multicast Name Resolution (LLMNR) — это протокол, основанный на формате пакета системы доменных имён (DNS), который позволяет хостам как IPv4, так и IPv6 выполнять разрешение имён для хостов на одном и том же локальном канале. Он включён в Windows Vista, Windows Server 2008, Windows 7, Windows 8 и Windows 10. Он также реализован с помощью systemd-resolved в GNU/Linux.

Отвечая на запросы, респонденты прослушивают порт UDP 5355 по следующему адресу многоадресной рассылки:

IPv4 — 224.0.0.252, MAC адрес 01-00-5E-00-00-FC
IPv6 — FF02:0:0:0:0:0:1:3 (эту нотацию можно сократить до FF02::1:3), MAC адрес 33-33-00-01-00-03

Ответчики также прослушивают TCP-порт 5355 по одноадресному (unicast) адресу, который хост использует для ответа на запросы.

NBT-NS

NBT-NS это NetBIOS-NS, то есть NetBIOS Name Service.

NetBIOS Name Service является одним из трёх сервисов NetBIOS: служба имён (NetBIOS-NS) для регистрации и разрешения имён. Подробности смотрите в статье NetBIOS: что это, как работает и как проверить.

Чтобы начать сеансы или распространять дейтаграммы, приложение должно зарегистрировать своё имя NetBIOS, используя службу имён. Имена NetBIOS имеют длину 16 октетов и различаются в зависимости от конкретной реализации. Часто 16-й октет, называемый суффиксом NetBIOS, обозначает тип ресурса и может использоваться для сообщения другим приложениям, какой тип услуг предлагает система. В NBT служба имён работает на UDP-порту 137 (TCP-порт 137 также может использоваться, но редко задействуется).

Примитивы службы имён, предлагаемые NetBIOS:

Add name (Добавить имя) — регистрирует имя NetBIOS.
Add group name (Добавить имя группы) — регистрирует NetBIOS-имя группы.
Delete name (Удалить имя) — отменяет регистрацию имени NetBIOS или имени группы.
Find name (Найти имя) — поиск имени NetBIOS в сети.

Разрешение имён NetBIOS не поддерживается Microsoft для Интернет-протокола версии 6 (IPv6).

MDNS

В компьютерных сетях протокол многоадресной DNS (mDNS) разрешает имена хостов в IP-адреса в небольших сетях, которые не включают локальный сервер имён. Это сервис с нулевой конфигурацией, использующий по существу те же программные интерфейсы, форматы пакетов и рабочую семантику, что и одноадресная система доменных имён (DNS). Хотя Стюарт Чешир разработал mDNS как самостоятельный протокол, он может работать совместно со стандартными DNS-серверами.

Протокол mDNS опубликован как RFC 6762, использует пакеты многоадресного протокола дейтаграмм пользователя (UDP) и используется пакетами программного обеспечения Apple Bonjour и Avahi с открытым исходным кодом. Android содержит реализацию mDNS. mDNS также был реализован в Windows 10, первоначально применение ограничивалось обнаружением сетевых принтеров, впоследствии стал способным также разрешать имена хостов.

mDNS может работать в сочетании с DNS Service Discovery (DNS-SD), сопутствующим методом нулевой конфигурации.

Когда клиенту mDNS необходимо разрешить имя хоста, он отправляет сообщение запроса в многоадресной IP рассылке, в которой просит хост, имеющий это имя, идентифицировать себя. Затем этот целевой компьютер многоадресно передаёт сообщение, которое включает его IP-адрес. Все машины в этой подсети могут затем использовать эту информацию для обновления своих кэшей mDNS. Любой хост может отказаться от своей заявки на имя, отправив ответный пакет с временем жизни (TTL), равным нулю.

По умолчанию mDNS разрешает только имена хостов, относящихся к доменам верхнего уровня (TLD) .local. Это может вызвать проблемы, если этот домен включает хосты, которые не реализуют mDNS, но которые можно найти через обычный DNS-сервер одноадресной передачи. Разрешение таких конфликтов требует изменений конфигурации сети, которые нарушают цель нулевой конфигурации.

Серверы Windows

HTTP

SMB

MSSQL

Система управления базами данных.

FTP

Протокол обеспечивающий работу файлового сервера.

LDAP

LDAP (англ. Lightweight Directory Access Protocol — «легкорасширяемый протокол доступа к каталогам») — протокол прикладного уровня для доступа к службе каталогов X.500, разработанный IETF как облегчённый вариант разработанного ITU-T протокола DAP. LDAP — относительно простой протокол, использующий TCP/IP и позволяющий производить операции аутентификации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей. Обычно LDAP-сервер принимает входящие соединения на порт 389 по протоколам TCP или UDP. Для LDAP-сеансов, инкапсулированных в SSL, обычно используется порт 636.

Протоколы аутентификации в Windows

В рамках лекции рассматриваются протоколы аутентификации :

SPNEGO
NTLM
Kerberos

Текст лекции

Рассмотрим наиболее распространенные протоколы безопасности, используемые в процессе аутентификации в Windows .

SPNEGO

SPNEGO (сокр. от Simple and Protected GSS-API Negotiation Mechanism — простой и защищенный механизм переговоров по GSS-API ) — механизм, который используется для аутентификации клиентского приложения на удаленном сервере в том случае, когда ни одна из сторон не знает, какой протокол аутентификации поддерживает другая сторона.

GSS-API ( Generic Security Service Application Program Interface — Обобщенный прикладной программный интерфейс службы безопасности) [14.1] предназначен для защиты коммуникаций между компонентами программных систем, построенных в архитектуре клиент/ сервер . Он предоставляет услуги по взаимной аутентификации осуществляющих контакт партнеров и по контролю целостности и обеспечению конфиденциальности пересылаемых сообщений.

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

Обобщенный интерфейс безопасности GSS-API не зависит от конкретной языковой среды и от механизмов безопасности , обеспечивающих реальную защиту. Последнее обстоятельство позволяет создавать приложения, которые на уровне исходного текста мобильны по отношению к смене механизмов безопасности . Тем самым реализуется открытость прикладных систем и соответствующих средств защиты.

На каждом компьютере, где предполагается применять интерфейс безопасности GSS-API , должно быть установлено клиентское программное обеспечение соответствующего механизма защиты. Приложение , использующее GSS-API , локальным образом вызывает необходимые функции, получая в ответ так называемые » токены безопасности». Токен может содержать зашифрованное удостоверение пользователя, электронную подпись или целое зашифрованное сообщение. Приложения обмениваются токенами безопасности, достигая тем самым аутентификации , целостности и конфиденциальности общения. Поскольку коммуникационные аспекты вынесены за пределы GSS-API , он автоматически оказывается независимым от сетевых протоколов . Сетевая мобильность приложений должна обеспечиваться иными средствами.

SPNEGO — стандартный псевдо-механизм GSS-API . Псевдо-механизм определяет, какие механизмы GSS-API являются доступными, выбирает один из них и передает ему «право» осуществлять в дальнейшем необходимые операции по обеспечению безопасного взаимодействия приложений.

Наиболее известным применением SPNEGO является расширение Microsoft » HTTP Negotiate «. Впервые SPNEGO был реализован в Internet Explorer 5.01 и IIS 5.0 с целью реализации возможности SSO ( Single Sign -On , «единый вход», «принцип однократной регистрации «), позже переименованной в Integrated Windows Authentication . SPNEGO мог выбирать между протоколами Kerberos и NTLM . Позднее Firefox и Konqueror также стали поддерживать SPNEGO .

Когда Microsoft начала работу над созданием централизованных сетей масштабов предприятия при работе над операционной системой Windows NT , перед разработчиками была поставлена весьма сложная и новая по тем временам задача — реализовать технологии SSO и » One user — one password «. » One user — one password » — «один пользователь — один пароль » означает, что у пользователя должен быть единый пароль , используемый для доступа ко всем ресурсам и протоколам сети. Действенные меры защиты не должны затруднять работу пользователей. Например, их следует освободить от необходимости отдельно регистрироваться на каждом ресурсе, используя при этом разные пароли. Кроме того, процесс регистрации не должен сопровождаться длительными задержками при получении доступа. Single sign -on , как отмечалось выше, подразумевает, что этот пароль указывается всего один раз — при входе пользователя в сеть ).

Необходимо было разработать такую схему аутентификации , которая позволила бы любому сетевому приложению передавать данные аутентификации независимо от сетевого протокола . Это привело к появлению NTLM и NTLMSSP ( NTLM Security Service Provider — подсистемы, позволяющей любому клиент- серверному приложению использовать NTLM , ничего не зная о его внутренней структуре). Протокол NTLM относится к семейству challenge — response ( запрос -ответ) протоколов . Это означает, что ни пароль , ни его хеш никогда не передаются «как есть»: они используются для генерации ответа ( response ) на случайный запрос ( challenge ). Аутентифицирующая сторона сравнивает полученный ответ с вычисленным локально. Генерация и проверка запроса и ответа осуществляется не приложениями, а провайдером NTLMSSP .

Протокол NTLM имеет много брешей в безопасности. Часть проблем вызвана тем, что Microsoft необходимо было сохранить совместимость с существующими сетями LanManager для MS-DOS и Windows for Workgroups . Другие являются ошибками проектирования, третьи — исключительно криптографические.

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

Kerberos

Kerberos — протокол аутентификации , разработанный в 1980-х гг. в Массачусетском технологическом институте ( MIT — Massachusetts Institute of Technology ). Первой операционной системой семейства Windows , реализующей протокол Kerberos [14.2], стала Windows 2000 . Сетевая служба Kerberos действует как доверенный посредник, обеспечивая безопасную сетевую проверку подлинности, которая дает пользователю возможность работать на нескольких машинах сети.

Kerberos использует криптографию с секретным ключом: как правило, применяются шифры DES или Triple-DES ( 3DES ), хотя в последней версии, Kerberos v5, описанной в документе RFC 1510 [14.4], поддерживаются и другие алгоритмы: так, Windows Vista была выпущена с улучшенной версией протокола Kerberos , позволяющей использовать криптоалгоритм AES .

Kerberos версии 5 использует режим СВС ( Cipher Block Chaining ). CBC [14.3] — это режим шифрования с обратной связью , при котором перед вычислением очередного шифрованного блока открытый текст складывается побитно по модулю 2 с предыдущим шифртекстом . В режиме СВС над открытым текстом и предыдущим шифртекстом выполняется операция XOR и тем самым каждый предыдущий шифрблок используется для модифицирования очередного блока открытого текста.

Для аутентификации в службе Kerberos используются удостоверения. Различают два вида удостоверений ( credentials ): мандаты ( tickets ) и аутентификаторы ( authenticators ). Подробно структура различных сообщений Kerberos описана в документе RFC 1510 [14.2], мы ограничимся основной информацией.

Мандат используется для безопасной передачи серверу данных о клиенте. Сервер также может проверить, действительно ли мандат был выдан клиенту, который его предъявляет. Мандат Kerberos имеет следующую форму:

— сервер , — клиент, — сетевой адрес клиента, — начало и окончание времени действия мандата , K_s — секретный ключ сервера, E(K,[d]) здесь и далее обозначает некоторые данные , зашифрованные ключом . Клиент не может расшифровать мандат , т.к. не знает секретного ключа сервера, но он может предъявлять его серверу неограниченное количество раз в течение промежутка от начала до окончания действия мандата .

Аутентификатор — некий блок информации, зашифрованный с помощью секретного ключа . Аутентификатор предъявляется вместе с мандатом . Клиент создает аутентификатор каждый раз, когда ему нужно воспользоваться службами сервера. Аутентификатор Kerberos имеет следующую форму:

— сервер , — клиент, — начало и окончание действия мандата , Схема работы протокола Kerberos

Запрос мандата на выделение мандата сервера
Мандат на выделение мандата сервера
Запрос мандата сервера
Мандат сервера
Запрос услуги
Метка времени, зашифрованная сеансовым ключом*

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

Краткие итоги

Были рассмотрены протоколы аутентификации , используемые в ОС Windows : SPNEGO , NTLM , Kerberos . Описаны принципы работы и области применения протоколов. Особое внимание уделено используемым криптографическим механизмам.

HackWare.ru

Этичный хакинг и тестирование на проникновение, информационная безопасность