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

Аннотация: В данной лекции рассматриваются протоколы аутентификации, используемые в ОС 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.

NTLM

Когда 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 имеет следующую форму:

$T_{c,s}=s, E(K_s,[c,a,v,K_{c,s}])$

где — сервер, — клиент, — сетевой адрес клиента, — начало и окончание времени действия мандата, K_s — секретный ключ сервера, $K_{c,s}$ — сеансовый ключ для клиента и сервера, $T_{c,s}$ — мандат клиента на пользование сервера. Запись здесь и далее обозначает некоторые данные , зашифрованные ключом . Клиент не может расшифровать мандат, т.к. не знает секретного ключа сервера, но он может предъявлять его серверу неограниченное количество раз в течение промежутка от начала до окончания действия мандата.

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

$A_{c,s}=E(K_{c,s},[C,t])$

где — сервер, — клиент, — начало и окончание действия мандата, $K_{c,s}$ — сеансовый ключ для клиента и сервера, $A_{c,s}$ — аутентификатор клиента для сервера. В отличие от мандата, аутентификатор используется только один раз: содержание этого блока данных должно меняться при каждом новом сеансе, иначе злоумышленник может проникнуть в систему, воспользовавшись перехваченным сообщением.

Схема работы протокола Kerberos представлена на рис. 14.1 [14.3]. Выделяется 3 основные стадии:

Клиент запрашивает у сервера аутентификации мандат на обращение к Серверу выдачи мандатов (Ticket-Granting Server, TGS ). В роли сервера аутентификации выступает центр распределения ключей ( KDC, Key Distribution Center). KDC направляет клиенту мандат, содержащий уникального сеансового ключа (session key) для предстоящего сеанса. Копия сеансового ключа, пересылаемая на сервер, шифруется с помощью долговременного ключа этого сервера (шаги 1-2);
Для подключения к конкретному серверу клиент запрашивает у TGS мандат на обращение к серверу. В роли TGS также выступает KDC. Если все в порядке, KDC отсылает мандат клиенту (шаги 3-4);
Клиент предъявляет серверу полученный мандат вместе с аутентификатором. Если удостоверение клиента правильно, сервер предоставляет клиенту доступ к службе (шаги 5-6*).

Рис.
14.1.
Схема работы протокола Kerberos

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

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

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

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

Источник

Microsoft Windows Server 2003 Service Pack 2 Microsoft Windows XP Professional x64 Edition Microsoft Windows XP Service Pack 3 Microsoft Windows XP Home Edition Microsoft Windows XP Professional Еще…Меньше

ВВЕДЕНИЕ

Нам хорошо известно, что имеется много информации и инструментов, которые могут быть использованы для совершения атак в ходе проверки подлинности по протоколам NT LAN Manager 1 (NTLMv1) и LAN Manager (LM). Нововведения в области компьютерного оборудования и программного обеспечения сделали эти протоколы уязвимыми для несанкционированных попыток получения учетных данных пользователей. Эта информация и инструменты в большей степени направлены на среды, в которых проверка подлинности по протоколу NTLMv2 не является обязательной. Мы настоятельно рекомендуем клиентам проверить свои среды и провести обновление параметров проверки подлинности сети. Все поддерживаемые операционные системы Майкрософт предоставляют возможность проверки подлинности по протоколу NTLMv2.

В первую очередь угрозе подвержены системы, которые используют конфигурацию по умолчанию (например, Microsoft Windows NT 4, Windows 2000, Windows XP и Windows Server 2003). По умолчанию как Windows XP, так и Windows Server 2003, к примеру, поддерживают проверку подлинности по протоколу NTLMv1.

В операционной системе Windows NT поддерживаются два варианта проверки подлинности с запросом и подтверждением при входе в сеть: запрос и подтверждение по протоколу LAN Manager (LM) и запрос и подтверждение Windows NT (также известное как запрос и подтверждение по протоколу NTLM 1). Оба варианта служат для взаимодействия с системами Windows NT 4.0, Windows 95, Windows 98 и Windows 98 Second Edition.

Если для решения проблемы требуется помощь, перейдите к разделу Получение помощи в решении проблемы.

Решение

Чтобы снизить риск возникновения проблемы, рекомендуется разрешить использование только протокола NTLMv2 для проверки подлинности в средах, в которых представлены системы Windows NT 4, Windows 2000, Windows XP и Windows Server 2003. Для этого вручную укажите для уровня проверки подлинности LAN Manager значение, равное 3 (или большее), как описано здесь.

Для Windows XP и Windows Server 2003 доступны решения Microsoft Fix it, чтобы автоматически настроить системы на использование исключительно протокола NTLMv2. Этот метод также позволяет использовать расширенную защиту для проверки подлинности в рамках параметров NTLM.

Получение помощи в решении проблемы

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

Microsoft Fix it для Windows XP

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

Включить

Примечания.

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

Microsoft Fix it для Windows Server 2003

Включить

Примечания.

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

Статус

Данное поведение является подтвержденной ошибкой в продуктах Майкрософт, перечисленных в разделе «Информация в данной статье относится к следующим продуктам».

Дополнительная информация

Вопросы и ответы

Можно ли найти дополнительные сведения об угрозах и мерах противодействия для сетевой системы безопасности Windows и уровня проверки подлинности LAN Manager?

Что явилось причиной проблемы?

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

Как узнать, является ли моя конфигурация уязвимой?

