Subdomain Takeover Nedir ve Nasıl Önlenir?

Bir geliştirici, artık kullanılmayan bir Heroku uygulamasını hesabından siler. DNS paneline bakmaz; nedenine gerek yoktur, uygulama kapanmıştır. Birkaç hafta sonra şirketin staging subdomain'i başka birinin kontrolündedir ve buradan gerçeğe benzer bir giriş sayfası yayınlanmaktadır.

Subdomain takeover (alt alan adı ele geçirme), çoğu ekibin fark etmeden taşıdığı bir DNS güvenlik sorunudur. Teknik olarak karmaşık değildir; gereken tek şey sahipsiz kalan bir CNAME kaydı ve bu kaydın işaret ettiği servis adını talep edecek biridir.

Tehdidin bu kadar yaygın olmasının nedeni açıktır: servisi kapatmak ile DNS kaydını kaldırmak, pek çok kuruluşta birbirinden kopuk iki ayrı işlemdir; zone denetimi kayıt izlemeyle bu boşluğu kapatır. Uygulamayı kapatan geliştirici DNS paneline girmez; DNS yöneticisi ise hangi kaydın hangi servise bağlı olduğunu bilmez. Bu boşlukta kayıtlar aylarca, bazen yıllarca sahipsiz kalır.

CNAME Kaydı "Askıda" Kaldığında Ne Olur?

CNAME (Canonical Name) kaydı, bir alan adını başka bir alan adına yönlendirir. staging.sirketiniz.com için yourapp.herokuapp.com hedefli bir CNAME oluşturduğunuzda, ziyaretçi bu adrese gittiğinde Heroku'daki uygulamanıza ulaşır. Sistem çalıştığı sürece her şey yolundadır.

Heroku uygulamasını silince yourapp.herokuapp.com adresi Heroku tarafından serbest bırakılır. Platform bu ismi ilk talep eden hesaba tahsis eder. CNAME kaydınız hâlâ yerindeyse, staging.sirketiniz.com artık bu yeni uygulamayı gösterir. Tarayıcıda hata yoktur; DNS zinciri eksiksiz çalışır, ancak içerik artık size ait değildir.

Bu duruma "dangling CNAME" (sarkan CNAME) denir. DNS çözümlemesi hata üretmez; hedef değişmiş olsa da yönlendirme zinciri geçerlidir. Sorun teknik katmanda değil, yetki katmanındadır. Ziyaretçinin tarayıcısı CNAME kaydını okur, hedefe gider ve oradan yanıt alır; bu yanıtın kime ait olduğunu kimse sorgulamaz.

Heroku Senaryosu: Silinen Uygulama, Kalan Kayıt

Heroku, uygulama adlarını birinci gelen alır ilkesiyle tahsis eder. yourapp.herokuapp.com adını siz kullanırken bu isim size ayrılmıştır; siz silince serbest kalır ve başkası aynı adı kendi hesabına ekleyebilir. Platforma göre bu işlem dakikalar içinde tamamlanabilir.

Saldırganın bunu yapabilmesi için ücretsiz bir Heroku hesabı yeterlidir. Platform, alınan uygulama adının hangi domain'i etkilediğini kontrol etmez; yalnızca ismin müsait olup olmadığına bakar. Domain sahipliği doğrulaması yoktur, onay süreci yoktur.

Benzer riskleri beraberinde getiren ad tabanlı tahsis modeli statik site platformlarında da geçerlidir. Vercel ve Netlify'da custom domain yapılandırması konusunu ele aldığımız yazıda, bu platformlarda servis kaldırıldığında DNS kaydının nasıl yönetilmesi gerektiği de tartışılmaktadır.

Heroku bu konuyu uzun süre ele almayan platformlardan biri oldu. Aynı sorun GitHub Pages proje adlarında, AWS S3 bucket adlarında, Azure App Service endpoint'lerinde ve Fastly servis başlıklarında da belgelenmiştir. Wildcard sarkan kayıtları wildcard DNS ile daha da genişletir. Ortak nokta her zaman aynıdır: isim tahsisi açık, domain sahipliği doğrulaması eksik.

Bir Saldırgan Bu Fırsatla Ne Yapabilir?

En doğrudan senaryo kimlik avıdır (phishing). Saldırgan staging.sirketiniz.com adresine gerçeğine benzer bir giriş sayfası koyar. Çalışanlar ya da müşteriler bu adresi tanıdık bulur; adres çubuğu doğru domain adını gösterdiğinden kuşku uyandırmaz. Kolay, düşük maliyetli, yüksek etki.

