Man in the browser

---

NOTA: per avere informazioni più aggiornate sul Man in the Browser è uscito un libro redatto dallo stesso autore di questo articolo.

Man in the browser è una forma di attacco che aggredisce il client della vittima per intercettare (sniffing) e modificare (tampering) il traffico ricevuto e spedito, da e verso il server.

Fa parte della famiglia di attacchi Man in the middle.

L'attacco Man in the browser non viene portato direttamente all'applicazione Web, ma al sistema operativo e al browser utilizzati dall'utente. Per questo motivo, l'applicazione Web ha poche difese.

L'applicazione è conosciuta dai malintenzionati in quanto le request e le response HTTP vengono modificate ad hoc dal software che ha infettato il browser. Per questo è necessario che gli attaccanti, oltre a creare il trojan per il browser, debbano conoscere le request e le response ricevute e spedite dall'applicazione per modificarle e portare a termine un'aggressione.
E' quindi il sistema operativo ed il browser ad avere una vulnerabilità tale da poter essere sfruttata per aggredire l'applicazione Web.

I sistemi di difesa per le aggressioni di tipo Man in the middle, falliscono per il semplice motivo che non sono stati pensati espressamente per questa tipologia di aggressione. E infatti l'HTTPS, anche se rinforzato tramite HSTS (HTTP Strict Transport Security), non difende da questa metodologia di attacco. Questo perché il trojan interviene prima (per le request) e dopo (per le response) che il browser cripti e decripti il traffico in arrivo tra client e server e può agire indisturbato.

Come avviene l'attacco Man in the browser

Dopo che il PC della vittima aggredito dal Man in the browser è stato infettato da un trojan (vedi I malware più diffusi per il Man in the browser), questo intercetta il traffico passante tra client e server. Una volta che vengono effettuate request verso applicazioni Web che il trojan sa aggredire, allora interviene per modificarle.

Man in the browser: esempio

Il Man in the browser è un attacco che ha colpito principalmente istituzioni finanziarie. Ci concentreremo maggiormente su queste applicazioni Web. Ipotizziamo di essere clienti della banca Vattelapesca, se chiedessimo di eseguire un bonifico, il nostro client potrebbe eseguire una request HTTP POST contenente, come body della chiamata, un JSON (semplificato) di questo tipo:

{
   "ndg": 87654321,
   "order": "Cliente Vittima",
   "amount": 1234.56,
   "cur": "EUR",
   "iban-payee": "IT31K0558401650000000000001",
   "payee": "Luigi Luzzatti"
}

Prima di eseguire la chiamata al server e anzi, prima ancora di crittografare il contenuto della chiamata HTTPS, il trojan potrebbe intervenire modificando il JSON con:

{
   "ndg": 87654321,
   "order": "Cliente Vittima",
   "amount": 1234.56,
   "cur": "EUR",
   "iban-payee": "IT98M0504003200453242374232",
   "payee": "John Robber"
}

Questo consentirebbe ad un attaccante di dirottare la somma di 1.234,56 EUR da:

• Luigi Luzzatti
• IBAN IT31K0558401650000000000001

a:

• John Robber
• IBAN IT98M0504003200453242374232

L'attacco potrebbe non fermarsi a questa modifica. Quando poi il server processa la richiesta del client, la banca potrebbe chiedere una conferma dell'operazione, che però verrebbe mostrata sul browser infetto. E così, a fronte di una response HTML tipo:

<p>Confermi l'invio di un bonifico di <b>1.234,56 EUR</b> a:</p>
 
<p>
<b>John Robber</b> (IBAN: IT98M0504003200453242374232)?
</p>

Il trojan potrebbe intervenire nuovamente e modificare il codice riportando i valori iniziali richiesti dalla vittima:

<p>Confermi l'invio di un bonifico di <b>1.234,56 EUR</b> a:</p>
 
<p>
<b>Luigi Luzzatti</b> (IBAN: IT31K0558401650000000000001)?
</p>

A questo punto, la vittima dell'attacco Man in the browser accetterebbe l'operazione e l'aggressione avrebbe successo. 1.234,56 EUR sono stati trasferiti a John Robber.

Man in the browser: cos'è?

In breve, il Man in the browser è un virus (più precisamente un trojan) che infetta il PC della vittima. Ne esistono di differenti e ognuno di essi ha adottato strategie diverse:

• un proxy che intercetta ed eventualmente modifica i dati comunicati tra client e server, così da rubare informazioni ed eseguire operazioni differenti rispetto a quelle volute dalla vittima, senza che questa possa accorgersene
• un injector che inserisce campi nuovi da compilare o fornisce un'intera pagina Web clone, per rubare le informazioni che il trojan chiede di inserire all'utente
• un keylogger per intercettare e registrare ciò che l'utente digita sulla tastiera (come username e password)

I malware più diffusi

Nella tabella che segue i più diffusi malware utilizzati per eseguire un attacco di tipo Man in the browser:

Man in the browser Malware	Funzionamento	Sistema Operativo	Browser
Agent.DBJP		Windows	IE, Firefox
Bugat		Windows	IE, Firefox
Carberp	Furto di e-cash vouchers su Facebook	Windows	IE, Firefox
ChromeInject		Windows	Firefox
Clampi		Windows	IE
Gozi	Data scraping per monitorare il saldo di conto e determinare le cifre da trasferire	Windows	IE, Firefox
Nuklus		Windows	IE
OddJob		Windows	IE, Firefox
Silentbanker	Inietta codice HTML con nuovi campi da compilare per invitare l'utente a inserire dati da rubare	Windows	IE, Firefox
Silon		Windows	IE
Shylock	Furto di credenziali di accesso
SpyEye		Windows	IE, Firefox
Sunspot		Windows	IE, Firefox
Tatanga		Windows	IE, Firefox, Chrome, Opera
Tiny Banker Trojan		Windows	IE, Firefox
Torpig		Windows	IE, Firefox
URLZone	Inietta codice HTML con messaggi di errore per fare reinserire dati da rubare	Windows	IE, Firefox, Opera
Weyland-Yutani BOT		Max OS X	Firefox
Yaludle		Windows	IE
Zeus		Windows	IE, Firefox

Fonte della tabella: Man in the Browser Attacks by Krishna Sai Anudeep Ayyagari

Strumenti di difesa contro il Man in the browser

Lato utente, come sempre, è indispensabile tenere aggiornato il sistema operativo e il browser alle ultime versioni possibili. Oltre a dotarsi di un buon antivirus per intercettare eventuali infezioni da parte di questi trojan.

Sniffing dei dati

L'applicazione Web ha poche difese contro il Man in the browser. In caso di sniffing, ovvero l'intercettazione dei dati senza alcuna modifica, l'applicazione può intervenire solo ex post. Quando il malintenzionato proverà ad effettuare lui stesso la login, allora l'applicazione Web potrà intervenire con i propri sistemi di controllo (accesso anomalo da device mai utilizzato, da un'area geografica nuova, ecc.). Ma i dati rubati potranno essere utilizzati anche in maniera differente, come il Credential Stuffing.

Lo sniffing dei dati può riguardare, a titolo esemplificativo e non esaustivo:

1. Furto delle credenziali di accesso
2. Furto del cookie di sessione (Session Hijacking)
3. Furto di informazioni riservate quali:
   1. numero di carta di credito
   2. codici di autorizzazione
   3. altri dati finanziari

Tampering dei dati

Più complicato è il tampering, ovvero la modifica, delle informazioni passate tra client e server (come nell'esempio di Man in the browser visto precedentemente). Il server infatti, si vedrebbe arrivare una richiesta da un device già utilizzato (e magari certificato dall'utente), con la solita geolocalizzazione e lo stesso operatore di rete. E per questo è difficile, per il layer dell'applicazione Web che risiede sul server, distinguere un'operazione corretta da una modificata.

Controllo sulle operazioni anomale

Le banche che lato server verificano e richiedono un ulteriore controllo per le operazioni anomale (che comprendono, ma non solo, le prime che vengono effettuate a benificiari nuovi) possono contare su un'arma di difesa in più contro il Man in the browser.

Content-Security-Policy

Se il colloquio tra client e server non avviene solo per mezzo di API e il contenuto delle response HTTP viene modificato dal trojan per mezzo di una manipolazione del DOM grazie ad un Javascript opportunamente iniettato, la direttiva CSP (Content-Security-Policy) implementata in maniera robusta, potrebbe impedire queste modifiche (bloccando gli inline script). È comunque una difesa debole che può essere superata con un nuovo software: in fase di progettazione del trojan, all'aggressore sarebbe sufficiente evitare di utilizzare Javascript ed agire direttamente sulle response, oppure modificare la response del server per eliminare la direttiva CSP.

Secondo fattore di autenticazione

Una prima difesa contro l'attacco Man in the browser può essere la presenza di un secondo fattore di autenticazione che non risieda nel browser, così da poter validare l'operazione in un canale che non è stato infettato (out of band communication). Per esempio, nell'attacco visto prima, una volta eseguita l'operazione, la banca avrebbe potuto chiedere una confema sullo smartphone del cliente indicando chiaramente:

• Importo
• Beneficiario
• IBAN beneficiario

A questo punto, la vittima potrebbe accorgersi che il suo bonifico originale indirizzato a Luigi Luzzatti, era stato modificato.

Dubbi sul secondo fattore di autenticazione

La presenza del secondo fattore di autenticazione su un canale out of band è valido solo se:

1. L'utente legge e verifica prima di autorizzare
2. Lo smartphone non è anch'esso infettato

I dubbi sul primo punto sussistono soprattutto perché in questo contesto, il secondo fattore di autenticazione viene utilizzato per scaricare sull'utente l'onere della verifica per una possibile falla presente nella catena di erogazione dell'applicazione Web. Quindi il secondo fattore non completa solo la fase di autenticazione, ma si richiede all'utente un controllo su ciò che è stato inserito in quanto sussiste la possibilità che il canale non sia sicuro. Può venire meno il senso di fiducia di chi utilizza i servizi on line.