Какие операционные системы Windows, для которых используются параметры по умолчанию, являются уязвимыми?

В параметрах по умолчанию для ОС Windows NT4, Windows 2000, Windows XP и Windows Server 2003 значение параметра LMCompatibilityLevel меньше чем три (<3).

Какой потенциальные риск существует при принудительном использовании протокола NTLMv2?

Все поддерживаемые версии операционных систем Windows поддерживают протокол NTLMv2. Windows NT 4.0 с пакетом обновления 6a (SP6a) также поддерживает протокол NTLMv2. Поэтому проблемы совместимости очень маловероятны. Возможно понадобится проверка сторонних (устаревших) приложений и конфигураций на предмет совместимости. Повторная настройка или обновление могут решить проблему. Клиентам настоятельно рекомендуется выполнить ряд действий для настройки или обновления их сетей, чтобы выяснить, используется ли протокол NTLMv1, и исключить его. Использование протокола NTLMv1 отрицательно влияет на сетевую безопасность и может поставить ее под угрозу.

Каким образом злоумышленник может использовать данную уязвимость?

Злоумышленник может извлечь хэш-значения из полученных подтверждений при проверке подлинности по протоколам LM и NTLM при входе в сеть.

Где найти сведения о включении протокола NTLMv2 в версиях ОС Microsoft Windows, которые не поддерживаются в настоящее время?

Дополнительные сведения о протоколе NTLMv2 для ОС Windows NT, Windows 95, Windows 98 и Windows 98 Second Edition доступны в статье 239869 базы знаний Майкрософт.

Благодарность

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

Марка Гамач (Mark Gamache), сотрудника компании T-Mobile (США), за совместную работу, направленную на защиту клиентов от атак в ходе проверки подлинности по протоколам NTLMv1 (NT LAN Manager версии 1) и LAN Manager (LM).

Нужна дополнительная помощь?

Источник

Лекция 11. Протоколы
аутентификации в 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.

NTLM

Когда 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 имеет следующую форму:

$T_{c,s}=s, E(K_s,[c,a,v,K_{c,s}])$

где  — сервер,  — клиент,  — сетевой адрес клиента,  — начало и
окончание времени действия мандата,  —
секретный ключ сервера, $K_{c,s}$ —
сеансовый ключ для клиента и
сервера, $T_{c,s}$ — мандат клиента на пользование сервера. Запись  здесь и далее
обозначает некоторые данные , зашифрованные ключом . Клиент
не может расшифровать мандат, т.к. не
знает секретного ключа сервера, но
он может предъявлять его серверу неограниченное количество раз в течение
промежутка от начала до окончания действия мандата.

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

$A_{c,s}=E(K_{c,s},[C,t])$

где — сервер, — клиент, — начало и
окончание действия мандата, $K_{c,s}$ —
сеансовый ключ для клиента и
сервера, $A_{c,s}$ — аутентификатор клиента для сервера. В отличие
от мандата, аутентификатор используется
только один раз: содержание этого блока данных должно
меняться при каждом новом сеансе, иначе злоумышленник может
проникнуть в систему, воспользовавшись перехваченным сообщением.

Схема работы протокола Kerberos представлена на рис. 14.1 [14.3]. Выделяется 3 основные стадии:

·
Клиент
запрашивает у сервера аутентификации мандат на
обращение к Серверу выдачи мандатов (Ticket-Granting Server, TGS ).
В роли сервера аутентификации выступает центр распределения ключей ( KDC, Key Distribution Center). KDC направляет
клиенту мандат, содержащий
уникального сеансового ключа (session key) для предстоящего сеанса.
Копия сеансового ключа, пересылаемая на
сервер, шифруется с помощью долговременного
ключа этого сервера (шаги 1-2);

·
Для
подключения к конкретному серверу клиент запрашивает у TGS мандат на
обращение к серверу. В роли TGS также
выступает KDC. Если все в порядке, KDC отсылает мандат клиенту
(шаги 3-4);

·
Клиент
предъявляет серверу полученный мандат вместе
с аутентификатором. Если удостоверение
клиента правильно, сервер предоставляет клиенту доступ к службе (шаги 5-6*).

Рис. 14.1. Схема работы протокола Kerberos

1.
Запрос мандата на выделение мандата сервера

2.
Мандат на выделение мандата сервера

3.
Запрос мандата сервера

4.
Мандат сервера

5.
Запрос
услуги

6.
Метка
времени, зашифрованная сеансовым ключом*

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

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

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

Скачано с www.znanio.ru

Источник

Протоколы, составляющие основу процедуры

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

Аутентификация: общие принципы

Аутентификация представляет собой один из компонентов любой компьютерной системы управления доступом. Как показано на экране 1, системы управления доступом обеспечивают идентификацию, аутентификацию, авторизацию и отчетность.

Рисунок 1. Механизмы управления доступом и аутентификация Windows

Идентификация (identification). В процессе идентификации используется набор данных, который уникально идентифицирует объект безопасности (например, пользователя, группу, компьютер, учетную запись службы) в общей службе каталогов. Служба каталогов, такая как Active Directory (AD), позволяет уникально идентифицировать объекты, подобно тому как DNS удостоверяет, что два человека не могут иметь одинаковые адреса электронной почты. Во внутренних механизмах Windows используются SID, глобально уникальные идентификаторы (globally unique identifier, GUID) и другие уникальные тэги. В большинстве случаев для идентификации достаточно ввести уникальное имя учетной записи, такое как Rgrimes. В большом лесу AD приходится применять полные имена пользователей (user principal name, UPN), например rgrimes@banneretcs.com. При использовании смарт-карт субъект безопасности может представить свой цифровой сертификат или ключ.

