Аутентификация и авторизация

Что такое аутентификация и авторизация?

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

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

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

Есть два варианта авторизации:

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

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

Где что хранится

Не следует путать хранилище LSA с защищенным хранилищем (Protected Storage) и бaзой данных SAM (Security Account Manager database).

В Protected Storage могут храниться любые данные, помещенные туда приложением (имена и пароли удаленного доступа, электронной почты, аутентификации сайтов и данные для автозаполнения форм). Они могут быть извлечены оттуда в том же виде, в котором были туда положены по запросу приложения через стандартный API. Хэшей паролей пользователя там нет.

В базе данных SAM хранятся локальные учетные записи пользователей (на контроллере домена – доменные), включая пароли в виде NT и LM хэшей, что уже несколько интересней. Локальная база данных SAM является кустом системного реестра (т.е. частью реестра хранящейся в отдельном файле).

Ранее, если на машине не использовалась утилита syskey, можно было извлечь хэши локальных паролей учетных записей непосредственно из файла или из реестра. Для извлечения хэшей из файла можно было использовать утилиту samdump Дмитрия Андрианова, для извлечения из реестра – pwdump (Jeremy Allison).

Однако, утилита syskey шифрует хранящиеся хэши с помощью системного ключа используя алгоритм RC4. Ключ может храниться на дискете, которую необходимо вставлять при загрузке машины, либо на диске – закрытый паролем (его необходимо вводить при каждой загрузке машины) или в некой обратимой форме.

Управлять хранением системного ключа можно с помощью утилиты syskey. Начиная с Windows 2000 syskey c хранением ключа в обратимой форме включен по-умолчанию, что затрудняет извлечение хэшей из SAM стандартным способом. То, что будет извлечено, на самом деле не является хэшем пароля.

Pwdump2 (Todd Sabin) обходит защиту syskey считывая хэши паролей через внутренний API в контексте процесса winlogon используя технику DLL injection. Pwdump3 (Phil Staubs) использует ту же саму технику в сочетании с Service API для того, чтобы запустить процесс на удаленном компьютере.

Похожие приемы использовались и для доступа к хранилищу LSA. Lsadump (PaulAshton) использовала недокументированный API LsaRetrievePrivateData() для получения данных из хранилища LSA и могла работать только из-под учетной записи локальной системы. В более поздних системах Microsoft сделал использование этой функции совсем невозможным.

Наверное, следует так же упомянуть о cached logon credentials (кэшированных удостоверениях). По-умолчанию Windows хранит данные о последних 10 набранных именах пользователей и паролей. Основная цель – дать возможность доменному пользователю войти на компьютер даже в случае отсутствия связи с контроллером домена.

Поскольку нет необходимости хранить непосредственно хэш пароля (он будет вычислен при входе пользователя в систему), хранится некое производное значение (MD4 от имени пользователя и NT-хэша). Т.е. восстановить хэш пароля сложно, но можно попытаться атаковать слабые пароли пользователя.

Указанные инструменты больше не поддерживаются разработчиками. Они, и другие тестировавшие утилиты, включая Cain & Abel, так же не дают надежного результата в Windows XP SP2, т.к. Microsoft изменил алгоритм работы winlogon и lsass, однако, для Cain & Abel это, скорее всего, лишь вопрос времени.

Совет: управлять Cached Logon Credentials можно с помощью доменных политик либо при помощи ключа реестра CachedLogonCount в разделе HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

Очень неприятно, если, например, в кэшированных удостоверениях останутся сведения о входе на компьютер администратора домена (это одна из причин управлять компьютером удаленно). Часто можно встретить рекомендацию устанавливать CachedLogonCount в 0, однако наиболее оптимальным представляется значение 1 – это позволяет в отсутствии сетевого подключения войти в систему последнему пользователю – т.е. тому, который обычно работает с компьютером .

Собственно NTLM

На сегодняшний момент существует две основных версии NTLM. Первая версия NT LanManager 0.12, часто называемая NTLM v1 и NTLM v2. Кроме того, существует несколько основанных на NTLM диалектов, например протокол аутентификации MS-CHAPv2 (MS-CHAP является NTLM 0.

Итак, NTLMSSP генерирует «кусочки» данных безопасности (security blob) которыми обмениваются клиентское и серверное приложение. Обмен происходит в несколько этапов, и для NTLM 0.12 выглядит следующим образом:

1. Клиент посылает серверу запрос на аутентификацию.
2. Сервер отвечает пакетом, в котором указывается выбранная NTLM аутентификация и поле EncryptionKey которого содержит 64-битный случайный запрос (challenge).
3. Клиент посылает сообщение, содержащее поля AccountName (учетная запись), PrimaryDomain (домен учетной записи), CaseInsensitivePassword (пароль не чувствительный к регистру, фактически это LM-ответ) и CaseSensitivePassword (пароль чувствительный к реестру, фактически NT-ответ). Оба ответа являются 192-битными и вычисляются на основе NT и LM ключа по одному и тому же алгоритму. Если соответствующего ключа нет, то и соответствующий ответ будет нулевым.

Давайте проиллюстрируем алгоритм генерации ответа на примере NT-ключа 8846F7EAEE8FB117AD06BDD830B7586C (как мы помним, он 128-битный) с 64-битным запросом сервера 0123456789ABCDEF.

NT-ответ DD5428B01E86F4DFCABEAC394946DBD43EE88F794DD63255.

Сразу должно бросаться в глаза, что не так с этим алгоритмом – проблема та же, что и при вычислении LM-хэша, все три DES-блока вычисляются независимо. Это означает, что и восстанавливаться по известному запросу и ответу они так же могут независимо. Для современного PC время восстановление одного блока хэша пароля методом полного перебора составляет порядка нескольких недель и не зависит от сложности пароля.

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

Из этого, в сочетании с тем, что имея хэш мы не нуждаемся в пароле в открытом тексте, следует однозначный вывод – NTLM 0.12 и MS-CHAP не должны использоваться для аутентификации в сетях, где возможен перехват трафика. Кроме того, если у внешнего недоверенного сервера есть возможно инициировать «прозрачный» вход пользователя, то он может использовать переданный ответ для восстановления ключа пользователя.

Протокол аутентификации удаленного доступа MS-CHAPv2 является всего лишь расширением протокола MS-CHAP и, соответственно, NTLM 0.12. Изменения состоят в следующем: клиент так же генерирует случайный запрос для сервера, на который сервер должен ответить, т.е. аутентификация клиента и сервера является взаимной.

Кроме того, запрос сервера попадает в алгоритм генерации ответа в измененном виде (сам алгоритм остается прежним) – берется SHA1 от запроса сервера, запроса клиента и имени пользователя. Это не влияет на сложность атаки на восстановление хэша т.к. SHA1 достаточно вычислить лишь один раз, а далее используется тот же алгоритм перебора.

Из этого следует, что MS-CHAPv2, который часто используется для аутентификации, например, PPTP соединений, так же ни в коем случае не должен использоваться для аутентификации по недоверенным каналам связи. На сегодня, единственный более-менее стойкий протокол парольной аутентификации удаленного доступа это PEAP (Password EAP), который, к сожалению, слабо поддерживается, что делает практически невозможным использовать, например, PPTP туннели с шифрованием MPPE, даже с ключем шифрования большой длины, для построения VPN сетей, т.к. ключи шифрования MPPE генерируются на основе NT-ключа.

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

Для справки: HMAC-MD5 генерирует хэш на основе текста (text) и ключа (key) с использованием стандартного хэша MD5 по следующему алгоритму:

HMAC_MD5(text,key) = MD5 (key xor opad . MD5(key XOR ipad.text))

Где ‘.’ Означает конкатенацию, ipad = 0x36363636363636363636363636363636, ipad = 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C

Ответ вычисляется следующим образом:

1. Клиент генерирует ключ (NT2 ключ) используя HMAC_MD5 с NT-ключем в качестве ключа и именем пользователя конкатенированным с именем домена в Unicode в качестве текста.
2. Клиент генерирует кусок данных (blob), в который входят случайные данные, временная метка, NetBIOS имя и т.д, всего порядка 64 байт, длина может варьироваться.
3. blob конкатенируется с ответом сервера
4. Вычисляется HMAC-MD5 c NT2 ключем полученном на первом шаге в качестве ключа и blob в качестве текста.
5. результат (4) конкатенируется с blob (2). То, что получилось и есть ответ.

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

Подсказка: В Cain & Abel реализованы практически все рассмотренные атаки. Кроме того, встроенный снифер с возможностью arp poisoning позволяет перехватывать данные NTLM аутентификации даже в коммутируемых сетях и автоматически передавать все необходимые данные в подсистему криптографиеского анализа для различного типа криптографических атак.

Совет: Можно управлять разрешенными протоколами аутентификации и запретить протоколы аутентификации отличные от NTLMv2 с помощью реестра или доменных политик. За это отвечает ключ реестра LMCompatibilityLevel в разделе HKLMSystemCurrentControlSetControlLSA. Возможные значения слудющие:

0. Посылать NT и LM ответы
1. безопасность сеанса NTLM (не затрагивает аутентификацию)
2. NTLM аутентификация. LM ответ не генерируется клиентом. На сервер не влияет.
3. NTLMv2 аутентификация, клиент не использует NTLM 0.12
4. NTLM требуется, сервер не принимает LM ответ
5. NTLMv2 требуется, сервер не принимает NTLM 0.12 аутентификацию.

Как следует из названия, установка высокого LMCompatibilityLevel может повлиять на клиентов со старыми ОС.

Атаки NTLM-релеинга

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

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

Единственное необходимое для этого условия (кроме связи с клиентом и сервером на сетевом уровне, разумеется) это возможность инициировать подключение клиента по протоколу поддерживающему прозрачную NTLM-аутентификацию. Таким образом не имея непосредственного доступа к каналу связи, можно организовать ситуацию человека-по-средине (man-in-the-middle).

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

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

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

Для некоторых протоколов Microsoft советуют применять подпись пакетов, например, SMB signing для CIFS/SMB. К сожалению, подпись SMB спасает лишь в единственной ситуации – она затрудняет подключение к серверу CIFS требующему подпись. Это делает невозможным использование межпротокольного релеинга NTLM для подключения к серверу CIFS.

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

Это не дает атакующему возможность вмешаться в передаваемые данные (например, запросить свой файл непосредственно у сервера), однако, если атакующий получил возможность управлять поведением клиента – он может заставить клиента запросить требуемый файл.

Атаки NTLM релеинга обсуждались разными авторами. DilDog в 2000м году, в связи с проблемой NTLM авторизации в telnet (Internet Explorer к тому времени уже имел опцию не выполнять прозрачную NTLM-авторизацию в Internet-зоне). 3APA3A в 2001 в связи с SPA авторизацией Outlook Express.

Как защищаться от атак NTLM

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

Чтобы предотвратить атаки NTLM релеинга с помощью протокола CIFS, следует ограничить использование этого протокола. Во-первых подключения по протоколам NetBIOS (TCP/139) и CIFS over TCP (TCP/445) не должны пропускаться не только из внешней сети во внутрь, но и из внутренней сети наружу.

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

Чтобы этого недопустить, следует ограничить связь на сетевом уровне между клиентскими компьютерами. В идеальном случае у клиентов должна быть связь только с теми серверами, к которым они должны подключаться. В сетях Windows 2000/XP/2003 такая структура сети легко реализуется за счет применения доменных политик безопасности IP.

Для этого создается правило, позволяющее блокировать пакеты:

Создается описание серверной сети

Создается политика разрешающая серверный трафик и запрещающая весь остальной:

Теперь данное правило можно применить к локальному компьютеру либо ко всем клиентским компьютерам с помощью политик Active Directory.

Устранив возможности NTLM атак в CIFS, мы не устраним атаки полностью. Существует большое количество протоколов поддерживающих NTLM аутентификацию, а развитие различных сервисов, в т.ч. и RPC, поверх HTML делает фильтрацию NTLM-аутентификации наружу еще более затруднительной.

Подсказка: в качестве решения можно посоветовать не позволять доступ к сервисам, доступным снаружи с учетными записями используемыми во внутренней сети. Для внешних ресурсов лучше использовать авторизацию на основе сертификатов, во внутренней сети – двухфакторную авторизацию.

Аутентификация ntlm

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

NTLM функционирует следующим образом.

1. Пользователь указывает имя пользователя, пароль и имя домена при
   входе на компьютер-клиент.
2. Клиент создает хэш данного пароля и удаляет оригинал.
3. Клиент отправляет серверу имя пользователя в открытом виде.
4. Сервер отправляет клиенту 16-битный фрагмент случайных данных.
5. Клиент шифрует этот фрагмент, а также хэш пароля пользователя и
   передает их на сервер.
6. Сервер передает имя пользователя, случайный фрагмент данных и ответ
   клиента на контроллер домена.
7. Контроллер домена шифрует отрезок случайных данных вместе со своим
   собственным хэшем пароля пользователя, после чего сравнивает их с
   элементами, присланными сервером.
8. Если значения совпадают, контроллер домена уведомляет сервер об
   успешном завершении аутентификации.
9. Если значения или имя пользователя не совпадают, контроллер домена
   уведомляет об этом сервер, который передает клиенту соответствующее
   сообщение. После этого браузер клиента запрашивает у пользователя
   аутентификационные данные.

Аутентификация посредством .net passport

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

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

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

Система .NETPassport является бесплатной для регистрации и
использования. Пользователи интернета входят и выходят из системы на
сервере Passport и направляются на нужный веб-сайт после успешного
прохождения процедуры аутентификации.

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

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

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

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

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

Биометрия.

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

До сих пор в Windows не было стандартной поддержки биометрических устройств. Чтобы решить эту проблему, Windows 7 вводит Windows Biometric Framework (WBF). WBF предоставляет новый набор компонентов, поддерживающий снятие отпечатка пальца с помощью биометрические устройства. Эти компоненты увеличивают безопасность пользователей.

Windows Biometric Framework упрощает пользователям и администраторам настройку и управление биометрическими устройствами на локальном компьютере или в домене.

Интеграция личности в интернете.

Управление аккаунтом – стратегия обеспечения безопасности. Для разрешения или запрета проверки подлинности определенных компьютеров или всех компьютеров, которыми вы управляете онлайн, используется Групповая политика.

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

Интегрированная аутентификация windows

Интегрированная аутентификацияWindows является наиболее безопасным
методом аутентификации, однако она доступна только в Internet Explorer.
Этот тип аутентификации раньше был известен как аутентификацияNTLM и
аутентификацияWindows NT вопрос/ответ.

Интегрированная аутентификацияWindows поддерживает как протокол
Kerberos v5, так и протокол NTLM (NT LAN Manager) для аутентификации
посредством пакета Negotiate.

При наличии ActiveDirectory и
соответствующей поддержке браузером (IE 5 или выше на платформе Windows
2000) используется протокол Kerberos, иначе – протокол NTLM.

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

Использование нескольких методов аутентификации

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

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

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

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

Наконец, если не удалось применить ни один из указанных выше методов
аутентификации, используется базоваяаутентификация.

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

Кому нужен сломанный ключ?

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

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

Нам будет достаточно только модифицировать библиотеку md4.c таким образом, чтобы не хэшировать что-то, что уже похоже на хэш. Например то, что состоит из 32х 16-ричных символов (как мы помним, ключ 128-битный, а пароль приходит в кодировке Unicode, т.е. каждый входящий символ занимает 2 байта, получается 64 байта на входе и 16 на выходе).

— md4.c.orig 2004-04-04 11:37:00.000000000 0400

md4.c 2004-10-27 23:01:31.000000000 0400

@@ -130,6 130,21 @@

C = 0x98badcfe;

D = 0x10325476;

if(n == 64){

int j;

unsigned char * hexd = (unsigned char *)”0123456789ABCDEF”;

for(j = 0; j<16; j ){

if(!strchr(hexd, in[(j<<2)]))break;

if(in[(j<<2) 1])break;

if(!strchr(hexd, in[(j<<2) 2]))break;

if(in[(j<<2) 3])break;

out[j] = ((strchr(hexd, in[(j<<2)]) – (char *)hexd)<<4);

out[j] ^= (strchr(hexd, in[(j<<2) 2]) – (char *)hexd);

}

if(j == 16) return;

}

while (n > 64) {

copy64(M, in);

mdfour64(M);

Проверим:

bash$ smbclient //WIN2KSRV/shared

added interface ip=192.168.1.1 bcast=192.168.1.255 nmask=255.255.255.0

Got a positive name query response from 192.168.1.2 ( 192.168.1.2 )

Password: (entering 8846F7EAEE8FB117AD06BDD830B7586C)

Domain=[WIN2KDOMAIN] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager]

smb: >

Получилось.

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

Быстрый поиск по системным файлам показывает, что в папке SYSTEM32 около 85 реализаций MD4 (видимо программистам платят по объему двоичного кода), есть и особо подозрительные, например в samlib.dll. Делались и попытки поменять ключи непосредственно в памяти или хранилище, например в статье Hernan Ochoa “Modifying Windows NT Logon Credentials”… Но, собственно, статья наша теоретическая и одного эксперимента для подтверждения теории вполне хватает.

Настройка сайта на работу с системой .net passport

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

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

Для реализации на сайте IIS аутентификации .NET Passport выполните
следующие шаги.

1. Откройте оснастку IIS MMC и разверните узел Web Sites (Веб-узлы) в
   левой части консоли.
2. Щелкните правой кнопкой мыши на соответствующем веб-сайте или
   виртуальном каталоге, для которого необходимо реализовать
   аутентификацию .NET Passport. Выберите Properties (Свойства).
3. В окне Properties откройте вкладку Directory Security (Безопасность
   каталога).
4. Нажмите на кнопку Edit (Изменить), расположенную в области
   Authentication And Access Control (Аутентификация и контроль доступа).
   Откроется окно Authentication Methods (Методы аутентификации).
5. В области Authenticated Access (Аутентифицируемый доступ) включите
   опцию .NET Passport Authentication (Аутентификация .NET Passport).
   После выбора той опции все остальные методы аутентификации будут
   недоступны. Тем не менее, вы по-прежнему сможете выбрать анонимный
   доступ.
6. При необходимости введите имя домена в текстовом поле Default Domain
   (Домен по умолчанию). Это домен, которому будут принадлежать имена
   пользователей на главном сервере после прохождения ими аутентификации
   .NET Passport. Для определения организации или домена при
   взаимодействии с системой, разработанной другой компанией (не
   Microsoft) можно задать Realm (Область).
7. Нажмите на кнопку OK для закрытия окна Authentication Methods (Методы
   аутентификации). Затем нажмите на кнопку OK для закрытия окна
   Properties (Свойства).

Если служба .NET Passport настроена правильно, то пользователям
отобразится запрос .NET Passport (см. рис. 7.2), за тем исключением,
что в нем будут указаны настройки, из таблицы 7.1, а не значения по
умолчанию, показанные на рисунке 7.2.

Настройка службы .net passport

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

Несколько слов о microsoft negotiate

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

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

Новые функции аутентификации в windows 7.

Целый ряд улучшений, связанных с процессами входа и проверки подлинности пользователя был добавлен еще в Windows Vista ®. Эти усовершенствования увеличили базовый набор функции проверки подлинности, чтобы помогло обеспечить лучшую безопасность и управляемость.

• Смарт-карты
• Биометрия
• Интеграция личности в Интернете.

Процесс авторизации и аутентификации.

Для получения доступа к файлам в сети пользователи для проверки их личности должны проходить аутентификацию. Это делается во время процесса входа в сеть. Операционная система Windows 7 для входа в сеть имеет следующие методы аутентификации:

• Протокол Kerberos версии 5: Основной метод аутентификации клиентов и серверов под управлением операционных систем Microsoft Windows. Он используется для проверки подлинности учетных записей пользователей и учетных записей компьютеров.
• Windows NT LAN Manager (NTLM): используется для обратной совместимости с операционными системами более старыми, чем Windows 2000 и некоторых приложений. Он менее гибок, эффективен и безопасен, чем протокол Kerberos версии 5.
• Сопоставление сертификатов: обычно используется для проверки подлинности при входе в сочетании со смарт-картой. Сертификат, записанный на смарт-карте, связан с учетной записью пользователя. Для чтения смарт-карт и аутентификации пользователя используется считыватель смарт-карт.

Смарт-карты.

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

• Смарт-карты Plug and Play
• Личные удостоверения проверки (PIV), стандарт национального института стандартов и технологий США (NIST)
• Поддержка для входа смарт-карты Kerberos.
• Шифрование дисков  BitLocker
• Документы и электронная почта
• Использование с бизнес-приложениями.