Source Code Disclosure in ASP.NET apps

Source Code Disclosure in ASP.NET apps
Source Code Disclosure in ASP.NET apps
Penetration Testing Expert

Recently, I came across an interesting ASP.NET application. It appeared to be secure, but it accidentally revealed its source code. Later, I found out that the used method is applicable to disclose code of many other .NET web applications.
最近,我遇到了一个有趣的 ASP.NET 应用程序。它看起来很安全,但它不小心泄露了它的源代码。后来,我发现使用的方法适用于公开许多其他 .NET Web 应用程序的代码。

Here are the details. If you just see an IIS or .NET app, this is for you.
以下是详细信息。如果你只看到一个 IIS 或 .NET 应用,则这是为你准备的。

Analyzing the App 分析应用程序

During an external penetration test, I found a web application. It consisted of two pages on different ports:
在外部渗透测试中,我发现了一个 Web 应用程序。它由不同端口上的两个页面组成:

Source Code Disclosure in ASP.NET apps

Here is a Burp screenshot with relevant HTTP headers:
下面是带有相关 HTTP 标头的 Burp 屏幕截图:

Source Code Disclosure in ASP.NET apps
HTTP headers of the 88444/tcp application
88444/tcp 应用程序的 HTTP 标头

It looked like my application was written in C# on the ASP.NET platform, was functioning under IIS, and was protected by a WAF based on nginx.
看起来我的应用程序是在 ASP.NET 平台上用 C# 编写的,在 IIS 下运行,并受到基于 nginx 的 WAF 的保护。

Knowing this was enough to bypass the 403 error:
知道这一点足以绕过 403 错误:

Source Code Disclosure in ASP.NET apps
The content of the “/login.aspx” page after bypassing the WAF (via a cookieless session)
绕过 WAF(通过无 cookie 会话)后“/login.aspx”页面的内容

After the bypass, I got nothing. There weren’t even any stylesheets present. I attempted to brute force every possible username and password, every possible path and parameter. All efforts were unsuccessful.

Another boring web application? Not today!
另一个无聊的 Web 应用程序?今天不行!

Cookieless Sessions in ASP.NET
ASP.NET 中的无 Cookie 会话

When you enable the ASP.NET feature in IIS, any page of the server starts accepting cookieless sessions.
在 IIS 中启用 ASP.NET 功能时,服务器的任何页面都将开始接受无 Cookie 会话。

The ASP.NET cookieless sessions, along with PHP’s and Java’s analogs, have always been used for WAF bypass, as we did, session fixation, XSS, and all kinds of other attacks.
ASP.NET 无 cookie 会话,以及 PHP 和 Java 的类似物,一直被用于 WAF 绕过,就像我们所做的那样,会话固定、XSS 和各种其他攻击。

Here are different formats of these “cookieless sessions”:
以下是这些“无 cookie 会话”的不同格式:

.NET Version .NET 版本 URI
V1.0, V1.1 V1.0、V1.1 版 /(XXXXXXXX)/ /(XXXXXXXX)/
V2.0+ V2.0+ 版 /(S(XXXXXXXX))/ /(S(XXXXXXXX))/
V2.0+ V2.0+ 版 /(A(XXXXXXXX)F(YYYYYYYY))/
V2.0+ V2.0+ 版

Furthermore, Soroush Dalili (a.k.a. @irsdl) recently discovered something new in this area: Cookieless DuoDrop: IIS Auth Bypass & App Pool Privesc in ASP.NET Framework (CVE-2023-36899 & CVE-2023-36560).
此外,Soroush Dalili(又名 @irsdl)最近在该领域发现了一些新发现:无 Cookie DuoDrop:ASP.NET 框架中的 IIS 身份验证绕过和应用程序池权限(CVE-2023-36899 和 CVE-2023-36560)。

Namely, two security issues in .NET Framework were found and reported. Both were associated with the repetition of a cookieless pattern in the URI twice, potentially leading to a restriction bypass and privilege escalation.
也就是说,在 .NET Framework 中发现并报告了两个安全问题。两者都与 URI 中无 cookie 模式的重复两次相关联,这可能导致绕过限制和权限升级。

Here are the POCs from Soroush Dalili’s article:
以下是 Soroush Dalili 文章中的 POC:

CVE-2023-36899 CVE-2023-36899 漏洞 /WebForm/(S(X))/prot/(S(X))ected/target1.aspx

CVE-2023-36560 CVE-2023-36560 漏洞 /WebForm/pro/(S(X))tected/target1.aspx/(S(X))/


Keep in mind these POCs. At that moment, I wasn’t able to imagine any way to apply these POCs for my one-page applications.
请记住这些 POC。在那一刻,我无法想象有什么方法可以将这些 POC 应用于我的单页应用程序。

Discovering Source Code Disclosure

I was playing with my websites once every two or three days. It all came to nothing. Just two pages, no username, and no password.

However, one day, this happened:

Source Code Disclosure in ASP.NET apps

In just one second, the DLL had appeared on my computer! It wasn’t corrupt, and there was a Remote Code Execution discovered inside!

