seanpesce/cve-2024-22243Example exploitable scenarios for CVE-2024-22243 affecting the Spring framework (open redirect & SSRF).
Autor: Sean Pesce
Este projeto contém um exemplo de aplicação web que demonstra cenários exploráveis para CVE-2024-22243, uma vulnerabilidade de análise de URL no Spring Framework do Java (divulgação oficial aqui).
As versões afetadas do Spring analisam o "segmento userinfo" de URLs de uma forma única, potencialmente resultando na extração de um segmento de nome de host que difere de muitas outras bibliotecas comuns.
O comportamento anormal deve-se à seguinte expressão regular ("regex") na classe
UriComponentsBuilder
(introduzida por
este commit
em 2014):
private static final String USERINFO_PATTERN = "([^@\\[/?#]*)";
Esta regex não permite o caractere "colchete esquerdo" ([) no segmento de userinfo. No entanto, o Spring
parece ser uma exceção com esse comportamento, então chamar getHost() em um objeto
UriComponents
construído usando UriComponentsBuilder.fromUriString
ou
UriComponentsBuilder.fromHttpUrl
pode resultar em comportamento inesperado. As classes
RestTemplate,
RestClient
e WebClient
também são afetadas devido ao uso interno de UriComponentsBuilder; portanto,
as implementações podem se tornar vulneráveis mesmo sem o uso direto de UriComponentsBuilder.
Para entradas especialmente criadas, o Spring retornará um valor de nome de host que difere de todos os seguintes:
java.net.URI (relatadamente apenas para versões específicas do Java; outras versões lançam uma URISyntaxException)java.net.URLcurlandroid.net.Uriokhttp3.HttpUrlurllib.parse.urlparse(Note que esta lista não é exaustiva.)
Este comportamento potencialmente torna as aplicações web baseadas em Spring vulneráveis a open redirect e server-side request forgery (SSRF) se a implementação dependente usar nomes de host confiáveis para autorização ou outros mecanismos de segurança.
A aplicação web de exemplo contém dois endpoints vulneráveis.
O primeiro endpoint, /redirect, mostra como a análise anormal de URL do Spring pode resultar em um open
redirect. Pode ser explorado usando uma URL como a seguinte:
https://127.0.0.1[@evil.com
O segundo endpoint, /health-check, demonstra como uma incompatibilidade na análise de URL entre o Spring e
a classe URL da biblioteca padrão Java pode resultar em server-side request forgery (SSRF). Pode ser
explorado usando uma URL como a seguinte:
https://evil.com[@127.0.0.1
Para construir este projeto com Maven, execute o seguinte comando (testado com OpenJDK 17):
mvn clean package
Em seguida, inicie a aplicação web com um comando como o seguinte:
java -jar seanpesce-cve-2024-22243.jar 9999
A aplicação web estará acessível em http://127.0.0.1:9999/.
Para construir a imagem Docker, execute o seguinte comando:
docker build -t seanpesce-cve-2024-22243:latest .
Em seguida, inicie a aplicação web com um comando como o seguinte:
docker run -i -e PORT=9999 -p 9999:9999 seanpesce-cve-2024-22243:latest
A aplicação web estará acessível em http://127.0.0.1:9999/ no host Docker.
Este repositório também contém regras semgrep para auxiliar na varredura de
caminhos de código potencialmente vulneráveis. spring-cve-2024-22243_loose.yaml
realiza varreduras ingênuas para qualquer uso das APIs vulneráveis; como tal, frequentemente retornará um grande
número de falsos positivos. spring-cve-2024-22243_strict.yaml
tenta usar lógica mais rigorosa e análise de taint; no entanto, isso não foi
testado minuciosamente e tem alto potencial de perder algumas implementações vulneráveis (especialmente quando não se usa
Semgrep Pro, que é necessário para análise entre arquivos).