# Windows системы занятие №3 AAA в Windows AAA- это: 1. Аутентификация(Authentication) 2. Авторизация(Avtorization) 3. Отчетность(Accounting) ## Права безопасности объектов в домене Один из важных параметров безопасности - **object SID**. Относительно него обеспечивается доступ и проверка объекта на возможность взаимосвязи с другими объектами. ![](https://i.imgur.com/9SGTfO9.png) ## Модель ААА Она предполагает, что сначала пройдет идентификация объекта. То есть проверится, что такое имя вообще существует в базе данных сервера. После этого идет процесс аутентификации- это проверка учетных данных и подлинности объекта Авторизация - подтверждение подлинности субъекта безопасности. Отчетность - позволяет вести журналы аутентификации и авторизации ![](https://i.imgur.com/8T7abWd.png) ## Winlogon Это системный процесс, который выполняет процедуры входа и выхода на компьютере Windows. Рассмотрим, как работает **локальная аутентификация**: Когда мы ввели пароль, наши учетные данные отправились в процесс **lsass.exe**. Он обрабатывает учетные данные, преобразует пароли в хэш, сравнивает их с учетными данными из базы и подтверждает вход пользователя. Как процесс поймет, что наши учетные данные валидны? Он обратиться к локальной базе учетных данных SAM, отправит туда username нашего пользователя и достанет хэш-пароль. После этого он сравнит хэш-пароль из базы данных и хэш от пароля, который предоставил пользователь. Если все хорошо, то учетные данные будут закэшированы в хранилище LSA. Кэширование нужно для того, чтобы при обращении к каким-то процессам компьютера не приходилось все время вводить свои учетные данные. ![](https://i.imgur.com/u8zTY77.png) ## Lan Manager Это протокол, позволяющий аутентифицироваться на различных ресурсах. На данный момент он устарел и не используется, но в современных системах он поддерживается для совместимости со старыми системами. Минусы - максимальная длина - 14 символов, так же преобразовывается в хэш, но его легко взломать. Еще один недостаток - он регистронезависимый(сначала все переводит в верхний регистр, и лишь потом хэширует). На смену этому протоколу пришел NT Lan Manager (NTLM) ## NT Lan Manager Преимущества перед Lan Manager: * Формируется по алгоритму MD4 * Пароль может быть длиной до 128 символов * Пароль регистрозависимый * Может содежать как ASCII-символы, так и Unicode Рассмотрим, как он работает. Для того, чтобы обратиться к какому-то ресурсу, необходимо отправить имя пользователя. Это нужно для того, чтобы ресурс увидел, а есть ли вообще такой пользователь в его базе данных или нет(рассматриваем случай, когда такой ресурс не является доменом) Если сервер нашел в своей базе данных пользователя с указанным именем пользователя, он отправляет в ответ специальный запрос. Это случайно сгенерированное число. Мы шифруем с помощью этого пароля наш хэш-пароль и отправляем на сервер Сервер проделывает то же самое, доставая хэш пароля из своей базы данных, и если строки совпали, то мы аутентифицировались в системе. ![](https://i.imgur.com/CGcjYP9.png) На данный момент этот протокол так же не актуален, так как MD4 уже не новый алгоритм, и он поддается брутфорсу. Более того, он подвергается ряду атак. Например - атака, связанная с временным накоплением данных. Если злоумышленник долго будет просматривать трафик, то у него получится примерно восстановить строчку хэша. Данный протокол- это уже сетевая аутентификация и для того, чтобы она корректно работала, предусмотрена служба Netlogon ## Netlogon Эта служба позволяет безопасно идентифицироваться на сетевых ресурсах. Она работает автоматически. Кроме того, она будет проверять, есть ли у нас доступ к каким-то ресурсам на основе SID. Она работает в рамках нашего доменного взаимодействия. Рассмотрим, как будет работать тот же NTLM в таком случае: 1. Первые шаги аналогичны - отправляем имя пользователя, получаем запрос сервера, шифруем с помощью него хэш нашего пароля и отправляем на сервер 1. Далее наш сервер пересылает на домен-контроллер наш ответ и свой запрос. 1. После этого уже домен-контроллер, достав из базы данных наши учетные данные и взяв запрос сервера, зашифрует это и сравнит это с нашим ответом. Если все хорошо, то домен-контроллер отправит в ответ, что аутентификация прошла успешна. ![](https://i.imgur.com/5dNLLnx.png) ## NTLMv2 Перейдем к более новому протоколу. Его отличия от предыдущего: * Использует MD5 * Добавлена метка времени Принцип работы: 1. Работает он аналогично NTLM, но теперь мы отправляем в сторону сервера метку времени. Берем метку времени и объеденяем с запросом сервера. 1. Берем от этой суммы хэш (в windows это называется HMAC-MD5) 1. После этого, мы хэшируем наш хэш с помощью специального ключа. 1. Сервер аналогично пересылает эти данные в домен, которые он так же должен сверить. Только на этот раз на сервер посылается ответ и уже захэшированная строчка из запроса сервера и запроса клиента. Остальные действия аналогичны ![](https://i.imgur.com/nyQXWz2.png) Этот протокол так же имеет свои уязвимости, и не всегда рекомендуется использовать его как единственный протокол аутентификации в домене. Для решения проблем этого протокола существует протокол Kerberos. Одна из проблем, которую данный протокол решает, это подтверждение обоих сторон. Ведь в данном протоколе ничто не мешает злоумышленнику провести spoofing атаку для сервера и представиться для клиента сервером, подменив его IP адрес и выведя оригинальный сервер из строя с помощью, к примеру, DDoS-атаки. ## Kerberos Протокол, обеспечивающий надежную аутентификацию пользователей. Особенности: * Основан на билетах(по умолчанию он действует 8 часов) * Работает в формате двух пользователей и третьей доверенной стороны * Предусматривает, что обмен информации происходит в незащищенной среде, а передаваемые пакеты могут быть перехвачены и модифицированы **Key-distribution center** - служба в контроллере домена, позволяющая проводить такого рода аутентификацию. Этапы работы протокола Kerberos: 1. **Получение TGT** - tiket granting ticket - это билет для получения билетов. Это наша аутентификация на ресурсе домена и подверждение что мы - это мы. Отправляем на домен-контроллер наш username для подтверждения аутентификации. В данной реализации наш домен-контроллер являеся key distribution center. Он распространяет те самые билеты по нашему домену. Когда мы отправили имя, домен-контроллер достал из базы данных NTDS хэш нашей учетной записи и хэш KKDC - **Key of Key Dictribution Center(или хэш KDC)**. На втором занятии мы смотрели учетную запись krbtgt. У нее есть кэш, который используется как раз для аутентификации Kerberos. ![](https://i.imgur.com/rOUnYc0.png) 2. После этого, домен начинает формировать сессию для работы с нашим комьютером. Первое что он создает - это ключ, с помощью которого будут шифроваться данные от сервера к клиенту и от клиента к серверу. Далее такой ключ шифруется с помощью хэша учетной записи. 3. Когда домен-контроллер получит наши данные, он присылает нам TGT. Разберем, что находится внутри TGT. Там есть три параметра: * Ключ общения с нашим компьютером. Они уникальны для каждой сессии с другим компьютером. Сам TGT шифровать нет смысла, так как без владения KKDC злоумышленник не сможет расшифровать данные внутри. * Имя пользователя * Время выдачи билета чтобы понимать, что билет уже не действителен Теперь рассмотрим такую ситуацию: **Получение Service Key c помощью TGS**. Итак, на нашем компьютере уже есть TGT и DSK(ключ сессии с компьютером). Мы себя идентифицировали, теперь мы должны обратиться к контроллеру домена чтобы, к примеру, обратиться к файловому хранилищу FS1. **1 Этап**. Отправляем в сторону контроллера домена TGT а так же зашифрованные данные о том, к кому мы обращаемся и время, в которое мы обращаемся. Когда сервер получит эту информацию, он сформирует билет на получение доступа к данному сервису. **2 Этап.** Формирование TGS - он состоит из имени пользователя, который обратился к серверу, имени ресурса, времени создания билета, срока жизни билета и service key(ключ сесии) **3 Этап**. Формирование тикета для FS1. Это надо для того, чтобы решить проблему взаимного шифрования. Для этого берется сам билет, шифруется с помощью машинной учетной записи fs1 и отправляется на pc1. В результате у нас на компьютере два ключика - один для fs1, а другой для самой Windows. Вся эта последовательность шифруется с помощью ключа общения с доменом. **4 Этап.** Windows предоставляет полученную информацию серверу FS1. Свой билет он шифрует с помощью Service Key, отправляя дополнительно уже зашифрованный TGS key. Теперь наше соединение установлено. Более того, теперь наше соединение будет зашифровано с помощью Service key. Именно такая система позволяет общаться между устройствами, не позволяя злоумышленнику что-либо сделать ![](https://i.imgur.com/gY1TG74.png) :::danger Если время между сервером и машиной отличается более чем на 5 минут, аутентификация переходит на старые протоколы, тем самым снижая защиту. ::: ## Типы входа Windows **logon type** - этот параметр в журнале событий отвечает за то, как была вызвана учетная запись. ![](https://i.imgur.com/pWYJoqQ.png) ![](https://i.imgur.com/arB5MZW.png) По умолчанию данные кэшируются до 10 раз. ## Mimikatz Mimikatz — это приложение с открытым исходным кодом, которое позволяет пользователям просматривать и сохранять учетные данные аутентификации, такие как тикеты Kerberos. ## Практика - анализ процесса lsas.exe 1. Открываем архив с приложениями SysinternalsSuite и запускаем PsExec64. 2. Открываем консоль от имени администратора, переходим в папку с программой выше 3. Запускае программу командой: ``PsExec64.exe -i -s regedit.exe``. У нас должен запуститься реестр. 4. Запускаем диспетчер задач от имени администратора. 5. Находим процесс lsass и пытаемся его сдампить. Будет создан файл. 6. Теперь нам необходимо передать сдампенный файл на линукс-машину. Для этого переходим в Kali и донастраиваем ее следующим образом: * Добавляем и конфигурируем настройки ip адреса * С помощью команды ``systemctl status ssh`` проверям состояние SSH соединения. По умолчанию оно выключено * Если протокол выключен - запускаем его комнадой ``systemctl start ssh`` ``systemctl enable ssh`` 7. Запускаем cmd из под администраторской учетной записи в Windows 8. Находим lsasdump и передаем его через SCP в линукс с помощью команды `scp lsass.DMP root@*ip-адрес Kali-Linux*:*расположение, где должен лежать наш файл*` 9. Вводим логин/пароль, после чего наш файл начинает загружаться. После всех этих пунктов скачиваем на нашу Kali-Linux программу pypykatz из GitHub. Используем команду для скачивания этой программы: ``git clone *ссылка на github*`` и появляется pypykatz. 10. Запускаем скрипт выше с помощью команды `` python setup.py install`` 11. После установки pypykatz вводим команду pypykatz lsa minidump lsass.DMP. Опция lsa minidump позволяет проанализировать локальный файл дампа. И после этого скрипт выводит актуальную информацию этого дампа Дамп - это слепок оперативной памяти процесса. lsas арендует для себя какие-то адреса из оперативной памяти и в них хранит свои данные. Что мы видим в нашем дампе? 1. Хэши NT, SHA1, DRAPI 1. SID учетной записи 2. Имя домена 3. Пароль от учетной записи самого компьютера Что же нам дает знание логина/пароля учетной компьютерной записи? * Через нее можно вызывать WinAPI для того, чтобы красть оттуда какие-то данные Интересное: * ``\\*название комьютера*\*название диска*$`` - так мы можем обратиться непосредственно к самому диску, но эта опция доступна только администраторам. * Служба lsas запускается в любой инсталяции Windows * Mimikatz крадет пароли не только из памяти lsas, но и из реестра. * Перезапуск компьютера очищает дамп памяти lsas # Итоги: 1. Увидели, что процесс lsas хранит в своей памяти определенные данные. Их оттуда можно достать и их необходимо защищать.