Investigation 调查

After obtaining the RCE, I was able to access the target’s web.config file. Then, I reduced it to the minimum possible configuration:
获得 RCE 后,我能够访问目标的 web.config 文件。然后,我将其减少到尽可能小的配置:

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

That was it. The runAllManagedModulesForAllRequests setting was the cause of our success.
就是这样。runAllManagedModulesForAllRequests 设置是我们成功的原因。

Scaling the POC 缩放 POC

It quickly became clear that the technique works on other servers. The setting runAllManagedModulesForAllRequests isn’t rare and I was able to download a few DLLs from different websites the same day.
很快就发现该技术适用于其他服务器。设置 runAllManagedModulesForAllRequests 并不罕见,我能够在同一天从不同的网站下载一些 DLL。

The only thing I noticed is that it’s impossible to check the existence of the “/bin” directory:

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

However, by applying IIS-ShortName-Scanner, you can not only check the existence of the “/bin” directory, but also discover its content:
但是,通过应用 IIS-ShortName-Scanner,您不仅可以检查“/bin”目录是否存在,还可以发现其内容:

Source Code Disclosure in ASP.NET apps
Executing 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/bin::$INDEX_ALLOCATION/’

Both IIS-ShortName-Scanner and the “::$INDEX_ALLOCATION” trick are attributed to Soroush Dalili.
IIS-ShortName-Scanner 和“::$INDEX_ALLOCATION”技巧都归功于 Soroush Dalili。

Full Exploitation Algorithm

Here’s a brief guide on how to check the server on the vulnerability.

1. Check if cookieless sessions are allowed.
1. 检查是否允许无 cookie 会话。

# If your application is in the main folder

# If your application is in a subfolder

2. Optionally, use IIS-ShortName-Scanner. Note, its functionality doesn’t depend on whether cookieless sessions are enabled or not.
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/'

In addition to “/bin”, I recommend you to check other special .NET folders:


3. Explore 404 page. 3. 浏览 404 页面。

For /(S(x))/b/(S(x))in/App.dll it should write something like /bin/App.dll or none in the output. If it’s .../b/(S(x))in/... on 404, this means the patches are installed.
因为它 /(S(x))/b/(S(x))in/App.dll 应该在输出中写类似 /bin/App.dll 或没有的东西。如果它 .../b/(S(x))in/... 位于 404 上,则表示已安装补丁。

4. Try to read DLLs. It’s necessary to reconstruct complete filenames from shortened 8.3 format filenames.
4. 尝试阅读 DLL。有必要从缩短的 8.3 格式文件名重建完整的文件名。


The PDB files, if such exists, will not be accessible.
PDB 文件(如果存在)将无法访问。

Attack Detection 攻击检测

A big thank you to Kirill Shipulin of our blue team for preparing the Suricata rule:
非常感谢我们蓝队的 Kirill Shipulin 准备了 Suricata 规则:

alert http any any -> any any (msg: "ATTACK [PTsecurity] Cookieless string in ASP.NET"; flow: established, to_server; http.uri; content: "/("; fast_pattern; content: "))"; distance: 0; pcre: "/\/\([A-Z]\(.*?\)\)/"; classtype: attempted-admin; sid: 10009357; rev: 1;)

Conclusion & Mitigations

For security teams 对于安全团队

Update your Microsoft IIS and .NET Framework to the latest versions. For Windows Server 2019 and .NET Framework 4.7, KB5034619 currently fixes the source disclosure.
将 Microsoft IIS 和 .NET Framework 更新到最新版本。对于 Windows Server 2019 和 .NET Framework 4.7,KB5034619 当前修复了源泄露。

For mitigating short name enumerations, run “fsutil behavior set disable8dot3 1” to disable 8.3 name creation. Next, reboot your system and run “fsutil 8dot3name strip /s /v [PATH-TO-WEB-DIRETORY]” to remove all existing 8.3 file names.
若要缓解短名称枚举,请运行“ fsutil behavior set disable8dot3 1 ”以禁用 8.3 名称创建。接下来,重新启动系统并运行“ fsutil 8dot3name strip /s /v [PATH-TO-WEB-DIRETORY] ”以删除所有现有的 8.3 文件名。

For pentesters and bughunters

I would recommend checking for obvious things and tricks, including ones that should not work.

As an example, on a different project, my friend was able to download DLL files from the “/bin” directory directly, even though I have never seen this technique succeed.

References 引用

This article was based on the following materials:

Feel free to write your thoughts about the article on our X page. Follow @ptswarm or @_mohemiv so you don’t miss our future research and other publications.
请随时在我们的 X 页面上写下您对这篇文章的看法。关注@ptswarm或@_mohemiv,这样您就不会错过我们未来的研究和其他出版物。

原文始发于Arseniy Sharoglazov Source Code Disclosure in ASP.NET apps

版权声明:admin 发表于 2024年3月8日 下午3:44。
转载请注明:Source Code Disclosure in ASP.NET apps | CTF导航