Аутентификация или проверка подлинности (authentication). После того как субъект безопасности вводит с клавиатуры или иным способом предоставляет необходимую для идентификации информацию (например, имя пользователя, маркер безопасности), он должен ввести с клавиатуры или представить частную информацию для аутентификации (например, пароль и PIN-код). В Windows субъект безопасности вводит эту информацию на экране регистрации с помощью программ Microsoft Graphical Identification and Authentication DLL (msgina.dll) и Winlogon.exe. Протокол аутентификации и механизм системы кодируют представленную информацию на настольном компьютере и передают запрос аутентификации. Служба аутентификации Windows может быть базой данных SAM или AD. База данных SAM обслуживает локальные процедуры регистрации и регистрацию на контроллерах домена Windows NT 4.0. AD аутентифицирует запросы в Windows 2000 или доменах более поздних версий этой операционной системы. Протокол аутентификации (например, LAN Manager, NT LAN Manager, NTLM, NTLMv2, Kerberos) используется для транспортировки запросов аутентификации и последующих транзакций между экраном регистрации и службой аутентификации. Чуть ниже каждый протокол аутентификации будет рассмотрен отдельно.

Авторизация (authorization). Если служба аутентификации удостоверяет комбинацию идентификатора и «секретных» данных аутентификации, то подлинность субъекта безопасности считается успешно подтвержденной. Затем система собирает информацию о членстве субъекта безопасности (т. е. пользователя) в группах. Нередко пользователь принадлежит к нескольким точно определенным группам — локальным (local), доменным (domain local), глобальным (global) и универсальным (universal) — в результате обычных процедур назначения членства. Система сверяет локальные группы с локальной базой данных SAM и проверяет локальные и глобальные группы на контроллерах DC в домашнем домене пользователя, а также универсальные группы на DC, который содержит глобальный каталог Global Catalog. Прямо или косвенно система собирает все сведения о членстве в группах, чтобы получить информацию о разрешениях безопасности.

Сразу после аутентификации система собирает идентификаторы SID учетной записи и сведения о членстве в группах в объекте, называемом маркером доступа (access token). Возможно, пользователю придется выйти и вновь зарегистрироваться в системе, чтобы новые разрешения безопасности вступили в силу. Если пользователю нужно получить доступ к объекту (например, файлу, папке, принтеру, разделу реестра), защищенному разрешениями NTFS, то процесс (например, Windows Explorer), выступающий от имени пользователя, предоставляет свой маркер доступа. Каждый объект NTFS располагает списком элементов управления доступом (access control entry, ACE), которые, в сущности, представляют собой знакомые разрешения NTFS (например, Allow Read, Allow Write). Набор элементов ACE, назначенных пользователям и группам, составляет список управления доступом (ACL) данного объекта. Примечательно, что ACL объекта представлен разрешениями безопасности, которые можно просмотреть в Windows Explorer.

Маркер доступа, содержащий учетную запись и группы, с которыми связан пользователь, определяет эффективные разрешения пользователя. Процесс авторизации заключается в разрешении или отказе в доступе к определенному объекту на основе сравнения маркера доступа с ACL объекта. Авторизацию обеспечивает Security Reference Monitor системы Windows (экран 1). В примере, показанном на экране 1, пользователь имеет разрешения Read, Write и Modify. Однако группа Everyone, к которой принадлежит пользователь, не имеет разрешения Modify. Члены других групп располагают разрешениями Read и Modify, но разрешение Deny группы Everyone отменяет разрешение Modify. Объект также располагает списками ACL, которые отказывают в разрешении Full Control группе HR, но пользователь к этой группе не принадлежит. Таким образом, эффективные разрешения пользователя по отношению к объекту на экране 2 — Read и Write.

Отчетность (accounting). Если в Windows режим аудита активизирован, то система сохраняет событие аутентификации в журнале Security, и это последний компонент системы управления доступом — отчетность. Большинство сложных событий начальной регистрации и последующей авторизации происходят за несколько секунд и скрыты от пользователя. Все сложные операции возлагаются на протокол аутентификации.

Задачи протокола

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

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

Компьютер получает данные для идентификации и аутентификации от пользователя и запрашивает аутентификацию на соответствующем сервере.
Сервер аутентификации генерирует случайное произвольное значение (называемое запросом — challenge) и посылает его запросчику.
Запросчик получает запрос и производит над ним и скрытой формой пароля математические операции, а затем передает результат (называемый ответом — response) серверу аутентификации.
Сервер аутентификации также выполняет математические манипуляции с запросом методом, идентичным используемому на рабочей станции, и сравнивает результат с полученным ответом. Если результаты совпадают, то запросчик считается успешно аутентифицированным.

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

Локальная и доменная регистрация

При регистрации пользователя одна из первых задач Windows — определить, относится ли процедура только к локальной машине или к учетной записи домена. Пользователи, регистрирующиеся от имени локальной учетной записи, имеют доступ только к ресурсам своего компьютера и только если информация об учетной записи пользователя содержится в локальной базе данных SAM. Если пользователям нужно обратиться к ресурсам на удаленном компьютере без аутентификации в домене, то их учетные записи должны быть продублированы в локальной базе данных SAM каждого доступного компьютера. Учетные записи в каждом компьютере-участнике должны быть синхронизированы (одинаковые имена регистрации, пароли и сроки действия учетных данных на всех машинах). В противном случае положение значительно усложняется. Трудно обслуживать одноранговые (P2P) сети средних размеров, в которых применяются только локальные процедуры регистрации.

