seanpesce/cve-2024-22243Esempi di scenari sfruttabili per CVE-2024-22243 che interessa il framework Spring (open redirect & SSRF).
Autore: Sean Pesce
Questo progetto contiene un'applicazione web di esempio che dimostra scenari sfruttabili per CVE-2024-22243, una vulnerabilità di parsing degli URL nel framework Java Spring Framework (divulgazione ufficiale qui).
Le versioni affette di Spring analizzano il "segmento userinfo" degli URL in modo unico, potenzialmente risultando nell'estrazione di un segmento del nome host che differisce da molte altre librerie comuni.
Il comportamento anomalo è dovuto alla seguente espressione regolare ("regex") nella classe
UriComponentsBuilder
(introdotta da
questo commit
nel 2014):
private static final String USERINFO_PATTERN = "([^@\\[/?#]*)";
Questa regex non permette il carattere "parentesi quadra aperta" ([) nel segmento userinfo. Tuttavia,
Spring sembra essere un outlier con questo comportamento, quindi chiamare getHost() su un oggetto
UriComponents
costruito usando UriComponentsBuilder.fromUriString
o
UriComponentsBuilder.fromHttpUrl
può risultare in un comportamento imprevisto. Anche le classi
RestTemplate,
RestClient,
e WebClient
sono affette a causa del loro uso interno di UriComponentsBuilder; quindi,
le implementazioni possono essere rese vulnerabili anche senza l'uso diretto di UriComponentsBuilder.
Per input appositamente costruiti, Spring restituirà un valore del nome host che differisce da tutti i seguenti:
java.net.URI (a quanto pare solo per versioni Java specifiche; altre versioni sollevano una URISyntaxException)java.net.URLcurlandroid.net.Uriokhttp3.HttpUrlurllib.parse.urlparse(Nota che questo elenco non è esaustivo.)
Questo comportamento potenzialmente rende le applicazioni web basate su Spring vulnerabili a open redirect e server-side request forgery (SSRF) se l'implementazione dipendente utilizza nomi host attendibili per autorizzazione o altri meccanismi rilevanti per la sicurezza.
L'applicazione web di esempio contiene due endpoint vulnerabili.
Il primo endpoint, /redirect, mostra come l'analisi anomala degli URL di Spring possa risultare in un open
redirect. Può essere sfruttato usando un URL come il seguente:
https://127.0.0.1[@evil.com
Il secondo endpoint, /health-check, dimostra come una mancata corrispondenza nell'analisi degli URL tra Spring e
la classe standard Java URL possa risultare in server-side request forgery (SSRF). Può essere
sfruttato usando un URL come il seguente:
https://evil.com[@127.0.0.1
Per costruire questo progetto con Maven, esegui semplicemente il seguente comando (testato con OpenJDK 17):
mvn clean package
Quindi, avvia l'app web con un comando come il seguente:
java -jar seanpesce-cve-2024-22243.jar 9999
L'app web sarà accessibile all'indirizzo http://127.0.0.1:9999/.
Per costruire l'immagine docker, esegui il seguente comando:
docker build -t seanpesce-cve-2024-22243:latest .
Quindi, avvia l'app web con un comando come il seguente:
docker run -i -e PORT=9999 -p 9999:9999 seanpesce-cve-2024-22243:latest
L'app web sarà accessibile all'indirizzo http://127.0.0.1:9999/ sull'host Docker.
Questo repository contiene anche regole semgrep per assistere nella scansione di
potenziali percorsi di codice vulnerabili. spring-cve-2024-22243_loose.yaml
esegue scansioni ingenue per qualsiasi uso delle API vulnerabili; pertanto, restituirà spesso un gran
numero di falsi positivi. spring-cve-2024-22243_strict.yaml
tenta di utilizzare una logica più rigorosa e l'analisi del taint; tuttavia, non è stato
testato approfonditamente e ha un'alta probabilità di non rilevare alcune implementazioni vulnerabili (specialmente quando non si utilizza
Semgrep Pro, che è richiesto per l'analisi cross-file).