← Bloga dönRehberler

Subdomain Takeover Nedir? Alt Alan Adı Ele Geçirme ve Önlemi

Subdomain takeover (alt alan adı ele geçirme) nedir, nasıl olur? Sahipsiz CNAME, NS, A ve MX kayıtları nasıl kötüye kullanılır, nasıl bulunur ve önlenir?

Yayınlanma: · 7 dk okuma

Subdomain takeover (alt alan adı ele geçirme), zone'unuzdaki bir DNS kaydının artık denetiminizde olmayan dış bir kaynağı göstermeye devam etmesi ve o kaynağı bir başkasının sahiplenmesiyle gerçekleşir. Tipik örnek: magaza.example.com hazır bir platforma CNAME ile bağlıdır, mağaza iptal edilmiş, kayıt yerinde kalmıştır. Platform, boşa çıkan adı alan adı üzerindeki denetimi kanıtlatmadan herkese veriyorsa saldırgan o adı alır ve geçerli bir sertifikayla birlikte kendi içeriğini sizin alt alan adınızda yayınlar. Çözüm sıkıcı ama etkilidir: hangi kayıtların altyapınızın dışını gösterdiğini bilin ve DNS kaydını, gösterdiği şeyi silmeden önce kaldırın. Bu yazıda saldırının türlerini, etkisini, dig ve curl ile tespitini ve bir önlem listesini bulacaksınız.

Subdomain takeover nasıl olur?

Alışıldık anlamda hiçbir şey "hack'lenmez". DNS'iniz doğru olarak ve sizin yetkinizle "bu ad şurada sunuluyor" der. "Şurası" ise bir sağlayıcının bütün müşterileriyle paylaşılan bir ad alanıdır. Sıra şöyle işler:

  1. Bir bulut ya da SaaS sağlayıcısında bir kaynak oluşturursunuz (depolama alanı, platform uygulaması, destek masası ya da açılış sayfası sitesi) ve bir alt alan adını CNAME ile ona bağlarsınız.

  2. Bir süre sonra kaynak silinir: proje bitmiş, abonelik iptal edilmiş, hesap kapatılmıştır.

  3. CNAME zone'da kalır. Sahibi yoktur, kimseye bir şey hatırlatmaz. Buna sahipsiz (dangling) kayıt denir.

  4. Sağlayıcı eski kaynak adını yeniden kullanıma açar ve ona işaret eden alan adının kimin denetiminde olduğuna bakmaz.

  5. Saldırgan o adı kaydeder. O andan sonra alt alan adınız saldırganın içeriğini sunar.

  6. adımın mümkün olup olmadığı sağlayıcıya bağlıdır. Birçoğu artık doğrulama için TXT kaydı istiyor ya da bırakılan adları rezerve ediyor. Buna güvenmeyin: bir ajansın yıllar önce bağladığı her hizmetin politikasını çoğu zaman bilmezsiniz.

Saldırının türleri

Sahipsiz kayıt Saldırgana gereken Eline geçen
Silinmiş bulut/SaaS kaynağına CNAME Sağlayıcıda aynı kaynak adını almak Alt alan adında web içeriği
Alan adının süresi dolmuş bir hedefe CNAME O alan adını kaydetmek O CNAME hedefinin altındaki her şey
Zone'un silindiği bir DNS sağlayıcısına ya da süresi dolmuş bir alan adının altındaki nameserver'lara yapılmış NS delegasyonu Zone'u o sağlayıcıda oluşturmak ya da nameserver'ın alan adını kaydetmek Alt zone'un tam denetimi: her kayıt türü, altındaki her ad. En kötü durum
Bırakılmış bir bulut IP adresine A kaydı Aynı IP adresinin kendisine atanması: şans ve tekrar işi Web içeriği; hedefli değil fırsatçı bir saldırı
Kapatılmış bir e-posta hizmetine MX kaydı Alan adını o e-posta hizmetinde sahiplenmek Alt alan adına gelen e-postalar

Bozulmuş bir sayfadan neden daha ciddi?

Alan adınızın bir alt alan adı, benzer görünümlü sahte bir alan adının asla elde edemeyeceği bir güveni devralır:

  • Gerçek adınız altında oltalama. giris-destek.example.com, "adres çubuğuna bakın" eğitimlerinin hepsinden geçer.
  • Çerezler. Domain=example.com ile konmuş çerezleri tarayıcı, saldırganın işlettiği dahil bütün alt alan adlarına gönderir. Çerezin özniteliklerine göre buna oturum çerezleri de dahil olabilir.
  • *.example.com adresine güvenen izin listeleri. CORS ayarları, Content Security Policy kaynakları, OAuth yönlendirme adresleri ve tek oturum açma ayarları sıkça alan adının tamamına güvenir. Ele geçirilmiş alt alan adı bu güvenin içindedir.
  • Herkesçe güvenilen sertifikalar. Bir host adının içeriğini denetleyen kişi HTTP tabanlı alan adı doğrulamasını geçebilir ve o ad için geçerli bir sertifika alabilir.
  • E-posta. Sahipsiz bir MX kaydında alt alan adına gönderilen postalar saldırgana teslim edilir; o adreslerle açılmış hesapların parola sıfırlama e-postaları da buna dahildir.

