Przejęcie domeny/poddomeny

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Przejęcie domeny

Jeśli odkryjesz jakąś domenę (domain.tld), która jest używana przez jakąś usługę w ramach zakresu, ale firma utraciła nad nią własność, możesz spróbować ją zarejestrować (jeśli wystarczająco tanio) i powiadomić firmę. Jeśli ta domena otrzymuje wrażliwe informacje, takie jak session cookie poprzez parametr GET lub w nagłówku Referer, to na pewno jest to podatność.

Przejęcie subdomeny

Subdomena firmy wskazuje na usługę zewnętrzną o nierozpoznanej/niezarejestrowanej nazwie. Jeśli możesz utworzyć konto w tej usłudze i zarejestrować używaną nazwę, możesz przeprowadzić przejęcie subdomeny.

Istnieje kilka narzędzi z słownikami do sprawdzania możliwych przejęć:

Generowanie przejęcia subdomen przez wildcard DNS

Gdy w domenie użyty jest wildcard DNS, każda żądana subdomena tej domeny, która nie ma jawnie innego adresu, zostanie rozwiązana do tych samych danych. Może to być adres A, CNAME itd.

Na przykład, jeśli *.testing.com jest skierowane na 1.1.1.1, to not-existent.testing.com będzie wskazywać na 1.1.1.1.

Jednak zamiast wskazywać na adres IP, jeśli administrator skieruje wildcard do usługi zewnętrznej przez CNAME, jak subdomena GitHub (sohomdatta1.github.io), atakujący może utworzyć własną stronę w tej usłudze (GitHub w tym przykładzie) i sprawić, że something.testing.com będzie wskazywać tam. Ponieważ CNAME wildcard to zaakceptuje, atakujący będzie w stanie generować dowolne subdomeny dla domeny ofiary wskazujące na swoje strony.

Przykład tej podatności można znaleźć w write-upie CTF: https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api

Wykorzystanie przejęcia subdomeny

Subdomain takeover to w praktyce DNS spoofing dla konkretnej domeny w internecie, pozwalający atakującemu ustawić rekordy A dla domeny, powodując, że przeglądarki wyświetlają treści z serwera kontrolowanego przez atakującego. Ta przejrzystość w przeglądarkach sprawia, że domeny są podatne na phishing. Atakujący mogą stosować [typosquatting] lub [Doppelganger domains] w tym celu. Szczególnie narażone są domeny, gdzie URL w wiadomości phishingowej wygląda wiarygodnie, wprowadzając w błąd użytkowników i omijając filtry spamu dzięki zaufaniu do domeny.

Zobacz ten post dla dalszych szczegółów

Certyfikaty SSL

Certyfikaty SSL, jeśli wygenerowane przez atakujących za pomocą usług takich jak Let’s Encrypt, zwiększają wiarygodność fałszywych domen, czyniąc ataki phishingowe bardziej przekonującymi.

Przejrzystość przeglądarek odnosi się również do bezpieczeństwa cookie, regulowanego przez polityki takie jak Same-origin policy. Cookies, często używane do zarządzania sesjami i przechowywania tokenów logowania, mogą być wykorzystywane przez przejęcie subdomen. Atakujący mogą zebrać session cookies po prostu kierując użytkowników na skompromitowaną subdomenę, narażając dane i prywatność użytkowników.

Obejście CORS

Może się okazać, że wszystkie subdomeny mają dostęp do zasobów objętych CORS z domeny głównej lub innych subdomen. To może być wykorzystane przez atakującego do uzyskania dostępu do wrażliwych informacji poprzez żądania CORS.

CSRF - obejście Same-Site

Możliwe, że subdomena jest dozwolona do wysyłania cookies do domeny lub innych subdomen, co normalnie byłoby zapobiegane przez atrybut Same-Site ciasteczek. Należy jednak pamiętać, że tokeny anty-CSRF wciąż powstrzymają ten atak, jeśli są poprawnie zaimplementowane.

Przekierowanie tokenów OAuth

Może się zdarzyć, że skompromitowana subdomena jest dozwolona jako redirect_uri w przepływie OAuth. To może być wykorzystane przez atakującego do kradzieży tokenu OAuth.

Obejście CSP

Może się zdarzyć, że skompromitowana subdomena (lub każda subdomena) jest dozwolona na przykład w script-src w CSP. To może być wykorzystane przez atakującego do wstrzyknięcia złośliwych skryptów i nadużycia potencjalnych podatności XSS.

E-maile i przejęcie subdomeny

Innym aspektem przejęcia subdomen jest usługa pocztowa. Atakujący mogą manipulować rekordami MX, aby odbierać lub wysyłać e-maile z prawowitej subdomeny, zwiększając skuteczność ataków phishingowych.

Ryzyka wyższego rzędu

Dalsze ryzyka obejmują przejęcie rekordów NS. Jeśli atakujący zdobędzie kontrolę nad jednym rekordem NS domeny, może potencjalnie skierować część ruchu na serwer pod jego kontrolą. Ryzyko to jest spotęgowane, jeśli atakujący ustawi duży TTL (Time to Live) dla rekordów DNS, wydłużając czas trwania ataku.

Podatność rekordów CNAME

Atakujący mogą wykorzystać niezarejestrowane rekordy CNAME wskazujące na zewnętrzne usługi, które nie są już używane lub zostały wycofane. To pozwala im stworzyć stronę pod zaufaną domeną, ułatwiając phishing lub dystrybucję malware.

Strategie łagodzenia

Strategie łagodzenia obejmują:

  1. Usunięcie podatnych rekordów DNS - skuteczne, jeśli subdomena nie jest już potrzebna.
  2. Zajęcie nazwy zasobu - zarejestrowanie zasobu u odpowiedniego dostawcy chmurowego lub odkupienie wygasłej domeny.
  3. Regularny monitoring podatności - narzędzia takie jak aquatone pomagają identyfikować podatne domeny. Organizacje powinny też zrewidować swoje procesy zarządzania infrastrukturą, upewniając się, że tworzenie rekordu DNS jest ostatnim krokiem przy tworzeniu zasobu i pierwszym przy jego usuwaniu.

Dla dostawców chmurowych weryfikacja własności domeny jest kluczowa, aby zapobiegać przejęciom subdomen. Niektórzy, jak GitLab, zdają sobie z tego sprawę i wprowadzili mechanizmy weryfikacji domen.

Techniki wykrywania

  • Znajdź wiszące (dangling) rekordy DNS: szukaj rekordów CNAME/A/AAAA/ALIAS/ANAME wskazujących na nieistniejące zasoby (usunięte buckets, aplikacje, pages, load balancery).
  • Sprawdź sygnatury błędów dostawcy: dopasuj odpowiedzi HTTP, certyfikaty TLS lub błędy DNS do znanych wzorców takeover (zob. can-i-take-over-xyz).
  • Szukaj osieroconych zasobów chmurowych: weryfikuj S3/CloudFront, Azure Websites, GCP App Engine/Storage, GitHub Pages, Heroku, Fastly, Netlify, Vercel, Zendesk, Shopify, Atlassian i podobne usługi.
  • Passive DNS i rekordy historyczne: stare CNAME często ujawniają wcześniej używane usługi zewnętrzne, które mogą nadal być podatne.
  • Pułapki wildcard: potwierdź wildcard DNS vs. jawne rekordy, aby uniknąć false positives i zrozumieć potencjał amplifikacji przejęcia.

API i źródła danych

Referencje

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks