juanschallibaum/cve-2024-38473-nuclei-templateModelo Nuclei para detectar servidores Apache vulneráveis ao CVE-2024-38473
Template Nuclei projetado para detectar servidores Apache vulneráveis ao CVE-2024-38473. Primeiro, ele identifica servidores executando Apache < 2.4.60 com configurações padrão do PHP-FPM. Em seguida, ele realiza fuzzing em busca de possíveis arquivos PHP protegidos por ACLs que podem ser contornados devido a essa vulnerabilidade.
Para usar este template Nuclei, você precisa clonar o repositório. Você pode fazer isso executando o seguinte comando:
git clone https://github.com/juanschallibaum/CVE-2024-38473-Nuclei-Template
Navegue até o diretório do repositório clonado:
cd CVE-2024-38473-Nuclei-Template
Executar o template Nuclei em um único host:
nuclei -t CVE-2024-38473.yaml -u http://example.com
Executar o template Nuclei contra uma lista de hosts:
nuclei -t CVE-2024-38473.yaml -l hosts.txt
Executar o template Nuclei em um único host especificando um arquivo .html ou .php válido:
nuclei -t CVE-2024-38473.yaml -u http://example.com/valid.php
Executar o Nuclei dessa maneira pode resultar em uma taxa de detecção mais alta. Você também pode incluir URLs neste formato no arquivo de hosts para executar o template contra essa lista.
Para testar facilmente a vulnerabilidade CVE-2024-38473, você pode configurar um ambiente vulnerável usando Docker. Siga estas etapas para verificar rapidamente a eficácia do template Nuclei:
Certifique-se de que o Docker Daemon está em execução: Verifique se o daemon do Docker está em execução no seu sistema. Você pode iniciá-lo com o seguinte comando se não estiver em execução:
sudo systemctl start docker
Execute o Container Docker: Dentro do diretório do repositório, use o seguinte comando Docker para iniciar um contêiner com uma configuração vulnerável do Apache e PHP-FPM:
docker run -p 8787:80 -v "$(pwd)/test-env-webroot:/app" webdevops/php-apache:7.1
Teste a Vulnerabilidade:
Manualmente: Abra seu navegador web e navegue até http://localhost:8787 para interagir com o servidor Apache em execução no contêiner Docker. Acesse http://localhost:8787/info.php para testar a vulnerabilidade. Este arquivo está protegido por uma ACL e, se o bypass da ACL for bem-sucedido, você verá a saída de phpinfo():
Usando o Template Nuclei: Execute o seguinte comando Nuclei para testar o servidor com o template:
nuclei -t CVE-2024-38473.yaml -u http://localhost:8787
Em 8 de agosto de 2024, o pesquisador de segurança Orange Tsai fez uma apresentação na Black Hat USA 2024 intitulada: Confusion Attacks: Exploiting Hidden Semantic Ambiguity in Apache HTTP Server!. Nesta apresentação, ele relatou múltiplas vulnerabilidades que afetam o Apache HTTP Server. Ele explicou que o Apache possui uma arquitetura altamente modular, composta por centenas de módulos, cada um realizando sua função enquanto lê e escreve em uma estrutura compartilhada chamada request_rec, que consiste em quase 100 campos.
A causa raiz das vulnerabilidades relatadas pelo pesquisador de segurança reside na inconsistência de como diferentes módulos do Apache tratam os vários campos da estrutura compartilhada. Por exemplo, mod_authz_core trata o campo r->filename como um arquivo, enquanto mod_proxy o trata como uma URL, levando a discrepâncias que resultam em uma ampla gama de vulnerabilidades.
Em sua apresentação, Orange Tsai define um tipo de ataque chamado "Filename Confusion". Embora esse ataque tenha uma superfície de ataque variada, o CVE-2024-38473, que abordamos neste template, refere-se a como podemos aplicar o ataque "Filename Confusion" para contornar ACLs do Apache e obter acesso a arquivos restritos.
O problema surge quando o módulo de autenticação do Apache, mod_authz_core, trata o atributo r->filename como um arquivo, enquanto mod_proxy o trata como uma URL. Devido a isso, instalações do Apache com PHP-FPM em sua configuração padrão são afetadas por essa vulnerabilidade. Imagine que um servidor executando Apache e PHP-FPM tenha uma ACL configurada como a seguir para proteger o acesso ao arquivo admin.php com credenciais:
<Files "admin.php">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user
</Files>
Devido à vulnerabilidade, é possível contornar ACLs como a acima que envolvem proteger um arquivo individual. Na verdade, isso pode ser feito tão facilmente quanto enviar a seguinte requisição: http://server/admin.php%3fooo.php.
Para entender isso em profundidade, é importante considerar que, quando o Apache processa uma requisição como a acima, o módulo mod_authz_core lê o valor admin.php?fooo.php do campo r->filename da estrutura compartilhada. Ele trata esse valor como o nome do arquivo solicitado e, ao compará-lo com a ACL, não há correspondência porque admin.php?fooo.php é diferente de admin.php.
Então, como admin.php?fooo.php termina em .php, a requisição é tratada pelo PHP-FPM. O PHP-FPM remove tudo após o ? no nome do arquivo recebido do Apache antes de processá-lo, tratando-o como uma URL em vez de um arquivo. Como resultado, o PHP-FPM processará admin.php diretamente. Como a verificação da ACL foi realizada anteriormente, o atacante pode acessar admin.php sem autenticação.
O template Nuclei atual não apenas visa descobrir arquivos protegidos por força bruta, mas também inclui lógica para identificar quando um servidor possui uma configuração vulnerável do Apache < 2.4.60 com PHP-FPM, mesmo que casos de arquivos protegidos por ACLs não sejam detectados. No fluxo básico, ele primeiro tenta identificar se o servidor possui uma configuração vulnerável e, em caso positivo, tenta identificar arquivos comuns que podem estar protegidos por ACLs.
A ideia por trás da detecção de configurações vulneráveis com Apache < 2.4.60 e PHP-FPM é baseada em duas premissas básicas:
Em uma configuração vulnerável, se file.php existir no servidor, então a requisição para http://server/file.php%3fooo.php retornaria o mesmo código de status 200 e o mesmo comprimento de corpo que a requisição para http://server/file.php (porque após o PHP-FPM remover %3fooo.php, o arquivo solicitado seria o mesmo).
Em uma configuração vulnerável, se file.html existir no servidor, então a requisição para http://server/file.html%3fooo.php retornaria 403 Access Denied. Isso ocorre porque o PHP-FPM tentaria carregar um arquivo com extensão .html em vez de .php, o que por padrão não é permitido.
O fluxo do template consiste em 7 grupos de requisições. Elas precisam ser executadas em ordem e devem atender às respectivas condições de correspondência para prosseguir para o próximo grupo de requisições. Isso ajuda a minimizar o número de requisições enviadas em vão quando as condições já são conhecidas por não serem atendidas.
O template envia uma requisição para index.phpooo.php%3fooo.php, que é um arquivo inexistente. A ideia é filtrar falsos positivos em casos onde index.php%3fooo.php retorna um código de status 200 e o mesmo corpo que index.php, mesmo quando o PHP-FPM não está configurado. Isso pode ocorrer, por exemplo, quando existem regras que reescrevem qualquer arquivo solicitado ou arquivos que começam com "index" para index.php, como:
RewriteRule . /index.php [L]
RewriteRule ^index\.php(.*)$ index.php [L]
RewriteRule ^index(.*)$ index.php [L]
Esta requisição deve retornar um código de status 200 se o servidor tiver regras como as mencionadas acima, ou um código de status 404 em casos normais onde o PHP-FPM pode estar configurado. Se esta requisição não retornar um código de status 404, o template interromperá o processamento neste host.
O template envia uma requisição para foo.phpooo.php%3fooo.php, que é um arquivo inexistente. A ideia é filtrar falsos positivos em casos onde index.html%3fooo.php retorna um código de status 403, mesmo quando o PHP-FPM não está configurado. Isso pode ocorrer, por exemplo, quando existem regras que proíbem o caractere %3f em qualquer lugar da URL ou que restringem o acesso a arquivos que terminam com .php. Exemplos de tais regras incluem:
<FilesMatch "\.php$">
Require all denied
</FilesMatch>
RewriteCond %{REQUEST_URI} (%3f)
RewriteRule ^(.*)$ - [F]
Esta requisição deve retornar um código de status 403 se o servidor tiver regras como as mencionadas acima, ou um código de status 404 em casos normais onde o PHP-FPM pode estar configurado. Se esta requisição não retornar um código de status 404, o template interromperá o processamento neste host.
O template envia requisições para identificar alguns arquivos disponíveis no servidor. Primeiro, ele tenta identificar se index.php está disponível. Em seguida, verifica index.html e index.htm. Finalmente, testa o arquivo presente na URL fornecida pelo usuário, se existir. Se o Nuclei for executado especificando um arquivo válido na URL, isso pode aumentar a eficácia da detecção em casos onde arquivos de índice clássicos não existem.
O template envia uma requisição para um arquivo inexistente para filtrar os últimos falsos positivos em casos onde index.php%3fooo.php retorna um código de status 200 e o mesmo corpo que index.php, mesmo quando o PHP-FPM não está configurado. Alguns servidores web, especialmente aqueles que não são Apache, ignoram tudo após o %3f. Portanto, se enviarmos index.php%3fooo.php, o servidor o trata como index.php. Para filtrar esses casos, o template envia uma requisição para index.php%3fooo.html (se index.php foi encontrado no servidor) ou index.html%3fooo.html (se index.html foi encontrado no servidor). Como termina em .html, em casos normais onde o PHP-FPM pode estar configurado, não seria processado pelo PHP-FPM e seria tratado como um arquivo estático que logicamente não existe, resultando em um código de status 404. No entanto, retornaria um código de status 200 nos casos que queremos filtrar, onde tudo após o %3f é ignorado. Se esta requisição não retornar um código de status 404, o template interromperá o processamento neste host.
O template envia uma requisição para identificar a configuração vulnerável. Existem 2 casos, dos quais pelo menos uma das condições de correspondência deve ser satisfeita:
Caso 1: Em Requisição #3, index.php foi encontrado. Neste caso, se Apache < 2.4.60 e PHP-FPM estiver habilitado com a configuração padrão, ele deve remover a parte %3fooo.php e carregar index.php, resultando em uma resposta 200 com o mesmo comprimento obtido na Requisição #3. Se mod_php ou outro manipulador for usado, ele trataria index.php%3fooo.php como o nome completo do arquivo e retornaria 404. Para que este caso corresponda, a requisição deve retornar 200 e um corpo com o mesmo comprimento da resposta da Requisição #3.
Caso 2: Em Requisição #3, index.html foi encontrado. Neste caso, se Apache < 2.4.60 e PHP-FPM estiver habilitado com a configuração padrão, ele deve remover a parte %3fooo.php e tentar carregar index.html, o que retornaria 403 Access Denied, pois o PHP-FPM estaria tentando carregar um arquivo com uma extensão não permitida. Se mod_php ou outro manipulador for usado, ele trataria index.php%3fooo.php como o nome completo do arquivo e retornaria 404. Para que este caso corresponda, a requisição deve retornar 404.
Se o template chegou a este ponto, indica que o servidor possui uma configuração vulnerável. Consequentemente, o template envia requisições para fazer fuzzing em busca de possíveis arquivos protegidos que retornam um código de status 403 ou que exigem autenticação e retornam um código de status 401. Por padrão, ele tenta identificar apenas alguns dos nomes de arquivo mais comuns e potencialmente protegidos. No entanto, você pode descomentar uma linha para usar uma wordlist personalizada com 350 possíveis nomes de arquivos PHP.
O template envia uma requisição para validar que o arquivo protegido identificado na Requisição #6 retorna um código de status 200 com o bypass.
Se alguma condição de correspondência da Requisição #5 for atendida, indica que o servidor está executando Apache < 2.4.60 com configurações padrão do PHP-FPM. Isso significa que, se houver uma ACL protegendo um arquivo individual, ela pode ser contornada. No entanto, muitas vezes essas configurações vulneráveis podem ser detectadas sem identificar nenhum arquivo protegido. Por padrão, o template usa a wordlist wordlists/potential_protected_php_files_10.txt para fazer fuzzing em busca de arquivos protegidos. Esta lista inclui os 10 nomes de arquivos PHP com maior probabilidade de serem protegidos por ACLs. Alternativamente, uma wordlist maior com 350 entradas está disponível: wordlists/potential_protected_php_files_350.txt. Para mudar para a lista maior, comente a wordlist de 10 entradas e descomente a lista de 350 entradas na seção YAML da Requisição #6 no template, da seguinte forma:
#fuzz: wordlists/potential_protected_php_files_10.txt
fuzz: wordlists/potential_protected_php_files_350.txt
O uso da wordlist maior pode aumentar as chances de encontrar arquivos PHP protegidos. No entanto, a wordlist potential_protected_php_files_350.txt pode conter nomes de arquivos PHP incomuns e pode faltar nomes de arquivos PHP mais comuns que poderiam ser protegidos por ACLs. Portanto, quaisquer melhorias ou acréscimos à wordlist são bem-vindos. Além disso, wordlists personalizadas ainda maiores podem ser empregadas para exploração adicional.
Observe que ACLs contornáveis podem estar configuradas para diferentes hosts virtuais, em arquivos .htaccess em qualquer diretório da aplicação, não apenas no diretório raiz. Portanto, para maximizar a chance de identificar arquivos protegidos por ACL, recomenda-se realizar um reconhecimento completo de diretórios e subdomínios, e executar o template contra todas as URLs identificadas com diferentes subdomínios e diretórios.
Atualmente, o fluxo da Requisição #6 para após identificar o primeiro arquivo protegido por ACL. No entanto, pode haver mais. Isso acontece porque não encontrei uma maneira de fazer fuzzing de vários arquivos com Nuclei, armazenar os resultados e depois usá-los em uma requisição de acompanhamento para verificar se o bypass realmente concede acesso aos arquivos protegidos. Portanto, quaisquer sugestões sobre como o template pode ser modificado para identificar vários arquivos protegidos e validar que eles são de fato contornáveis também são bem-vindas.
Todos os créditos por relatar as vulnerabilidades e conduzir a notável pesquisa vão para Orange Tsai. Seu extenso trabalho sobre vulnerabilidades do Apache HTTP Server, incluindo CVE-2024-38473, contribuiu significativamente para aumentar a conscientização sobre segurança. Eu, Juan Schallibaum, sou responsável unicamente pela criação deste template Nuclei para facilitar o teste e a detecção do CVE-2024-38473.
O uso deste template Nuclei para atacar alvos sem consentimento mútuo prévio é ilegal. É de responsabilidade do usuário final cumprir todas as leis locais, estaduais e federais aplicáveis. Os desenvolvedores não assumem nenhuma responsabilidade por qualquer uso indevido, dano ou consequência legal resultante do uso deste template. Sempre certifique-se de ter permissão explícita antes de realizar qualquer teste de segurança.