Proxy / WAF Protections Bypass
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Tecniche da questa ricerca.
Esempio di regola Nginx:
In order to prevent bypasses Nginx performs path normalization before checking it. However, if the backend server performs a different normalization (removing characters that nginx doesn't remove) it might be possible to bypass this defense.
Nginx Version
Node.js Bypass Characters
1.22.0
\xA0
1.21.6
\xA0
1.20.2
\xA0
, \x09
, \x0C
1.18.0
\xA0
, \x09
, \x0C
1.16.1
\xA0
, \x09
, \x0C
Nginx Version
Flask Bypass Characters
1.22.0
\x85
, \xA0
1.21.6
\x85
, \xA0
1.20.2
\x85
, \xA0
, \x1F
, \x1E
, \x1D
, \x1C
, \x0C
, \x0B
1.18.0
\x85
, \xA0
, \x1F
, \x1E
, \x1D
, \x1C
, \x0C
, \x0B
1.16.1
\x85
, \xA0
, \x1F
, \x1E
, \x1D
, \x1C
, \x0C
, \x0B
Nginx Version
Spring Boot Bypass Characters
1.22.0
;
1.21.6
;
1.20.2
\x09
, ;
1.18.0
\x09
, ;
1.16.1
\x09
, ;
Nginx FPM configuration:
Nginx è configurato per bloccare l'accesso a /admin.php
, ma è possibile aggirare questo bloccando accedendo a /admin.php/index.php
.
In questo post si spiega che ModSecurity v3 (fino alla 3.0.12), ha implementato in modo errato la variabile REQUEST_FILENAME
che doveva contenere il percorso accessibile (fino all'inizio dei parametri). Questo perché eseguiva un URL decode per ottenere il percorso.
Pertanto, una richiesta come http://example.com/foo%3f';alert(1);foo=
in mod security supporrà che il percorso sia solo /foo
perché %3f
viene trasformato in ?
che termina il percorso URL, ma in realtà il percorso che un server riceverà sarà /foo%3f';alert(1);foo=
.
Le variabili REQUEST_BASENAME
e PATH_INFO
sono state anch'esse influenzate da questo bug.
Qualcosa di simile è accaduto nella versione 2 di Mod Security che ha permesso di bypassare una protezione che impediva agli utenti di accedere a file con estensioni specifiche relative a file di backup (come .bak
) semplicemente inviando il punto codificato in URL come %2e
, per esempio: https://example.com/backup%2ebak
.
Questa ricerca menziona che era possibile bypassare le regole AWS WAF applicate sugli header HTTP inviando un header "malformato" che non veniva correttamente analizzato da AWS ma dal server backend.
Ad esempio, inviando la seguente richiesta con un'iniezione SQL nell'header X-Query:
È stato possibile bypassare AWS WAF perché non comprendeva che la riga successiva fa parte del valore dell'intestazione mentre il server NODEJS lo faceva (questo è stato risolto).
Comunemente i WAF hanno un certo limite di lunghezza delle richieste da controllare e se una richiesta POST/PUT/PATCH supera tale limite, il WAF non controllerà la richiesta.
Per AWS WAF, puoi controllare la documentazione:
Dimensione massima di un corpo di richiesta web che può essere ispezionata per le protezioni di Application Load Balancer e AWS AppSync
8 KB
Dimensione massima di un corpo di richiesta web che può essere ispezionata per le protezioni di CloudFront, API Gateway, Amazon Cognito, App Runner e Verified Access**
64 KB
Da documenti Azure:
I firewall per applicazioni web più vecchi con Core Rule Set 3.1 (o inferiore) consentono messaggi più grandi di 128 KB disattivando l'ispezione del corpo della richiesta, ma questi messaggi non verranno controllati per vulnerabilità. Per le versioni più recenti (Core Rule Set 3.2 o più recenti), lo stesso può essere fatto disabilitando il limite massimo del corpo della richiesta. Quando una richiesta supera il limite di dimensione:
Se modalità di prevenzione: Registra e blocca la richiesta.
Se modalità di rilevamento: Ispeziona fino al limite, ignora il resto e registra se il Content-Length
supera il limite.
Da Akamai:
Per impostazione predefinita, il WAF ispeziona solo i primi 8KB di una richiesta. Può aumentare il limite fino a 128KB aggiungendo Metadati Avanzati.
Da Cloudflare:
Fino a 128KB.
A seconda dell'implementazione della normalizzazione Unicode (maggiori informazioni qui), i caratteri che condividono la compatibilità Unicode potrebbero essere in grado di bypassare il WAF ed eseguire il payload previsto. I caratteri compatibili possono essere trovati qui.
https://github.com/ustayready/fireprox: Genera un URL di gateway API da utilizzare con ffuf
https://github.com/rootcathacking/catspin: Simile a fireprox
https://github.com/PortSwigger/ip-rotate: Plugin di Burp Suite che utilizza gli IP del gateway API
https://github.com/fyoorer/ShadowClone: Un numero dinamicamente determinato di istanze di container viene attivato in base alla dimensione del file di input e al fattore di suddivisione, con l'input suddiviso in parti per l'esecuzione parallela, come 100 istanze che elaborano 100 parti da un file di input di 10.000 righe con un fattore di suddivisione di 100 righe.
Tecniche diverse possono essere utilizzate per bypassare i filtri regex sui firewall. Esempi includono l'alternanza di maiuscole e minuscole, l'aggiunta di interruzioni di riga e la codifica dei payload. Risorse per i vari bypass possono essere trovate su PayloadsAllTheThings e OWASP. Gli esempi qui sotto sono stati estratti da questo articolo.
nowafpls: plugin di Burp per aggiungere dati spazzatura alle richieste per bypassare i WAF in base alla lunghezza
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)