不久前，我们在为客户进行应用程序安全测试时，发现了一个NTLM凭证转发攻击，挺有意思的，这里给大家分享一下。

该应用程序乍一看非常不起眼。一个非常典型的Windows胖客户端，一个应用程序服务器和一个后端MSSQL数据库服务器。查看胖客户端目录中的一些XML配置文件，我们在一些明文的主机名和端口号旁边找到了名为“DBUsername”和“DBPassword”的一串base64编码值。解码之后，存在一些无法识别的二进制乱码，显然是经过加密的。应用程序开发人员可能认为攻击者会就此放弃，但我们偏不放弃，谁让我们固执呢。我们认为如果客户端软件能够解密这些凭据，那我们有了客户端的副本，我们肯定也能进行解密。

刚开始，我们进行了枯燥的逆向工作，但很快就发现相关的二进制文件都是.NET管理，这意味着我们能够简单的将它们反编译成非常清晰的源代码。在源代码中搜索“crypt”字串，很快就定位到了负责加密和解密存储数据库凭证的函数，以及硬编码密钥和IV，这两者都是基于软件供应商的名字。

使用Python捣鼓了一段时间后，我们重新实现了应用程序中的解密函数，值得自豪的是，我们获取了一些数据库凭证，使用它登录到MS SQL Server实例后，我们发现即使这个数据库与应用程序主数据库使用的服务器相同，我们的凭据也只能访问服务器上非常有限的数据库，而且没什么有用的东西。客户端使用更传统的方法获取最敏感的数据，即通过带有数据库后端连接的应用层服务器。

'xp_cmdshell'这个组件是攻击者最喜欢用的，不过这里，我们的用户无法使用。如果我们想找到一种方法来拿下数据库服务器，我们需要有一些骚思路。

接下来，我们尝试了另一个经典的技巧，就是使用'xp_dirtree'这个扩展存储过程。xp_dirtree这个存储过程实际上是让SQL服务实例对提供的文件路径进行目录遍历。通过UNC路径，将服务器指重定向到攻击者控制的主机上，我们通常可以使用Responder或ntlmrelayx等工具来捕获SQL Server服务帐户密码的NetNTLMv2哈希值，或者转发服务帐户的凭据并使用它们通过SMB对辅助主机进行身份验证。虽然我们能够获取哈希值，但密码设置的非常复杂，我们在有效时间内很难破解。此外，我们无法通过SMB将凭证转发到任何范围内的主机，因为都已经配置了SMB签名，设置为 “REQUIRED”，这就非常头疼了，使得我们的转发凭证毫无价值。

挫败ing……

不过，先稍等一下！好像可以转发NTLM身份验证来对其他协议进行身份验证，包括HTTP和MSSQL！也许不允许将NTLM身份验证返回到源主机的这种常规的规则不适用于这样的跨协议场景？no no no，其实他们仍然适用。

再次挫败！！！

到了这一步，我们变得有点沮丧并且回到了刚开始的基础知识部分，深入挖掘我们之前收集到的侦察数据，包括使用PowerShell模块PowerUpSQL收集到的信息。PowerUpSQL将枚举一个数据库服务器与另一个数据库服务器之间的链接。当你有主运行的数据库服务器和充当“数据仓库”的辅助服务器的情况下，这些链接尤为常见，其中数据定期从一个数据库进行整理并归档到另一个服务器中，我们案例中的情况正是它所定义的场景。

通过第一个数据库将查询发送到数据仓库并没有立即产生任何特别有用的结果。我们在数据仓库中权限也非常低，这刚开始看起来似乎是一条死胡同，不过，我们突然意识到我们已经拥有了拿下服务器所需要的一切信息。

首先，我们设置ntlmrelayx以捕获针对我们攻击者控制的主机的SMB身份验证尝试，并将它们转发到与之前相同的MSSQL服务器端口上，只不过这次不是在第一台服务器上运行xp_dirtree，而是使用数据库链接将相同的xp_dirtree查询发送到第二个服务器执行。它会尝试连接我们的主机，协商NTLM身份验证，然后将身份验证尝试转发回第一台服务器的MS SQL Server端口上，这就完成了一个完整的流程，如图：

我们回到刚开始的地方，但现在我们通过了身份验证，成为了SQL Server服务帐户，该帐户在两个SQL服务器上都具有本地管理员权限，因此它们也被授予了全部的“sa”权限。有了管理员访问权限，我们就能够启用“xp_cmdshell”扩展存储过程，并使用它以管理员用户在操作系统中执行shell命令。我们这里不会详细介绍，但在这次突破之后，只需要几分钟的时间，我们就能够完全控制整个AD / Windows环境。

那么，这一切的主要经验教训是什么？

· 不要将凭据和加密密钥硬编码到应用程序配置文件或二进制文件中。如果你的安全是基于此来设计的，那么你的设计是错误的。

· 不要让用户直接登录到数据库服务器 –让他们通过应用层服务器进行访问。

· 禁用不需要的SQL Server扩展过程，包括xp_cmdshell，xp_dirtree和xp_filexist。

· 出站防火墙规则与入站规则一样重要。如果你的后端服务器不需要与客户端进行SMB通信，那就禁止SMB通信！

· 虽然SMB签名是一种极其有效的安全控制，但遇到坚持不懈的对手，任何单一的安全控制都不会完全有效。