Quando si esegue un PenTest su un sito protetto da WAF, cosa dovrebbe sapere un Pentestore per migliorare la qualità del test?

Il tuo approccio dovrebbe essere duplice:

tecniche:
Verifica:

• Varie sequenze di escape (ad es. \ x00,% s, \\, ecc.)
• Trucchi Unicode (ad esempio caratteri multi-byte che terminano con 0x22 per produrre un ")
• Metodi XSS alternativi (ad esempio <img src=0 onerror=alert(1) /> anziché <script>alert(1)</script> )
• Vari tipi di nasties (ad esempio XSS, SQL injection) all'interno di cookie e intestazioni HTTP - spesso i WAF mancano questi!

Advisory:
Assicurati che il cliente capisca che un WAF è solo un cerotto e non può riparare un arto rotto. Se l'applicazione viene interrotta in modo sfruttabile, un WAF può impedire l'attacco o mitigare parte dell'impatto, ma non c'è modo di essere sicuro che sia efficace.

È anche un'arma a doppio taglio, nel senso che le persone spesso presumono che un bug che un WAF rende non utilizzabile sia sempre non sia utilizzabile, e quindi non ha bisogno di essere corretto (almeno con ogni fretta). I browser e i linguaggi HTML / CSS / JavaScript / SQL / XML / lato server, ecc. Si evolvono costantemente, quindi potrebbero venire a crearsi nuove tecniche di exploit che rendono sfruttabili vecchi bug.

Un ulteriore punto che vorrei fare: se il test è indirizzato all'app Web e non specificatamente rivolto alla soluzione WAF che hanno implementato, ti consiglio vivamente di chiedere client per disabilitare il WAF sul loro sito di staging per tutta la durata del test. Lasciandolo acceso è molto più difficile per te dare loro una stima ragionevole della postura di sicurezza dell'applicazione, e questo significa che ottengono meno valore dal test. Se sono veramente interessati a testare il WAF, potrebbero eseguire un ulteriore giorno di test in seguito che confronta la sfruttabilità dei problemi riscontrati con e senza che WAF sia abilitato.

Esistono tre approcci per attaccare un'applicazione web dietro un Web Application Firewall (WAF). Se guardi exploit di bypass WAF esistenti puoi vedere che si suddividono in due categorie principali. È possibile ignorare un insieme di regole perché è eccessivamente restrittivo o non corrisponde esattamente ad un attacco reale, o attacca il pre-processore che bypasserà ogni set di regole. Esiste una terza categoria di bypass WAF, che non richiede un exploit di bypass WAF.

1. Gli attacchi al pre-processore WAF mirano a cercare di oscurare o rimuovere un carico utile di attacco da una richiesta prima di essere elaborato da un WAF serie di regole. Ecco due exploit che sono pre-processore WAF attacchi:

   PHPIDS ha avuto un pre-processore "Rimuovi duplicati" non sicuro può essere usato per oscurare qualsiasi carico utile che viene duplicato 33 volte. (Disclaimer: Questo è il mio exploit)

   IBM WebSphere aveva un pre-processore "Rimuovi Commenti" non sicuro può essere usato per oscurare qualsiasi carico utile.

2. Gli attacchi del set di regole WAF stanno sfruttando un set di regole debole che consente a attaccante per inviare una stringa di attacco valida. In questo caso le regole sono eccessivamente semplicistici, un attacco può essere modificato per evitare il rilevamento. Ci sono due direzioni per attaccare un'applicazione web dietro un web firewall dell'applicazione.

   Una direzione è tentare di sfruttare una vulnerabilità comune, ad esempio come XSS o SQLi. Determina quale regola hai violato e prova e modificare il carico utile di attacco per ignorare questa regola. Le regole possono essere verificato usando Regex Debugger , RegEx Buddy è il mio preferito strumento per questo processo. Dopo sei in grado di sfruttare SQLi, quindi cerca le vulnerabilità SQLi nell'applicazione. Per esempio, se avessi una stringa modificata che eseguirà sleep(30) su a Database MySQL senza essere rilevato dal WAF, che è possibile utilizzare questa stringa a fuzz per SQLi cieco nell'applicazione. Ecco un esempio di un carico utile di SQL Injection modificato per bypassare mod_security . Questo è un approccio blackbox in cui non si ha accesso all'applicazione Web, ma l'autore dell'attacco deve sempre accedere al WAF.

   L'altra direzione è l'opposto, sfruttare l'applicazione Web con una vulnerabilità come SQLi senza WAF e quindi provare a creare una stringa di attacco per sfruttare questa vulnerabilità senza essere rilevata dal WAF. Questo è un approccio in grigio.

3. Il terzo metodo per attaccare un'applicazione web dietro un WAF è di evitare completamente il problema. È impossibile rilevare un WAF ogni attacco . Ci sono vulnerabilità comuni nel web applicazioni che i WAF non possono impedire. CSRF, Assegnazione di massa , Riferimento di oggetti diretti non sicuri, click-jacking, oracoli crittografici, errori logici di autenticazione / autorizzazione ... usa la tua immaginazione .