Просмотр пароля Службы

Доброго времени суток, друзья!

Из этого руководства вы узнаете, как извлечь пароли из учетных записей служб и как внедрить gMSA (групповые учетные записи управляемых служб) для правильного управления идентификацией служб. Неправильно настроенные учетные записи служб случаются в каждой компании, и не многие администраторы компании знают о том, насколько опасным может быть неправильная настройка учетных записей.

Так уж сложилось исторически, что все известные мне админы систем не всегда осознают опасности запуска сервисов под доменными администраторами. Как правило существуют различные приложения, наподобии Acronis Backup или к примеру службы SQL Server, а зачастую и службы кластера 1С, службы Параграф, которые необходимо запускать под своими учетными записями. В тот или иной момент времени по различным причинам возникает необходимость просмотра пароля сервисов, ну к примеру неадекватный уход предыдущего системного администратора. Правда, я лично сталкивался с такими случаями неоднократно и представляете себе, практически всем приходится переустанавливать сервис для получения контроля над службой приложения.

Есть способ, который позволяет узнать пароль администратора в случае, если какая-либо служба запускается от его имени.
Пароли учетных записей, от которых запускаются службы Windows, хранятся в зашифрованном виде в реестре (LSA Secrets) по пути:

HKEY_LOCAL_MACHINE/Security/Policy/Secrets

Существуют способы, которые позволяют извлечь пароли из LSA Secrets:

• Скопировать путь реестра во временный путь, а затем расшифровать зашифрованные пароли
• Использовать теневые копии
• Использовать специальные утилиты для работы с процессом lsass.exe

Итак приступим…

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

PsExec / PsExec64
Инструмент, написанный Марком Руссиновичем, который вы можете скачать с sysinternals.com. Нам понадобится этот инструмент для повышения уровня учетной записи локальной системы.

>> Скачать PsExec <<

CQ Secrets Dumper
Мы собираемся извлекать пароли из реестра, получая доступ к LSASS с помощью нашего инструмента CQ Secrets Dumper. Мы практически используем его в тесте на проникновение.

>> Скачать CQ Secrets Dumper <<

Пароль от архива: CQUREAcademy#123!

Попав в систему под локальным администратором (как конкретно это сделать и какими средствами пользоваться можете найти в нашем блоге), Вам необходимо запустить командную строку с правами Системы (не запустить от имени Администратора, а именно NT Authority\System) по причине отсутсвия прав к определенным веткам реестра даже у локальных или доменных администоров.

Для этого воспользуемся утилитой Марка PsExec или PsExec64 в зависимости от битности Вашей системы, запустив ее через командную строку запущенную от имени Администратора.

PsExec64.exe -s -i -d cmd.exe

Затем, нам всего лишь необходимо воспользоваться второй утилитой CQSecretsDumper для извлечения информации о необходимой для нас службы:

CQSecretsDumper.exe /service pjservice

Если не убедительно, то давайте замарочимся без стилиты, который мы получили пароль в 2 шага:

Попробуем получить пароль от учетной записи под которой запускается служба SQL Server.
Имеется:
Контроллер домена на Windows Server 2012 R2
SQL Server Express 2012
При установке SQL Server, для запуска службы, специально укажем существующую доменную учётную запись (пароль тот самый).

Воспользуемся утилитой gsecdump для извлечения паролей (!Внимание данная утилита в отличии от предыдущих попадает под прицел антивирусных продуктов).
Запустим PowerShell от имени администратора и выполним команду:

gsecdump-v2b5.exe -l

Результат:

Ужасаемся и думаем, что с этим делать и как себя и свою компанию обезопасить. Об этом ниже и нам необходимо воспользоваться gMSA (group Managed Service Accounts) в нормальной поднятом уровне леса домена до Windows Server 2012 ну или на худой конец до Windows Server 2008R2.

Теперь Вы можете проверить это в рамкой своей организации на обслуживаемых серверах и если найдете службы запускаемые не от Локальной системы или не от Сетевой службы (отсортируйте по Входу от…):

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

