Вступление от меня: Статье +- пол годика, но мне она показалась крайне занимательной. Просерчил по форуму, вроде еще не было.
Вышло так, что я искал дополнительный вектор атаки. И когда у меня уже опускались руки, эта находка оказалась прям "вкусной", а гланое, своевременной. И, скажу тебе, mon ami, я довольно успешно смог применить это на практике. А следовательно - сможешь и ты.
Это мой кривой перевод (не без гуглтранслэйт ессно). Кому не по нраву моя "адаптация" - плюйтесь в репу, пишите вспортлото гугол или чекайте статью в оригинале туть
От автора (было бы неуважением это опустить):
_________
За свою карьеру у меня была привилегированная возможность заглянуть за завесу некоторых крупнейших организаций мира. По моему опыту, большинство отраслевых вертикалей полагаются на корпоративные сети Windows. Фактически, я могу пересчитать по пальцам одной руки, сколько раз я видел децентрализованную сеть с нулевым доверием, корпоративный Linux, сеть, построенную на macOS или альтернативу Active Directory (FreeIPA).
Путешествуя по этим большим и часто сложным корпоративным сетям, я часто обнаруживаю серверы Microsoft SQL, которые обычно разворачиваются для поддержки бизнес-функций. Для читателей, незнакомых с SQL Server:
Короче говоря, это программное обеспечение для реляционных баз данных, обычно устанавливаемое поверх сервера Windows. Основная цель SQL Server — хранить и предоставлять данные приложениям или пользователям.
В этой статье будет рассмотрена поверхность атаки, которую представляет SQL Server, а также способы горизонтального перемещения, выполнения произвольных комманд, азлоупотребления неправильными конфигурациями и уязвимостями с помощью нашего инструмента SQLRecon . Кроме того, там, где это применимо, будут изложены и соображения защиты.
Приступим.
Microsoft SQL-сервер
Уязвимости и неправильные настройки SQL Server хорошо документированы. Хотя эти недостатки, по-видимому, существовали всегда, защитные команды (blue team,голубые карочь) по-прежнему часто упускают из виду апгроейд секурности SQL Server-ов. В основном, я имею в виду, усиление базовой конфигурации и предотвращение тривиального доступа к сервису.
Одним из правдоподобных оправданий такого упущения является то, что организации необходимо расставить приоритеты и устранить более серьезные риски. В результате, усиление защиты SQL Server-ов отходит на второй план, поскольку изменения в конфигурациях производственной базы данных могут привести к проблемам с доступностью, которые могут проявиться в операционных проблемах и в конечном итоге повлиять на производительность самого бизнеса.
Распространенные уязвимости и неправильные настройки
Одна из наиболее распространенных ошибок конфигурации, которую я продолжаю наблюдать в корпоративных сетях — это возможность любого аутентифицированного объекта домена подключаться к службе SQL с учетной записью с низкими привилегиями. Для этого требуется только действительный контекст домена. Другими словами, действительный токен для учетной записи пользователя домена или компьютера домена.
В качестве примера: если рабочая станция обычного бизнес-пользователя взломана и существует сетевой маршрут к неправильно настроенному SQL-серверу, злоумышленник может:
SQLRecon
SQLRecon помогает устранить пробелы в инструментах пост-эксплуатации, модернизируя подход, который операторы red team могут использовать при атаке на SQL-серверы. Инструмент был разработан как модульный, что обеспечивает простоту масштабирования и адаптации. SQLRecon применим в качестве как самостоятельного инструмента, так и в составе разнообразного набора для платформ C2. При использовании последних, SQLRecon может выполняться либо внутри процесса, либо посредством традиционного разветвления и запуска.
SQLRecon предлагает на выбор более 80 модулей.
Ниже приведен общий обзор некоторых функций, предоставляемых SQLRecon:
Authentication Providers
Подробную информацию об использовании каждого метода можно найти в wiki
Использование SQLRecon
Чтобы подготовить почву для предстоящих демонстраций, я буду работать на взломанной рабочей станции Windows 10, принадлежащей Джеффу Смиту (JSmith) в корпоративной сети kawalabs.local.
Рабочая станция Джеффа имеет сетевой маршрут к трем SQL-серверам, на каждом из которых работают разные версии; 2016, 2019 и 2022.
Между SQL01 и SQL02 настроена SQL "ссылка" (они прилинкованы) + SQL02 и SQL03 так же прилинкованы. Для читателей, которые не знакомы со связанными SQL-серверами: это эффективно позволяет одному экземпляру SQL выполнять операторы\SQL запросы на другом SQL экземпляре. Например, SQL01 может выполнять SQL операторы на SQL02, и SQL02 может выполнять инструкции SQL03, но SQL01 не может выполнять инструкции на SQL03 и наоборот. В реальных корпоративных сетях часто можно увидеть подобные "линкованные" SQL-серверы.
Кроме того, между SQL03 и основным контроллером домена в сети kawalabs.local, DC01, существует связь служб Active Directory (ADSI).
Ссылки ADSI предоставляют SQL Server-ам возможность взаимодействия с объектами Active Directory.
Наконец, домен kawalabs.local был подключен к домену Azure Active Directory kawalabs.onmicrosoft.com с помощью Azure AD Connect. Это позволяет локальным пользователям Active Directory в kawalabs.local получать доступ к ресурсам в облаке Azure.
Azure AD onmicrosoft.com содержит SQL-сервер ECOM01, на котором хранятся данные о платежах.
Конфигурация сети
Кроме того, я буду использовать Cobalt Strike, популярную систему управления и контроля, для выполнения задач пост-эксплуатации со скомпрометированной рабочей станции Джеффа (DESKTOP-LF8Q3C6).
На следующем снимке экрана я выполнил команду whoami.
Это просто для того, чтобы показать, что Джефф не является привилегированным пользователем и имеет обычные права в домене kawalabs.local и в основной сети.
whoami
Enumerating (перечисление)
На момент написания, SQLRecon имел два модуля перечисления, которые можно использовать для обнаружения SQL серверов в сети, а также для получения некоторой информации об экземпляре SQL Server-а. Следующая команда перечислит имена участников службы Active Directory (SPN) и определит, установлены ли какие-либо SPN для серверов SQL. В домене kawalabs.local для нескольких разных учетных записей установлено имя SPN, это показано на скриншоте ниже:
Обнаружение SQL-серверов через SPN
Так же весьма полезен информационный модуль, для получения дополнительной информации о сервере. В приведенном ниже примере показан тип информации, получаемой с SQL-сервера.
Получение информации о SQL02
Стандартные модули
Стандартные модули выполняются на одном экземпляре SQL Server.
В следующем примере я использую AzureAD, который задействует имя пользователя и пароль для учетной записи Azure Active Directory, для аутентификации в ECOM01 - экземпляре SQL, расположенном в облаке Azure.
Затем я использую модуль whoami, чтобы определить права Джеффа на ECOM01.
Перечисление SQL привилегий для jsmith@kawalabs.onmicrosoft.com
По умолчанию SQLRecon подключается к главной базе данных, поскольку эта база данных обычно существует во всех экземплярах SQL Server.
Однако, вы можете легко составить список всех различных баз данных на экземплярах SQL Server, используя databases модуль.
Перечисление баз данных на ECOM01
Вы можете подключиться к другим базам данных, указав имя базы данных с флагом /database: и передать любой модуль, который вы хотите выполнить.
В приведенном ниже примере я подключаюсь к базе данных «Payments» на ECOM01 и выполняю специальный SQL-запрос, который получит все содержимое из таблицы cc.
Obtaining dummy card data from the cc table in the Payments database on ECOM01
Переходя к некоторым более интересным модулям, SQLRecon поддерживает внедрение пути UNC, которое может выполняться учетной записью пользователя с низкими привилегиями, например KAWALABS\JSmith. Это может привести к получению хешированных учетных данных, которые, в свою очередь, могут быть взломаны или переданы для выполнения атак в стиле ретрансляции. В следующем примере я использую WinToken, который задействует токен для учетной записи пользователя KAWALABS\JSmith, для аутентификации на локальном сервере SQL02,
UNC path injection
На следующем снимке экрана мы видим подключение SQL02 к хосту в нашем элементе управления (172.16.10.19).
В результате получаем хэш NetNTLMv2 для учетной записи домена KAWALABS\mssql_svc.
Получаем хеш NetNTLMv2 для KAWALABS\mssql_svc
SQLRecon имеет множество модулей выполнения команд, которые можно использовать для выполнения произвольных команд в базовой системе. Это особенно полезно, если вы хотите выполнить повышение привилегий и/или горизонтальное перемещение.
В SQLRecon реализованы значительные меры, обеспечивающие обход ограничений операционной безопасности по умолчанию. Двумя основными являются:
В следующем примере я использовал учетную запись KAWALABS\JSmith с низким уровнем привилегий, чтобы попытаться запустить приложение notepad.exe на SQL01.
Демонстрация ограничения, препятствующего выполнению команд.
Как видно на изображении выше, обнаружено ограничение выполнения и получено сообщение об ошибке, указывающее, что xp_cmdshell отключен. Обычно это конфигурация по умолчанию в большинстве версий SQL Server.
Приятно то, что SQLRecon имеет модуль EnableXp, который включает настройку xp_cmdshell.
SQLRecon также имеет модуль DisableXp, позволяющий вернуться в исходное безопасное состояние после выполнения команды с помощью xpCmd.
Демонстрация еще одного ограничения, при котором недостаточные привилегии препятствуют выполнению команды.
Как и ожидалось, учетная запись KAWALABS\JSmith, с низкими привилегиями, столкнулась с препятствием выполнения и получила сообщение о том, что у нее нет этих необходимых привилегий для включения или отключения xp_cmdshell… или все таки они есть?
Имперсонализация (выдаем себя за другое "лицо")
SQL impersonation — это специальное разрешение, которое, по сути, позволяет пользователю или группе работать с разрешением другого пользователя, а также со своими собственными разрешениями. Следующий снимок экрана взят из внутренней конфигурации SQL02 и демонстрирует, что BUILTIN\Users может выдавать себя за учетную запись sa (system admin.)
BUILTIN\Users могут выдавать себя за учетную запись sa на SQL02
SQLRecon имеет модуль имперсонализации, помогающий определить, может ли учетная запись текущего пользователя, выдавать себя за другого пользователя.
Как видно на снимке экрана ниже, учетная запись пользователя KAWALABS\JSmith с низкими привилегиями может выдавать себя за учетную запись sa в SQL02.
Это демонстрирует возможность выполнять команды на экземпляре SQL с привилегиями администратора. Более того, это означает, что теперь мы можем выполнять системные команды на базовом сервере.
Перечисление учетных записей, которые можно "подменять" в SQL02
Чтобы продемонстрировать другой модуль выполнения команд, SQLRecon может выполнять команды базового пользователя, используя OLE Automation Procedures. При этом используется сборка odsole70.dll для взаимодействия с COM-объектами, поэтому wscript.shell можно использовать для запуска произвольных системных команд.
Модули имперсонализации всегда начинаются с буквы i, и этим модулям потребуется имя учетной записи, которая будет олицетворяться. В следующем примере я подключаюсь к SQL02 как учетная запись KAWALABS\JSmith с низким уровнем привилегий и "подменяю" свою учетную запись, выступая в роли sa, чтобы включить процедуры автоматизации OLE на SQL02.
Включение процедур OLE-автоматизации с использованием имперсонализации
Теперь, когда процедуры автоматизации OLE включены в SQL02, я могу выполнить любую произвольную команду на базовом сервере, в контексте учетной записи пользователя, которая запустила процесс SQL Server. В следующем примере я запускаю дочерний процесс PowerShell, в котором указан каталог того же общего ресурса, который ранее использовался для захвата учетных данных NetNTLMv2. Имейте в виду, что данный метод в основном используется для демонстрационных целей, а не для действий, которые обычно выполняются при моделировании реальной атаки
Использование PowerShell для вывода списка каталогов на удаленном хосте
Как видно на снимке экрана выше, создается случайно сгенерированный объект и метод OLE, затем выполняется наш пэйлоад, а объекты OLE уничтожаются. Это сделано намеренно, поскольку мы не хотим оставлять после себя никаких следов.
На следующем скриншоте, мы видим подключение учетной записи пользователя KAWALABS\mssql_svc через SQL02 к хосту под нашим контролем (172.16.10.19).
В результате получаем хеш NetNTLMv2 для учетной записи аккаунта KAWALABS\mssql_svc.
получаем хеш NetNTLMv2 для KAWALABS\mssql_svc
В следующем примере показано использование имперсонализации, для вывода списка задач, с использованием xp_cmdshell в SQL02.
Включение xp_cmdshell и выполнение системных команд с использованием имперсонализации на SQL02
Аттеншн: Всегда полезно возвращать конфигурации обратно в исходное состояние.
Атака на "линкованные" SQL-сервера
SQLRecon также может выполнять атаки на связанные экземпляры SQL Server.
Следующий снимок экрана взят из внутренней конфигурации SQL02 и демонстрирует, что SQL02 имеет ссылку на SQL03. По моему опыту, это обычная конфигурация в крупных корпоративных сетях.
SQL02 имеет SQL ссылку на SQL03.
Для настройки ссылки от одного экземпляра SQL Server к другому, часто требуется набор привилегированных учетных данных для установки и привязки ссылки. Это выгодно злоумышленникам, поскольку позволяет выполнять команды на связанном SQL-сервере в контексте учетной записи, которая установила соединение.
Еще один момент, который следует учитывать, заключается в том, что связанные серверы могут быть отделены от сети, в которой работает злоумышленник. Это может предоставить возможность пересечь границы сегментации и войти в сетевую зону с более высокими требованиями безопасности.
SQLRecon имеет модуль ссылок, позволяющий определить, есть ли на SQL Server-е какие-либо связанные экземпляры SQL.
Перечисление линкованных SQL servers на SQL02
Связанные модули всегда начинаются с буквы l, и этим модулям потребуется имя связанного сервера, которому вы хотите отдавать команды.
В следующем примере я подключаюсь к SQL02 как учетная запись KAWALABS\JSmith с низким уровнем привилегий и запускаю команду lWhoami для линкованного экземпляра SQL03.
Перечисление привилегий SQL, которые мы можем получить на SQL03 через SQL02
Как видно на снимке экрана выше, мы работаем в контексте учетной записи sa на SQL03. Это связано с тем, что учетная запись sa использовалась для установления связи SQL с SQL02 на SQL03.
Все модули выполнения в SQLRecon полностью поддерживаются на связанных SQL-серверах. В следующем примере я включаю интеграцию Common Language Runtime (CLR) в SQL02.
Включение интеграции CLR в SQL02
Интеграция CLR позволяет импортировать пользовательские сборки .NET в SQL Server. Эти сборки находятся внутри хранимой процедуры до их выполнения. Это хороший пример примитивной атаки боковым перемещением.
На следующем скрине я создаю пользовательскую сборку .NET, совместимую с SQL Server CLR, под названием Hollow.dll.
При этом пэйлоады Cobalt Strike будут размещены в хранимой процедуре, с именем ExecuteShellcode.
Полезная нагрузка выполняет базовый процесс и внедряет шелл-код Cobalt Strike в новый процесс Internet Explorer (iexplore.exe).
Hollow.dll — сборка .NET, совместимая с SQL Server CLR.
Если вы хотите узнать больше о пользовательских сборках .NET, совместимых с SQL Server CLR, посетите раздел Clr вики-страницы SQLRecon. Пример hollow.dll можно найти здесь.
В следующей демонстрации я загрузил hollow.dll на веб-сервер и переименовал сборку в favicon.png. Я даю указание линкованному серверу SQL03 загрузить favicon.png с веб-сервера и выполнить необходимые шаги для импорта пользовательской сборки в хранимую процедуру SQL Server и выполнения полезной нагрузки.
В результате получается маяк Cobalt Strike в контексте пользователя KAWALABS\mssql_svc на SQL03.
Получение маяка Cobalt Strike в контексте KAWALABS\mssql_svc на SQL03
Конечно, предыдущий пример требует, чтобы SQL03 имел доступ к Интернету для загрузки сборки с общедоступного веб-сервера. Бывают случаи, когда загрузка стороннего ресурса с общедоступного веб-сервера невозможна или нежелательна. Как таковой, SQLRecon позволяет загружать пользовательские сборки непосредственно из файловой системы скомпрометированного хоста или из общего ресурса SMB. В следующей демонстрации я загрузил hollow.dll на локальный SMB-сервер и переименовал сборку в Reports.xlsx. Я даю указание связанному серверу SQL03 загрузить Reports.xlsx с сервера SMB и выполнить необходимые действия для импорта пользовательской сборки в хранимую процедуру SQL Server для выполнения полезной нагрузки. В результате так же получается маяк Cobalt Strike в контексте пользователя KAWALABS\mssql_svc на SQL03.
Получение маяка Cobalt Strike в контексте KAWALABS\mssql_svc<code> на <code>SQL03
Атака на линкованные SQL-сервера – злоупотребление ADSI
SQLRecon также может выполнять атаки на связанные экземпляры сервера ADSI, чтобы получить учетные данные в открытом виде для учетных записей домена. Дополнительную информацию о ADSI можно найти в блоге Tarlogic.
Следующий снимок экрана взят из серверной конфигурации SQL03 и демонстрирует, что SQL03 имеет ссылку ADSI на основной контроллер домена, в домене kawalabs.local, DC01.
Эта ссылка ADSI представлена объектом linkADSI.
SQL03 имеет ссылку ADSI на DC01.
Настройка канала ADSI от экземпляра SQL Server к контроллеру домена Active Directory не обязательно требует привилегированных учетных данных. Однако в ходе реальных операций, я видел случаи, когда принцип наименьших привилегий не применялся.
В следующем примере я использую модуль lLinks для первого подключения к SQL02. ---> а затем запрашиваю у SQL03 дополнительный связанный SQL-сервер. Вы можете думать об этом как о сценарии "двойной ссылки".
Перечисление ссылок на SQL03 из SQL02
Теперь, когда мы убедились, что ссылка ADSI существует на SQL03, мы можем использовать модуль lAdsi для получения учетных данных домена в открытом виде, используемых для настройки соединения ADSI с SQL03 на DC01. Это предполагает загрузку пользовательской сборки CLR, содержащей сервер LDAP, в новую процедуру выполнения SQL Server на SQL03.
Затем сервер LDAP будет выполнять и прослушивать локальные соединения на указанном пользователем порту, в данном случае 49103. Затем мы используем задания агента SQL Server на SQL03, чтобы направить учетные данные, используемые для настройки соединения ADSI, для вызова LDAP-запроса на локальный сервер LDAP по порту 49103.
Это временное перенаправление аутентификации LDAP в конечном итоге приводит к получению учетных данных домена в открытом виде. Следует отметить, что модули Adsi и iAdsi не используют задания агента SQL Server для инициирования процесса запроса LDAP, вместо этого используются стандартные SQL-запросы.
Атака со сбором учетных данных ADSI по двойной ссылке
Модули SCCM
Одно из крупнейших расширений SQLRecon принадлежит моему коллеге Дэйву Косса (@G0ldenGunSec), он представил множество модулей, которые можно использовать для злоупотреблений Microsoft System Center Configuration Manager (SCCM) и Microsoft Endpoint Configuration Manager (ECM).
Модули SCCM были разработаны на основе реального взаимодействия, где злоупотребление базой данных SCCM SQL Server способствовало нашему продвижению к целям.
В большинстве случаев для взаимодействия с базой данных SCCM необходимо получить контекст с повышенными привилегиями или получить доступ к серверу SCCM.
В примерах ниже, у меня есть маяк Cobalt Strike, работающий в контексте учетной записи KAWALABS\mssccm_svc на ECM сервере - MECM01.
С этого момента я буду просто называть их ECM и SCCM.
В следующем примере я использую модуль баз данных для перечисления баз данных, существующих в экземпляре SQL Server на MECM01.
Перечисление баз данных на MECM01
Как видно на снимке экрана выше, существует база данных CM_KAW, которая, скорее всего, является базой данных, настроенной для SCCM на этом сервере.
Модули SCCM всегда начинаются с буквы s, и этим модулям потребуется имя базы данных SCCM, для которой вы хотите выполнять команды.
В следующем примере я подключаюсь к базе данных CM_KAW на MECM01 под учетной записью KAWALABS\mssccm_svc и ввожу команду sUsers.
Этот модуль перечисляет всех участников, настроенных для входа на сервер SCCM.
Перечисление всех пользователей, которые могут войти в SCCM через базу данных SCCM SQL Server.
Также можно перечислить задачи, настроенные в SCCM, с помощью модуля sTaskList.
Перечисление задач, настроенных в SCCM, через базу данных SCCM SQL Server.
SCCM обычно требуется хранить учетные данные, которые используются для аутентификации в системах или ресурсах в среде для развертывания пакетов программного обеспечения или выполнения любых других различных действий, предоставляемых SCCM. Используя модуль sCredentials, мы можем получить список учетных данных в хранилище.
Получение учетных данных из хранилища через базу данных SCCM SQL Server.
На снимке экрана выше, мы видим, что одна учетка сохранена, и это учетные данные аккаунта KAWALABS\mssccm_svc.
Используя логику Адама Честера (@_xpn_), можно расшифровать учетные данные из хранилища SCCM и получить пароль в виде открытого текста для учетных записей в хранилище. Для этого требуются права локального администратора на сервере SCCM.. На следующем снимке экрана я использую учетную запись sDecryptCredentials для расшифровки учетных данных, сохраненных для учетной записи KAWALABS\mssccm_svc.
Расшифровка учетных данных SCCM в хранилище
На этом, пожалуй, все, мой друг.
В оригинале статьи (ссылка в "шапке") еще есть советы по защите. Однако я не для того переводил эту простыню . Ты можешь, по желанию, перевести это и самостоятельно.
З.Ы. Обычно я не занимаюсь переводом и копирайтингом (на это совершенно нет времени), но т.к. у нас на форуме эта тема (довольно актуальная, хочу заметить) не была освещена - мне было просто необходимо исправить столь досадное упущение.
Всех благ.
Вышло так, что я искал дополнительный вектор атаки. И когда у меня уже опускались руки, эта находка оказалась прям "вкусной", а гланое, своевременной. И, скажу тебе, mon ami, я довольно успешно смог применить это на практике. А следовательно - сможешь и ты.
Это мой кривой перевод (не без гуглтранслэйт ессно). Кому не по нраву моя "адаптация" - плюйтесь в репу, пишите в
От автора (было бы неуважением это опустить):
_________
За свою карьеру у меня была привилегированная возможность заглянуть за завесу некоторых крупнейших организаций мира. По моему опыту, большинство отраслевых вертикалей полагаются на корпоративные сети Windows. Фактически, я могу пересчитать по пальцам одной руки, сколько раз я видел децентрализованную сеть с нулевым доверием, корпоративный Linux, сеть, построенную на macOS или альтернативу Active Directory (FreeIPA).
Путешествуя по этим большим и часто сложным корпоративным сетям, я часто обнаруживаю серверы Microsoft SQL, которые обычно разворачиваются для поддержки бизнес-функций. Для читателей, незнакомых с SQL Server:
Короче говоря, это программное обеспечение для реляционных баз данных, обычно устанавливаемое поверх сервера Windows. Основная цель SQL Server — хранить и предоставлять данные приложениям или пользователям.
В этой статье будет рассмотрена поверхность атаки, которую представляет SQL Server, а также способы горизонтального перемещения, выполнения произвольных комманд, азлоупотребления неправильными конфигурациями и уязвимостями с помощью нашего инструмента SQLRecon . Кроме того, там, где это применимо, будут изложены и соображения защиты.
Приступим.
Microsoft SQL-сервер
Уязвимости и неправильные настройки SQL Server хорошо документированы. Хотя эти недостатки, по-видимому, существовали всегда, защитные команды (blue team,
Одним из правдоподобных оправданий такого упущения является то, что организации необходимо расставить приоритеты и устранить более серьезные риски. В результате, усиление защиты SQL Server-ов отходит на второй план, поскольку изменения в конфигурациях производственной базы данных могут привести к проблемам с доступностью, которые могут проявиться в операционных проблемах и в конечном итоге повлиять на производительность самого бизнеса.
Распространенные уязвимости и неправильные настройки
Одна из наиболее распространенных ошибок конфигурации, которую я продолжаю наблюдать в корпоративных сетях — это возможность любого аутентифицированного объекта домена подключаться к службе SQL с учетной записью с низкими привилегиями. Для этого требуется только действительный контекст домена. Другими словами, действительный токен для учетной записи пользователя домена или компьютера домена.
В качестве примера: если рабочая станция обычного бизнес-пользователя взломана и существует сетевой маршрут к неправильно настроенному SQL-серверу, злоумышленник может:
- Выполнить ограниченные команды SQL на удаленном SQL сервере в сетке.
- Определить, какие есть привилегии у других пользователей, которые могут предоставить возможности эскалации посредством атак в стиле имперсонализации (т.н. подмены "личности").
- Заставить SQL Server предоставлять данные аутентификации пользователей, через инициированный запрос по пути Universal Naming Convention (UNC), что может привести к получению хешированных учетных данных, которые, в свою очередь, могут быть взломаны (расхэш) или переданы для выполнения атак в стиле ретрансляции.
- Совмещение прав (piggyback), назначенных целевому SQL-серверу, прилинкованному к другим SQL-серверам в области взаимодействия, что может привести к повышению привилегий.
SQLRecon
SQLRecon помогает устранить пробелы в инструментах пост-эксплуатации, модернизируя подход, который операторы red team могут использовать при атаке на SQL-серверы. Инструмент был разработан как модульный, что обеспечивает простоту масштабирования и адаптации. SQLRecon применим в качестве как самостоятельного инструмента, так и в составе разнообразного набора для платформ C2. При использовании последних, SQLRecon может выполняться либо внутри процесса, либо посредством традиционного разветвления и запуска.
SQLRecon предлагает на выбор более 80 модулей.
Ниже приведен общий обзор некоторых функций, предоставляемых SQLRecon:
Authentication Providers
- Local SQL database account
- Windows domain authentication based on current token
- Windows domain authentication with user supplied credentials
- Azure domain authentication
- Azure local authentication
- Locate SQL Servers associated with a Service Principal Name (SPN)
- Obtain information about the SQL service
- Determine privileges within SQL Server
- List databases, tables, columns, and users
- Search databases for content
- Execute arbitrary queries
- Enumerate users which can be impersonated
- Identify linked SQL Servers
- xp_сmdshell
- OLE Automation Procedures
- Load and execute custom .NET CLR assemblies
- SQL Agent Jobs
- ADSI credential gathering
- Continuous authentication validation
- Extensive command line logging
- Execution guardrails based on whether SQL Server options are enabled or disabled
- Argument error handling
- Randomized alphanumeric SQL content creation where applicable
- Automatic clean-up of data created in SQL Server for command execution purposes
- Ability to switch database contexts
- Connect to SQL Servers listening on non-standard TCP ports
- Support for impersonation-style attacks
- Ability to enumerate and attack linked SQL Servers
- Support for a variety of Microsoft System Center Configuration Manager (SCCM) and Microsoft Endpoint Configuration Manager (ECM) SQL database attacks
- All SQL queries use the System.Data.SqlClient namespace, developed by Microsoft
Подробную информацию об использовании каждого метода можно найти в wiki
Использование SQLRecon
Чтобы подготовить почву для предстоящих демонстраций, я буду работать на взломанной рабочей станции Windows 10, принадлежащей Джеффу Смиту (JSmith) в корпоративной сети kawalabs.local.
Рабочая станция Джеффа имеет сетевой маршрут к трем SQL-серверам, на каждом из которых работают разные версии; 2016, 2019 и 2022.
Между SQL01 и SQL02 настроена SQL "ссылка" (они прилинкованы) + SQL02 и SQL03 так же прилинкованы. Для читателей, которые не знакомы со связанными SQL-серверами: это эффективно позволяет одному экземпляру SQL выполнять операторы\SQL запросы на другом SQL экземпляре. Например, SQL01 может выполнять SQL операторы на SQL02, и SQL02 может выполнять инструкции SQL03, но SQL01 не может выполнять инструкции на SQL03 и наоборот. В реальных корпоративных сетях часто можно увидеть подобные "линкованные" SQL-серверы.
Кроме того, между SQL03 и основным контроллером домена в сети kawalabs.local, DC01, существует связь служб Active Directory (ADSI).
Ссылки ADSI предоставляют SQL Server-ам возможность взаимодействия с объектами Active Directory.
Наконец, домен kawalabs.local был подключен к домену Azure Active Directory kawalabs.onmicrosoft.com с помощью Azure AD Connect. Это позволяет локальным пользователям Active Directory в kawalabs.local получать доступ к ресурсам в облаке Azure.
Azure AD onmicrosoft.com содержит SQL-сервер ECOM01, на котором хранятся данные о платежах.
Конфигурация сети
Кроме того, я буду использовать Cobalt Strike, популярную систему управления и контроля, для выполнения задач пост-эксплуатации со скомпрометированной рабочей станции Джеффа (DESKTOP-LF8Q3C6).
На следующем снимке экрана я выполнил команду whoami.
Это просто для того, чтобы показать, что Джефф не является привилегированным пользователем и имеет обычные права в домене kawalabs.local и в основной сети.
whoami
Enumerating (перечисление)
На момент написания, SQLRecon имел два модуля перечисления, которые можно использовать для обнаружения SQL серверов в сети, а также для получения некоторой информации об экземпляре SQL Server-а. Следующая команда перечислит имена участников службы Active Directory (SPN) и определит, установлены ли какие-либо SPN для серверов SQL. В домене kawalabs.local для нескольких разных учетных записей установлено имя SPN, это показано на скриншоте ниже:
Обнаружение SQL-серверов через SPN
Так же весьма полезен информационный модуль, для получения дополнительной информации о сервере. В приведенном ниже примере показан тип информации, получаемой с SQL-сервера.
Получение информации о SQL02
Стандартные модули
Стандартные модули выполняются на одном экземпляре SQL Server.
В следующем примере я использую AzureAD, который задействует имя пользователя и пароль для учетной записи Azure Active Directory, для аутентификации в ECOM01 - экземпляре SQL, расположенном в облаке Azure.
Затем я использую модуль whoami, чтобы определить права Джеффа на ECOM01.
Перечисление SQL привилегий для jsmith@kawalabs.onmicrosoft.com
По умолчанию SQLRecon подключается к главной базе данных, поскольку эта база данных обычно существует во всех экземплярах SQL Server.
Однако, вы можете легко составить список всех различных баз данных на экземплярах SQL Server, используя databases модуль.
Перечисление баз данных на ECOM01
Вы можете подключиться к другим базам данных, указав имя базы данных с флагом /database: и передать любой модуль, который вы хотите выполнить.
В приведенном ниже примере я подключаюсь к базе данных «Payments» на ECOM01 и выполняю специальный SQL-запрос, который получит все содержимое из таблицы cc.
Obtaining dummy card data from the cc table in the Payments database on ECOM01
Переходя к некоторым более интересным модулям, SQLRecon поддерживает внедрение пути UNC, которое может выполняться учетной записью пользователя с низкими привилегиями, например KAWALABS\JSmith. Это может привести к получению хешированных учетных данных, которые, в свою очередь, могут быть взломаны или переданы для выполнения атак в стиле ретрансляции. В следующем примере я использую WinToken, который задействует токен для учетной записи пользователя KAWALABS\JSmith, для аутентификации на локальном сервере SQL02,
UNC path injection
На следующем снимке экрана мы видим подключение SQL02 к хосту в нашем элементе управления (172.16.10.19).
В результате получаем хэш NetNTLMv2 для учетной записи домена KAWALABS\mssql_svc.
Получаем хеш NetNTLMv2 для KAWALABS\mssql_svc
SQLRecon имеет множество модулей выполнения команд, которые можно использовать для выполнения произвольных команд в базовой системе. Это особенно полезно, если вы хотите выполнить повышение привилегий и/или горизонтальное перемещение.
В SQLRecon реализованы значительные меры, обеспечивающие обход ограничений операционной безопасности по умолчанию. Двумя основными являются:
- Непрерывная проверка подлинности: SQLRecon чекает возможность проверки подлинности в домене или на SQL-сервере перед выполнением каких-либо модулей.
- SQLRecon проверяет наличие оптимальных условий перед выполнением любых модулей, которые загружают объекты, создают объекты или выполняют команды.
В следующем примере я использовал учетную запись KAWALABS\JSmith с низким уровнем привилегий, чтобы попытаться запустить приложение notepad.exe на SQL01.
Демонстрация ограничения, препятствующего выполнению команд.
Как видно на изображении выше, обнаружено ограничение выполнения и получено сообщение об ошибке, указывающее, что xp_cmdshell отключен. Обычно это конфигурация по умолчанию в большинстве версий SQL Server.
Приятно то, что SQLRecon имеет модуль EnableXp, который включает настройку xp_cmdshell.
SQLRecon также имеет модуль DisableXp, позволяющий вернуться в исходное безопасное состояние после выполнения команды с помощью xpCmd.
Демонстрация еще одного ограничения, при котором недостаточные привилегии препятствуют выполнению команды.
Как и ожидалось, учетная запись KAWALABS\JSmith, с низкими привилегиями, столкнулась с препятствием выполнения и получила сообщение о том, что у нее нет этих необходимых привилегий для включения или отключения xp_cmdshell… или все таки они есть?
Имперсонализация (выдаем себя за другое "лицо")
SQL impersonation — это специальное разрешение, которое, по сути, позволяет пользователю или группе работать с разрешением другого пользователя, а также со своими собственными разрешениями. Следующий снимок экрана взят из внутренней конфигурации SQL02 и демонстрирует, что BUILTIN\Users может выдавать себя за учетную запись sa (system admin.)
BUILTIN\Users могут выдавать себя за учетную запись sa на SQL02
SQLRecon имеет модуль имперсонализации, помогающий определить, может ли учетная запись текущего пользователя, выдавать себя за другого пользователя.
Как видно на снимке экрана ниже, учетная запись пользователя KAWALABS\JSmith с низкими привилегиями может выдавать себя за учетную запись sa в SQL02.
Это демонстрирует возможность выполнять команды на экземпляре SQL с привилегиями администратора. Более того, это означает, что теперь мы можем выполнять системные команды на базовом сервере.
Перечисление учетных записей, которые можно "подменять" в SQL02
Чтобы продемонстрировать другой модуль выполнения команд, SQLRecon может выполнять команды базового пользователя, используя OLE Automation Procedures. При этом используется сборка odsole70.dll для взаимодействия с COM-объектами, поэтому wscript.shell можно использовать для запуска произвольных системных команд.
Модули имперсонализации всегда начинаются с буквы i, и этим модулям потребуется имя учетной записи, которая будет олицетворяться. В следующем примере я подключаюсь к SQL02 как учетная запись KAWALABS\JSmith с низким уровнем привилегий и "подменяю" свою учетную запись, выступая в роли sa, чтобы включить процедуры автоматизации OLE на SQL02.
Включение процедур OLE-автоматизации с использованием имперсонализации
Теперь, когда процедуры автоматизации OLE включены в SQL02, я могу выполнить любую произвольную команду на базовом сервере, в контексте учетной записи пользователя, которая запустила процесс SQL Server. В следующем примере я запускаю дочерний процесс PowerShell, в котором указан каталог того же общего ресурса, который ранее использовался для захвата учетных данных NetNTLMv2. Имейте в виду, что данный метод в основном используется для демонстрационных целей, а не для действий, которые обычно выполняются при моделировании реальной атаки
Использование PowerShell для вывода списка каталогов на удаленном хосте
Как видно на снимке экрана выше, создается случайно сгенерированный объект и метод OLE, затем выполняется наш пэйлоад, а объекты OLE уничтожаются. Это сделано намеренно, поскольку мы не хотим оставлять после себя никаких следов.
На следующем скриншоте, мы видим подключение учетной записи пользователя KAWALABS\mssql_svc через SQL02 к хосту под нашим контролем (172.16.10.19).
В результате получаем хеш NetNTLMv2 для учетной записи аккаунта KAWALABS\mssql_svc.
получаем хеш NetNTLMv2 для KAWALABS\mssql_svc
В следующем примере показано использование имперсонализации, для вывода списка задач, с использованием xp_cmdshell в SQL02.
SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iEnableXp
SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iXpCmd /c
Включение xp_cmdshell и выполнение системных команд с использованием имперсонализации на SQL02
Аттеншн: Всегда полезно возвращать конфигурации обратно в исходное состояние.
Атака на "линкованные" SQL-сервера
SQLRecon также может выполнять атаки на связанные экземпляры SQL Server.
Следующий снимок экрана взят из внутренней конфигурации SQL02 и демонстрирует, что SQL02 имеет ссылку на SQL03. По моему опыту, это обычная конфигурация в крупных корпоративных сетях.
SQL02 имеет SQL ссылку на SQL03.
Для настройки ссылки от одного экземпляра SQL Server к другому, часто требуется набор привилегированных учетных данных для установки и привязки ссылки. Это выгодно злоумышленникам, поскольку позволяет выполнять команды на связанном SQL-сервере в контексте учетной записи, которая установила соединение.
Еще один момент, который следует учитывать, заключается в том, что связанные серверы могут быть отделены от сети, в которой работает злоумышленник. Это может предоставить возможность пересечь границы сегментации и войти в сетевую зону с более высокими требованиями безопасности.
SQLRecon имеет модуль ссылок, позволяющий определить, есть ли на SQL Server-е какие-либо связанные экземпляры SQL.
Перечисление линкованных SQL servers на SQL02
Связанные модули всегда начинаются с буквы l, и этим модулям потребуется имя связанного сервера, которому вы хотите отдавать команды.
В следующем примере я подключаюсь к SQL02 как учетная запись KAWALABS\JSmith с низким уровнем привилегий и запускаю команду lWhoami для линкованного экземпляра SQL03.
Перечисление привилегий SQL, которые мы можем получить на SQL03 через SQL02
Как видно на снимке экрана выше, мы работаем в контексте учетной записи sa на SQL03. Это связано с тем, что учетная запись sa использовалась для установления связи SQL с SQL02 на SQL03.
Все модули выполнения в SQLRecon полностью поддерживаются на связанных SQL-серверах. В следующем примере я включаю интеграцию Common Language Runtime (CLR) в SQL02.
Включение интеграции CLR в SQL02
Интеграция CLR позволяет импортировать пользовательские сборки .NET в SQL Server. Эти сборки находятся внутри хранимой процедуры до их выполнения. Это хороший пример примитивной атаки боковым перемещением.
На следующем скрине я создаю пользовательскую сборку .NET, совместимую с SQL Server CLR, под названием Hollow.dll.
При этом пэйлоады Cobalt Strike будут размещены в хранимой процедуре, с именем ExecuteShellcode.
Полезная нагрузка выполняет базовый процесс и внедряет шелл-код Cobalt Strike в новый процесс Internet Explorer (iexplore.exe).
Hollow.dll — сборка .NET, совместимая с SQL Server CLR.
Если вы хотите узнать больше о пользовательских сборках .NET, совместимых с SQL Server CLR, посетите раздел Clr вики-страницы SQLRecon. Пример hollow.dll можно найти здесь.
В следующей демонстрации я загрузил hollow.dll на веб-сервер и переименовал сборку в favicon.png. Я даю указание линкованному серверу SQL03 загрузить favicon.png с веб-сервера и выполнить необходимые шаги для импорта пользовательской сборки в хранимую процедуру SQL Server и выполнения полезной нагрузки.
В результате получается маяк Cobalt Strike в контексте пользователя KAWALABS\mssql_svc на SQL03.
Получение маяка Cobalt Strike в контексте KAWALABS\mssql_svc на SQL03
Конечно, предыдущий пример требует, чтобы SQL03 имел доступ к Интернету для загрузки сборки с общедоступного веб-сервера. Бывают случаи, когда загрузка стороннего ресурса с общедоступного веб-сервера невозможна или нежелательна. Как таковой, SQLRecon позволяет загружать пользовательские сборки непосредственно из файловой системы скомпрометированного хоста или из общего ресурса SMB. В следующей демонстрации я загрузил hollow.dll на локальный SMB-сервер и переименовал сборку в Reports.xlsx. Я даю указание связанному серверу SQL03 загрузить Reports.xlsx с сервера SMB и выполнить необходимые действия для импорта пользовательской сборки в хранимую процедуру SQL Server для выполнения полезной нагрузки. В результате так же получается маяк Cobalt Strike в контексте пользователя KAWALABS\mssql_svc на SQL03.
Получение маяка Cobalt Strike в контексте KAWALABS\mssql_svc<code> на <code>SQL03
Атака на линкованные SQL-сервера – злоупотребление ADSI
SQLRecon также может выполнять атаки на связанные экземпляры сервера ADSI, чтобы получить учетные данные в открытом виде для учетных записей домена. Дополнительную информацию о ADSI можно найти в блоге Tarlogic.
Следующий снимок экрана взят из серверной конфигурации SQL03 и демонстрирует, что SQL03 имеет ссылку ADSI на основной контроллер домена, в домене kawalabs.local, DC01.
Эта ссылка ADSI представлена объектом linkADSI.
SQL03 имеет ссылку ADSI на DC01.
Настройка канала ADSI от экземпляра SQL Server к контроллеру домена Active Directory не обязательно требует привилегированных учетных данных. Однако в ходе реальных операций, я видел случаи, когда принцип наименьших привилегий не применялся.
В следующем примере я использую модуль lLinks для первого подключения к SQL02. ---> а затем запрашиваю у SQL03 дополнительный связанный SQL-сервер. Вы можете думать об этом как о сценарии "двойной ссылки".
Перечисление ссылок на SQL03 из SQL02
Теперь, когда мы убедились, что ссылка ADSI существует на SQL03, мы можем использовать модуль lAdsi для получения учетных данных домена в открытом виде, используемых для настройки соединения ADSI с SQL03 на DC01. Это предполагает загрузку пользовательской сборки CLR, содержащей сервер LDAP, в новую процедуру выполнения SQL Server на SQL03.
Затем сервер LDAP будет выполнять и прослушивать локальные соединения на указанном пользователем порту, в данном случае 49103. Затем мы используем задания агента SQL Server на SQL03, чтобы направить учетные данные, используемые для настройки соединения ADSI, для вызова LDAP-запроса на локальный сервер LDAP по порту 49103.
Это временное перенаправление аутентификации LDAP в конечном итоге приводит к получению учетных данных домена в открытом виде. Следует отметить, что модули Adsi и iAdsi не используют задания агента SQL Server для инициирования процесса запроса LDAP, вместо этого используются стандартные SQL-запросы.
Атака со сбором учетных данных ADSI по двойной ссылке
Модули SCCM
Одно из крупнейших расширений SQLRecon принадлежит моему коллеге Дэйву Косса (@G0ldenGunSec), он представил множество модулей, которые можно использовать для злоупотреблений Microsoft System Center Configuration Manager (SCCM) и Microsoft Endpoint Configuration Manager (ECM).
Модули SCCM были разработаны на основе реального взаимодействия, где злоупотребление базой данных SCCM SQL Server способствовало нашему продвижению к целям.
В большинстве случаев для взаимодействия с базой данных SCCM необходимо получить контекст с повышенными привилегиями или получить доступ к серверу SCCM.
В примерах ниже, у меня есть маяк Cobalt Strike, работающий в контексте учетной записи KAWALABS\mssccm_svc на ECM сервере - MECM01.
С этого момента я буду просто называть их ECM и SCCM.
В следующем примере я использую модуль баз данных для перечисления баз данных, существующих в экземпляре SQL Server на MECM01.
Перечисление баз данных на MECM01
Как видно на снимке экрана выше, существует база данных CM_KAW, которая, скорее всего, является базой данных, настроенной для SCCM на этом сервере.
Модули SCCM всегда начинаются с буквы s, и этим модулям потребуется имя базы данных SCCM, для которой вы хотите выполнять команды.
В следующем примере я подключаюсь к базе данных CM_KAW на MECM01 под учетной записью KAWALABS\mssccm_svc и ввожу команду sUsers.
Этот модуль перечисляет всех участников, настроенных для входа на сервер SCCM.
Перечисление всех пользователей, которые могут войти в SCCM через базу данных SCCM SQL Server.
Также можно перечислить задачи, настроенные в SCCM, с помощью модуля sTaskList.
Перечисление задач, настроенных в SCCM, через базу данных SCCM SQL Server.
SCCM обычно требуется хранить учетные данные, которые используются для аутентификации в системах или ресурсах в среде для развертывания пакетов программного обеспечения или выполнения любых других различных действий, предоставляемых SCCM. Используя модуль sCredentials, мы можем получить список учетных данных в хранилище.
Получение учетных данных из хранилища через базу данных SCCM SQL Server.
На снимке экрана выше, мы видим, что одна учетка сохранена, и это учетные данные аккаунта KAWALABS\mssccm_svc.
Используя логику Адама Честера (@_xpn_), можно расшифровать учетные данные из хранилища SCCM и получить пароль в виде открытого текста для учетных записей в хранилище. Для этого требуются права локального администратора на сервере SCCM.. На следующем снимке экрана я использую учетную запись sDecryptCredentials для расшифровки учетных данных, сохраненных для учетной записи KAWALABS\mssccm_svc.
Расшифровка учетных данных SCCM в хранилище
На этом, пожалуй, все, мой друг.
В оригинале статьи (ссылка в "шапке") еще есть советы по защите. Однако я не для того переводил эту простыню
. Ты можешь, по желанию, перевести это и самостоятельно. З.Ы. Обычно я не занимаюсь переводом и копирайтингом (на это совершенно нет времени), но т.к. у нас на форуме эта тема (довольно актуальная, хочу заметить) не была освещена - мне было просто необходимо исправить столь досадное упущение.
Всех благ.