Oturum çerezleri ayrı bir risktir. Tarayıcılar, üst domain için ayarlanmış çerezleri Secure ve HttpOnly nitelikleri eksikse ya da SameSite politikası eski bir yapılandırmada kaldıysa alt alan adlarından okuyabilir. Bu durumda saldırganın kontrolündeki subdomain, geçerli oturum çerezlerine erişme imkânı bulur.

Zararlı yazılım dağıtımı da seçenekler arasındadır. Eski belgelerinizde, üçüncü taraf sitelerde ya da arama motoru önbelleklerinde o subdomain adresine işaret eden bağlantılar bulunabilir; bu bağlantılar üzerinden indirme sayfaları yayınlanabilir. Bağlantının kaynağı kaynak kodunuzdaki belgeler olduğunda içerik güvenilir görünür.

Marka zararı ayrı bir boyuttur. Şirket adını taşıyan bir domain üzerinden yayınlanan içerik doğrudan sizi işaret eder; kimin yaptığını ispat etmek zaman alır ve bu süre içinde itibar kaybı gerçekleşir.

Hangi Platformlar Risk Taşır?

Risk, ad tabanlı açık tahsis modeliyle çalışan tüm platformlarda vardır. Bu modelde bir isim serbest kalınca herkes talep edebilir; platform, yeni kullanıcı ile eski domain sahibi arasında doğrulama ilişkisi kurmaz.

Sık karşılaşılan risk alanları: Heroku uygulama adları, GitHub Pages proje adları, AWS S3 bucket adları, Azure web app adları ve Fastly servis başlıkları. Bu platformlara bağlı oluşturduğunuz CNAME kaydı servis hesabınıza dayanır; hesabı kapattığınızda veya servisi sildiğinizde kayıt sahipsiz kalır.

AWS S3 bucket takeover özellikle dikkat gerektiren bir senaryodur. S3 CNAME hedefi bucket adını ve bölgeyi içerdiğinden saldırgan, boşalan bucket adını aynı bölgede oluşturabilir ve trafiği doğrudan kendi bucket'ına çekebilir. Bölge bilgisi hedef URL'de açıkça görünür.

Kendi sunucunuzu gösteren CNAME ve A kayıtları bu kapsamın dışındadır; sunucuyu siz yönettiğinizden devralma riski yoktur. DigitalOcean üzerinde subdomain yönetimi yapıyorsanız, hangi CNAME kaydının harici bir platforma bağlı olduğunu kayıt açıklamalarıyla etiketlemek ilerideki temizlik sürecini kolaylaştırır.

Askıda CNAME Kaydını Nasıl Tespit Edersiniz?

DNS panelindeki tüm CNAME kayıtlarını listeleyip her birinin hedefini sorgulamak ilk adımdır. Hangi kayıt nereye gidiyor, bu hedef hâlâ aktif mi? Kısa listeler için elle yürütülebilir; uzun listeler otomasyonu zorunlu kılar.

nslookup staging.sirketiniz.com

NXDOMAIN yanıtı geliyorsa hedef çözümlenmiyordur; kayıt askıdadır ama devralma henüz gerçekleşmemiştir. Geçerli bir IP dönüyorsa ve bu IP sizin sunucunuza ait değilse, durum daha acildir. Heroku özelinde şu sorgu ek bilgi verir:

curl -I https://yourapp.herokuapp.com

Heroku'nun standart "No such app" sayfası yerine gerçek uygulama içeriği dönüyorsa, o isim başkasına geçmiştir. Zone dosyasını dışa aktarıp her CNAME hedefine programlı HTTP isteği göndermek, büyük kayıt listelerinde işi otomatikleştirir; beklenmedik içerik veya platform hata sayfası dışında yanıt dönen kayıtları işaretleyip incelirsiniz.

Göz ardı edilen bir durum şudur: bazı platformlar uygulamanın mevcut olmadığını belirten özel bir hata sayfası döndürür. Bu yanıt, o ismin henüz müsait olduğunu gösterir ve devralma için uygun bir pencereye işaret eder. Yalnızca NXDOMAIN dönen kayıtlar değil, platform bazında tanınan "boş uygulama" yanıtları da risk listesine alınmalıdır.

Düzeltme: Hangi Adım Önce Gelir?

Hemen kaldırın. Askıda bir CNAME buldunuz ve bu subdomain artık gerekmiyorsa, DNS panelinden kaydı silin. Başka hiçbir adım bu kadar hızlı etkili değildir.

