Silinmiş bir S3 bucket'ına sarkan CNAME sayesinde bir araştırmacı Bime'in alt alan adını ele geçirdi

Silinen bir bucket nasıl başkasının varlığına dönüştü

2016'da bir güvenlik araştırmacısı, Bime'e ait a2.bime.io alt alan adının bimeio.s3.amazonaws.com'u işaret eden bir CNAME kaydına sahip olduğunu fark etti. Bu kaydın diğer ucunda bimeio adlı bucket artık yoktu. Ne Bime'in ne de başka birinin mülkiyetindeydi. Araştırmacı bucket'ı kendi AWS hesabında oluşturdu ve o andan itibaren alt alan adı, Bime'in alan adı üzerinde araştırmacının içeriğini sunmaya başladı; şirket adına düzenlenmiş SSL sertifikasıyla, ona güvenen kullanıcılara gösterildi. Bulgu HackerOne raporu 121461 olarak kaydedildi ve davayı yeniden ele alan bir dev.to yazısına göre bucket'ın silinmesi ile araştırmacının adı talep etmesi arasındaki boşluk günlerce sürdü.

Bunun mekanizması basittir. S3 bucket adları tüm AWS genelinde tektir ve bir bucket silindiğinde adı hemen herhangi bir hesaba açık hale gelir. Bir DNS kaydı hâlâ artık boş olan S3 endpoint'ini işaret ediyorsa, adı kaydeden ilk kişi o hostname'in ne sunacağını kontrol eder.

Üç komut ve sıfır exploit

dev.to yazısı saldırıyı yalnızca standart araçlarla yeniden üretiyor: bir DNS sorgusu CNAME kaydını ortaya koyuyor, bir aws s3 ls çağrısı NoSuchBucket döndürüyor ve tek bir aws s3 mb adı ele geçiriyor. Ne kimlik bilgisi, ne exploit kodu, ne sosyal mühendislik. Alt alan adı, sahibi fark edene dek saldırganın içeriğini sunmaya devam ediyor — Bime vakasında bu, adın sahipsiz kaldığından çok sonra oldu.

İki envanter arasındaki kör nokta

Yazıya göre geleneksel araçların bu yapılandırmaya dair bir görünürlüğü yok. Bulut güvenlik duruşu yönetimi (CSPM) ürünleri bir kuruluşun AWS hesaplarındaki bucket'ları envanterler; silinen bucket bu envanterden düşer ve taranacak bir şey kalmaz. Bu arada CNAME kaydı Route 53, Cloudflare veya bir kayıt kuruluşunun kontrol panelinde yaşar — AWS kaynak modellerinin dışında, AWS Config ve Security Hub'ta yok ve CSPM bulgularına görünmezdir. Hostname'in döndürdüğü NoSuchBucket yanıtı başlı başına geçerli bir HTTP yanıtı olduğu için izleme sistemleri bunu bir açık değil kesinti olarak okur. Artık bucket'ı olmayan AWS hesabı ile hâlâ kaydı barındıran DNS bölgesi arasındaki bu uyumsuzluk tam ortada kalır ve ikisini çapraz kontrol eden bir şey çalıştıran kuruluş azdır.

Bu boşluk genellikle sıradan iş akışlarıyla açılır. Bir ekip S3 destekli bir özellik yayınlar, CNAME kaydını ekler ve daha sonra özelliği kullanımdan kaldırır. Bucket'ı silmek AWS konsolunda gerçekleşir; kaydı kaldırmak ise ayrı bir sistemde, çoğunlukla ayrı bir ekibin sorumluluğundadır ve dağıtım sürecinde hiçbir şey buna bağlı kalmaz. Temizlik görevi unutulur ve aylar sonra kimsenin o alt alan adının varlığından haberi kalmaz.

Referansı varlık olarak ele alın

Yazı kuralı tek bir değişmezeye indirgiyor: Bir S3 endpoint'ini işaret eden her DNS CNAME kaydı, var olan ve aynı kuruluşa ait bir bucket'a referans vermelidir. Bu, üretim ortamına dokunmadan bir anlık görüntüden doğrulanabilir — kayıt bimeio.s3.amazonaws.com'u işaret ediyor, bucket hesap envanterinde yok, ad talep edilebilir durumda — ve tek başına bu gözlem bulgunun kendisidir.

Makale daha sonra Stave adlı bir aracın bu fikri nasıl uyguladığını gösteriyor: DNS'den S3'e bağlantıyı birinci sınıf bir varlık olarak modelliyor ve referans verilen bucket'ın var olup olmadığıyla kime ait olduğunu kaydeden özellikler taşıyor. Kontrollerden biri başarısız olduğunda bir alarm tetikleniyor ve projenin uçtan uca testlerinden biri, sekiz günü kapsayan iki anlık görüntüde tam Bime yapılandırmasını yeniden oluşturuyor. Araçtan bağımsız olarak daha geniş nokta geçerlidir: güvenlik açığı bucket'ta değil referansta yaşar ve bucket düzeyindeki tarayıcıların değerlendirecek bir şey bulamamasının nedeni tam olarak budur.

Saniyelerle ölçülen iyileştirme

Yazıya göre açığı kapatmak bir dakikadan kısa sürüyor. Bir seçenek bucket adını geri almaktır — tüm genel erişimi engellenmiş boş bir bucket, ad alanını başkasına kapatmak için yeterlidir ve DNS yayılımını beklemeyi de gerektirmez. Diğeri CNAME kaydını tamamen silmektir; yazar, boş bir bucket'ı işaret eden alt alan adının zaten var olmaması gerektiği için bunun her durumda yapılmasını öneriyor. Kalıcı süreç düzeltmesi ise sıralamayla ilgili: bir bucket'ın adına yapılan referanslar için DNS kayıtlarını arayın ve bunları bucket'ı silmeden önce kaldırın; ardından bölgeleri *.s3.amazonaws.com hedefleyen CNAME kayıtları için düzenli olarak denetleyin ve referans verilen her bucket'ın var olduğunu ve kuruluşa ait olduğunu doğrulayın.

Neden önemli

Bime raporu 2016'dan kalma ama mekaniklerin hiçbir şeyi değişmedi: S3 adları hâlâ küresel olarak tek, silme işlemi onları hâlâ anında serbest bırakıyor ve DNS temizliği hâlâ kaynak silinmesinden ayrı bir sistemde yaşıyor. Hiç değilse bir kez bucket — ya da bir hostname'in işaret ettiği herhangi bir bulut kaynağı — silmiş her kuruluş, bugün aynı gizli açığı taşıyor olabilir. Etki alanı yolunda bir 404 değil; saldırgan, şirketin alan adı içinde, kullanıcıların zaten güvendiği bir sertifika üzerinden erişilen canlı bir hostname'i kontrol eder. DNS kayıtlarıyla bulut envanterini ilişkilendirdiğinizde tespit ucuzdur ve iyileştirme, orijinal raporu okumaktan daha az zaman alır.