На DC не распространяется требование синхронизации нескольких учетных записей пользователей на разных компьютерах. При доменной аутентификации компьютеры, зарегистрированные в домене, отыскивают контроллеры DC, чтобы предъявить учетные данные доменной учетной записи пользователя при запросах аутентификации. Таким образом, если удаленный пользователь пытается получить доступ к локальному ресурсу какой-нибудь машины, то этот компьютер просит DC проверить идентичность запрашивающего пользователя. Учетные записи пользователя домена располагаются только на DC и создаются лишь один раз. Любой компьютер-участник, которому нужно удостоверить учетную запись в домене, может обратиться к контроллерам DC в любое время. Проблемы синхронизации имен регистрации, паролей и сроков их действия не возникает, так как учетные данные и управление учетной записью осуществляются только в одном месте — на DC. Независимо от типа регистрации (локальной или доменной), Windows должна аутентифицировать запрос пользователя.

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

Как отмечалось выше, в Windows применяется четыре основных протокола аутентификации: LAN Manager, NTLM, NTLMv2 и Kerberos. LAN Manager появился во времена DOS и продолжал использоваться с первыми версиями Windows. NTLM был выпущен вместе с NT. Новшеством пакета обновлений NT Server 4.0 Service Pack 4 (SP4) стал NTLMv2, а Windows 2000 привнесла Kerberos. По умолчанию все компьютеры с Windows 2000 и более новыми операционными системами совместимы со всеми четырьмя протоколами аутентификации. Передавая в эти системы соответствующие команды, другие рабочие станции и серверы могут выбирать протокол для обработки запроса аутентификации. Системы Windows 9x и более поздние с полным набором программных исправлений совместимы с LM, NTLM и NTLMv2. На платформе Microsoft Kerberos может использоваться только клиентами Windows 2000 (или более новыми) при обращениях в домены Windows 2000 (и выше). Компьютер с Windows 2000 или более новой версией операционной системы должен иметь Kerberos и по крайней мере еще один из протоколов аутентификации.

Исследования в области безопасности показали, что более старые протоколы (LM и NTLM) уязвимы в случае прослушивания и атак с разгадыванием пароля.

Поэтому, если возможно, рекомендуется использовать только Kerberos и NTLMv2. Чтобы убедиться в правильности этого совета, следует оценить возможности каждого протокола.

LAN Manager

Компания IBM разработала протокол LAN Manager, применив его в ранних версиях Windows и сетях Windows. Как все протоколы аутентификации Microsoft, LAN Manager генерирует хеш паролей (LM hash), который хранится и используется отправителем и получателем в процессе аутентификации. LAN Manager формирует LM-хеши, изменяя все буквы пароля на верхний регистр, разбивая пароль на две 7-символьные половины, а затем шифруя. В дальнейшем LM-хеш используется в нескольких последовательных операциях, аналогичных процессу запрос—ответ, описанному выше.

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

пароли могут состоять из ограниченной последовательности 128 символов ASCII;
длина пароля не превышает 14 символов;
если пароль содержит менее 14 символов, то отсутствующие символы заменяются легко угадываемой хешированной формой, что позволяет точно определить длину пароля;
перед кэшированием LAN Manager преобразует все буквенные символы пароля в верхний регистр.

Почему LAN Manager до сих пор не вышел из употребления? В целях обратной совместимости он активен по умолчанию во всех компьютерах Windows, в том числе Windows Server 2003. В новейших базах данных аутентификации Windows слабый LM-хеш хранится наряду с более надежными просто на случай, если придется выполнить транзакцию LAN Manager. Если на предприятии не используются другие приложения, требующие аутентификации LAN Manager, то можно (и нужно) LAN Manager отключить.

NTLM

С появлением NT компания Microsoft спроектировала и развернула более надежный протокол аутентификации NTLM. В NTLM используется более эффективный алгоритм аутентификации, который создает более надежный хеш паролей (NTLM hash). Пароль NTLM может содержать до 128 символов. В отличие от хеширования LAN Manager, ограниченного использованием только символов ASCII, NTLM совместим с полным набором символов Unicode, что повышает сложность паролей. NTLM-хеш отсекается на 128-м символе, преобразуется в 16-разрядное значение Unicode, обрабатывается распределительной функцией MD4 и сохраняется в 32-символьной шестнадцатеричной строке. За счет использования NTLM-хеша в операциях запрос—ответ последовательность аутентификации NTLM гораздо сложнее процедуры LAN Manager.

NTLMv2

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

В целом NTLMv2 более устойчив к атакам с применением «грубой силы», нежели NTLM, так как в протоколе применяется 128-разрядный ключ шифрования. Известно только о двух программах взлома паролей (одна из них — LC5 компании Symantec), с помощью которых удавалось открыть хеши паролей NTLMv2.

Kerberos

Компания Microsoft приняла Kerberos в качестве выбираемого по умолчанию протокола доменной аутентификации для доменов Windows 2000, а затем и AD. Kerberos — открытый стандарт, пригодный для взаимодействия с инородными доменами (называемыми областями — realm — в UNIX и Linux). Каждый DC в доменах AD играет роль сервера распределения (Kerberos Distribution Server, KDC) и может участвовать в процедуре аутентификации. Безопасность повышается благодаря следующим характеристикам Kerberos:

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

Краткое описание работы Kerberos:

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

Следует обратить внимание, что, хотя принцип работы Kerberos напоминает инфраструктуру с частным открытым ключом (public key infrastructure, PKI), вся информация защищается с использованием симметричных ключей (в отличие от асимметричных ключей, применяемых в большинстве служб аутентификации).

Смарт-карты

Надежность паролей и других методов аутентификации на основе одного параметра быстро снижается. Электронная коммерция проникает в повседневную жизнь и возрастает как число способов кражи личных данных (спам, мошенничество с URL), так и вероятность злоупотреблений паролями. Многие специалисты считают, что аутентификация с двумя параметрами — в форме смарт-карт, USB-устройств или других криптографических устройств — в будущем станет обычным явлением для транзакций в Internet. Разработчики Microsoft встраивают в свои решения функции для работы с цифровыми сертификатами и смарт-картами. Для использования смарт-карт необходимо установить службу Certificate Services и распространить сертификаты смарт-карт. Конечно, нужны также физические смарт-карты, устройства считывания и программное обеспечение поставщика. Затем при необходимости пользователи могут вставлять свои смарт-карты в локальные устройства чтения для доступа к компьютеру Windows. При грамотном использовании смарт-карты могут существенно повысить надежность аутентификации.

Защита протокола аутентификации

В некоторых статьях ошибочно утверждается, что взломать механизм аутентификации Microsoft по-прежнему просто. В действительности из 20 существующих инструментов взлома пароля только два работают с NTLMv2 и лишь один — с Kerberos. Но, предприняв несколько простых шагов, можно отвести и эту угрозу. Для предотвращения попыток разгадывания и сброса пароля нужно принять следующие меры (большинство параметров можно настроить локально или с помощью Group Policy).

