takito1812/web-hacking-playgroundApplicazione web con vulnerabilità trovate in casi reali, sia in pentest che in programmi Bug Bounty.
Web Hacking Playground è un ambiente di hacking web controllato. Consiste in vulnerabilità trovate in casi reali, sia in penetration test che in programmi Bug Bounty. L'obiettivo è che gli utenti possano esercitarsi con esse e imparare a rilevarle e sfruttarle.
Verranno affrontati anche altri argomenti di interesse, come: bypassare i filtri creando payload personalizzati, eseguire attacchi concatenati sfruttando varie vulnerabilità, sviluppare script proof-of-concept, tra gli altri.
Il codice sorgente dell'applicazione è visibile. Tuttavia, l'approccio del laboratorio è di tipo black box. Pertanto, il codice non dovrebbe essere esaminato per risolvere le sfide.
Inoltre, va notato che il fuzzing (sia di parametri che di directory) e gli attacchi di forza bruta non forniscono alcun vantaggio in questo laboratorio.
Si consiglia di utilizzare Kali Linux per eseguire questo laboratorio. In caso di utilizzo di una macchina virtuale, si consiglia di utilizzare l'hypervisor VMware Workstation Player.
L'ambiente è basato su Docker e Docker Compose, quindi è necessario averli entrambi installati.
Per installare Docker su Kali Linux, eseguire i seguenti comandi:
sudo apt update -y
sudo apt install -y docker.io
sudo systemctl enable docker --now
Per installare Docker su altre distribuzioni basate su Debian, eseguire i seguenti comandi:
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo systemctl enable docker --now
Per installare Docker Compose, eseguire il seguente comando:
sudo apt install -y docker-compose
Nota: In caso di utilizzo di M1, si consiglia di eseguire il seguente comando prima di costruire le immagini:
export DOCKER_DEFAULT_PLATFORM=linux/amd64
Il passo successivo è clonare il repository e costruire le immagini Docker:
git clone https://github.com/takito1812/web-hacking-playground.git
cd web-hacking-playground
sudo docker-compose build
Inoltre, si consiglia di installare l'estensione del browser Foxy Proxy, che consente di cambiare facilmente le impostazioni del proxy, e Burp Suite, che utilizzeremo per intercettare le richieste HTTP.
Creeremo un nuovo profilo in Foxy Proxy per utilizzare Burp Suite come proxy. Per fare ciò, andiamo nelle opzioni di Foxy Proxy e aggiungiamo un proxy con la seguente configurazione:
Una volta installato tutto il necessario, è possibile distribuire l'ambiente con il seguente comando:
git clone https://github.com/takito1812/web-hacking-playground.git
cd web-hacking-playground
sudo docker-compose up -d
Questo creerà due contenitori di applicazioni sviluppate in Flask sulla porta 80:
È necessario aggiungere l'IP dei contenitori al file /etc/hosts, in modo che possano essere raggiunti per nome e che il server di exploit possa comunicare con l'applicazione web vulnerabile. Per fare ciò, eseguire i seguenti comandi:
sudo sed -i '/whp-/d' /etc/hosts
echo "$(sudo docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' whp-socially) whp-socially" | sudo tee -a /etc/hosts
echo "$(sudo docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' whp-exploitserver) whp-exploitserver" | sudo tee -a /etc/hosts
Una volta fatto ciò, l'applicazione vulnerabile può essere raggiunta all'indirizzo http://whp-socially e il server di exploit all'indirizzo http://whp-exploitserver.
Quando si utilizza il server di exploit, è necessario utilizzare gli URL sopra indicati, utilizzando il nome di dominio e non gli IP. Questo garantisce una corretta comunicazione tra i contenitori.
Quando si tratta di hacking, per rappresentare il server dell'attaccante, è necessario utilizzare l'IP locale di Docker, poiché il laboratorio non è pensato per effettuare richieste a server esterni come Burp Collaborator, Interactsh, ecc. È possibile utilizzare un Python http.server per simulare un server web e ricevere interazioni HTTP. Per fare ciò, eseguire il seguente comando:
sudo python3 -m http.server 80
L'ambiente è suddiviso in tre fasi, ciascuna con vulnerabilità diverse. È importante eseguirle in ordine, poiché le vulnerabilità nelle fasi successive si basano su quelle delle fasi precedenti. Le fasi sono:
Di seguito sono riportati gli spoiler per le vulnerabilità di ciascuna fase. Se non hai bisogno di aiuto, puoi saltare questa sezione. D'altra parte, se non sai da dove iniziare, o vuoi verificare se sei sulla strada giusta, puoi espandere la sezione che ti interessa.
In questa fase, la sessione di un utente specifico può essere rubata tramite Cross-Site Scripting (XSS), che consente di eseguire codice JavaScript. Per fare ciò, la vittima deve essere in grado di accedere a un URL nel contesto dell'utente; questo comportamento può essere simulato con il server di exploit.
I suggerimenti per risolvere questa fase sono:
In questa fase, è possibile generare un token che consente l'accesso come admin. Questo è un tipico attacco JSON Web Token (JWT), in cui il payload del token può essere modificato per escalare i privilegi.
Il suggerimento per risolvere questa fase è che esiste un endpoint che, dato un JWT, restituisce un cookie di sessione valido.
In questa fase, il file /flag può essere letto tramite una vulnerabilità Server Site Template Injection (SSTI). Per fare ciò, è necessario far eseguire all'applicazione codice Python sul server. È possibile eseguire comandi di sistema sul server.
I suggerimenti per risolvere questa fase sono:
La funzionalità vulnerabile è protetta da autenticazione a due fattori. Pertanto, prima di sfruttare la SSTI, è necessario trovare un modo per bypassare la richiesta del codice OTP. Ci sono volte in cui l'applicazione si fida delle richieste provenienti dallo stesso server e gli header HTTP giocano un ruolo importante in questa situazione.
La SSTI è Blind, il che significa che l'output del codice eseguito sul server non viene ottenuto direttamente. Il modulo Python smtpd consente di creare un server SMTP che stampa i messaggi ricevuti sullo standard output:
sudo python3 -m smtpd -n -c DebuggingServer 0.0.0.0:25
L'applicazione utilizza Flask, quindi si può dedurre che il motore di template sia Jinja2 perché è raccomandato dalla documentazione ufficiale di Flask ed è ampiamente utilizzato. Devi ottenere un payload compatibile con Jinja2 per ottenere la flag finale.
Il messaggio email ha una limitazione di caratteri. Informazioni su come bypassare questa limitazione possono essere trovate su Internet.
Soluzioni dettagliate per ogni fase si trovano nella cartella Soluzioni.
Le seguenti risorse possono essere utili per risolvere le fasi:
I pull request sono benvenuti. Se trovi bug, per favore apri una issue.