Subdomain takeover: tespit ve önleme rehberi

Ele geçirme nasıl gerçekleşir

Ekipler alt alan adlarını sürekli olarak barındırılan hizmetlere yönlendirir: docs.example.com bir statik site sağlayıcısına, shop.example.com bir e-ticaret platformuna, assets.example.com bir depolama kovasına. DNS kaydı çoğu zaman, sağlayıcının size verdiği example-docs.hosting.example.net gibi bir ada işaret eden bir CNAME kaydıdır. Hizmet iptal edildiğinde kaynak silinir, ancak CNAME kaydı çoğu kez bölgede öylece kalır. Kaydı kimin hangi proje için eklediği zamanla unutulur ve kimse onu temizlemekle görevli hissetmez.

Geride kalan bu kayda İngilizcede dangling DNS, yani sahipsiz DNS kaydı denir. Sağlayıcı herhangi bir müşterinin aynı adı taşıyan bir kaynak oluşturmasına izin veriyorsa, o adı önce üstlenen kişi docs.example.com adresinin ne sunacağını belirler. Tarayıcının adres çubuğunda hâlâ sizin alan adınız görünür ve birçok sağlayıcı bu ad için geçerli bir TLS sertifikası bile düzenler. Ziyaretçi açısından sayfa, kilit simgesi dahil her bakımdan size aitmiş gibi görünür.

Bir alt alan adı barındırılan bir kaynağı gösterir, kaynak silinir ama DNS kaydı bölgede kalır, başka bir müşteri aynı kaynak adını üstlenir ve alt alan adı artık onun içeriğini sunar.

Sahipsiz kalabilen kayıt türleri

Sahipsiz kalabilen kayıt türleri
Kayıt	Ne zaman sahipsiz kalır	Sonucu
CNAME	Bir bulut ya da SaaS sağlayıcısındaki hedef kaynak silinmiştir	Alt alan adınızda başkasının web içeriği ve sertifikaları
NS delegasyonu	Alt alan adı, artık var olmayan bir DNS barındırma bölgesine ya da süresi dolmuş bir alan adındaki ad sunucularına devredilmiştir	O alt alan adı altındaki bütün kayıtların tam denetimi
MX	Süresi dolmuş bir alan adındaki posta sunucusunu ya da iptal edilmiş bir hizmeti gösterir	O ada gelen postanın başkasına teslim edilmesi
A / AAAA	Serbest bıraktığınız bir bulut IP adresini gösterir	O IP adresini sonra kim alırsa trafiğinizi o alır
Süresi dolmuş alan adına CNAME	Hedef, kimsenin yenilemediği bir alan adı altındadır	O alan adını kaydeden herkes hedefi denetler

NS delegasyonları bu listenin en ağır durumudur. Devredilen bölgenin denetimi, tek bir web sayfasının değil, o adın altındaki MX, TXT ve doğrulama kayıtları dahil her kaydın denetimi anlamına gelir. Buna karşılık NS delegasyonları daha seyrek görülür ve denetlenmesi kolaydır, çünkü çoğu bölgede dışarıdaki ad sunucularına yapılmış devirler alışılmış bir durum değildir. Bu yüzden bölge dışa aktarımınızdaki her NS kaydını tek tek gözden geçirmek genellikle yalnızca birkaç dakikanızı alır.

Neden önemli

Bir alt alan adında sunulan içerik, kurumunuza ait olan güveni de devralır. Kullanıcılar login.example.com adresini gördüğünde bunun size ait olduğunu varsayar; *.example.com adresine güvenen güvenlik filtreleri ve izin listeleri de o içeriği sorgusuz geçirir. Zararın büyüklüğü, alan adınıza başka nelerin güvendiğine bağlıdır. Bu yüzden etki değerlendirmesine, ele geçirilen sayfadan değil, alan adınıza güvenen sistemlerin listesinden başlamak gerekir.

Kimlik avı: gerçek bir alan adı ve geçerli bir sertifika ile yapılır.
Çerez hırsızlığı: oturum çerezleri Domain=example.com ile ayarlandığında bu çerezler her alt alan adına gönderilir.
CSP ve CORS atlatma: politikalar https://*.example.com adresine izin verdiğinde ortaya çıkar.
OAuth ve yönlendirme kötüye kullanımı: izin verilen yönlendirme adresleri joker alt alan adlarını kapsadığında mümkün olur.
E-posta kötüye kullanımı: sahipsiz MX veya NS kayıtları üzerinden, o addaki adreslere gelen parola sıfırlama postalarını almak dahil.
İtibar kaybı: alan adınızdan zararlı yazılım veya spam sunulduğunda ve adınız kara listelere düştüğünde.

Çerezleri dar kapsamda tutun

Gerçekten alt alan adlarında gerekmedikçe oturum çerezlerini Domain özniteliği olmadan, yani yalnızca o ana özel biçimde ayarlayın. Tek başına bu önlem, bir ele geçirmenin en yıkıcı sonucunu ortadan kaldırır.

Bölgelerinizdeki sahipsiz kayıtları bulmak

Kendi yetkili verinizden başlayın: kullandığınız her DNS sağlayıcısındaki bölge dışa aktarımlarından, başka ekiplerin ve ajansların yönettiği bölgeler dahil olmak üzere. Yalnızca hatırladığınız adları taramak, tam da ele geçirmelere yol açan kayıtları gözden kaçırır. Ardından hedefi sizin denetiminizin dışında kalan her kaydı tek tek kontrol edin.

Tüm bölgeleri dışa aktarın ve her CNAME, NS, MX ve A/AAAA kaydını listeleyin.
CNAME kayıtları için hedefi çözümleyin. Hedefin NXDOMAIN dönmesi ya da kayıtlı olmayan bir alan adı altında bulunması güçlü bir işarettir.
Barındırma sağlayıcılarındaki hedefler için alt alan adını HTTPS ve HTTP üzerinden isteyin ve sağlayıcının "not found" ya da "no such site" sayfasını arayın.
NS delegasyonları için devredilen ad sunucularına doğrudan alt alan adının SOA kaydını sorun; REFUSED veya SERVFAIL yanıtı barındırılan bölgenin silindiğine işaret eder.
Başka alan adları altındaki MX ve CNAME hedefleri için, o alan adlarının hâlâ kayıtlı olup olmadığını WHOIS sorgusu ile kontrol edin.
Bulut IP aralıklarına giden A kayıtları için, IP adresinin hâlâ sizin hesabınıza atanmış olduğunu doğrulayın.

# where does it point?
dig +short CNAME docs.example.com
example-docs.hosting.example.net.

# does the target still exist?
dig +short example-docs.hosting.example.net A
dig example-docs.hosting.example.net A | grep -E 'status: (NXDOMAIN|NOERROR)'

# what does the subdomain serve?
curl -sS -o /dev/null -w '%{http_code}\n' https://docs.example.com/

DNS Sorgulama ve DNS Sorgulama araçları CNAME kaydını ve onun çözümlenmesini ağınızın dışından gösterir; HTTP Başlık Denetleyicisi ise alt alan adının yanıtını ve sunucu başlıklarını gösterir. GitHub üzerinde topluluk tarafından sürdürülen "can-i-take-over-xyz" projesi, hangi sağlayıcıların silinmiş kaynak adlarının yeniden üstlenilmesine izin verdiğini ve bu sağlayıcıların hata sayfalarının nasıl göründüğünü belgeler. Bulduğunuz bir kaydın gerçekten riskli olup olmadığına karar verirken bu liste iyi bir başlangıç noktasıdır.

İşaretler ve anlamları
İşaret	Anlamı	Öncelik
CNAME hedefi NXDOMAIN dönüyor	Hedef silinmiş ya da hiç var olmamış	Yüksek, sağlayıcı tarafında doğrulayın
"no such app" gibi bir sağlayıcı hata sayfası	Kaynak adı büyük olasılıkla sahipsiz	Yüksek
NS delegasyonu REFUSED yanıtı veriyor	Barındırılan bölge büyük olasılıkla silinmiş	Kritik
Hedef, kayıtlı olmayan bir alan adı altında	Bu alan adını isteyen herkes kaydedebilir	Kritik
Kayıt, tanımadığınız çalışan bir siteyi gösteriyor	Ya çoktan ele geçirilmiş ya da bilinmeyen bir proje	Hemen araştırın

Böyle bir kayıt bulduğunuzda

İlk adım, sahipsiz kaydı kaldırmak ya da denetiminizdeki bir hedefe yöneltmektir. Kaydı kaldırmak, birisi kaynağı çoktan üstlenmiş olsun ya da olmasın, önbellekler boşaldığı anda ele geçirmeyi sona erdirir. Kaynağı sağlayıcı tarafında test amacıyla üstlenmeye çalışmayın; onun yerine kendi DNS kaydınızı düzeltin.

DNS kaydını silin ya da düzeltin.
Alt alan adı başkasının içeriğini sunduysa, neyi ne zaman sunduğunu olay müdahale süreciniz için kayıt altına alın.
Alt alan adı için düzenlenmiş sertifikaları tespit edebiliyorsanız, örneğin sertifika şeffaflık günlükleri üzerinden, bunları iptal ettirin.
Çerezler üst alan adı kapsamında ayarlanmışsa açık oturumları geçersiz kılın.
Alt alan adına güvenen izin listelerini, CSP ve OAuth ayarlarını gözden geçirin.
Kaydın nasıl geride kaldığını bulun ve bu sonucu doğuran süreci düzeltin.

Alt alan adı kimlik avı için kullanıldıysa ya da oturum açma sayfaları sunduysa kullanıcılarınıza haber verin. Tarihleri ve ne yapılması gerektiğini, örneğin orada girilen parolaların sıfırlanmasını içeren kısa ve olgusal bir duyuru, zararı sessiz kalmaktan çok daha fazla sınırlar.

Sertifika şeffaflık günlükleri soruşturma için ayrıca değerlidir: herkesçe güvenilen her sertifika bu günlüklere yazılır, bu yüzden sizin alt alan adınız için başkasına düzenlenmiş bir sertifika orada görünür hale gelir. Alan adınız için CT günlüklerini izlemek, henüz fark etmediğiniz ele geçirmeler konusunda da erken uyarı sağlar. Bu izleme ücretsiz servislerle kurulabilir ve haftalarca sürebilecek sessiz bir istismarı günler içinde görünür kılar.

Ele geçirmeleri önlemek

Önce DNS kaydını, sonra kaynağı silin

Bir hizmeti devreden çıkarırken DNS kaydını bulut ya da SaaS kaynağından önce kaldırın ve TTL süresinin dolmasını bekleyin. Sırayı tersine çevirmek, kaydın serbest bir adı gösterdiği ve bazen kalıcı olan bir pencere açar. Bu sırayı runbook'lara ve altyapı kodu süreçlerinize yazın ki kimsenin onu hatırlamak zorunda kalmasına gerek olmasın.

DNS'i kod olarak yönetin

DNS kayıtları, işaret ettikleri altyapıyla aynı depoda durduğunda bir kaynağı ve onun kaydını kaldırmak tek bir değişiklikte gerçekleşir. İnceleme süreci ayrıca birinin dış bir hizmete CNAME eklediğini de görünür kılar ve bu kaydın en baştan bir sahibi olur.

Sağlayıcının alan adı doğrulamasını kullanın

Birçok platform, özel bir alan adını sunmaya başlamadan önce bir TXT kaydıyla sahipliği kanıtlamanızı ister. Bir sağlayıcı bunu destekliyorsa, yeni bir müşteri sizin DNS bölgenizi de denetlemeden alt alan adınızı kendi kaynağına bağlayamaz. Bunu zorunlu tutan sağlayıcıları tercih edin.

Envanter tutun ve sürekli tarayın

Dışarıyı gösteren her kayıt için bir sahip ve bir amaç kaydedin.
Tüm bölgeleri belirli aralıklarla yukarıdaki tablodaki işaretler için tarayın.
CNAME, MX ve NS hedefleri için süresi dolmuş alan adı kontrollerini de ekleyin.
Adlarınız için beklenmedik sertifikalara karşı sertifika şeffaflık günlüklerini izleyin.
Paylaşımlı barındırma platformlarını gösteren joker DNS kayıtlarından kaçının.

Alan adı taşımaları ve tedarikçi değişiklikleri, sahipsiz kayıtların en sık oluştuğu anlardır. Alan adı taşıma kontrol listesi temizlik adımını da içerir; CSP rehberi ise joker alt alan adı izin listelerinin neden ikinci bir bakışı hak ettiğini anlatır. Her iki durumda da temizliği tek bir kişiye bağlayın; sırayı bilen birinin listesinde durmayan adım, uygulamada hiç yapılmamış sayılır.

Taramayı otomatikleştirmek

Bölge dışa aktarımlarınıza karşı haftada bir çalıştırılan küçük bir betik, sahipsiz CNAME kayıtlarının çoğunu yakalar. Betik her hedefi çözümler ve artık var olmayanları işaretler. Hiçbir şeyi üstlenmek için istek göndermez ve sıradan DNS sorgularının ötesinde başkalarının sistemlerini yoklamaz. Betiği sürüm kontrolünde tutmak ve çıktısını bir ekip kanalına göndermek, bu kontrolün zamanla unutulup gitmesini de engeller.

import dns.resolver

records = [
    ("docs.example.com", "example-docs.hosting.example.net"),
    ("status.example.com", "example.status.example.org"),
]

resolver = dns.resolver.Resolver()
resolver.lifetime = 5
for name, target in records:
    try:
        resolver.resolve(target, "A")
        state = "ok"
    except dns.resolver.NXDOMAIN:
        state = "DANGLING: target does not exist"
    except dns.resolver.NoAnswer:
        state = "check: target has no A record"
    except dns.exception.DNSException as error:
        state = f"check: {error.__class__.__name__}"
    print(f"{name:<28} -> {target:<40} {state}")

Çözümlenen bir hedef kendiliğinden güvenli sayılmaz, çünkü birçok platform kendi alan adı altındaki her ada yanıt verir ve sahipsiz olanlar için bir hata sayfası gösterir. Taramayı, her alt alan adına yapılan bir HTTP isteğiyle ve kullandığınız sağlayıcıların hata sayfası metinlerinden oluşan bir listeyle genişletin. Her bulguyu, kaydın sahibine düşen bir iş kaydı olarak ele alın. Böylece tarama, gerçekten silinmiş hedefleri ve yalnızca sahipsiz görünen adları aynı raporda toplar.

Önizleme ortamları ve joker kayıtlar

Modern yayın süreçleri kısa ömürlü ortamlar oluşturur; örneğin her pull request için pr-123.preview.example.com adresinde bir önizleme sitesi. Süreç DNS kayıtlarını otomatik olarak oluşturuyorsa, ortam yok edildiğinde bu kayıtları kaldırması da gerekir; bir iş yarıda kaldığında da aynısı geçerlidir. Aksi halde kayıtlar, hiçbir elle incelemenin yetişemeyeceği bir hızla birikir. Bu yüzden ortamı yaratan ve yok eden adımların aynı otomasyonda ve aynı sahibin altında durması gerekir.

Paylaşımlı bir platformu gösteren *.preview.example.com gibi joker kayıtlar, ortam başına kayıt tutma zorunluluğunu ortadan kaldırır ama kendi riskini taşır: joker kaydın altındaki her ad, siz onun için bir kaynak oluşturmuş olsanız da olmasanız da platforma işaret eder. Joker kayıtları yalnızca özel host'lar için alan adı sahipliği doğrulamasını zorunlu tutan platformlarda kullanın ve onları ana alan adınızda değil, bu işe ayrılmış bir alt alan adında tutun. Ayrı bir alt alan adı, bir sorun çıktığında etkinin sınırını da baştan çizmiş olur.

Sorun kimin sorumluluğunda

Ele geçirmeler ekiplerin arasındaki boşlukta durur: DNS'i genellikle altyapı ya da BT ekibi yürütür, oysa iptal edilen hizmet pazarlamaya, dokümantasyona veya bir ürün ekibine aitti. Kimse kendi oluşturmadığı bir kayıttan sorumlu hissetmez. Dışarıyı gösteren her kayda bir sahip atamak ve DNS temizliğini herhangi bir tedarikçi sözleşmesinin sonlandırılmasının parçası haline getirmek bu boşluğu kapatır.

Dış kayıtların tutulduğu hafif bir kütük pratikte iyi işler: kayıt adı, hedef, hizmet, sahip ekip ve kaydı doğuran sözleşme ya da iş kaydı. Bir sözleşme sona erdiğinde satın alma birimi veya hizmet sahibi, listedeki kayıtların kaldırılmasını başlatır. Bu kütük ayrıca her olayın ilk sorusunu da yanıtlar: bu addan kim sorumlu?

Güvenlik ekipleri düzenli taramalarla ve sahipsiz kayıtları bir önem derecesi ve bir son tarihi olan zafiyetler gibi ele alarak katkı sunabilir. Ödül avcılığı programları her yıl çok sayıda ele geçirme bildirir; bu da hem sorunun ne kadar yaygın olduğunu hem de önlemenin, kendi alan adınızda çıkan bir kimlik avı olayını yönetmeye kıyasla ne kadar ucuz olduğunu gösterir. Bu karşılaştırmayı bir kez yaptığınızda, düzenli taramaya ayrılan zamanın gerekçesini yönetime anlatmak da kolaylaşır.

SSS

Subdomain takeover bulut sağlayıcısındaki bir zafiyet midir?

Genellikle alan adı sahibinin tarafındaki bir yapılandırma sorunudur: bir DNS kaydı, artık sahip olunmayan bir kaynağı göstermektedir. Sağlayıcılar alan adı doğrulamasıyla riski azaltabilir, ama güvenilir çözüm sahipsiz kayıtları kaldırmaktır.

Ele geçirme ana alan adını da etkileyebilir mi?

Ana siteyi doğrudan etkilemez; ancak üst alan adı kapsamında ayarlanmış çerezler, tüm alt alan adlarına güvenen CSP veya CORS kuralları ve kullanıcıların alan adına duyduğu güven bir alt alan adı üzerinden kötüye kullanılabilir.

DNSSEC subdomain takeover'ı engeller mi?

Hayır. DNSSEC kayıtlarınızın bütünlüğünü korur, ama sahipsiz kayıt aslında meşru ve doğru imzalanmış bir kayıttır; yalnızca artık başkasının denetimindeki bir kaynağı göstermektedir.

Sahipsiz kayıtları ne sıklıkla taramalıyım?

Çok sayıda bölgesi ve tedarikçisi olan kurumlarda sürekli ya da en azından haftada bir; ayrıca her hizmet devreden çıkarma ve DNS taşıma işleminden sonra mutlaka.

A kayıtları ele geçirmeye karşı güvenli midir?

Daha güvenlidir ama güvenli değildir. Serbest bırakılmış bir bulut IP adresini gösteren bir A kaydı, o adresi sonra kim alırsa trafiği ona gönderir.

Ele geçirme kök alan adında olabilir mi?

Nadiren, çünkü apex kaydı CNAME olamaz. Serbest bırakılmış bulut IP adreslerini gösteren apex kayıtlarında ya da alan adının tüm ad sunucuları süresi dolmuş bir alan adında bulunduğunda gerçekleşebilir.

Tedarikçi ayrılma kontrol listesinde neler olmalı?

Tedarikçiyi gösteren DNS kayıtlarını kaldırın, kullandıkları DKIM anahtarlarını ve SPF include ifadelerini iptal edin, doğrulama TXT kayıtlarını silin, host'larını adıyla anan izin listelerini ve OAuth ayarlarını kontrol edin.

Kaynağı kendim üstlenerek test etmeli miyim?

DNS kaydınızı kaldırmak ya da düzeltmek doğru çözümdür ve bunun için bir test üstlenmesi gerekmez. Bir ele geçirmeyi kanıtlamak üzere sağlayıcıda kaynak oluşturmak, sağlayıcının kurallarını gözeten yetkili güvenlik testlerine bırakılmalıdır.

Kaynaklar

Araçlar

DNS Sorgulama DNS kayıtlarını türe göre sorgulayın; IP adresleri için ters (PTR) sorgular dahil.
WHOIS Sorgulama Bir alan adını kimin kaydettiğini, ne zaman sona erdiğini ve hangi ad sunucularını kullandığını görün.
HTTP Başlıkları Bir sitenin güvenlik başlıklarını ve çerezlerini notlandırın, eklenecek başlık satırlarını alın ve aynı kontrolün onayladığı bir Content-Security-Policy oluşturun.

Rehberler

Domain migration checklist: DNS, email, TLS and redirects A step-by-step checklist for moving DNS providers, transferring registrars, switching mail hosts or renaming a domain without downtime or lost mail.
Content Security Policy without breaking your site Build a CSP that stops injected scripts: report-only rollout, nonces and strict-dynamic, the directives that matter, and fixing violations step by step.
DNS Lookup guide How DNS resolution works, what each record type in the XGM DNS Lookup means, how to read the findings and how to troubleshoot common DNS problems.
DNSSEC: should you turn it on, and how What DNSSEC protects against, how the chain of trust works, which algorithms to choose, and a safe path to signing a zone without taking it offline.