Отключить хранение LM-хешей, как описано в статье Microsoft «How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases» (http://support.microsoft.com/ default.aspx?scid=kb;en-us;299656). Это делается для того, чтобы помешать взломщикам открыть исходный пароль.
Отключить все протоколы аутентификации, кроме NTLMv2 и Kerberos (после исчерпывающего тестирования). Процедура описана в статье Microsoft TechNet «Network security: LAN Manager authentication level» (http://www.microsoft.com/resources/ documentation/windowsserv/2003/ standard/proddocs/en-us/576.asp).
Запретить начальную загрузку со сменных носителей, чтобы предотвратить запуск инструментов взлома пароля в обход операционной системы. Запрет начальной загрузки со всех дисков, кроме выбираемого по умолчанию, предотвращает доступ автономных программ взлома пароля к базе данных аутентификации, где хранятся хеши паролей.
Пользователи должны назначать сложные пароли длиной не менее 8 символов.
Пользователи должны менять свои пароли по крайней мере раз в квартал.
Активизировать блокировку учетной записи хотя бы на одну минуту с автоматическим сбросом. Это предотвращает разгадывание паролей в сети.

Обязанности пользователей

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

Роджер Граймз — Редактор Windows IT Pro и консультант по проблемам безопасности. Имеет сертификаты CPA, CISSP, CEH, CHFI, TICSA, MCT, MCSE: Security и Security+. roger@banneretcs.com

Источник

Записки IT специалиста

Работая в среде 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_MACHINESYSTEMCurrentControlSetServicesLsa нужно создать параметр 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.

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

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

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

Текст лекции

SPNEGO

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

Обобщенный интерфейс безопасности 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 . Другие являются ошибками проектирования, третьи — исключительно криптографические.

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 и тем самым каждый предыдущий шифрблок используется для модифицирования очередного блока открытого текста.

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

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

— сервер , — клиент, — начало и окончание действия мандата ,

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

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

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

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

Источник

Обзор способов и протоколов аутентификации в веб-приложениях

Время прочтения
18 мин

Просмотры 537K

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

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

Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

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

Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.

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

Аутентификация по паролю

Этот метод основывается на том, что пользователь должен предоставить username и password для успешной идентификации и аутентификации в системе. Пара username/password задается пользователем при его регистрации в системе, при этом в качестве username может выступать адрес электронной почты пользователя.

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

HTTP authentication

Этот протокол, описанный в стандартах HTTP 1.0/1.1, существует очень давно и до сих пор активно применяется в корпоративной среде. Применительно к веб-сайтам работает следующим образом:

Сервер, при обращении неавторизованного клиента к защищенному ресурсу, отсылает HTTP статус “401 Unauthorized” и добавляет заголовок “WWW-Authenticate” с указанием схемы и параметров аутентификации.
Браузер, при получении такого ответа, автоматически показывает диалог ввода username и password. Пользователь вводит детали своей учетной записи.
Во всех последующих запросах к этому веб-сайту браузер автоматически добавляет HTTP заголовок “Authorization”, в котором передаются данные пользователя для аутентификации сервером.
Сервер аутентифицирует пользователя по данным из этого заголовка. Решение о предоставлении доступа (авторизация) производится отдельно на основании роли пользователя, ACL или других данных учетной записи.

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

Basic — наиболее простая схема, при которой username и password пользователя передаются в заголовке Authorization в незашифрованном виде (base64-encoded). Однако при использовании HTTPS (HTTP over SSL) протокола, является относительно безопасной.

Пример HTTP аутентификации с использованием Basic схемы.
Digest — challenge-response-схема, при которой сервер посылает уникальное значение nonce, а браузер передает MD5 хэш пароля пользователя, вычисленный с использованием указанного nonce. Более безопасная альтернативв Basic схемы при незащищенных соединениях, но подвержена man-in-the-middle attacks (с заменой схемы на basic). Кроме того, использование этой схемы не позволяет применить современные хэш-функции для хранения паролей пользователей на сервере.
NTLM (известная как Windows authentication) — также основана на challenge-response подходе, при котором пароль не передается в чистом виде. Эта схема не является стандартом HTTP, но поддерживается большинством браузеров и веб-серверов. Преимущественно используется для аутентификации пользователей Windows Active Directory в веб-приложениях. Уязвима к pass-the-hash-атакам.
Negotiate — еще одна схема из семейства Windows authentication, которая позволяет клиенту выбрать между NTLM и Kerberos аутентификацией. Kerberos — более безопасный протокол, основанный на принципе Single Sign-On. Однако он может функционировать, только если и клиент, и сервер находятся в зоне intranet и являются частью домена Windows.

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

Forms authentication

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

Работает это по следующему принципу: в веб-приложение включается HTML-форма, в которую пользователь должен ввести свои username/password и отправить их на сервер через HTTP POST для аутентификации. В случае успеха веб-приложение создает session token, который обычно помещается в browser cookies. При последующих веб-запросах session token автоматически передается на сервер и позволяет приложению получить информацию о текущем пользователе для авторизации запроса.

Пример forms authentication.

Приложение может создать session token двумя способами:

Как идентификатор аутентифицированной сессии пользователя, которая хранится в памяти сервера или в базе данных. Сессия должна содержать всю необходимую информацию о пользователе для возможности авторизации его запросов.
Как зашифрованный и/или подписанный объект, содержащий данные о пользователе, а также период действия. Этот подход позволяет реализовать stateless-архитектуру сервера, однако требует механизма обновления сессионного токена по истечении срока действия. Несколько стандартных форматов таких токенов рассматриваются в секции «Аутентификация по токенам».

Необходимо понимать, что перехват session token зачастую дает аналогичный уровень доступа, что и знание username/password. Поэтому все коммуникации между клиентом и сервером в случае forms authentication должны производиться только по защищенному соединению HTTPS.

Другие протоколы аутентификации по паролю

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

Существует всего несколько мест, где можно передать username и password в HTTP запросах:

URL query — считается небезопасным вариантом, т. к. строки URL могут запоминаться браузерами, прокси и веб-серверами.
Request body — безопасный вариант, но он применим только для запросов, содержащих тело сообщения (такие как POST, PUT, PATCH).
HTTP header —оптимальный вариант, при этом могут использоваться и стандартный заголовок Authorization (например, с Basic-схемой), и другие произвольные заголовки.

Распространенные уязвимости и ошибки реализации

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

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

Веб-приложение позволяет пользователям создавать простые пароли.

Веб-приложение не защищено от возможности перебора паролей (brute-force attacks).

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

Веб-приложение допускает передачу паролей по незащищенному HTTP-соединению, либо в строке URL.

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

Веб-приложение не предоставляет пользователям возможность изменения пароля либо не нотифицирует пользователей об изменении их паролей.

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

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

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

Веб-приложение допускает передачу session tokens по незащищенному HTTP-соединению, либо в строке URL.

Веб-приложение уязвимо для session fixation-атак (т. е. не заменяет session token при переходе анонимной сессии пользователя в аутентифицированную).

Веб-приложение не устанавливает флаги HttpOnly и Secure для browser cookies, содержащих session tokens.

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

Аутентификация по сертификатам

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

На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.

В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.

Использование сертификата для аутентификации.

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

Сертификат должен быть подписан доверенным certification authority (проверка цепочки сертификатов).
Сертификат должен быть действительным на текущую дату (проверка срока действия).
Сертификат не должен быть отозван соответствующим CA (проверка списков исключения).

Пример X.509 сертификата.

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

Использование сертификатов для аутентификации — куда более надежный способ, чем аутентификация посредством паролей. Это достигается созданием в процессе аутентификации цифровой подписи, наличие которой доказывает факт применения закрытого ключа в конкретной ситуации (non-repudiation). Однако трудности с распространением и поддержкой сертификатов делает такой способ аутентификации малодоступным в широких кругах.

Аутентификация по одноразовым паролям

Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации two-factor authentication (2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.

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

Существуют разные источники для создания одноразовых паролей. Наиболее популярные:

Аппаратные или программные токены, которые могут генерировать одноразовые пароли на основании секретного ключа, введенного в них, и текущего времени. Секретные ключи пользователей, являющиеся фактором владения, также хранятся на сервере, что позволяет выполнить проверку введенных одноразовых паролей. Пример аппаратной реализаций токенов — RSA SecurID; программной — приложение Google Authenticator.
Случайно генерируемые коды, передаваемые пользователю через SMS или другой канал связи. В этой ситуации фактор владения — телефон пользователя (точнее — SIM-карта, привязанная к определенному номеру).
Распечатка или scratch card со списком заранее сформированных одноразовых паролей. Для каждого нового входа в систему требуется ввести новый одноразовый пароль с указанным номером.

Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.

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

Аутентификация по ключам доступа

Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (access key, API key) — длинные уникальные строки, содержащие произвольный набор символов, по сути заменяющие собой комбинацию username/password.

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

Хороший пример применения аутентификации по ключу — облако Amazon Web Services. Предположим, у пользователя есть веб-приложение, позволяющее загружать и просматривать фотографии, и он хочет использовать сервис Amazon S3 для хранения файлов. В таком случае, пользователь через консоль AWS может создать ключ, имеющий ограниченный доступ к облаку: только чтение/запись его файлов в Amazon S3. Этот ключ в результате можно применить для аутентификации веб-приложения в облаке AWS.

Пример применения аутентификации по ключу.

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

С технической точки зрения, здесь не существует единого протокола: ключи могут передаваться в разных частях HTTP-запроса: URL query, request body или HTTP header. Как и в случае аутентификации по паролю, наиболее оптимальный вариант — использование HTTP header. В некоторых случаях используют HTTP-схему Bearer для передачи токена в заголовке (Authorization: Bearer [token]). Чтобы избежать перехвата ключей, соединение с сервером должно быть обязательно защищено протоколом SSL/TLS.

Пример аутентификации по ключу доступа, переданного в HTTP заголовке.

Кроме того, существуют более сложные схемы аутентификации по ключам для незащищенных соединений. В этом случае, ключ обычно состоит их двух частей: публичной и секретной. Публичная часть используется для идентификации клиента, а секретная часть позволяет сгенерировать подпись. Например, по аналогии с digest authentication схемой, сервер может послать клиенту уникальное значение nonce или timestamp, а клиент — возвратить хэш или HMAC этого значения, вычисленный с использованием секретной части ключа. Это позволяет избежать передачи всего ключа в оригинальном виде и защищает от replay attacks.

Аутентификация по токенам

Такой способ аутентификации чаще всего применяется при построении распределенных систем Single Sign-On (SSO), где одно приложение (service provider или relying party) делегирует функцию аутентификации пользователей другому приложению (identity provider или authentication service). Типичный пример этого способа — вход в приложение через учетную запись в социальных сетях. Здесь социальные сети являются сервисами аутентификации, а приложение

доверяет

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

Реализация этого способа заключается в том, что identity provider (IP) предоставляет достоверные сведения о пользователе

в виде токена

, а service provider (SP) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.
На общем уровне, весь процесс выглядит следующим образом:

Клиент аутентифицируется в identity provider одним из способов, специфичным для него (пароль, ключ доступа, сертификат, Kerberos, итд.).
Клиент просит identity provider предоставить ему токен для конкретного SP-приложения. Identity provider генерирует токен и отправляет его клиенту.
Клиент аутентифицируется в SP-приложении при помощи этого токена.

Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.

Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. е. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же — пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем. В этом случае аутентификация достигается посредством автоматического перенаправления браузера между веб-приложениями identity provider и service provider.

Пример аутентификации «пассивного» клиента посредством перенаправления запросов.

Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.

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

При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:

Токен был выдан доверенным identity provider приложением (проверка поля issuer).
Токен предназначается текущему SP-приложению (проверка поля audience).
Срок действия токена еще не истек (проверка поля expiration date).
Токен подлинный и не был изменен (проверка подписи).

В случае успешной проверки SP-приложение выполняет авторизацию запроса на основании данных о пользователе, содержащихся в токене.

Форматы токенов

Существует несколько распространенных форматов токенов для веб-приложений:

Simple Web Token (SWT) — наиболее простой формат, представляющий собой набор произвольных пар имя/значение в формате кодирования HTML form. Стандарт определяет несколько зарезервированных имен: Issuer, Audience, ExpiresOn и HMACSHA256. Токен подписывается с помощью симметричного ключа, таким образом оба IP- и SP-приложения должны иметь этот ключ для возможности создания/проверки токена.
Пример SWT токена (после декодирования).

Issuer=http://auth.myservice.com&
Audience=http://myservice.com&
ExpiresOn=1435937883&
UserName=John Smith&
UserRole=Admin&
HMACSHA256=KOUQRPSpy64rvT2KnYyQKtFFXUIggnesSpE7ADA4o9w
JSON Web Token (JWT) — содержит три блока, разделенных точками: заголовок, набор полей (claims) и подпись. Первые два блока представлены в JSON-формате и дополнительно закодированы в формат base64. Набор полей содержит произвольные пары имя/значения, притом стандарт JWT определяет несколько зарезервированных имен (iss, aud, exp и другие). Подпись может генерироваться при помощи и симметричных алгоритмов шифрования, и асимметричных. Кроме того, существует отдельный стандарт, отписывающий формат зашифрованного JWT-токена.
Пример подписанного JWT токена (после декодирования 1 и 2 блоков).

{ «alg»: «HS256», «typ»: «JWT» }.
{ «iss»: «auth.myservice.com», «aud»: «myservice.com», «exp»: «1435937883», «userName»: «John Smith», «userRole»: «Admin» }.
S9Zs/8/uEGGTVVtLggFTizCsMtwOJnRhjaQ2BMUQhcY
Security Assertion Markup Language (SAML) — определяет токены (SAML assertions) в XML-формате, включающем информацию об эмитенте, о субъекте, необходимые условия для проверки токена, набор дополнительных утверждений (statements) о пользователе. Подпись SAML-токенов осуществляется при помощи ассиметричной криптографии. Кроме того, в отличие от предыдущих форматов, SAML-токены содержат механизм для подтверждения владения токеном, что позволяет предотвратить перехват токенов через man-in-the-middle-атаки при использовании незащищенных соединений.

Стандарт SAML

Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.

Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:

Assertions — собственный формат SAML токенов в XML формате.
Protocols — набор поддерживаемых сообщений между участниками, среди которых — запрос на создание нового токена, получение существующих токенов, выход из системы (logout), управление идентификаторами пользователей, и другие.
Bindings — механизмы передачи сообщений через различные транспортные протоколы. Поддерживаются такие способы, как HTTP Redirect, HTTP POST, HTTP Artifact (ссылка на сообщения), SAML SOAP, SAML URI (адрес получения сообщения) и другие.
Profiles — типичные сценарии использования стандарта, определяющие набор assertions, protocols и bindings необходимых для их реализации, что позволяет достичь лучшей совместимости. Web Browser SSO — один из примеров таких профилей.

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

Рассмотрим краткий пример использования SAML для сценария Single Sign-On. Пользователь хочет получить доступ на защищенный ресурс сервис-провайдера (шаг № 1 на диаграмме аутентификации пассивных клиентов). Т. к. пользователь не был аутентифицирован, SP отправляет его на сайт identity provider’а для создания токена (шаг № 2). Ниже приведен пример ответа SP, где последний использует SAML HTTP Redirect binding для отправки сообщения с запросом токена:

В случае такого запроса, identity provider аутентифицирует пользователя (шаги №3-4), после чего генерирует токен. Ниже приведен пример ответа IP с использованием HTTP POST binding (шаг № 5):

После того как браузер автоматически отправит эту форму на сайт service provider’а (шаг № 6), последний декодирует токен и аутентифицирует пользователя. По результатам успешной авторизации запроса пользователь получает доступ к запрошенному ресурсу (шаг № 7).

Стандарты WS-Trust и WS-Federation

WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.

Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.

Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:

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

Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.

Стандарты OAuth и OpenID Connect

В отличие от SAML и WS-Federation, стандарт OAuth (Open Authorization) не описывает протокол аутентификации пользователя. Вместо этого он определяет механизм получения доступа одного приложения к другому от имени пользователя. Однако существуют схемы, позволяющие осуществить аутентификацию пользователя на базе этого стандарта (об этом — ниже).

Первая версия стандарта разрабатывалась в 2007 – 2010 гг., а текущая версия 2.0 опубликована в 2012 г. Версия 2.0 значительно расширяет и в то же время упрощает стандарт, но обратно несовместима с версией 1.0. Сейчас OAuth 2.0 очень популярен и используется повсеместно для предоставления делегированного доступа и третье-сторонней аутентификации пользователей.

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

> Попросить пользователя указать данные своей учетной записи? — плохой вариант.
> Попросить пользователя создать ключ доступа? — возможно, но весьма сложно.

Как раз эту проблему и позволяет решить стандарт OAuth: он описывает, как приложение путешествий (client) может получить доступ к почте пользователя (resource server) с разрешения пользователя (resource owner). В общем виде весь процесс состоит из нескольких шагов:

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

Взаимодействие компонентов в стандарте OAuth.

Стандарт описывает четыре вида грантов, которые определяют возможные сценарии применения:

Authorization Code — этот грант пользователь может получить от сервера авторизации после успешной аутентификации и подтверждения согласия на предоставление доступа. Такой способ наиболее часто используется в веб-приложениях. Процесс получения гранта очень похож на механизм аутентификации пассивных клиентов в SAML и WS-Federation.
Implicit — применяется, когда у приложения нет возможности безопасно получить токен от сервера авторизации (например, JavaScript-приложение в браузере). В этом случае грант представляет собой токен, полученный от сервера авторизации, а шаг № 2 исключается из сценария выше.
Resource Owner Password Credentials — грант представляет собой пару username/password пользователя. Может применяться, если приложение является «интерфейсом» для сервера ресурсов (например, приложение — мобильный клиент для Gmail).
Client Credentials — в этом случае нет никакого пользователя, а приложение получает доступ к своим ресурсам при помощи своих ключей доступа (исключается шаг № 1).

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

Зачастую API сервера ресурсов включает операцию, предоставляющую информацию о самом пользователе (например, /me в Facebook API). Приложение может выполнять эту операцию каждый раз после получения токена для идентификации клиента. Такой метод иногда называют псевдо-аутентификацией.
Использовать стандарт OpenID Connect, разработанный как слой учетных данных поверх OAuth (опубликован в 2014 г.). В соответствии с этим стандартом, сервер авторизации предоставляет дополнительный identity token на шаге № 2. Этот токен в формате JWT будет содержать набор определенных полей (claims) с информацией о пользователе.

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

Заключение

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

Способ

Основное применение

Протоколы

По паролю

Аутентификация пользователей

HTTP, Forms

По сертификатам

Аутентификация пользователей в безопасных приложениях; аутентификация сервисов

SSL/TLS

По одноразовым паролям

Дополнительная аутентификация пользователей (для достижения two-factor authentication)

Forms

По ключам доступа

Аутентификация сервисов и приложений

—

По токенам

Делегированная аутентификация пользователей; делегированная авторизация приложений

SAML, WS-Federation, OAuth, OpenID Connect

Надеюсь, что информация оказалась полезна, и вы сможете применить ее при дизайне и разработке новых приложений. До новых встреч!

Автор: Дмитрий Выростков, Solutions Architect в DataArt.

Источник