Sahipsiz DNS kayıtları nasıl bulunur?

Dışarıdan değil, zone'unuzdan başlayın. Elinizdeki bütün zone'ları dışa aktarın ve hedefi kendi altyapınız olmayan kayıtları listeleyin: başka alan adlarına giden CNAME'ler, NS delegasyonları, MX kayıtları ve bulut sağlayıcılarının adres aralıklarındaki A/AAAA kayıtları.

Sonra her birini sınayın.

CNAME kayıtları. Hedefi çözümleyin. Var olmayan bir hedef en açık işarettir:

$ dig +short CNAME magaza.example.com
promo-example.cloudhost.example.

$ dig promo-example.cloudhost.example
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4711

Hedef için NXDOMAIN dönmesi, kaydın hiçbir şeyi göstermediği anlamına gelir. Hedef çözümleniyorsa (birçok platform wildcard ile her ada cevap verir) HTTP cevabına bakın:

$ curl -sI https://magaza.example.com | head -n 1
HTTP/2 404

Alt alan adınızda sağlayıcının genel "böyle bir site yok", "böyle bir depolama alanı yok" ya da "burada henüz bir şey yok" sayfasının çıkması, arkadaki kaynağın gittiğini gösterir. Ayrıca her CNAME hedefinin alan adının hâlâ kayıtlı olduğunu ve beklediğiniz sağlayıcıya ait olduğunu kontrol edin.

NS delegasyonları. Delege edilen her nameserver'a doğrudan, özyineleme istemeden, alt zone için yetkili olup olmadığını sorun:

$ dig +short NS sub.example.com
ns1.dns-host.example.
ns2.dns-host.example.

$ dig @ns1.dns-host.example sub.example.com SOA +norec
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 1289

REFUSED, SERVFAIL ya da aa bayrağı taşımayan bir cevap, o sunucunun zone'unuzu tutmadığını gösterir. Hiç cevap gelmemesi ağ sorunu da olabilir: sonuca varmadan önce sınamayı tekrarlayın. NXDOMAIN dönen bir nameserver adı görürseniz o adın alan adının süresinin dolup dolmadığına bakın.

Unuttuğunuz adlar. Zone dökümü kayıtları bulur; sahip olduğunuzu unuttuğunuz zone'ları ya da başka bir ekibin başka bir DNS sağlayıcısında açtığı adları bulmaz. Burada Certificate Transparency kayıtları işe yarar: herkesçe güvenilen her sertifika bu kayıtlara işlenir, dolayısıyla bir zamanlar sertifika almış host adlarını ortaya çıkarırlar. İstemediğiniz sertifikaları da gösterirler; bir ele geçirmenin geride bıraktığı iz budur.

Subdomain takeover nasıl önlenir?

İşlem sırası. Vakaların çoğunu tek başına şu kural önler:

  • Kapatırken: önce DNS kaydını kaldırın, TTL süresinin geçmesini bekleyin, kaynağı sonra silin.
  • Kurarken: önce kaynağı oluşturup doğrulayın, DNS kaydını en son ekleyin.

Kayıtların sahibi olsun. DNS değişikliklerini gözden geçirmeyle, mümkünse kod olarak altyapı (infrastructure as code) yaklaşımıyla ve gösterdiği kaynakla aynı depoda yapın; böylece kaynağı silmek ile kaydı silmek tek bir değişiklik olur. En azından dışarıyı gösteren her kayıt için kimin, neden istediğini not edin.

Düzenli denetleyin. Yukarıdaki sınamaları belirli aralıklarla çalıştırın. Bir ajansla ya da SaaS ürünüyle yolların ayrılması da denetim sebebidir.

Alan adı doğrulayan sağlayıcıları seçin. Özel alan adını sunmadan önce doğrulama için TXT kaydı isteyen bir sağlayıcı, bir yabancı tarafından bu saldırıda kullanılamaz.

Üçüncü taraflara wildcard CNAME vermeyin. *.example.com CNAME birsey.provider.example kaydı, olası her adı aday hâline getirir. Bkz. wildcard DNS kayıtları.

Bir alt alan adının yapabileceklerini sınırlayın. Oturumlar için host'a özel çerez (Domain özniteliği olmadan) kullanın. CORS, CSP ve OAuth yönlendirme izin listelerinde *.example.com yerine tam origin'leri yazın.

