Come Valutare WAF e WAAP

I cloud provider che offrono servizi di web application firewall stanno crescendo sempre più e con loro i tentativi di aziende e ricercatori di comparare servizi e progetti messi a disposizione dai vari vendor che li riuniscono in un'unica proposition definita da Gartner "WAAP". Vediamo di cosa si tratta e come valutare al meglio uno di questi servizi.

Una doverosa premessa: Per chi non lo sapesse, mi occupo di servizi di web application firewall, web application hardening, DoS mitigation e virtual patching da molti anni. Faccio parte del team di sviluppo del progetto OWASP Core Rule Set che è il principale set di regole utilizzato da moltissimi WAF vendor come: Akamai, CloudFlare, Microsoft Azure, Google Cloud Platform, Oracle, Positive Technologies, Fastly, e molti (molti) altri, <rant>senza contare i vendor che non ammettono di usarlo</rant>. Per queste ragioni, mi sento abbastanza confidente nell'esprimere un giudizio su comparazioni di servizi WAF e di commentarne l'evoluzione che hanno avuto negli ultimi 20 anni.

Soprattutto negli ultimi mesi, sono state pubblicate diverse comparazioni tra WAF opensource e servizi WAF in cloud, alcune realmente imparziali e fatte con cognizione di causa, altre no...

Don't call me Firewall

Per parlare dei nuovi servizi di web application firewall in cloud e della loro evoluzione, non possiamo prescindere dal parlare della loro genesi. Sin dalla fine degli anni 90 e inizio 2000 le soluzioni WAF esistenti erano utilizzabili sia come modulo di un server web che ospitava il sito protetto, oppure all'interno di un reverse proxy che prima analizza le request HTTP e poi le inoltra all'upstream. Queste due diverse implementazioni sono presenti anche oggi anche se la nascita di servizi WAF in cloud ha pesantemente spostato l'ago della bilancia verso la soluzione reverse proxy.

Parlando di siti e applicazioni web "internet facing" ovvero pubblicamente raggiungibili, sin da subito ci si è resi conto che la parola "Firewall" non era affatto calzante, anzi in molti casi destabilizzava e mandava in confusione gli utilizzatori. Ma ancora di più il fatto che con il tempo si sia radicata la convinzione che un WAF sia un IPS specifico per il protocollo HTTP, cosa assolutamente falsa già 20 anni fa. Infatti uno dei padri di questa tecnologia Ivan Ristić, ideatore di ModSecurity (forse il WAF opensource più utilizzato al mondo), nel suo Protocol-Level Evasion of Web Application Firewalls nel 2o12 scriveva:

I have a feeling that WAFs could be much more useful if more organizations stopped treating them as specialized IPS tools for HTTP. There are many other use cases with tremendous potential, such as application security monitoring (ASM), attack surface reduction, application hardening, policy enforcement, and others.

Infatti i Cloud Provider hanno iniziato ad aggiungere servizi WAF ai preesistenti servizi CDN, Cache, Load Balancer e DoS protection. Oggi possiamo dire che quasi tutti i grandi vendor propongono WAF come accessorio di una soluzione più ampia che comprende appunto Bad Bot Mitigation, API Security oltre ai già citati Caching, CDN e DoS Protection. Questo per due motivi principali: il primo è che WAF e soluzioni DoS protection e Bad Bot detection sono molto vicine a livello di market e spesso competono per lo stesso budget nelle aziende. Il secondo motivo è che i clienti spesso preferiscono una gestione unificata e report aggregati che spesso vanno anche a vantaggio del prezzo. Gartner definisce questo ensemble come "Web Application and API Protection" (WAAP):

Gartner defines WAAP services as the evolution of cloud WAF services. WAAP services combine cloud-delivered, as-a-service deployment of WAF, bot mitigation, DDoS protection and API security, with a subscription model.

Oltre a questo Gartner prevede che nel 2023 più del 30% delle web application e API saranno protette da servizi cloud WAAP. Nel 2024, sempre Gartner, stima che molte aziende che utilizzano diversi servizi e strategie di protezione, convoglieranno in un unico servizio in cloud WAAP.

By 2023, more than 30% of public-facing web applications and APIs will be protected by cloud web application and API protection (WAAP) services, which combine distributed denial of service (DDoS) protection, bot mitigation, API protection and web application firewalls (WAFs). This is an increase from fewer than 15% today. By 2024, most organizations implementing multicloud strategies for web applications in production will use only cloud WAAP services.

Valutare Cloud WAAP

Abbiamo visto come ormai, almeno per i servizi in cloud, dobbiamo pensare al WAF come uno degli elementi che compongono un servizio WAAP in cloud. Per questo motivo non possiamo valutare un WAAP senza valutare con attenzione anche il WAF (cosa di cui parleremo nel dettaglio tra poco). Prenderò in considerazione DoS Protection, Bad Bot Detection e WAF.

DoS Protection

Uno dei primi aspetti da valutare su un servizio WAAP è la protezione da attacchi volumetrici layer 7, cioè ciò che normalmente definiamo "attacchi DoS" (anche se personalmente, se devo parlare a una platea di tecnici, non amo definirli attacchi DoS dato che il Denial of Service è una conseguenza spesso di un attacco volumetrico o meno frequentemente di un exploit di una vulnerabilità - vedi CVE-2019-19886 - o abuse of functionality - vedi ReDoS e simili). Molti, o forse tutti, vendor affrontano la tematica nello stesso modo, cioè attivare una challenge JavaScript al superamento di una certa soglia di traffico. Mi spiego meglio.

La maggior parte degli "attacchi DoS" che riceve un sito o una applicazione web (parlando specificatamente sempre di layer 7) vengono effettuati attraverso "DoS for hire" o ciò che comunemente viene definito "booter" o "stresser". Questi servizi a pagamento, permettono di utilizzare una potente infrastruttura per effettuare il maggior numero di request HTTP possibili verso un determinato target. Le request spesso vengono "anonimizzate" utilizzando open proxy o amplificando l'attacco tramite, ad esempio, wordpress pingback. La necessità di effettuare moltissime request per ogni connessione attiva, fa sì che i client utilizzati da questi servizi siano semplici script non in grado di interpretare codice JavaScript (sarebbe troppo oneroso in termini di tempo e di CPU usare browser headless tramite puppeteer o selenium per interpretare codice JavaScript, vanificherebbe l'attacco).

Per questo motivo molti vendor attivano al bisogno una challenge JavaScript, cioè una "pagina di cortesia" che include uno script JavaScript, solitamente offuscato, che se interpretato correttamente restituisce un token di sessione che permetterà all'utente di navigare indisturbato sul sito. Gli altri user-agent non in grado di interpretare codice JavaScript si fermeranno alla pagina di cortesia senza proseguire sul sito di destinazione. In questo modo il vendor assorbirà tutto l'attacco al posto del sito protetto. Per saperne di più sulle challenge JavaScript consiglio di vedere il mio talk al RomHack 2018 "Human Users Detection: stop bots with Nginx". La configurabilità della soglia in cui viene attivata la challenge e la rapidità nell'attivazione e disattivazione è tutto! Tant'è che alcuni vendor fanno campagne di marketing sull'argomento, dicendo che il loro servizio è migliore per i tempi di reazione rispetto agli altri.

Un esempio reale: Il grafico che vedete qui sotto è un reale attacco volumetrico layer 7 mitigato dal nostro WAAP su AWS. Per chi è pratico del elastic load balancer di AWS riconoscerà il seguente screenshot:

Provo a spiegarlo meglio sintetizzando tutto con questo schema:

Il sito target è un e-commerce. Come si vede dal grafico, il normale andamento del traffico HTTP non supera mai le 2 milioni di request HTTP all'ora. Tra la sera del giorno 3 e la mattina del giorno 4 c'è stato un picco che è arrivato a circa 5 milioni di request all'ora. Il nostro sistema, come fanno anche tanti altri in commercio, ha attivato la challenge JavaScript al superamento della soglia di tolleranza oltre i 2 milioni di eventi e l'ha disattivata al rientro nella "zona verde". Qualcuno potrebbe chiedersi: perchè attivarla e disattivarla? Non si può lasciare attiva? La risposta è no. In molti casi la pagina di cortesia proposta dai vendor (il classico messaggio "stiamo controllando il tuo browser, attendi 5 secondi") uccide la user experience tanto che molti utenti abbandonano il sito prima che venga risolta. Infatti uno dei punti cruciali nella valutazione di questo servizio è quello di poter customizzare la pagina di cortesia. Ad esempio per il nostro cliente, abbiamo sincronizzato la pagina di cortesia con la sua reale home page, così facendo l'utente non si accorge di stare visualizzando la pagina di cortesia e può scorrere gli articoli in vendita ignaro di tutto.

Alcuni vendor aggiungono alla normale challenge anche l'obbligo di risolvere un CAPTCHA. Sinceramente, a mio personalissimo parere, trovo che sia un punto a sfavore dato che molti dei nostri clienti lamentano il fatto che obbligare gli utenti a risolvere un CAPTCHA faccia perdere conversioni, visite, e quindi soldi.

Punti per valutare DoS Protection:

• rapidità di attivazione e disattivazione challenge JS
• configurabilità della soglia di tolleranza
• configurabilità della pagina di cortesia
• presenza o meno di captcha

Bad Bot Detection

Parlando dei servizi che potremmo definire "Bad Bot Detection" il discorso si fa un po' più complicato. Come dicevo prima, spesso i servizi che compongono un WAAP si intersecano: Bad Bot potrebbe essere una giusta definizione dell'attività di booter e stresser descritte prima per quanto riguarda DoS Protection. L'obiettivo di questi servizi è quello di contrastare il più possibile problematiche elencate nella OWASP TOP 20 Automated Threats (in particolare OAT-014 Vulnerability Scanning, OAT-005 Scalping, OAT-011 Scraping, OAT-007 Credential Cracking, OAT-017 Spamming) ma anche di identificare Impersonators. Mentre per problematiche come Vulnerability Scanner e Spamming l'esigenza di una contromisura è palese, per quanto riguarda gli Impersonators essa è più sottile. Sono consapevole del fatto che per un Penetration Tester la minaccia più grave per una web application o un sito web possa essere una vulnerabilità come SQLi o RCE e ha perfettamente senso. Se però chiedeste a un propietario di un e-commerce medio-grande quale problema ha più impatto sul suo business, in molti casi la risposta sarebbe "I bot della concorrenza che ci battono sul tempo sulle offerte su specifici prodotti, e i bot che alterano le statistiche fingendosi motori di ricerca o crawler di social network".

Partiamo con l'italiano. A volte leggo post e tweet che utilizzano il termine "Impersonare" e altri che usano "Impersonificare" ma quale sarebbe l'uso corretto? A mio avviso nel nostro campo, e soprattutto riferendosi a Bad Bot, sarebbe meglio non tradurre il termine (e quindi usare Impersonators). Ma se proprio dobbiamo usare l'italiano, Impersonificare è il neologismo corretto. Infatti "Impersonare" è corretto in italiano ma significa "dare personalità" o "interpretare una parte". Se si vuole intendere il furto o l'occultamento di identità il termine corretto è "Impersonificare". Ad esempio il decreto legislativo 11 aprile 2011, n. 64 recita
Per furto d’identità si intende:
a) l’impersonificazione totale: occultamento totale della propria identità mediante l’utilizzo indebito di dati relativi all’identità e al reddito di un altro soggetto […]
b) l’impersonificazione parziale: occultamento parziale della propria identità mediante l’impiego, in forma combinata, di dati relativi alla propria persona e l’utilizzo indebito di dati relativi ad un altro soggetto […]

Uno degli aspetti da valutare in una soluzione Bad Bot Detection è quello di capire se sia in grado di identificare un finto Googlebot o crawler di Facebook. Molti bot utilizzano impropriamente il request header User-Agent fingendosi il crawler di Google per diversi motivi: bypass dei rate limit, evitare challenge JavaScript (solitamente disattivate per i crawler dei motori di ricerca), ecc... Spesso la tecnica è questa:

• se il request header User-Agent è quello di Googlebot
• -> rDNS del IP, e verificare che il 2nd level domain del PTR sia googlebot.com
• -> se sì, resolve dell'hostname del PTR per verificare che combaci con l'IP

In questo modo è possibile accertarsi che lo user agent sia realmente ciò che afferma di essere. Questo vale sia per Google che per altri motori di ricerca e social network come Bing, Facebook e molti altri.

In questo caso reale, è possibile vedere come tutte le request HTTP siano arrivate al nostro WAAP con uno User-Agent appartenente a Googlebot, ma analizzando l'IP di connessione, esse provenivano da reti come Aruba o Huawei che nulla hanno a che vedere con Google.

Altri punti fondamentali sono l'identificazione del device tramite fingerprint e la configurabilità di azioni a fronte di visite da browser headless o comunque controllati tramite WebDriver. O ancora, la validazione dei request header in base a quanto previsto dal protocollo HTTP. Per fare un esempio, tempo fa ho bloccato una botnet per il semplice fatto che le request generate contenevano un errore sul request header Cache-Control. Per maggiori informazioni consiglio di leggere questo tweet:

https://twitter.com/AndreaTheMiddle/status/1327634480778141697

Punti per valutare Bad Bot Protection:

• protezione da tematiche incluse nel OWASP TOP 20 Automated Threats
• identificazione di Impersonators
• fingerprint e identificazione di WebDriver
• utilizzo machine learning e/o validazione request headers

Valutare WAF

È importante capire un aspetto che accomuna tutti i Web Application Firewall: è necessario valutare separatamente "engine" dal "rule set". L'engine è il motore che permette di interpretare le regole, il Rule Set rappresenta l'insieme di regole. utilizzando un valido e ben fatto Rule Set, l'installazione di default genera sempre falsi positivi. Eccezion fatta per webapp ben definite in cui le regole di exclusion fanno già parte del Rule Set, ad esempio CMS come WordPress, Joomla, Drupal, ecc... per tutte le altre web application o siti web un buon Rule Set genera sempre falsi positivi che vanno obbligatoriamente gestiti e indirizzati. Quando vedo WAF in cloud senza falsi positivi utilizzando lo stesso Rule Set su un eterogeneo parco di applicazioni web, il primo pensiero è che il Rule Set sia poco efficace. Oltre a questo, è importante capire che non si può valutare l'efficacia di un WAF in base a "quanti attacchi blocca" a fronte di una scansione eseguita, per esempio,  con un active scan o simili. In questo modo si valuta semplicemente il Rule Set e neanche nel modo corretto. Mi spiego meglio:

Ad esempio, il Rule Set più utilizzato al mondo (😎) OWASP Core Rule Set ha 4 livelli di Paranoia, ognuno dei quali aggiunge regole sempre più stringenti e che possono potenzialmente e in modo crescente aggiungere falsi positivi. Testare solo il livello di default (Paranoia Level 1) non è un buon modo per testare il servizio. Bisognerebbe prima adeguare il Rule Set ad un livello da 2 a 3 per avere un risultato attendibile. Oltre a questo è necessario capire le funzionalità dell'engine che fa funzionare il Rule Set e quali e quante transformation function possiede. Ad esempio, ModSecurity offre moltissime funzionalità che prescindono dal Rule Set come ad esempio diversi Body Processor a seconda del Content-Type, transformation function per decode, sanitize e normalization dello user input che sono tutti aspetti fondamentali per la creazione di una regola ma anche per scongiurare bypass.

Parlando di implementare nuove regole, una funzionalità stupenda del OWASP Core Rule Set che pochi vendor espongono, è quella di applicare una nuova regola WAF su una percentuale minima di traffico per verificare eventuali falsi positivi preservando le performance.

A mio avviso, un esempio di ottima comparison è quella fatta da Fraktal, che si è concentrata su diversi Rule Set ma su scenari simili di piattaforme in cloud. Quindi ha testato la percentuale di blocchi in base al Rule Set utilizzato con diversi engine:

Una pessima comparazione, a parer mio, è quella fatta da Vulners che ha comparato servizi con diversi Rule Set, diverse configurazioni e diversi scenari (incompatibili tra loro), completamente a membro canino e con un sospettissimo conflitto di interessi. L'articolo sul loro blog parte dicendo che hanno utilizzato GoTestWAF che è un tool sviluppato da un WAF vendor chiamato Wallarm e che serve a valutare l'impatto su di un WAF a fronte di diverse versioni di un payload. Aggiungono che sono "amici" con Wallarm: "GoTestWAF is a relatively new project that is actively maintained by another WAF vendor Wallarm (Full disclaimer: They are our friends)" e questo non è un buon modo di partire. Su 5 WAF che volevano provare sono riusciti a installarne solo 4, ASM di F5 (uno dei prodotti di punta sul mercato globale) evidentemente era fuori dalla loro portata. Hanno fatto un test approssimativo su ModSecurity e OWASP Core Rule Set palesemente disattivando alcune regole per poter far funzionare il test come si evince in questa discussione:

https://twitter.com/AndreaTheMiddle/status/1359516622470475781?s=20

Originariamente il test è stato effettuato solo in Paranoia Level 1, dopo la mia segnalazione hanno pubblicato anche i risultati dei livelli 2 e 3.

Indovinate quale azienda è risultata migliore in questa comparazione? 😂 Non voglio insultare la vostra intelligenza, ciò che state immaginando è corretto.

Punti per valutare WAF:

• quale rule set usa, se propietario o opensource
• possibilità di configurare il livello di protezione
• quali e quante transformation function ha a disposizione
• quanti e quali body processor ha a disposizione
• possibilità di creare regole nelle 5 fasi del webserver
• possibilità di gestire livello e formato di logging
• possibilità di fare inspection di una singola request

Guarda il video