Subdomain devralmaları iyi belgelenmiş bir güvenlik yanlış yapılandırmasıdır. Yaygın farkındalığa rağmen, geliştiriciler hala unutulmuş ve kullanılmayan üçüncü taraf hizmetlere işaret eden DNS kayıtlarını kaldırmayı unutuyor ve bu güvenlik açıklarının bugün bile mevcut olmasına izin veriyor.
Bu makalede, alt alan altındaki devralma güvenlik açıklarının ne olduğunu öğreneceğiz, bunları nasıl tanımlayacağınız (ve vulnerne edilemeyen vakaları ayırt edeceğiniz) ve ayrıca ilk bulgunuzu yükseltmenize yardımcı olacak neredeyse tüm olası sömürü vektörlerini belgeleyeceğiz.
Hadi dalalım!
Alt alan devralma güvenlik açıkları nelerdir
Şirketler genellikle üçüncü taraf hizmetlerini tercih ederler çünkü birçok fayda sağlarlar: geliştirme süresini ve maliyetlerini azaltırlar, özel endüstri uzmanlığına sahip satıcılardan gelirler ve düzenli güncellemelerle sürekli iyileşirler. Satıcılar, çeşitli kişiselleştirme ve markalaşma seçenekleri sunarak müşteri ihtiyaçlarına uyum sağlar. Bu özelleştirme özellikleri, logo yerleşiminden özel stil sayfalarına ve temalara kadar değişir ve hatta şirketlerin kendi alt alanlarını üçüncü taraf hizmetine yönlendirmelerine olanak tanır.
Özel alan adlarını bağlama imkanı sağlayan bir yazılım satıcısı örneği
Subdomain devralma güvenlik açıkları, şirketin alt alanlarından biri artık var olmayan bir üçüncü taraf bir hizmete işaret ettiğinde meydana gelir ve bir saldırganın alt alanda görünenleri hizmeti ve kontrol ettiğini iddia etmesine izin verir.
Alt alan devralma güvenlik açıklarını belirleme
Ancak, kayıp bir üçüncü taraf hizmeti talep etmeden önce, aşağıdaki koşulları karşılamalısınız:
Üçüncü taraf hizmeti (AWS S3 gibi) Kayıt sırasında alan doğrulaması gerektirmemelidir.
Üçüncü taraf hizmeti Alt alan boşluğunu ayarlarken adı seçmenize izin verin. CNAME kaydı olarak eklemeniz gereken rastgele bir alt alan adını otomatik olarak oluşturursa, bir alt alan devralması mümkün olmayabilir.
Üçüncü taraf bir hizmetin alt alan devralmalarına izin verebileceğini açıkça belirten birkaç örneğe bakalım. Çoğu hata ödül programı potansiyel veya teorik başvuruları kabul etmediğinden, bu sorunlardan yararlanırken bu daha alakalı olacaktır.
AWS S3 (savunmasız dava)
Çeşitli endüstrilerdeki şirketler, veri nesnelerini bulutta kolayca saklamak için AWS S3 kovaları kullanıyor. Yaygın bir uygulama, JavaScript dosyaları gibi herkese açık erişilebilir içeriği depolamak için kovaların kullanılmasını içerir. Bir şirketteki bir yazılım mühendisinin, tüm istemci tarafı JavaScript kodlarını ve CSS stil sayfalarını barındırmak için yeni bir kova oluşturduğunu varsayalım. Geliştirme sırasında, geliştirici kullanım durumlarına daha iyi uyan ve geçiş yapmaya karar veren başka bir üçüncü taraf hizmeti keşfeder.
Geliştirici kovayı siler, ancak ilgili DNS kaydını kaldırmayı unutursa, yanlışlıkla yeni bir alt alan devralma güvenlik açığı getirmiş olur. Bir saldırgan daha sonra AWS konsolu aracılığıyla aynı adla yeni bir AWS S3 kovası oluşturabilir ve subdomain.com.com adresinde sunulan tüm içeriğin kontrolünü ele geçirebilir.
AWS S3 Kovası’na işaret eden bir DNS CNAME KAYDIMI
Daha sonra sömürü bölümündeki bu makale boyunca, bunun neden şu anda olduğundan daha sorunlu olduğunu ele alacağız. Alt alan devralma güvenlik açıklarını önlemek için proaktif önlemlerin kullanıldığı başka bir örneğe bakalım.
UÇ! Yukarıdaki örnek, AWS S3 kovası yanlış konfigürasyon sorunundan farklı olan bir alt alan devralma güvenlik açığını belgelemektedir. AWS S3 Buck yanlış yakınlaştırmaları hakkında daha fazla okumak isterseniz, ayrıntılı makalemizi okumanızı öneririz ‘Hacking yanlış yapılandırılmış AWS S3 kovaları.‘
HubSpot (Vulnerning Olmayan Durum)
HubSpot, pazarlama ve satış ekiplerinin birlikte çalışmasını sağlayan bir diğer popüler üçüncü taraf yazılım satıcısıdır. Bu üçüncü taraf hizmet, statik siteler (açılış sayfaları, bloglar, iletişim formları vb.) Tasarlamak ve dağıtmak için bir özellik sağlar. Hizmetlerinin bir parçası olarak, müşterilerin kendi birincil alanlarını bağlamalarına da izin verirler. Ancak, bu durumda HubSpot, eklemeniz gereken etki alanının başka bir Hubspot hesabına bağlı olmamasını gerektirir. Buna ek olarak, sizin için bir ana bilgisayar adını da otomatik olarak oluşturur.
Bu senaryoda, savunmasız şirket bir HubSpot alanına işaret eden DNS kaydını kaldırmayı unutsa bile, bir alt alan devralması olası değildir. Birincil etki alanını hesaplarından tamamen kaldırmaları gerekecek:
Hubspots Alt alan devralma güvenlik açıklarına karşı proaktif güvenlik önlemleri
Atlassian Durum Sayfası (Vulnerning Case)
Atlassian statüsü, alt alan devralmasının var olmadığı bir örnektir. Durum sayfası, şirketlerin müşterilerini olası hizmet kesintileri, planlanan veya sürekli bakım ve diğer sistem performans sorunları konusunda güncel tutmasına yardımcı olan basit bir araçtır. Durum sayfası ayrıca müşterilerin kendi (alt) alanlarından birini durum sayfalarına göstermelerini sağlar.
Bununla birlikte, durum boyası, TXT kaydı eklemeyi içeren önce DNS doğrulamasını tamamlamanızı gerektirir. Bir saldırgan olarak, mevcut kayıtları değiştirmek için DNS Kayıt Şirketine erişmeniz gerekir, bu da böyle olması muhtemel değildir. Bu durum, alt alan devralmalarının nerede imkansız kaldığını mükemmel bir şekilde göstermektedir.
UÇ! ‘XYZ’yi devralabilir miyim?‘Subdomain devralmalarının mümkün olduğu onlarca satıcıyı listeleyen popüler topluluk destekli bir kaynaktır!
Alt alan devralma güvenlik açıklarını otomatikleştirme
Otomasyon, alt alan devralma güvenlik açıklarının belirlenmesi söz konusu olduğunda anahtardır. Neyse ki bizim için kullanabileceğimiz birkaç açık kaynaklı araç var. İlk odak noktamız, hata ödül hedefimizin tüm olası alt alanlarını toplamak olmalıdır. OWASP toplama ve altfinder (Project Discovery’den) gibi araçlar, tüm alt alanların bir listesini toplamamıza yardımcı olmak için hem pasif hem de aktif numaralandırma yöntemlerini destekler.
Daha sonra, mevcut olmayan bir hizmete işaret edip etmediklerini ve alt alan devralmalarına duyarlı olup olmadıklarını anlamak için her bir alt alanın DNS kayıtlarını ve HTTP yanıtlarını kontrol etmemiz gerekecek. Bu adımı açık kaynaklı araçlar kullanarak bile otomatikleştirebilirsiniz. Subjack ve Subzy, alt alanlar listemizi kolayca besleyebileceğimiz ve onlarca farklı üçüncü taraf hizmetlere karşı otomatik kontrol edebileceğimiz için mükemmel bir uyum.
Subjack işaretleme potansiyel alt alan devralma güvenlik açıkları
Bir alt alan devralma güvenlik açığını başarıyla belirledikten sonra, sömürü aşamasına geçebiliriz.
Alt alan devralmalarını sömürmek
Aşağıda ayrıntılı olarak belgeleyeceğimiz alt alan altındaki devralma güvenlik açıklarından aktif olarak yararlanmanın birkaç yolu vardır. Ancak ilerlemeden önce, genellikle çoğu şirketin bir alt alanın kontrolünü ele geçirebildiğinizi kanıtladıktan sonra test etmenizi tercih ettiğini hatırlatalım. Bu genellikle, gizli bir HTML yorumuyla alt alanda tahmin edilemez bir URL tuşuna sahip basit bir gizli sayfa oluşturmayı içerir:
Subdomain kavramın devralma kanıtı
Şimdi bazı sömürü yöntemlerine bir göz atalım.
OAUTH/SSO Token Sızıntısı Açık URL Yönlendirmeleri
Çoğu şirket, müşterilerin Microsoft veya Google hesaplarıyla oturum açmasına izin vermek için OAuth veya SSO kimlik doğrulaması uygular. Geliştiriciler, bu kimlik doğrulama akışlarını birincil alanın herhangi bir alt alanına yönlendirmeye izin verecek şekilde yapılandırdıklarında, saldırganlar oturum jetonlarını kapmak için alt alan devralmalarını kullanabilirler.
OAuth/SSO akışları tipik olarak jetonları URL parametreleri veya fragmanları olarak döndürdüğünden, saldırganlar bu gizli jetonları kendi sunucularına yakalamak ve iletmek için savunmasız alt alanda dinleyicileri kurabilirler.
OAuth/SSO’yu destekleyen bir kimlik doğrulama formu örneği
Yanlış yapılandırılmış çerez politikalarından sızan çerez
Web siteleri çerezleri bir etki alanı özelliği ile yapılandırdığında *.example.com veya .example.combu çerezler otomatik olarak, devralmaya karşı savunmasız herhangi bir alt alan da dahil olmak üzere örnek.com’un tüm alt alanları için kullanılabilir hale gelir. Bu gevşek çerez politikası, saldırganlara bir alt alan devralma güvenlik açığından başarıyla yararlandıklarında bu çerezlere erişim sağlar. Herhangi bir çerez, kimlik doğrulama jetonları veya oturum kimlikleri içeriyorsa, saldırganlar bunları ana alandaki mağdurların hesaplarına erişmek için kullanabilirler.
‘Örnek.com’ olarak ayarlanan etki alanı özniteliğine sahip çerez, tüm alt alanlarında otomatik olarak erişilebilir
Siteler Arası Talep Ambiyatı (CSRF) saldırıları
Çoğu web tarayıcısı varsayılan olarak, çerezlerde aynı site çerez ilkesini ‘LAX’ olarak ayarlar ve bu da bunları ana alanın herhangi bir alt alanına saha arası isteklerde bulundurur. Bu, bazı koşullarda, saha arası talep ampgery saldırılarını azaltmak ve ana başvuruda kurban adına eylemler yürütmek için uygulanan mevcut güvenlik önlemlerini atlamamızı sağlar.
Çapraz Origin Kaynak Paylaşımı (CORS) saldırıları
Subdomain devralma güvenlik açıkları, alt alanımızın CORS istekleri için beyaz listeye alınması koşuluyla, ana uygulamada bulunan hassas verileri sızdırmak için çapraz orijin kaynak paylaşım (CORS) sorunlarını kullanmamıza yardımcı olabilir.
Bazı uygulamalar, tüm hizmetler arasında kesintisiz entegrasyon sağlamak için varsayılan olarak tüm alt alanları beyaz listeye koyar. Alt alanlar listenizdeki CORS sorunlarını otomatik olarak tespit etmenize yardımcı olabilecek birkaç açık kaynaklı araç vardır.
İçerik Güvenliği Politikası (CSP) Bypass
İçerik Güvenliği Politikası (CSP), geliştiricilerin uygulamalarında değerlendirilen tüm kaynakların kontrolünü ele geçirmesini sağlayan bir tarayıcı güvenlik özelliğidir. Bu, siteler arası komut dosyası (XSS) saldırılarını geri tutabilir. Mevcut CSP önlemlerini atlamak için alt alan devralmamızdan yararlanabiliriz.
Özellikle, savunmasız alt alanın ana uygulamada ayarlanan içerik güvenliği politikasında beyaz listeye alınmış olup olmadığını araştırmalısınız.
UÇ! Bir İçerik Dağıtım Ağı (CDN) veya Bulut Depolama Hizmeti (AWS S3 gibi) içeren bir alt alanda devralma güvenlik açığı keşfettiğinizde, ana web sitesinin bu alt alandan kaynakları (özellikle JavaScript dosyaları) yükleyip yüklemediğini kontrol edin. Bu, kaçırılan alt alanın ana uygulamaya kötü amaçlı kod enjekte etmenize izin vereceği potansiyel bir tedarik zinciri saldırısı vektörünü gösterebilir!
Subdomain devralmalarının bulunması nispeten kolaydır, ancak doğru koşullarda sömürüldüğünde sadece savunmasız organizasyon için daha önemli bir etki yaratırlar. Bu makalede, potansiyel alt alan devralmalarının nasıl tanımlanacağını ve bu güvenlik açığı türlerinin nasıl kullanılacağına dair çeşitli yolların nasıl daha yüksek şiddet sorunlarına yükseltileceğini öğrendik. Ayrıca, otomasyonun diğerlerinden önce yeni alt alan devralmaları bulmanın üstünde kalmada önemli bir rol oynadığı sonucuna vardık!
Az önce alt alan devralma güvenlik açıklarını nasıl avlayacağınızı öğrendiniz … şu anda, becerilerinizi test etme zamanı! Intigriti’deki 70+ genel böcek ödül programlarımıza göz atın ve kim bilir, belki bir sonraki ödülünüz bizimle kazanılacak!
Bugün Intigriti’de hacklemeye başlayın