CAA'nın ne yapıp ne yapmadığını bilin. CAA kaydı, adlarınız için hangi sertifika otoritelerinin sertifika verebileceğini kısıtlar. Ele geçirmeyi durdurmaz: saldırgan izin verdiğiniz otoritelerden birini kullanır. Alanı daraltır ve izlemeyi kolaylaştırır, o kadar. Ayrıntı: CAA kaydı nedir.

Certificate Transparency kayıtlarını izleyin; alan adınız için sizin tarafınızda kimsenin istemediği sertifikaları arayın.

Kontrol listesi

  • Bütün DNS sağlayıcılarındaki bütün zone'lar biliniyor ve dökümü alınmış.
  • Her CNAME, NS, MX ve bulut IP'li A/AAAA kaydının adı belli bir sahibi ve amacı var.
  • Dışarıyı gösteren her CNAME hedefi çözümleniyor ve alan adı beklenen sağlayıcıya kayıtlı.
  • Delege edilmiş her alt zone'a bütün nameserver'ları yetkili cevap veriyor.
  • Kapatma prosedüründe "önce DNS kaydı, sonra kaynak" yazıyor.
  • Üçüncü tarafa işaret eden wildcard CNAME yok.
  • Oturum çerezleri host'a özel; izin listelerinde tam host adları var.
  • CT kayıtları bilinmeyen host adları ve beklenmeyen sertifikalar için gözden geçiriliyor.

Bir tane bulduysanız

  1. Sahipsiz kaydı hemen kaldırın (hizmet hâlâ gerekiyorsa önce kaynağı kendi hesabınızda yeniden oluşturun). Kayıt kalkınca, önbellekler boşalır boşalmaz açık kapanır.
  2. Daha önce sahiplenilmiş mi, öğrenin. Alt alan adı şu anda ne sunuyor? Denemek için kimlik bilgisi girmeyin.
  3. Sahiplenilmişse: üst alan adına kapsanan çerezleri açığa çıkmış sayın ve oturumları geçersiz kılın. Bu alt alan adını içeren izin listelerini gözden geçirin.
  4. CT kayıtlarına bakın; açık kaldığı sürede o ad için verilmiş sertifikaları bulun ve sizin istemediklerinizin iptalini sertifikayı veren otoriteden isteyin.
  5. Kaydı geride bırakan süreci düzeltin, sonra zone'un kalanını denetleyin: sahipsiz kayıtlar nadiren tek başına gelir.

Etik ve hukuk

Yalnızca sorumlusu olduğunuz ya da değerlendirmek için yazılı yetki aldığınız alan adlarını sınayın. Açık DNS'i sorgulamak zararsızdır. Başkasının sahipsiz kaydının arkasındaki kaynağı sahiplenmek ise başka bir eylemdir: onların adı altında içerik sunmuş, belki de kullanıcılarının çerezlerini ya da e-postalarını almış olursunuz. Zararsız bir "kanıt" sayfası ve iyi niyetle bile bu, yetkisiz erişimdir. Size ait olmayan bir alan adında sahipsiz kayıt fark ederseniz durumu sahibine security.txt dosyasındaki iletişim adresinden bildirin (security.txt kontrol aracı böyle bir dosyanın yayınlanıp yayınlanmadığını gösterir) ve orada durun.

Sık yapılan hatalar

  • Önce bulut kaynağını silip "DNS'i sonra temizleriz" demek.
  • Sağlayıcının aynı adı başkasına vermeyeceğini varsaymak.
  • Yalnızca ana zone'u denetleyip delege edilmiş alt zone'ları ve ikinci DNS sağlayıcısındaki zone'ları unutmak.
  • CORS, CSP ya da OAuth ayarlarında *.example.com adresine güvenmek.
  • CAA kaydının ele geçirmeyi önlediğini sanmak.
  • CNAME ya da NS hedefindeki süresi dolmuş bir alan adını başkasının sorunu saymak.
  • Üçüncü bir tarafın alan adındaki bulguyu, kaynağı sahiplenerek "kanıtlamak".

OrbitProbe ile kontrol edin

OrbitProbe subdomain bulucu, bir alan adının açık Certificate Transparency kayıtlarında geçen alt alan adlarını, her biri için en son sertifika tarihiyle listeler. Bu bir DNS dökümü değil, sertifika kaydıdır: listedeki bir ad artık var olmayabilir, yalnızca wildcard sertifika kullanmış bir ad ise listede hiç görünmez; yani zone dökümünün yerini tutmaz, onu tamamlar. Sorumlusu olduğunuz alan adlarında unutulmuş host'ları ve kimsenin sipariş ettiğini hatırlamadığı sertifikaları fark etmek için kullanın; tanımadığınız her adın bugün nereyi gösterdiğini de bir DNS sorgusuyla kontrol edin. İlgili kayıt türleri DNS kayıt türleri yazısında anlatılıyor.