Как устроена система безопасности Windows
Сущности системы безопасности
В Windows все активные сущности, которые могут быть аутентифицированы операционной системой (пользователи или группы), называются участниками безопасности (security principals). Все участники безопасности имеют уникальный идентификатор переменной длины — Security ID (SID). Структура SID следующая — S-R-IA-SA-RID, например S-1-5-21-1687231434-1254558764-1544283289-1004, где:
S— литеральный префикс, указывает на то, что идентификатор является SID (это просто конвенция наименования);R— однобайтное значение версии или ревизии (revision) SID. Пока существует только версия 1;IA— источник выдачи (issuing authority), шестибайтное значение. Указывает, в чьей области ответственности был выдан SID (буквально authority значит «орган власти»). Почти всегда имеет значение 5 (SECURITY_NT_AUTHORITY), за исключением well-known SID, о которых мы поговорим чуть позже. Например,1означаетSECURITY_WORLD_SID_AUTHORITYи относится к well-known-группе Everybody;SA— уполномоченный центр (sub-authority). Уникальное (в рамках IA) значение, состоит из четырех частей: 4-байтного числа, указывающего, кем был выдан идентификатор (контроллером домена или локальным компьютером), и 12-байтного значения, которое делится на три части и идентифицирует конкретный объект, выдавший идентификатор. Смысл этого поля в том, что при наличии нескольких доменов в лесу объекты в разных доменах будут иметь уникальный SA;RID— относительный идентификатор (Relative-ID), 4-байтное значение, служит для разделения объектов внутри домена. Для встроенных учетных записей RID всегда будет один и тот же (например, для учетной записи администратора RID = 500).
Если быть более точным, то существует SID машины (machine SID) и SID домена (domain SID). А сам SID представляет собой базовый идентификатор (S, R, IA, SA) + RID.
Также есть стандартные так называемые well-known SID для пользователей и групп. Они имеют один и тот же SID на любых системах (например, группа Everyone или пользователь System).
Поизучать SID можно с помощью утилиты PsGetsid.exe из пакета Sysinternals. А почитать о структуре SID более подробно можно, например, в этих публикациях:
Также при администрировании можно допустить небольшой недочет, связанный с дубликацией сидов. Иногда он влияет на безопасность или функциональность (например, когда ОС развертывают, просто копируя диск). Об этом можно почитать подробнее в статье Марка Руссиновича, еще одной статье и в VMware knowledge base.
SID, в свою очередь, входит в так называемый маркер доступа — программный объект (структура в ядре Windows), который закрепляется за сессией (logon session) участников безопасности после авторизации. За выдачу маркера, как и за аутентификацию, отвечает LSASS (local security authority subsystem).
Помимо всего прочего, в маркер включены SID пользователя и его групп, а также механизм привилегий на совершение каких-либо действий (например, привилегия на отладку debug, которая, кстати, используется в mimikatz для получения доступа к системным процессам).
После того как удаляется последний ассоциированный с сессией токен, LSASS удаляет и саму сессию — таким образом завершается сеанс пользователя. Можно поподробнее изучить структуру маркера доступа в отладчике ядра (kernel debugger) с помощью команды dt_TOKEN. Вообще, если не получается нагуглить подробности о внутреннем устройстве Windows, можно изучить структуру самому с помощью средств отладки. Подробности представлены в документации Microsoft. С привилегиями может быть, например, связана такая вещь, как bypass traverse checking.
Маркеры доступа системы безопасности Windows
Маркеры доступа тоже могут иметь проблемы с безопасностью. Вот несколько ссылок для более подробного изучения:
- Интересная исследовательская работа Брайана Александера
- Блог по пентесту и редтиму ired.team
- Выступление Андреа Пьерини с конференции Hack in Paris
- Статья Windows Privilege Abuse: Auditing, Detection, and Defense (Palantir Security)
В свою очередь, для «пассивных» объектов, которые предназначены для предоставления к ним доступа извне (их называют securable objects), используется SD — security descriptor. Это дескриптор для управления доступом к данным объектам (например, процесс может иметь SD или SD может быть привязан к файлу в NTFS). У SD тоже, кстати, бывают проблемы с безопасностью.
В security descriptor включены ACL (access control list), которые бывают двух видов — SACL (нужен для ведения журнала доступа к объекту) и DACL (нужен непосредственно для управления доступом). В свою очередь, ACL включают ACE (access control entry) — каждая ACE предназначена для конкретного субъекта, который получает доступ, и содержит в себе тип (запрет или разрешение) и маску доступа. Правильно настроенные ACL позволяют перекрыть несанкционированный доступ к объектам внутри системы.
Однако, если кто-то загрузится на таком компьютере в Linux или вытащит жесткий диск из машины с Windows и примонтирует его в том же Linux, он сможет прочитать эти данные. В Windows удастся получить доступ к данным с «чужого» носителя NTFS, только если пользователь или его группа на другой системе имеет тот же SID — например, если в ACL выставлено слишком много прав на well-known-группы.
От этого можно защититься только шифрованием, но стоит быть осторожнее с выбором и использованием инструмента (см. статьи о проблемах с шифрованными контейнерами VeraCrypt и BitLocker, а также уязвимостях NAS).
В ядре Windows проверки ACL выполняются с помощью security reference monitor и object manager. Предоставление доступа выглядит так: субъект (пользователь) после авторизации получает маркер доступа, затем субъект обращается к файлу, система сравнивает необходимые данные из маркера доступа с соответствующими ACE в DACL объекта, и в зависимости от разрешений субъект получает доступ или отказ.
Подробнее о ACL/ACE можно почитать на портале Microsoft или на сайте ntfs.com. Также в этом может участвовать механизм Mandatory Integrity Control, который проверяет доступ к объекту по уровню надежности того, кто этот доступ запрашивает.
Кстати, повышение привилегий за счет DACL было использовано в прошлогодней уязвимости CVE-2019-0841. Криво выпущенный патч — знакомые грабли. Также в 2018 году была уязвимость CVE-2018-1036, связанная с обходом разрешений.
Помимо привилегий, есть еще один способ контролировать действия пользователя, требующие прав администратора. Для этого был создан хорошо известный UAC (User Access Control). Идеала, разумеется, не бывает, поэтому вот несколько старых ссылок для дальнейшего изучения методик обхода UAC.
- Bypass User Account Control (MITRE)
- Defeating Windows User Account Control (GitHub)
- FUCK UAC! 10 способов обхода системы User Account Control в Windows
- Техника обхода UAC в Windows 10 через App Paths в реестре («Хакер»)
- UAC Bypass, или история о трех эскалациях (Хабр)
- How to bypass UAC in newer Windows versions (zc00l)
- User Account Control — What Penetration Testers Should Know (Cobalt Strike)
Аутентификация и авторизация
Как уже упоминалось, за аутентификацию отвечает LSASS. На деле, конечно, все выглядит сложнее. Ниже приведена схема механизма аутентификации для старых версий Windows.
Вкратце это работает так: в LSASS поступают аутентификационные данные (пароль, биометрия и прочее), затем Windows производит авторизацию. Хеш от аутентификационных данных кладется в SAM, а пользовательскому процессу назначается маркер доступа. Известная проблема состоит в том, что можно сохраненные хеши сдампить (например, при помощи всем известного mimikatz) и провести атаку pass-the-hash.
В Windows 10 добавили Credential Guard (вместе с ним, кстати, появился новый процесс — Lsalso.exe). Этот механизм должен был защитить, в частности, от использования mimikatz. Но на каждого хитреца найдется свой мудрец.
Прежде всего, Credential Guard — опциональная функция, которая может быть отключена. Так как Credential Guard основан на механизме Virtual Secure Mode (VSM), который, в свою очередь, базируется на механизмах виртуализации CPU, то не стоит забывать и об аппаратных уязвимостях, позволяющих обойти Credential Guard.
Ну и напоследок нужно помнить, что введенный пароль преодолевает некоторый путь перед тем, как будет сохранен в компьютере для последующей авторизации. Это значит, что его можно получить с помощью кейлоггера или кастомного SSP (security support provider). Последнее возможно с помощью mimikatz — пример есть в недавней статье. Помимо mimikatz, перехватить пароль помогут Empire, SharpSploit или PowerSploit, в которых, по сути, используется интегрированный mimikatz. Альтернативой в PowerSploit могут быть следующие команды:
Import-Module .\PowerSploit.psm1
Install-SSP -Path .\mimilib.dllЕстественно, обойти системы безопасности Windows позволят и методы социальной инженерии. Например, можно через msf и msfvenom получить реверс-шелл, с помощью его загрузить на целевую систему специальный исполняемый файл для имитации окна авторизации, а потом запустить его из шелла. На экране пользователя отобразится окно, как при входе в систему, — при этом инструмент проверяет, правильный ли пароль введен.
Кстати, есть старый трюк для обхода окна авторизации, который на удивление может сработать и в Windows 10. Суть этого способа в том, что нужно заменить программу sethc.exe на cmd.exe простым переименованием, а затем вызвать sethc.exe, пять раз нажав клавишу Shift. После этого можно сменить пароль пользователя. Еще в Windows 10 существует возможность сделать примерно следующее:
- Вставить загрузочный USB, перезагрузить компьютер, затем нажать Shift + F10, чтобы открыть
cmd.exe. - Ввести команду
move D:\windows\Sstem32\utilman.exe D:\windows\system32\utilman.exe.bak. - Для маскировки
cmdподutilmanввести командуcopy D:\windows\system32\cmd.exe D:\windows\System32\utilman.exe. - Перезагрузить компьютер без загрузочного USB.
- После загрузки нажать «Специальные возможности» (рядом с кнопкой выключения питания в окне авторизации).
- Для создания нового пользователя ввести команду
net user youruser /add. - Для добавления нового пользователя в группы администраторов использовать команду
net localgroup administrators youruser /add.
Можно добиться подобного эффекта, если у тебя уже есть доступ к системе с правами редактирования реестра. В этом случае нужно в ветке HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ добавить раздел utilman.exe, в котором прописать ключ с типом String Value и значением в виде пути до нужной программы. Эта программа будет запускаться при попытке открыть окно специальных возможностей.
От этого опять-таки спасает шифрование диска. Для запрета смены пароля определенного юзера можно использовать учетную запись Microsoft вместо локальной. Также можно отключить для всех юзеров права на выполнение utilman.exe и sethc.exe. Ну и дополнительно включить Secure Boot и поставить пароль на BIOS/UEFI. Кстати, этот трюк показывался в сериале Mr.Robot в третьей серии четвертого сезона.
Также для байпаса окна авторизации есть старый, но по-прежнему рабочий инструмент (с поддержкой Windows 10) под названием kon-boot. Правда, работает он с некоторыми ограничениями (например, не поддерживается включенный secure boot). Чтобы защититься от него, нужно включить в системе функции, которые инструмент не поддерживает. Ну и конечно, не стоит забывать про HID-атаки (см. руководство по созданию BadUSB с Wi-Fi на Arduino).
Постэксплуатация
Часто бывает так, что эксплуатация уязвимости ведет к получению доступа, например, к учетной записи веб-сервера, а не к учетной записи администратора. Пути тут два: повышать привилегии и искать интересную информацию, к которой есть доступ. Если речь идет о доменном компьютере, то также можно почерпнуть полезные сведения из недавней статьи, посвященной сбору информации в домене. Для поиска интересностей в скомпрометированной системе есть множество скриптов, например winPEAS, Seatbelt, Powerless, Privesc, Sherlock, JAWS, Watson и SharpUp.
Но стоит учесть, что такие скрипты «шумные». Тем более программы, требующие .NET, могут и не сработать, если в системе настроен белый список ПО.
Дополнительные ссылки
При желании ты можешь сам поискать нужную информацию. В этих целях рекомендуется использовать списки LPE (local privilege escalation). Вот несколько полезных ссылок:
- Windows Local Privilege Escalation (HackTricks)
- Windows / Linux Local Privilege Escalation Workshop (sagishahar)
- Privilege Escalation (ired.team)
- Windows — Privilege Escalation (swisskyrepo)
- Windows-Privilege-Escalation (frizb)
- Windows Privilege Escalation — a cheatsheet (pentest.tonyng.net)
- Privilege Escalation Windows (Total OSCP Guide)
- Windows Privilege Escalation Guide (absolomb.com)
- Windows Privilege Escalation Scripts & Techniques (Рахмат Нурфаузи)
- Stored Credentials (Penetration Testing Lab)
- Основы повышения привилегий в Windows (artdeep.i.tech)
В материалах, ссылки на которые приведены выше, мелькает эксплуатация ядра как способ повышения привилегий. Стоит учесть, что в Windows есть механизм защиты ядра Kernel Patch Protection (PatchGuard), но и этому механизму тоже не чужды уязвимости. Также при постэксплуатации стоит знать про наличие AppContainer.
Заключение
Безопасность зависит не только от недочетов в логике, но и от программных ошибок, вплоть до бинарных уязвимостей в ядре.
Появление новых механизмов защиты и способов обхода этих механизмов — бесконечный цикл. Нужно регулярно проводить аудит, в чем тебе помогут следующие полезные ссылки:
- Гайд по безопасности десктопных версий Windows (CIS)
- Статья про комплексный аудит безопасности
- Обзор системы безопасности в Windows 10 (Microsoft)
- Сведения о безопасности в корпоративной версии Windows 10 (Microsoft)
Но для полного понимания вещей полезно знать, как все устроено внутри. Лучшим источником информации в этой области считается книга Марка Руссиновича под названием Windows internals (на данный момент выпущена первая часть 7-го издания, вторая часть находится в разработке).