Этот метод активно демонстрирует знаменитая Паула Янушкевич со своей командой CQURE:

Как обезопасить:

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

Чтобы защититься от такого рода атак начиная с Windows Server 2008 R2 был придуман механизм Managed Service Accounts или MSA в Server 2012 — gMSA.
Managed Service Accounts являются управляемыми учетными записями в домене, которые обеспечивают автоматическое управление паролями и упрощенное управление именами служб-участников, включая делегирование управления другим администраторам.

Преимущества управляемых учетных записей служб:

• Автоматическая смена паролей. По умолчанию смена пароля – раз в 30 дней
• Сложный пароль. Используется комплексный автоматически генерируемый пароль из 240 символов в случайном порядке (первая половина — буквы английского алфавита, вторая половина — цифры и другие символы)
• Отсутствие избыточных прав
• Возможность использования одного MSA на нескольких серверах (gMSA). В случае, когда требуется, чтобы все экземпляры служб использовали один и тот же субъект, например для использования в службе NLB
• Управление SPN

Автоматическое обновление SPN при переименовании
— учетной записи сервера
— свойства dnshostname учетной записи сервера
— изменении свойства addition¬aldnshostname учетной записи сервера
— изменении свойства additionalsam¬accountname учетной записи сервера

Сервисы и службы, которые поддерживают MSA:

• IIS
• AD LDS
• SQL Server 2008 R2 SP1, 2012
• MS Exchange 2010, 2013

Требования MSA:

• Уровень домена и леса – Windows Server 2008 R2
• Windows Server 2008 R2, Windows 7 (Professional, Enterprise, Ultimate)
• .Net Framework 3.5x
• Модуль администрирования Active Directory для PowerShell
• Установленный патч 2494158

Если лес и домен не имеют уровень 2008 R2 (MSA) и 2012 (gMSA) нужно поднять уровень леса командой:

adprep /forestprep

И уровень домена, командой:

adprep /domainprep

в каждом домене, в котором необходимо создать и использовать управляемые учетные записи службы.

Включение MSA в PowerShell
1) Выполнить командлет: Import-Module ActiveDirectory
2) Чтобы создать учётную запись MSA нужно выполнить командлет:

New-ADServiceAccount serviceaccount –RestrictToSingleComputer

где serviceaccount – имя учетной записи MSA
RestrictToSingleComputer – параметр означает, что MSA будет привязан только к одному серверу.

Можно зайти в Active Directory Users and Computers и убедиться, что MSA был создан (чтобы появился раздел Managed Service Accounts, нужно включить в оснастке View — Advanced Features).

3) Чтобы привязать MSA к серверу нужно выполнить командлет:

Add-ADComputerServiceAccount -Identity server -ServiceAccount serviceaccount

где server – имя сервера, который будет соотнесён с MSA
serviceaccount – имя учетной записи MSA
Чтобы проверить, что операция выполнена успешно, нужно зайти в оснастку Active Directory Users and Computers, перейти в свойства сервера и посмотреть атрибут msDS-HostServiceAccount

4) Установка управляемой учетной записи службы на локальном компьютере
Нужно выполнить командлет:

Install-ADServiceAccount -Identity serviceaccount

где serviceaccount – имя учетной записи MSA
5) Тестирование MSA (Windows 8.1, Windows PowerShell 4.0, Windows Server 2012 R2)
Нужно выполнить командлет:

Test-ADServiceAccount serviceaccount

где serviceaccount – имя учетной записи MSA
Вернёт значение True или False
6) Установить для службы Windows запуск от имени MSA и перезапустить службу.
В конце имени MSA не забудьте указать знак $
Поле пароль нужно оставить пустым.

Проверим с помощью утилиты gsecdump пароль для учётной записи службы:

В Windows Server 2012 появились Групповые управляемые учетные записи служб (Group Managed Service Accounts).
Они позволяют привязывать управляемую учетную запись не к одному серверу, а к нескольким.
Это может потребоваться, например, для использования в службе балансировки сетевой нагрузки.

Требования:

• Уровень схемы – Windows Server 2012
• Контроллер домена Windows Server 2012 (R2) на котором запущена служба Microsoft Key Distribution Service
• Windows Server 2012, 2012 R2, 8, 8.1
• Модуль администрирования Active Directory для PowerShell

Включение gMSA в PowerShell
1) Проверить, что включена служба Microsoft Key Distribution Services
«Служба распространения ключей использует общий секрет для создания ключей учетной записи. Эти ключи периодически изменяются. В дополнение к прочим атрибутам групповых управляемых учетных записей служб контроллер домена Windows Server 2012 вычисляет пароль для ключа, предоставленного службами распространения ключей. Обратившись к контроллеру домена Windows Server 2012, узлы Windows Server 2012 и Windows 8 могут получить текущий и предыдущий пароль.»
2) Создать Root Key
За создание Root Key отвечает командлет:

Add-KdsRootKey

Чтобы создать новый Root Key нужно выполнить командлет:

Add-KdsRootKey –EffectiveImmediately

В таком случае ключ будет доступен через 10 часов, пока не среплицируется.
Мы также можем использовать небольшую хитрость для нашей тестовой среды, где мы укажем, что время будет десять часов назад или как я называю Назад в прошлое. Кто помнит, таким методом в свое время обходили некоторые активаторы приложений или временные ограничения приложений (Time bomb)

Можно выполнить командлет:

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

В таком случае, ключ будет доступен сразу (-10 часов начала работы)
3) Создать gMSA
Выполнить командлет:

New-ADServiceAccount serviceaccount -DNSHostName test.test.com –PrincipalsAllowedToRetrieveManagedPassword $test

где serviceaccount – имя учетной записи gMSA
test.test.com – имя сервера, на котором был создан Root Key
$test – имя сервера, который может обращаться к KDS для получения информации

Можно зайти в Active Directory Users and Computers и убедиться, что gMSA был создан (чтобы появился раздел Managed Service Accounts, нужно включить в оснастке View — Advanced Features).

4) Установка управляемой учетной записи службы на локальном компьютере
Нужно выполнить командлет:

Install-ADServiceAccount -Identity serviceaccount

где serviceaccount – имя учетной записи gMSA
5) Тестирование MSA (Windows 8.1, Windows PowerShell 4.0, Windows Server 2012 R2)
Нужно выполнить командлет:

Test-ADServiceAccount serviceaccount

где serviceaccount – имя учетной записи MSA
Вернёт значение True или False
6) Установить для службы Windows запуск от имени gMSA и перезапустить службу.
В конце имени gMSA не забудьте указать знак $
Поле пароль нужно оставить пустым.

Ну и проверим с помощью утилиты gsecdump пароль для учётной записи службы

Удалить MSA/gMSA можно с помощью командлета Uninstall-ADServiceAccount

Задавать параметры MSA/gMSA можно с помощью командлета Set-ADServiceAccount
Задание периода смены пароля:

Set-ADServiceAccount serviceaccount -ManagedPasswordIntervalInDays 60

где serviceaccount – имя учетной записи gMSA
60 – период, через который сменится пароль

Задание криптоалгоритмов Kerberos для использования MSA
Варианты: RC4, AES128, AES256

Set-ADServiceAccount serviceaccount -KerberosEncryptionType RC4, AES128, AES256

Задание SPN

Set-ADServiceAccount serviceaccount -ServicePrincipalNames @{Add=«добавляемый SPN»}

Задание NetBIOS имени для сервиса (SAMAccountName)
Если не задано, используется идентификатор Name
Если задано, имя отображения в AD будет из Name, а идентификатор для логина из SAMAccountName

Set-ADServiceAccount serviceaccount –SamAccountName test

MSA/gMSA – это ещё один способ, который позволяет повысить безопасность. Надеюсь Вам было полезно и интересно.