TTL süresi burada belirleyicidir. Kaydın mevcut TTL değeri ne kadardı? Bu süre dolduğunda çözücüler önbelleği atar ve artık çözümleme yapmaz. Yayılım (propagation) süresi boyunca bazı çözücüler eski yanıtı döndürmeye devam edebilir; bunu kısaltmak için kaydı önceden düşük TTL'e çekmek işe yarar, ancak acil müdahalede bu lükse çoğu zaman sahip olunmaz.

1. DNS panelinden CNAME kaydını kaldırın.
2. Mevcut TTL değerini not edin; propagation bu süre kadar sürebilir.
3. Subdomain üzerinden oturum veya kimlik doğrulama akışı geçiyorsa ilgili token'ları geçersiz kılın.
4. Kaydın ne zamandan beri sahipsiz olduğunu araştırın; bu süreye göre olası maruz kalma değerlendirmesi yapın.

Devralma gerçekleşmişse kaydı silmek domain'inizden gelen trafiği hemen keser. Saldırganın içeriği başka bir adreste yayınlamaya devam etmesi mümkündür; ancak sizin domain'inizden akan trafik artık ona ulaşmaz.

Subdomain'i yeniden kullanmak istiyorsanız servisi yeniden oluşturun ya da platforma custom domain bölümünden sahipliği doğrulayın. Bu doğrulama adımı aradaki yetkisiz sahipliği ortadan kaldırır ve CNAME kaydınız doğru hedefe bağlanır.

Servis Kapatma Protokolüne DNS Adımını Dahil Edin

Sorun çoğunlukla teknik değil, süreçseldir. Geliştirici uygulamayı siler; DNS adımı kimsenin listesinde yoktur. Çözüm de bellidir: servis kaldırma adımlarına DNS temizliğini eklemek.

• Bu servise ait CNAME kayıtlarını DNS panelinde bulun; hedef adrese göre arama yapın.
• Bu subdomain'lerin aktif trafik alıp almadığını kontrol edin.
• Gerekli değilse kaydı silin; başka bir hedefe taşınması gerekiyorsa önce yeni kaydı ekleyin, sonra eskiyi kaldırın.
• Silme tarihini, hangi kaydın kaldırıldığını ve işlemi yapanı bir ticket veya değişiklik logu olarak kayıt altına alın.

Periyodik denetim bu önlemi tamamlar. Mevcut CNAME kayıtlarını ayda bir gözden geçirmek kaçak kayıtları yakalar. Her CNAME hedefine DNS sorgusu gönderip NXDOMAIN dönenlerini işaretleyen basit bir script, manuel takibin sürüklendiği noktalarda fark yaratır.

Birden fazla geliştirici ve DNS yöneticisi olan ekiplerde bu protokolü onboarding belgelerine eklemek kalıcı bir çözümdür. Domain portföyü yönetimi kapsamında önerilen denetim alışkanlıkları burada doğrudan uygulanabilir; özellikle büyük portföylerde her kaydın hangi servise bağlı olduğunu merkezi bir sistemden takip etmek kör noktaları azaltır.

Bazı platformlar ek bir güvence olarak domain sahipliği doğrulama sunar. Custom domain eklemeden önce DNS üzerinde platforma özgü bir TXT kaydı oluşturmanız istenir; bu kayıt başka hesapların aynı domain'i talep etmesini engeller. Azure App Service ve Google Cloud Run bu modeli destekler. Doğrulama TXT kaydı sahipsiz kalsa bile CNAME gibi devralma riski taşımaz; geçerliliğini yitirmiş eski bir kayıt olarak kalır, tehdit oluşturmaz.

Subdomain takeover, başlangıçta küçük bir teknik ihmal gibi görünür: kaldırılan bir uygulamanın ardında unutulan birkaç satır DNS verisi. Bu ihmalin bir güvenlik açığına dönüşmesi için saldırgana özel bir yetenek gerekmez; yalnızca hangi servis adının müsait olduğunu bilen biri yeterlidir.

DNS kayıt listenizi temiz tutmak bu riski büyük ölçüde engeller. Servis kapatma sürecine DNS adımını dahil etmek ekstra bir yük değildir; zaman içinde ekip genelinde rutin bir kontrol hâline gelir.

Kayıt silme eylemi hiçbir zaman ekleme eyleminden daha karmaşık değildir, ancak çoğu zaman geri planda kalır. O adımı ön plana çıkarmak takeover riskini neredeyse sıfıra indirir.