Host Header Injection

Back to Posts

Host Header Injection

Articolo in collaborazione con: Jatinder Pal Singh, professionista da oltre nove anni nel settore dell’ Information Security. Master in Information & Security System dell’Università di Glamorgan, attualmente consulente capo (Threat Management Services) di Aujas Networks.

HTTP Header Injection Vulnerability

Le applicazioni web che non filtrano correttamente gli header delle intestazioni HTTP sono vulnerabili all’attacco HTTP Header Injection (anche conosciuto come Response Splitting); questa vulnerabilità non solo consente ad un attaccante di controllare le intestazioni e il corpo della risposta, ma gli consente di creare risposte supplementari interamente sotto il suo controllo.

Vediamo di capirne meglio il funzionamento.

Perché l’exploit funzioni correttamente, l’applicazione deve consentire input che contengono i seguenti caratteri CR (carriage return, %0d o \r) e LF (line feed, %0a o \n).

Prendiamo in esempio il codice sottostante:

String author = Request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);

Il codice “legge” il nome dell’autore da una richiesta HTTP e imposta il valore del cookie nella risposta.

Tuttavia, poiché il valore del cookie è generato da input degli utenti non validati, la risposta non creerà problemi fintanto che il parametro AUTHOR_PARAM non conterrà caratteri CR e LF.

Se l’attaccante utilizzerà i caratteri, ad esempio
Attacker \ r \ n HTTP / 1.1 200 OK \ r \ n“, allora la risposta HTTP verrà divisa in due risposte distinte:

Set-Cookie: author=Jane Smith
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Attacker
HTTP/1.1 200 OK

Chiaramente, la seconda risposta è completamente controllata dall’attaccante e può essere composta da qualsiasi intestazione e corpo. La capacità dell’attaccante di forgiare risposte HTTP arbitrarie risulta in un ampia varietà di attacchi: Cross-User Defacement, Cache Poisoning, Cross-site Scripting (XSS) e Page Hijacking.

Concentriamoci su un attacco nello specifico:

Cache Poisoning & Redirection

E’ pratica comune dei programmatori web fare affidamento sul valore dell’intestazione Host HTTP per “generare” i link, in modo che lo stesso software funzioni su localhost, vari server di prova, sottodomini, domini secondari, ecc, senza ulteriori modifiche.
Per esempio:

<?=$_SERVER['HTTP_HOST']?>/login">Login

Vi sembra familiare? L’intestazione host HTTP è un testo arbitrario controllato dall’utente ma è pratica comune considerla come se fosse una variabile d’ambiente sicura.

La seconda vulnerabilità avviene quando sul “percorso” tra il sito e gli utenti è presente una qualche forma di cache: gestita dal sito stesso, un proxy a livello di ISP, CDN, ecc.
Questo permette ad un attaccante di riscrivere gli URL di una qualsiasi pagina.

Dimostriamo l’exploit prima in linea teorica e poi con un esempio pratico:

telnet www.example.com 80
Connected to www.example.com.
GET /index.html HTTP/1.1
User-Agent: Mozilla
Host: evilsite.com

HTTP/1.1 200 OK Date: Wed, 10 Jun 2008 00:27:45 GMT Server: Apache Cache-Control: max-age=60 Expires: Wed, 17 Jun 2008 00:27:45 GMT Content-Length: 2959 Content-Type: text/html; charset=iso-8859-1 
<a.href="http://evilsite.com/">Home
<a.href="http://evilsite.com/about">About
<a.href="http://evilsite.com/login">Login …

Apache Server at evilsite.com Port 80

Ora, se è presente una cache, attiva da parte dei proprietari del sito o un qualsiasi proxy lungo la strada, altri client otterranno la pagina da noi compromessa.

TARGET: flickr.com

1.1 - Intercept the request 1.2 - change the host header 1.3 - redirected to google 1.4 - Google Redirection 1.5 - Cache Poisioning Google Request

Assieme a Jatinder Pal Singh, il team di VoidSec ha riportato la problematica ai seguenti Team di sicurezza, di cui elenchiamo le risposte ricevute:

  • Flickr – Yahoo closed Host Header Injection as Duplicate
  • Western Union closed Host Header Injection as a Duplicate
  • eBay Inc closed Host Header Injection as Out Of Scope

Mitigation

Utilizzare il valore dell’intestazione host come un qualsiasi dato proveniente dall’esterno.
Se necessario, applicare filtri molto rigidi per consentire solo nomi di dominio validi (whitelist).
Se il server web è configurato per “emettere” il valore dell’intestazione host (come nell’esempio, e per impostazione predefinita di molti web server) disabilitare tale configurazione.

Per ulteriori informazioni riguardanti questo attacco: SkeletonScribe e Zope Bug

di VoidSec

Share this post

Back to Posts