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