Domain/Subdomain takeover

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Domain takeover

Se scopri un dominio (domain.tld) che è utilizzato da qualche servizio all’interno dello scope ma la azienda ha perso la proprietà, puoi provare a registrarlo (se economico) e avvisare l’azienda. Se questo dominio riceve informazioni sensibili come un cookie di sessione tramite parametro GET o nell’intestazione Referer, si tratta sicuramente di una vulnerabilità.

Subdomain takeover

Un sottodominio dell’azienda punta a un servizio di terze parti con un nome non registrato. Se riesci a creare un account in questo servizio di terze parti e registrare il nome in uso, puoi eseguire il subdomain takeover.

Ci sono diversi tool con dizionari per verificare possibili takeover:

Subdomain Takeover Generation via DNS Wildcard

Quando è usato un wildcard DNS in un dominio, qualsiasi sottodominio richiesto di quel dominio che non ha un indirizzo diverso esplicitamente verrà risolto allo stesso valore. Questo può essere un indirizzo A, un CNAME…

Per esempio, se *.testing.com è wildcarded a 1.1.1.1. Allora, not-existent.testing.com punterà a 1.1.1.1.

Tuttavia, se invece di puntare a un indirizzo IP, il sysadmin lo indirizza a un servizio di terze parti tramite CNAME, come un sottodominio GitHub ad esempio (sohomdatta1.github.io). Un attaccante potrebbe creare la propria pagina di terze parti (su GitHub in questo caso) e dichiarare che something.testing.com punta lì. Poiché il CNAME wildcard acconsentirà, l’attaccante sarà in grado di generare sottodomini arbitrari per il dominio della vittima che puntano alle sue pagine.

Puoi trovare un esempio di questa vulnerabilità nel write-up CTF: https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api

Sfruttare un subdomain takeover

Subdomain takeover è essenzialmente DNS spoofing per un dominio specifico sulla rete internet, permettendo agli attaccanti di impostare record A per un dominio, facendo sì che i browser mostrino contenuti dal server dell’attaccante. Questa trasparenza nei browser rende i domini suscettibili al phishing. Gli attaccanti possono usare lo typosquatting o domini Doppelganger per questo scopo. Sono particolarmente vulnerabili i domini dove l’URL in una email di phishing appare legittimo, ingannando gli utenti e sfuggendo ai filtri anti-spam grazie alla fiducia implicita nel dominio.

Check this post for further details

SSL Certificates

Gli SSL certificates, se generati dagli attaccanti tramite servizi come Let’s Encrypt, aggiungono legittimità a questi domini falsi, rendendo gli attacchi di phishing più convincenti.

La trasparenza del browser si estende anche alla sicurezza dei cookie, governata da politiche come la Same-origin policy. I cookie, spesso usati per gestire sessioni e memorizzare token di accesso, possono essere sfruttati tramite subdomain takeover. Gli attaccanti possono raccogliere cookie di sessione semplicemente indirizzando gli utenti verso un sottodominio compromesso, mettendo a rischio i dati e la privacy degli utenti.

CORS Bypass

Potrebbe essere possibile che ogni sottodominio sia autorizzato ad accedere alle risorse CORS dal dominio principale o da altri sottodomini. Questo potrebbe essere sfruttato da un attaccante per accedere a informazioni sensibili abusando di richieste CORS.

CSRF - Same-Site Cookies bypass

Potrebbe essere possibile che il sottodominio sia autorizzato a inviare cookie al dominio o ad altri sottodomini che sarebbe stato impedito dall’attributo Same-Site dei cookie. Tuttavia, nota che i token anti-CSRF continueranno a prevenire questo attacco se implementati correttamente.

OAuth tokens redirect

Potrebbe essere possibile che il sottodominio compromesso sia autorizzato ad essere usato nell’URL redirect_uri di un flusso OAuth. Questo potrebbe essere sfruttato da un attaccante per rubare l’OAuth token.

CSP Bypass

Potrebbe essere possibile che il sottodominio compromesso (o ogni sottodominio) sia autorizzato ad essere usato per esempio nel script-src del CSP. Questo potrebbe essere sfruttato da un attaccante per iniettare script malevoli e sfruttare potenziali vulnerabilità XSS.

Emails and Subdomain Takeover

Un altro aspetto del subdomain takeover riguarda i servizi email. Gli attaccanti possono manipolare i MX records per ricevere o inviare email da un sottodominio legittimo, aumentando l’efficacia degli attacchi di phishing.

Higher Order Risks

Ulteriori rischi includono il takeover di record NS. Se un attaccante ottiene il controllo su un record NS di un dominio, può potenzialmente indirizzare una parte del traffico verso un server sotto il suo controllo. Questo rischio è amplificato se l’attaccante imposta un alto TTL (Time to Live) per i record DNS, prolungando la durata dell’attacco.

CNAME Record Vulnerability

Gli attaccanti potrebbero sfruttare record CNAME non reclamati che puntano a servizi esterni non più usati o decommissionati. Questo permette loro di creare una pagina sotto il dominio affidabile, facilitando ulteriormente phishing o distribuzione di malware.

Mitigation Strategies

Strategie di mitigazione includono:

  1. Rimuovere i record DNS vulnerabili - Questo è efficace se il sottodominio non è più necessario.
  2. Claiming the domain name - Registrare la risorsa con il rispettivo cloud provider o riacquistare un dominio scaduto.
  3. Regular monitoring for vulnerabilities - Tool come aquatone possono aiutare a identificare domini suscettibili. Le organizzazioni dovrebbero anche rivedere i loro processi di gestione dell’infrastruttura, assicurando che la creazione del record DNS sia l’ultimo passo nella creazione di una risorsa e il primo passo nella distruzione.

Per i cloud providers, verificare la proprietà del dominio è cruciale per prevenire i subdomain takeover. Alcuni, come GitLab, hanno riconosciuto questo problema e implementato meccanismi di validazione del dominio.

Tecniche di rilevamento

  • Find dangling DNS records: cerca CNAME/A/AAAA/ALIAS/ANAME che puntano a risorse non esistenti (bucket cancellati, app, pages, load balancer).
  • Check provider error signatures: confronta le risposte HTTP, i certificati TLS o gli errori DNS con pattern noti di takeover (vedi can-i-take-over-xyz).
  • Look for orphaned cloud assets: verifica S3/CloudFront, Azure Websites, GCP App Engine/Storage, GitHub Pages, Heroku, Fastly, Netlify, Vercel, Zendesk, Shopify, Atlassian e servizi simili.
  • Passive DNS and historical records: vecchi CNAME spesso rivelano servizi di terze parti precedentemente usati che potrebbero essere ancora vulnerabili.
  • Wildcard pitfalls: conferma wildcard DNS vs. record espliciti per evitare falsi positivi e comprendere l’amplificazione del takeover.

APIs and data sources

References

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks