- Регистрация
- 7 Фев 2020
- Сообщения
- 525
- Реакции
- 98
- Репутация
- 147
Data Protection API (DPAPI) — криптографический интерфейс программирования приложений в ОС семейства Windows, обеспечивающий конфиденциальность данных путем их шифрования.
Почти для всех криптосистем одна из самых сложных задач — управление ключами, вернее вопрос безопасного хранения ключей. Если ключ хранится в виде обычного текста, то любой пользователь, имеющий доступ к ключу, может получить доступ и к зашифрованным данным. DPAPI позволяет разработчикам шифровать приватные данные или ключи, используя симметричный ключ, полученный на основе пароля пользователя.
DPAPI предоставляет набор API для простого шифрования (CryptProtectData()) и дешифрования (CryptUnprotectData()) данных с использованием неявных ключей, привязанных к конкретному пользователю или системе. Это позволяет приложениям защищать пользовательские данные, не беспокоясь о таких вещах, как управление ключами.
Пароль юзера используется для получения мастер-ключа. Эти ключи расположены в папке C:\Users\<USER>\AppData\Roaming\Microsoft\Protect\<SID>\<GUID>, где <SID> — это идентификатор безопасности пользователя, а <GUID> — имя мастер-ключа. Пользователь может иметь несколько мастер-ключей. Этот мастер-ключ необходимо расшифровать с помощью пароля пользователя или ключа резервного копирования домена, а затем применить для расшифровки любых данных DPAPI. Поэтому, если мы попытаемся расшифровать зашифрованный пользователем объект данных DPAPI (например, cookie Chrome), нам нужно получить конкретный мастер-ключ пользователя.
ПО, использующее DPAPI
Chrome использует DPAPI для хранения двух основных типов данных, которые интересуют оператора: содержимого файлов cookie и сохраненных паролей. Файлы cookie расположены по пути %localappdata%\Google\Chrome\User Data\Default\Cookies, а данные авторизации — %localappdata%\Google\Chrome\User Data\Default\Login Data. В большинстве систем %localappdata% сопоставляется с C:\Users\<USER>\AppData\Local. Но сами шифрованные данные хранятся в базе данных SQLite, с которыми способен работать mimikatz. Так как у меня установлен Chrome Dev, то в примере вместо директории Chrome используется директория Chrome Dev.
Просмотреть список файлов cookie и учетных данных с помощью mimikatz можно следующим образом:
mimikatz # dpapi::chrome /in:”%localappdata%\Google\Chrome Dev\User Data\Default\Cookies”
Cookie, хранящиеся в базе данныхmimikatz # dpapi::chrome /in:”%localappdata%\Google\Chrome Dev\User Data\Default\Login Data”
Данные форм авторизации, хранящиеся в базе данных
Однако значения файлов cookie зашифрованы DPAPI с помощью мастер-ключа пользователя, который, в свою очередь, защищен паролем пользователя (или ключом резервного копирования домена). Есть несколько сценариев, в которых может оказаться оператор, пытаясь получить данные файлов cookie (или данные для входа).
1. В контексте целевого пользователя
Самый простой случай, когда твоя сессия находится в контексте целевого пользователя. При таком раскладе следует добавить в команду флаг /unprotect.
mimikatz # dpapi::chrome /in:”%localappdata%\Google\Chrome Dev\User Data\Default\Cookies” /unprotect
Расшифрованные Cookiemimikatz # dpapi::chrome /in:”%localappdata%\Google\Chrome Dev\User Data\Default\Login Data” /unprotect
Расшифрованные данные форм авторизации
Поскольку код выполняется в контексте пользователя, то его ключи будут неявно использоваться для расшифровки. Единственная проблема, с которой может столкнуться оператор, — это невозможность открыть базу данных Cookies, когда она используется Chrome. Тогда необходимо просто скопировать файлы в другое место и повторно использовать mimikatz.
2. В контексте администратора с активной сессией целевого пользователя
К примеру, оператор получил административный доступ к системе, в которой имеются пользователи, в текущий момент времени вошедшие в систему. В этом случае прошлый сценарий не сработает.
Неудачное расшифрование данных форм авторизации
Так происходит потому, что ключ юзера в текущем контексте неявно не используется. И как видно из сообщения mimikatz, для работы необходим мастер-ключ пользователя (также сообщается GUID). Так как пользователь залогинен в системе, его сессия открыта и DPAPI хранит его ключевую информацию. Имея административный доступ, оператор может извлечь все данные DPAPI, где и следует искать мастер-ключ.
mimikatz # privilege::debug
mimikatz # sekurlsa::dpapi
Извлечение данных DPAPI
Ключевая информация целевого пользователя
Теперь, когда оператор владеет мастер-ключом, он может использовать его для расшифровки данных пользователя.
mimikatz # dpapi::chrome /in:”С:\Users\<USER>\AppData\Local\Google\Chrome Dev\User Data\Default\Login Data” /unprotect /masterkay:[мастер-ключ]
Расшифрованные данные формы авторизации пользователя3. В контексте администратора без сессии целевого пользователя
Если целевой пользователь на текущий момент не вошел в систему, то для получения его мастер-ключа необходимо знать его SID, GUID и пароль или NTLM-хеш пароля. Если пароль или хеш известен (а как получить хотя бы хеш, рассказывалось ранее), то нужно узнать только SID, GUID мы получим из сообщения mimikatz (как в предыдущем пункте).
SID целевого пользователя
И теперь оператор может получить мастер-ключ.
mimikatz # dpapi::chrome /in:”С:\Users\<USER>\AppData\Roaming\Microsoft\Protect\<SID>\<GUID>” /sid:[SID] /password:[пароль]
Получение мастер-ключа
Что делать дальше, уже подробно рассказывалось выше.
4. Административный доступ к контроллеру домена
Теперь рассмотрим случай, когда оператор не имеет хешей или паролей пользователей, при этом сами пользователи в настоящий момент не залогинены в системе. Как уже говорилось, получить мастер-ключ можно с помощью ключа резервного копирования домена. Ключ резервного копирования никогда не меняется, и его можно использовать для расшифровки абсолютно любых ключей пользователей домена.
mimikatz # privilege::debug
mimikatz # lsadump::backupkeys /system:[контроллер домена] /export
Экспорт ключа резервного копирования
Далее оператору нужен GUID целевого пользователя.
GUID целевого пользователя
Осталось получить мастер-ключ для этого пользователя.
dpapi::masterkey /in:[GUID] /pvk:[PVK-ключ]
Получение мастер-ключа пользователя
Таким образом, мы рассмотрели все способы извлечения сохраненных паролей.
Почти для всех криптосистем одна из самых сложных задач — управление ключами, вернее вопрос безопасного хранения ключей. Если ключ хранится в виде обычного текста, то любой пользователь, имеющий доступ к ключу, может получить доступ и к зашифрованным данным. DPAPI позволяет разработчикам шифровать приватные данные или ключи, используя симметричный ключ, полученный на основе пароля пользователя.
DPAPI предоставляет набор API для простого шифрования (CryptProtectData()) и дешифрования (CryptUnprotectData()) данных с использованием неявных ключей, привязанных к конкретному пользователю или системе. Это позволяет приложениям защищать пользовательские данные, не беспокоясь о таких вещах, как управление ключами.
Пароль юзера используется для получения мастер-ключа. Эти ключи расположены в папке C:\Users\<USER>\AppData\Roaming\Microsoft\Protect\<SID>\<GUID>, где <SID> — это идентификатор безопасности пользователя, а <GUID> — имя мастер-ключа. Пользователь может иметь несколько мастер-ключей. Этот мастер-ключ необходимо расшифровать с помощью пароля пользователя или ключа резервного копирования домена, а затем применить для расшифровки любых данных DPAPI. Поэтому, если мы попытаемся расшифровать зашифрованный пользователем объект данных DPAPI (например, cookie Chrome), нам нужно получить конкретный мастер-ключ пользователя.
ПО, использующее DPAPI
Chrome использует DPAPI для хранения двух основных типов данных, которые интересуют оператора: содержимого файлов cookie и сохраненных паролей. Файлы cookie расположены по пути %localappdata%\Google\Chrome\User Data\Default\Cookies, а данные авторизации — %localappdata%\Google\Chrome\User Data\Default\Login Data. В большинстве систем %localappdata% сопоставляется с C:\Users\<USER>\AppData\Local. Но сами шифрованные данные хранятся в базе данных SQLite, с которыми способен работать mimikatz. Так как у меня установлен Chrome Dev, то в примере вместо директории Chrome используется директория Chrome Dev.
Просмотреть список файлов cookie и учетных данных с помощью mimikatz можно следующим образом:
mimikatz # dpapi::chrome /in:”%localappdata%\Google\Chrome Dev\User Data\Default\Cookies”
Cookie, хранящиеся в базе данныхmimikatz # dpapi::chrome /in:”%localappdata%\Google\Chrome Dev\User Data\Default\Login Data”
Данные форм авторизации, хранящиеся в базе данных
Однако значения файлов cookie зашифрованы DPAPI с помощью мастер-ключа пользователя, который, в свою очередь, защищен паролем пользователя (или ключом резервного копирования домена). Есть несколько сценариев, в которых может оказаться оператор, пытаясь получить данные файлов cookie (или данные для входа).
1. В контексте целевого пользователя
Самый простой случай, когда твоя сессия находится в контексте целевого пользователя. При таком раскладе следует добавить в команду флаг /unprotect.
mimikatz # dpapi::chrome /in:”%localappdata%\Google\Chrome Dev\User Data\Default\Cookies” /unprotect
Расшифрованные Cookiemimikatz # dpapi::chrome /in:”%localappdata%\Google\Chrome Dev\User Data\Default\Login Data” /unprotect
Расшифрованные данные форм авторизации
Поскольку код выполняется в контексте пользователя, то его ключи будут неявно использоваться для расшифровки. Единственная проблема, с которой может столкнуться оператор, — это невозможность открыть базу данных Cookies, когда она используется Chrome. Тогда необходимо просто скопировать файлы в другое место и повторно использовать mimikatz.
2. В контексте администратора с активной сессией целевого пользователя
К примеру, оператор получил административный доступ к системе, в которой имеются пользователи, в текущий момент времени вошедшие в систему. В этом случае прошлый сценарий не сработает.
Неудачное расшифрование данных форм авторизации
Так происходит потому, что ключ юзера в текущем контексте неявно не используется. И как видно из сообщения mimikatz, для работы необходим мастер-ключ пользователя (также сообщается GUID). Так как пользователь залогинен в системе, его сессия открыта и DPAPI хранит его ключевую информацию. Имея административный доступ, оператор может извлечь все данные DPAPI, где и следует искать мастер-ключ.
mimikatz # privilege::debug
mimikatz # sekurlsa::dpapi
Извлечение данных DPAPI
Ключевая информация целевого пользователя
Теперь, когда оператор владеет мастер-ключом, он может использовать его для расшифровки данных пользователя.
mimikatz # dpapi::chrome /in:”С:\Users\<USER>\AppData\Local\Google\Chrome Dev\User Data\Default\Login Data” /unprotect /masterkay:[мастер-ключ]
Расшифрованные данные формы авторизации пользователя3. В контексте администратора без сессии целевого пользователя
Если целевой пользователь на текущий момент не вошел в систему, то для получения его мастер-ключа необходимо знать его SID, GUID и пароль или NTLM-хеш пароля. Если пароль или хеш известен (а как получить хотя бы хеш, рассказывалось ранее), то нужно узнать только SID, GUID мы получим из сообщения mimikatz (как в предыдущем пункте).
SID целевого пользователя
И теперь оператор может получить мастер-ключ.
mimikatz # dpapi::chrome /in:”С:\Users\<USER>\AppData\Roaming\Microsoft\Protect\<SID>\<GUID>” /sid:[SID] /password:[пароль]
Получение мастер-ключа
Что делать дальше, уже подробно рассказывалось выше.
4. Административный доступ к контроллеру домена
Теперь рассмотрим случай, когда оператор не имеет хешей или паролей пользователей, при этом сами пользователи в настоящий момент не залогинены в системе. Как уже говорилось, получить мастер-ключ можно с помощью ключа резервного копирования домена. Ключ резервного копирования никогда не меняется, и его можно использовать для расшифровки абсолютно любых ключей пользователей домена.
mimikatz # privilege::debug
mimikatz # lsadump::backupkeys /system:[контроллер домена] /export
Экспорт ключа резервного копирования
Далее оператору нужен GUID целевого пользователя.
GUID целевого пользователя
Осталось получить мастер-ключ для этого пользователя.
dpapi::masterkey /in:[GUID] /pvk:[PVK-ключ]
Получение мастер-ключа пользователя
Таким образом, мы рассмотрели все способы извлечения сохраненных паролей.