Протоколы, составляющие основу процедуры
Аутентификация — это незаменимая процедура для каждого пользователя, компьютера и служебной учетной записи 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
Если служба
аутентификации удостоверяет комбинацию
идентификатора и «секретных» данных
аутентификации, то подлинность субъекта
безопасности считается успешно
подтвержденной.
Затем система
собирает информацию о членстве субъекта
безопасности (т. е. пользователя) в
группах. Нередко пользователь принадлежит
к нескольким точно определенным группам
— локальным (Local),
доменным (Domain
Local),
глобальным (Global)
и универсальным (Universal)
— в результате обычных процедур
назначения членства.
Прямо или
косвенно система собирает все сведения
о членстве в группах, чтобы получить
информацию о разрешениях безопасности.
Сразу после
аутентификации система собирает
идентификаторы SID учетной записи и
сведения о членстве в группах в объекте,
называемом маркером
доступа
(Access
Token).
Если пользователю
нужно получить доступ к объекту (например,
файлу, папке, принтеру, разделу реестра),
защищенному разрешениями NTFS, то процесс
(например, Windows Explorer), выступающий от
имени пользователя, предоставляет свой
маркер доступа.
Каждый объект NTFS
располагает списком элементов управления
доступом Access
Control
Entry
(ACE), которые, в сущности, представляют
собой знакомые разрешения NTFS (например,
Allow Read – разрешить чтение, Allow Write –
разрешить запись). Набор элементов ACE,
назначенных пользователям и группам,
составляет список управления доступом
Access
Control
List
(ACL) данного объекта.
Маркер доступа,
содержащий учетную запись и группы, с
которыми связан пользователь, определяет
эффективные разрешения пользователя.
Процесс
авторизации заключается в разрешении
или отказе в доступе к определенному
объекту на основе сравнения маркера
доступа с ACL объекта.
Авторизацию обеспечивает Security Reference
Monitor (справочный монитор безопасности)
системы Windows .
4.Отчетность
Отчетность
(Accounting). Если в Windows режим аудита
активизирован, то система сохраняет
событие аутентификации в журнале
Security, и это последний компонент системы
управления доступом – отчетность.
Большинство сложных событий начальной
регистрации и последующей авторизации
происходят за несколько секунд и скрыты
от пользователя. Все сложные операции
возлагаются на протокол аутентификации.
Локальная и доменная регистрация
При регистрации
пользователя одна из первых задач
Windows – определить, относится ли процедура
только к локальной машине или к учетной
записи домена. Пользователи, регистрирующиеся
от имени локальной учетной записи, имеют
доступ только к ресурсам своего компьютера
и только если информация об учетной
записи пользователя содержится в
локальной базе данных SAM. Если пользователям
нужно обратиться к ресурсам на удаленном
компьютере без
аутентификации в домене,
то их учетные записи должны быть
продублированы в локальной базе данных
SAM каждого доступного компьютера. Учетные
записи в каждом компьютере-участнике
должны быть синхронизированы (одинаковые
имена регистрации, пароли и сроки
действия учетных данных на всех машинах).
В противном случае положение значительно
усложняется. Трудно обслуживать
одноранговые (P2P) сети средних размеров,
в которых применяются только локальные
процедуры регистрации.
На контроллер
домена не распространяется требование
синхронизации нескольких учетных
записей пользователей на разных
компьютерах. При доменной аутентификации
компьютеры, зарегистрированные в домене,
отыскивают контроллеры домена, чтобы
предъявить учетные данные доменной
учетной записи пользователя при запросах
аутентификации. Таким образом, если
удаленный пользователь пытается получить
доступ к локальному ресурсу какой-нибудь
машины, то этот компьютер просит
контроллер домена проверить аутентичность
запрашивающего пользователя. Учетные
записи пользователя домена располагаются
только на контроллере домена и создаются
лишь один раз. Любой компьютер-участник,
которому нужно удостоверить учетную
запись в домене, может обратиться к
контроллерам домена в любое время.
Проблемы синхронизации имен регистрации,
паролей и сроков их действия не возникает,
так как учетные данные и управление
учетной записью осуществляются только
в одном месте – на контроллере домена.
Независимо от типа регистрации (локальной
или доменной), Windows должна аутентифицировать
запрос пользователя.
Соседние файлы в папке лк
- #
02.02.2021530.94 Кб40Л9.ppt
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
Аутентификация и авторизация
В операционной системе Windows 7 реализовано новое поколение технологий безопасности для рабочего стола и одна из них аутентификация и авторизация. Часть технологий направлена на укрепление общей инфраструктуры Windows, а остальные на оказание помощи в управлении системой и пользовательскими данными.
Прежде чем устанавливать в Windows 7 эффективные меры безопасности, например, для совместного пользования файлами и папками, важно понимать используемые во время настройки безопасности типы учетных записей пользователей, и как сетевой протокол аутентифицирует и авторизует вход пользователей в систему.
Что такое аутентификация и авторизация?
Аутентификация — это процесс, используемый для подтверждения личности пользователя, при обращении его к компьютерной системе или дополнительным системным ресурсам. В частных и государственных компьютерных сетях (включая Интернет) наиболее часто для аутентификации предполагается проверка учетных данных пользователя; то есть, имя пользователя и пароль. Однако для типов критических транзакций, например обработка платежей, проверки подлинности имени пользователя и пароля не достаточно, так как пароли могут быть украдены или взломаны. По этой причине, основная часть интернет-бизнеса, а также многие другие сделки теперь используют цифровые сертификаты, которые выдаются и проверяются центром сертификации.
Аутентификация логически предшествует авторизации. Авторизация позволяет системе определить, может ли заверенный пользователь получить доступ и возможность обновить защищенные системные ресурсы. Авторизация позволяет установить директивный доступ к папкам и файлам, часы доступа, размер разрешенного места для хранения, и так далее.
Есть два варианта авторизации:
- Изменения системных ресурсов первоначально разрешены системным администратором.
- При попытке пользователя получить доступ или обновить системный ресурс разрешение на действие оценивается системой или приложением.
Последний вариант позволяет пользователю получить доступ без аутентификации и авторизации. Он используется в случае, когда требуется предоставить доступ для анонимных не проходящих аутентификацию пользователей. Такой доступ, как правило, весьма ограничен.
Процесс авторизации и аутентификации.
Для получения доступа к файлам в сети пользователи для проверки их личности должны проходить аутентификацию. Это делается во время процесса входа в сеть. Операционная система Windows 7 для входа в сеть имеет следующие методы аутентификации:
- Протокол Kerberos версии 5: Основной метод аутентификации клиентов и серверов под управлением операционных систем Microsoft Windows. Он используется для проверки подлинности учетных записей пользователей и учетных записей компьютеров.
- Windows NT LAN Manager (NTLM): используется для обратной совместимости с операционными системами более старыми, чем Windows 2000 и некоторых приложений. Он менее гибок, эффективен и безопасен, чем протокол Kerberos версии 5.
- Сопоставление сертификатов: обычно используется для проверки подлинности при входе в сочетании со смарт-картой. Сертификат, записанный на смарт-карте, связан с учетной записью пользователя. Для чтения смарт-карт и аутентификации пользователя используется считыватель смарт-карт.
Новые функции аутентификации в Windows 7.
Целый ряд улучшений, связанных с процессами входа и проверки подлинности пользователя был добавлен еще в Windows Vista ®. Эти усовершенствования увеличили базовый набор функции проверки подлинности, чтобы помогло обеспечить лучшую безопасность и управляемость. В Windows 7 Microsoft продолжает начатые в Windows Vista усовершенствования, предоставляя следующие новые функции аутентификации:
- Смарт-карты
- Биометрия
- Интеграция личности в Интернете.
Смарт-карты.
Использование смарт-карт самый распространенный метод аутентификации. Для поощрения применения организациями и пользователями смарт-карт, Windows 7 предлагает новые возможности, облегчающие их использование и развертывание. Эти новые возможности позволяют использовать смарт-карты для выполнения разнообразных задач, включая:
- Смарт-карты Plug and Play
- Личные удостоверения проверки (PIV), стандарт национального института стандартов и технологий США (NIST)
- Поддержка для входа смарт-карты Kerberos.
- Шифрование дисков BitLocker
- Документы и электронная почта
- Использование с бизнес-приложениями.
Биометрия.
Биометрия — все более популярная технология, обеспечивающая удобный доступ к системам, услугам и ресурсам. Биометрия для однозначного определения человека использует измерение его неизменных физических характеристик. Одна из наиболее часто используемых биометрических характеристик — отпечатки пальцев.
До сих пор в Windows не было стандартной поддержки биометрических устройств. Чтобы решить эту проблему, Windows 7 вводит Windows Biometric Framework (WBF). WBF предоставляет новый набор компонентов, поддерживающий снятие отпечатка пальца с помощью биометрические устройства. Эти компоненты увеличивают безопасность пользователей.
Windows Biometric Framework упрощает пользователям и администраторам настройку и управление биометрическими устройствами на локальном компьютере или в домене.
Интеграция личности в Интернете.
Управление аккаунтом — стратегия обеспечения безопасности. Для разрешения или запрета проверки подлинности определенных компьютеров или всех компьютеров, которыми вы управляете онлайн, используется Групповая политика.
В Windows 7 пользователи в небольшой сети могут выбрать обмен данными между определенными компьютерам на отдельной пользовательской основе. Эта функция в Windows 7 дополняет функцию домашней группы с помощью сетевых удостоверений для идентификации лиц в сети.
Для того, чтобы разрешить эту идентификацию пользователи должны связать свою учетную запись пользователя Windows ID онлайн. Включение в Windows протокола Public Key Cryptography Based User-to-User (PKU2U) разрешает проходить идентификацию при помощи свидетельств.
Интеграцией онлайн идентификации можно управлять политикой группы. Политика, настроенная как: “Сетевая безопасность: Позволить этому компьютеру при запросе идентификации PKU2U использовать ID онлайн”, управляет возможностью ID онлайн подтвердить подлинность этого компьютера при помощи протокола PKU2U. Этот параметр политики не влияет на способность учетных записей доменов или локальных учетных записей пользователей входить на этот компьютер.
Система безопасности Windows — это сложная и многогранная структура, разработанная для защиты пользователя и его данных от различных угроз. База данных безопасности Windows состоит из множества технологий и методов, которые обеспечивают надежную защиту от вредоносных программ, хакерских атак, утечек информации и других угроз.
Одной из основных технологий безопасности Windows является контроль доступа, который позволяет ограничить права пользователей на выполнение определенных операций и доступ к определенным ресурсам. Контроль доступа основан на разделении пользователей на различные уровни доступа и назначении им соответствующих разрешений.
Еще одной важной технологией безопасности является авторизация и аутентификация пользователей. Аутентификация позволяет проверить подлинность пользователя, а авторизация определяет, какие действия пользователь может совершать в системе. Для этого Windows использует механизмы паролей, сертификатов, биометрических данных и других факторов.
Однако, помимо контроля доступа и аутентификации, защита в базе данных безопасности Windows включает и другие методы, такие как криптография, межсетевые экраны, система обнаружения вторжений и множество других инструментов и технологий. Комплексное сочетание этих мер позволяет создать надежную систему безопасности Windows, которая способна эффективно обнаруживать и предотвращать угрозы.
В статье мы рассмотрим подробнее каждую из технологий и методов защиты, которые входят в базу данных безопасности Windows, и изучим их особенности и преимущества. Познакомимся с принципами работы этих технологий, а также узнаем о возможных проблемах и уязвимостях, с которыми может столкнуться пользователь при их использовании.
Содержание
- Официальные методы безопасности Windows
- Защита данных и разграничение доступа
- Аутентификация и авторизация пользователей
Официальные методы безопасности Windows
Windows предлагает набор официальных методов безопасности, которые помогают обеспечить защиту операционной системы и данных пользователей. Эти методы разработаны компанией Microsoft и включают в себя:
Аутентификацию и управление доступом – Windows оснащена механизмами аутентификации, позволяющими проверить подлинность пользователей перед предоставлением доступа к системе. В качестве методов аутентификации могут использоваться пароли, биометрические данные или смарт-карты. С помощью управления доступом можно определить права пользователей на выполнение определенных действий.
Обновления безопасности – Microsoft регулярно выпускает обновления безопасности для операционной системы Windows, чтобы исправлять возникающие уязвимости и улучшать защиту. Установка этих обновлений является важным шагом в поддержании безопасности системы.
Брандмауэр – В Windows встроен межсетевой экран, который контролирует входящие и исходящие сетевые подключения. Брандмауэр способен обнаружить и блокировать нежелательный сетевой трафик, что помогает улучшить безопасность системы.
Windows Defender – Windows поставляется с встроенным антивирусным программным обеспечением Windows Defender. Он защищает систему от вредоносных программ, включая вирусы, шпионское ПО и другие угрозы. Windows Defender регулярно обновляется, чтобы обеспечить более надежную защиту.
BitLocker – Этот инструмент позволяет шифровать данные на жестком диске или на съемных носителях, таких как USB-флеш-накопители. Шифрование данных делает их недоступными для посторонних лиц, даже если физический доступ к носителям получен.
Учетные записи и политики безопасности – Windows позволяет создавать различные учетные записи с разными уровнями доступа. Это позволяет ограничить права пользователя и предотвратить несанкционированный доступ. Кроме того, Windows предлагает различные политики безопасности, которые можно задать для ограничения доступа и повышения безопасности системы.
Аудит безопасности – Windows позволяет настраивать аудит безопасности, что позволяет системным администраторам отслеживать действия пользователей и обнаруживать подозрительную активность. Это помогает рано выявить нарушения безопасности и принять меры по их устранению.
Windows Hello – Это технология, позволяющая пользователю использовать биометрические данные, например сканер отпечатков пальцев или камеру для распознавания лица, в качестве метода аутентификации. Это повышает уровень безопасности, исключая необходимость использования паролей.
AppLocker – Данная функция позволяет администраторам контролировать запуск приложений на компьютерах в сети, что помогает предотвратить запуск нежелательных или потенциально опасных программ.
Общие эти методы безопасности помогают качественно обеспечить безопасность системы Windows и защитить пользовательские данные.
Защита данных и разграничение доступа
Windows предоставляет несколько механизмов для обеспечения безопасности данных. Один из таких механизмов – криптография. Криптографические алгоритмы позволяют защитить данные от несанкционированного доступа путем шифрования. Важно отметить, что выбор правильного алгоритма шифрования имеет огромное значение для обеспечения безопасности данных.
Кроме того, разработчики могут использовать механизмы защиты данных, предоставляемые самой операционной системой. Например, Windows предоставляет возможность использовать механизм шифрования файловой системы NTFS, который позволяет зашифровать отдельные файлы или папки. Это позволяет обеспечить безопасное хранение данных на диске даже в случае физического доступа к нему.
Разграничение доступа – это механизм, позволяющий определить, какие пользователи и группы пользователей имеют доступ к определенным ресурсам в операционной системе Windows. Разграничение доступа помогает предотвратить несанкционированный доступ к данным и ограничить возможности пользователей.
Стандартные механизмы разграничения доступа включают в себя установку прав и привилегий.
Права позволяют задать, какие операции пользователь может выполнять с ресурсом, например, чтение, запись или выполнение.
Привилегии определяют набор дополнительных возможностей, которые пользователь может получить.
Windows также предоставляет возможность использовать групповые политики для разграничения доступа. Групповая политика позволяет управлять настройками безопасности и конфигурацией операционной системы для групп пользователей.
Сочетание механизмов защиты данных и разграничения доступа является важной составляющей безопасности Windows. Эти механизмы позволяют создавать надежную систему, которая защищает данные и контролирует доступ пользователей к ним.
Аутентификация и авторизация пользователей
Аутентификация пользователей представляет собой процесс проверки представленных учетных данных, чтобы убедиться в их подлинности. В Windows существует несколько методов аутентификации, включая использование паролей, сертификатов и биометрических данных. Пароли остаются наиболее распространенным методом аутентификации, хотя современные системы также могут поддерживать более сложные способы, такие как двухфакторная аутентификация.
Авторизация пользователей состоит в определении разрешения или ограничений, связанных с доступом к определенным ресурсам или функциям. Это позволяет определить, какие действия пользователь может выполнять в системе. Система безопасности Windows использует разные методы авторизации, включая разграничение доступа на уровне групп и ролей пользователей.
Вместе, аутентификация и авторизация обеспечивают надежный уровень защиты, позволяя только подлинным и уполномоченным пользователям получить доступ к информации и функциональности системы. Эти меры помогают предотвратить несанкционированный доступ к данным и важным ресурсам, а также сохранить конфиденциальность и целостность информации.
Windows authentication is not as straightforward, and it’s made a little more complex thanks to Active Directory and having multiple machines use the same set of credentials. Understanding how Windows authenticates users is critical to allowing us to move laterally in a domain.
There are different methods of which a user can authenticate to a Windows machine that may or may not be connected to a domain.
Local users are only present in one specific standalone system. Obviously, my user isn’t present in my friend’s laptop, and it is only present in my laptop. Likewise, laptop1\user
and laptop2\user
are totally different users.
The local users have their records and passwords stored in the Security Account Manager (SAM) database. Windows would use these records to verify passwords when trying to authenticate to a system. This is similar to how /etc/passwd
works in checking users:
-
1.
User attempts to login with
user:Password@123
. -
2.
Laptop checks SAM for whether
user
exists and ifPassword@123
is valid. -
3.
If yes, grant access. If no, deny.
Domain users are only present in one specific domain. For example, acme\user123
is not present in acme2\user123
. However, all domain-joined devices know how to handle authentication. This means that, by default, any domain user can login to any domain computer provided they have physical access to it.
Domain joined devices delegate the authentication to the DC, and all of these records are stored within the NT Directory Service (NTDS) database. The DC uses the NTDS records to authenticate users.
-
1.
User attempts to login with
acme\user:Password@123
onWKSTN
. -
2.
WKSTN
delegates the authentication to theDC
. -
3.
DC
checks NTDS to verify that the user exists and password is correct, -
4.
DC
verifies user and sends a thumbs up toWKSTN
.
Remote authentications require privileges to do (for example, being part of the Remote Management Group allows users to have remote Powershell sessions). When moving laterally, this is the main thing we care about.
Some terms we need to know before discussing how the authentication works:
Authentication Packages (APs) authenticate users by analysing their logon data via Security Support Providers (SSP). Different APs provide support for different logon processes, and they are typically .dll
files that are loaded and used by Local Security Authority (LSA).
Some examples of APs are:
When we try to login to a website, the website is probably using some kind of backend database that is verifying our credentials. APs provide the logic needed for Windows to act as both of these using the same machine.
As mentioned earlier, LSA allows Windows to act as both the client and authentication server at the same time.
How it works is illustrated in this diagram here (taken from ATTL4S):
Microsoft provides an Interface for the SSPs (SSPI) to integrate applications with this authentication system.
There are 4 major categories for the functions provided:
-
1.
Package Management —> Handles packages
-
2.
Credential Management —> Handles credentials of principals
-
3.
Context Management —> Creates security context
-
4.
Message Support —> Ensures message integrity and privacy during message exchanges.
When someone successfully authenticates to the WIndows message, the AP does 2 things:
-
1.
Create a new logon session
-
2.
Provides security information about the authenticated user to the LSA
The LSA then creates an access token representing the user’s local security context on the system. This security context would contain information like:
This security context is used to create an access token, which is the thing required to create the new logon session.
There are 2 main types of sessions that are created:
-
1.
Interactive —> Credentials given
-
2.
Non-interactive —> Credentials not given
Interactive sessions are what happens when we login normally through our login page. The user credentials are cached within the memory of the LSA process, called the Local Security Authority Subsystem Service (LSASS). In specific, it is cached in lsass.exe
. Cached credentials allow for Windows to provide for a Single Sign-On (SSO) service to users.
These are sessions that leverage the cached credentials on behalf of a user. When we use the SSO service to logon to the same or another device, this is actually a non-interactive session. Interactive sessions need to happen first for credentials to be cached.
This leverages the use of the SSPI to work.
For example, a non-interactive session can grant us access to the file system of another device and do ls \\dc\c$
using cached credentials.
After a user successfully authenticates, a new logon session is created regardless of what type of authentication is used. The cached credentials in the AP are tied to logon sessions. Logon sessions are not limited to the 2 types listed above:
We can verify a logon session with Get-LogonSession
from Powerview.
The information that is returned to LSA after creating the logon session is used to create an access token. An access token is a protected object that contains the local security context of an authenticated user. The security context is defined as the privileges and permissions a user has on a specific workstation and across the network.
Every single logon session is identifiable by a 64-bit locally unique identifier (LUID), otherwise known as the logon ID. This access token contains an Authentication ID (AuthID) that identifies the logon session via the LUID.
The access token caches a number of attributes that determine its security context such as the user SID, group memberships, privileges and logon ID that references the origin logon session. In the above image, we can see that the Integrity is set to Medium. But what if we use the ‘Run as Administrator’ option and run cmd.exe
?
This is where multiple security contexts come in. A user can have more than 1 context, and using the ‘Run as Administrator’ option simply spawns a high integrity process via the User Account Control (UAC). As such, Windows allows users to have different access tokens and logon sessions in the same system.
These access tokens serve as an access check for Windows. For instance, when a thread or process attempts to read a high security object (like root.txt
), it needs 3 pieces of information:
-
1.
Who is requesting access?
-
2.
What do they want to do (read, write or execute)?
-
3.
Who can access this object?
Windows will first check the token associated with the calling thread and look at the authorization attributes cached. Then, it looks at the access requested by the thread. Lastly, Windows retrieves the security descriptor for the target object in the form of a DACL specifying what users have access to the object and what type of access is granted.
If the access token matches what is required, then access is granted, else it is not.
There are 2 types of tokens:
-
1.
Primary (process tokens) —> Every process has aprimary token, and when a new process is created, the default action is to inherit the primary token of the parent process.
-
2.
Impersonation (thread tokens) —> Enable a thread to run with a different security context (and hence token).
The point of impersonation is to allow for one process to spawn different threads that have different security contexts.
One use case is the listing of shares via remote authentication. If a user user1
has access to the web shares of DB
, then credentials for user1
is first retrieved and verified. Then, an access token with the security context of user1
is created. The chrome.exe
instance can spawn a thread and place a copy of the access token into that new thread. This thread can now act on behalf of user1
and any subsequent access to files or resources are determined by pre-set ACLs.
There are different types of impersonation levels:
Creating a security context requires credentials, while hijacking a security context (via stealing tokens) requires privileges.
User impersonation is the thing that let’s us move laterally!
Windows API allows us to manipulate access tokens, such as duplicating it, or spawning a new process. The level of manipulation depends on our privileges on the system:
-
As a local admin or SYSTEM user, we can manipulate all tokens in the system
-
As a service account, we can make use of Hot Potato or PrintSpoofer.
-
As a normal user, we can only manipulate our own token.
There are 2 common ways of which token exploits happen:
-
1.
Token Impersonation —> Duplicate target token and use it to spawn a new process (such as Cobalt Strike’s / Meterpreter’s
steal_token
command). -
2.
Process Injection —> Inject payload (reverse shell shel code) into the process where the token we want is at (Meterpreter’s
migrate
function allows us to run our shell in themmc.exe
of another user).
runas.exe
is a binary that allows us to create processes using alternate credentials. When running runas.exe
, it would ask for credentials, which are verified by the LSA in a similar process to how Interactive Sessions are created.
If we attempt to use credentials from a user that is not known by the system, then it would just fail. This is because starting a process on the local system as an unknown user obviously doesn’t work. When we run runas.exe
and give the correct credentials, then it spawns a local level process.
This is where the /netonly
flag comes in. This flag indicates that the credentials given are for remote access only. Thus, they are not verified by the LSA, and spawn a network level process with the identity of the user given.
This reason is what leads to tickets and NTLM hashes being cached on the system. How runas.exe
works is actually using the Win32 API CreateProcessWithLogon function, which is in charge of the creation of new processes with the new security context.
The /netonly
flag uses the LOGON_NETCREDENTIALS_ONLY logon option, which creates and uses a new logon session, but using the original token.
In most tools like Metasploit and Cobalt Strike, they have their own version of runas
. This provides some additional functionality:
-
1.
Execute payload directly with wanted security context.
-
2.
Create an arbitrary process and steal its token.
-
3.
Create an arbitary process and inject payloads.
The CreateProcessWithLogon function uses another function called LogonUser, and this fnction allows us to create new logon sessions and tokens without creating a new process. We can choose between different logon approaches. This is what Cobalt Strike’s make_token
function uses to create a new token using passwords.
As mentioned earlier, it is trivial to use a high integrity administrative context to manipulate tokens since we can basically do everything with it. However, the same cannot be done using a medium integrity user context:
-
Only can play with own processes (steal tokens and process injection)
-
Impersonating tokens in current process if we can access those
-
Cannot create new token since that requires credentials as well.
In short, we cannot do much without an administrator shell!
If we somehow retrieve a hash of a user, we cannot use Win32 APIs to do anything with them. Windows does not provide functionality to authenticate with users via NT hashes. As such, there are 2 broad categories of what we can do:
This method would involve injection into lsass.exe
, which can be quite risky.
This is done using the mimikatz.exe sekurlsa::pth
function. This allows us to create a new process using an NT hash rather than a password, which basically requires administrative privileges in the form of SeDebugPrivilege
. This is how it works:
-
1.
Create new process with CreateProcessWithLogon via net credentials only.
-
2.
Identify the new session created by extracting from the access token belonging to the new process.
-
3.
Write credential material into the target logon session, which requires debugging privileges.
Basically, injecting credentials into the logon session.
A similar thing happens when we use the Overpass The Hash exploit to request for tickets:
This approach involves specifying credentials to external tools without playing around with Windows components. For example, Invoke-the-hash
is a cmdlet that can be used to do this. The Impacket suite of tools can be used for this via wmiexec.py
.
Kerberos can also be used, and this involves tools being used to generate Kerberos traffic to obtain TGTs or STs. Tools like Rubeus.exe
or scripts from Impacket can be used for this.
python getTGT.py jurassic.park/velociraptor -hashes :2a3de7fe356ee524cc9f3d579f2e0aa7
Rubeus.exe asktgt /user:user123 /domain:acme.local /rc4:2a3de7fe356ee524cc9f3d579f2e0aa7 /nowrap /ptt
These tickets retrieved can also be passed along to generate new processes.
Windows provides functionality for Kerberos tickets, and we can import TGTs or STs into existing logon sessions. Importing a ticket into our current session does not require privileges, but doing so for another session does.
If we have the ticket from another user, we can importing the ticket into an attacker-controlled logon session and act on behalf of another user in the network.
The cool thing about this is the the Kerberos LSA API does not require administrative privileges to interact with. How mimikatz.exe
and Rubeus.exe
do this is via the LsaCallAuthenticationPackage function. This function enables apps to talk to Windows APs, and is done through messages which have a specific structure.
In the case of Pass The Ticket, this is done using KerbSubmitTicketMessage. There are 2 methods of passing tickets via LSA:
-
1.
Import ticket into another session, then steal tokens or do process injection via
Rubeus.exe ptt
function. -
2.
Import ticket into current session. (prevents overwriting the original TGT, for eg.
make_token
).
We can do the same thing with MSF and Impacket tools. Impacket tools generally support the -k
option, which would use the tickets exported in Kali (export KRB5CCNAME
) to make requests on behalf of the user. Alternatively, MSF’s run
option still works.
We can also move laterally to other machines using a user’s security context. Windows provides loads of protocols to allow remote execution. The simplest example is using psexec
. With the appropriate security context and network visibility, we can create a remote service using the SCM remote procotol.
Using the sc.exe
native tool, we can use our new security context to create services on the remote device to execute payloads like beacons. The sc_start.x64.o
file can be used to start a service remotely.
This is the basics of how Windows authenticates users!