Domain/Subdomain takeover

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Domain takeover

Якщо ви виявили якийсь домен (domain.tld), який використовується якимось сервісом у межах scope, але компанія втратила власність на нього, ви можете спробувати зареєструвати його (якщо це недорого) і повідомити компанію. Якщо цей домен отримує якусь чутливу інформацію, наприклад session cookie через параметр GET або в заголовку Referer, це однозначно вразливість.

Subdomain takeover

Піддомен компанії вказує на сторонній сервіс з ім’ям, яке не зареєстроване. Якщо ви можете створити акаунт у цьому сторонньому сервісі і зареєструвати ім’я, яке використовується, ви зможете виконати subdomain takeover.

Є кілька інструментів зі словниками для перевірки можливих takeover:

Subdomain Takeover Generation via DNS Wildcard

Коли в домені використано DNS wildcard, будь-який запитаний піддомен цього домену, який явно не має іншої адреси, буде резолвитися до тієї ж інформації. Це може бути A IP-адреса, CNAME…

Наприклад, якщо *.testing.com вказано на 1.1.1.1. Тоді not-existent.testing.com буде вказувати на 1.1.1.1.

Однак, якщо замість вказування на IP-адресу системний адміністратор вказує на сторонній сервіс через CNAME, наприклад на GitHub subdomain (sohomdatta1.github.io). Атакувальник може створити власну сторінку на сторонньому сервісі (в GitHub у цьому прикладі) і сказати, що something.testing.com вказує туди. Оскільки CNAME wildcard це дозволяє, атакувальник зможе генерувати довільні піддомени для домену жертви, що вказують на його сторінки.

Приклад цієї вразливості можна знайти в CTF write-up: https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api

Exploiting a subdomain takeover

Subdomain takeover по суті є DNS spoofing для конкретного домену в Інтернеті, дозволяючи атакувальникам встановлювати A запис для домену, внаслідок чого браузери показують контент з сервера атакувальника. Ця прозорість в браузерах робить домени вразливими до phishing. Атакувальники можуть використовувати typosquatting або Doppelganger domains з цією метою. Особливо вразливі домени, де URL в phishing-листі виглядає легітимно, обманюючи користувачів і уникаючи спам-фільтрів завдяки довірі до домену.

Перегляньте цей пост для детальніших відомостей: https://0xpatrik.com/subdomain-takeover/

SSL Certificates

SSL сертифікати, якщо створені атакувальниками через сервіси на кшталт Let’s Encrypt, додають легітимності цим фальшивим доменам, роблячи phishing-атаки більш переконливими.

Прозорість браузера також стосується безпеки cookie, яку регулюють політики на кшталт Same-origin policy. Cookies, які часто використовуються для управління сесіями та зберігання токенів входу, можуть бути експлуатовані через subdomain takeover. Атакувальники можуть збирати session cookies, просто перенаправляючи користувачів на скомпрометований піддомен, ставлячи під загрозу дані і приватність користувачів.

CORS Bypass

Може бути так, що кожному піддомену дозволено доступ до ресурсів через CORS з основного домену або інших піддоменів. Це може бути використано атакувальником для доступу до чутливої інформації, зловживаючи CORS-запитами.

CSRF - Same-Site Cookies bypass

Можливо, що піддомену дозволено надсилати cookie до домену або інших піддоменів, що зазвичай запобігається атрибутом Same-Site у cookies. Однак зауважте, що anti-CSRF токени все одно запобігатимуть цій атаці, якщо вони реалізовані правильно.

OAuth tokens redirect

Може бути так, що скомпрометований піддомен дозволено використовувати в полі redirect_uri OAuth-флоу. Це може бути використано атакувальником для викрадення OAuth токена.

CSP Bypass

Може бути так, що скомпрометований піддомен (або кожному піддомену) дозволено використовуватися, наприклад, в script-src CSP. Це може бути використано атакувальником для впровадження шкідливих скриптів і використання потенційних XSS вразливостей.

Emails and Subdomain Takeover

Ще один аспект subdomain takeover стосується email-сервісів. Атакувальники можуть маніпулювати MX записами, щоб отримувати або надсилати листи від імені легітимного піддомену, збільшуючи ефективність phishing-атак.

Higher Order Risks

Подальші ризики включають NS record takeover. Якщо атакувальник отримує контроль над одним NS записом домену, він може потенційно направляти частину трафіку на сервер під своїм контролем. Цей ризик посилюється, якщо атакувальник встановлює великий TTL (Time to Live) для DNS записів, продовжуючи тривалість атаки.

CNAME Record Vulnerability

Атакувальники можуть експлуатувати незаявлені CNAME записи, які вказують на зовнішні сервіси, що більше не використовуються або були виведені з експлуатації. Це дозволяє їм створити сторінку під довіреним доменом, що полегшує phishing або розповсюдження malware.

Mitigation Strategies

Стратегії пом’якшення включають:

  1. Removing vulnerable DNS records - ефективно, якщо піддомен більше не потрібен.
  2. Claiming the domain name - реєстрація ресурсу у відповідного cloud provider або повторна купівля простроченого домену.
  3. Regular monitoring for vulnerabilities - інструменти на кшталт aquatone можуть допомогти виявляти вразливі домени. Організації також повинні переглянути процеси управління інфраструктурою, забезпечивши, що створення DNS запису є останнім кроком при створенні ресурсу і першим кроком при його знищенні.

Для cloud providers перевірка володіння доменом є критичною для запобігання subdomain takeovers. Деякі сервіси, наприклад GitLab, визнали цю проблему і впровадили механізми валідації доменів.

Detection techniques

  • Find dangling DNS records: шукайте CNAME/A/AAAA/ALIAS/ANAME записи, які вказують на неіснуючі ресурси (видалені buckets, apps, pages, load balancers).
  • Check provider error signatures: порівнюйте HTTP-відповіді, TLS certs або DNS-помилки з відомими патернами takeover (див. can-i-take-over-xyz).
  • Look for orphaned cloud assets: перевіряйте S3/CloudFront, Azure Websites, GCP App Engine/Storage, GitHub Pages, Heroku, Fastly, Netlify, Vercel, Zendesk, Shopify, Atlassian та подібні сервіси.
  • Passive DNS and historical records: старі CNAME часто відкривають інформацію про раніше використовувані сторонні сервіси, які все ще можуть бути вразливими.
  • Wildcard pitfalls: перевіряйте wildcard DNS проти явних записів, щоб уникнути false positives і зрозуміти потенційне посилення takeover.

APIs and data sources

References

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks