- AWS, S3 bucket squatting (bucketsquatting) sorununu çözmek için yeni bir hesap tabanlı namespace koruma özelliği sundu
- Yeni namespace,
<prefix>-<accountid>-<region>-an biçiminde ve bu ada sahip bucket’ı yalnızca aynı hesap oluşturabiliyor
- Başka bir hesap aynı adı kullanmaya çalışırsa
InvalidBucketNamespace hatası oluşuyor; yanlış region belirtilse bile aynı hata dönüyor
- Bu namespace’in varsayılan olarak kullanılması öneriliyor ve kuruluş politikalarında (SCP)
s3:x-amz-bucket-namespace koşul anahtarıyla zorunlu kılınabiliyor
- Mevcut bucket’lara geriye dönük uygulanmasa da, yeni bucket’lar için güçlü koruma sağlayarak S3 güvenlik yapısında temel bir iyileştirme anlamına geliyor
Bucketsquatting sorununun özeti
- Bucketsquatting (veya Bucketsniping), AWS S3’te bucket adlarının küresel olarak benzersiz olmasını kötüye kullanan bir saldırı türü
- Bir bucket silindiğinde ad yeniden kullanılabilir hale gelir ve saldırgan aynı adla yeni bir bucket kaydedebilir
- Bu da hassas verilere erişim veya hizmet kesintisi riski yaratabilir
- Kuruluşlar sıkça
myapp-us-east-1 gibi öngörülebilir adlandırma kuralları kullandığı için saldırıya açıklık artıyordu
- AWS iç ekipleri de bu sorundan etkilendi ve yaklaşık 10 yıl boyunca AWS güvenlik ekibiyle birlikte çözüm aradı
Yeni S3 namespace’inin devreye alınması
- AWS, sorunu çözmek için hesap başına namespace (account namespace) kavramını tanıttı
- Biçim:
<prefix>-<accountid>-<region>-an
- Örnek:
myapp-123456789012-us-west-2-an
- Bu namespace, ilgili hesabın yalnızca kendisinin bu adla bucket oluşturabilmesini sağlıyor
- Başka bir hesap aynı adı oluşturmaya çalışırsa
InvalidBucketNamespace hatası oluşuyor
- Bucket adındaki region gerçek region ile uyuşmazsa da aynı hata dönüyor
- AWS, bu namespace’in tüm yeni bucket’larda varsayılan olarak kullanılmasını öneriyor
- Mevcut namespace’lerden (
.mrap, --x-s3, -s3alias) farklı olarak bu kez güvenlik amacıyla genel kullanıcılara yönelik bir namespace olarak sunuluyor
Politika uygulaması ve yönetim
- Güvenlik yöneticileri,
s3:x-amz-bucket-namespace koşul anahtarını kullanarak kuruluş genelinde politika (SCP) ile namespace kullanımını zorunlu kılabilir
- Mevcut bucket’lara veya namespace içermeyen şablonlara otomatik olarak uygulanmaz
- Mevcut bucket’ları korumak için yeni namespace biçiminde bucket oluşturup verileri taşımanız gerekir
- Bu adımla bucket squatting fiilen “ortadan kalkma yoluna giriyor” ve yeni bucket’lar için tam koruma sağlanıyor
Diğer bulut sağlayıcılarının yaklaşımı
- Google Cloud Storage (GCS) zaten alan adı doğrulamasına dayalı bir namespace kullanıyor
myapp.com gibi alan adı biçimindeki bucket’ları yalnızca alan adı sahibi oluşturabiliyor- Alan adı olmayan bucket’larda ise bucket squatting olasılığı hâlâ mevcut
- Azure Blob Storage, storage account adı + container adı yapısını kullanıyor
- En fazla 24 karakter sınırı nedeniyle namespace daha dar ve aynı soruna karşı daha kırılgan olabilir
Sonuç (tl;dr)
- AWS S3’e yeni bir hesap-bölge namespace’i eklendi
- Bu namespace, bucket squatting saldırılarını engelliyor ve yeni bucket oluştururken mutlaka kullanılması öneriliyor
- Mevcut bucket’lar otomatik olarak korunmadığı için gerekirse veri taşıma ile korumanın güçlendirilmesi gerekiyor
1 yorum
Hacker News görüşleri
Kısa süre önce, AWS hesabı silindikten sonra bile root kullanıcı e-posta adresinin yeniden kullanılamadığını öğrendim
Kuruluşumuzdan biri, kapatılan hesabın root kullanıcısını şirketin ana e-posta adresiyle oluşturmuş, yeni hesabı ise başka bir e-postayla açmıştı; şimdi silme kurtarma süresi de geçmiş durumda
Sonuç olarak bu e-posta, silinmiş root hesaba kalıcı olarak bağlı kaldı ve harici IdP üzerinden SSO girişi yapmak imkansız hale geldi
AWS destek ekibiyle görüştüm ama neredeyse hiç yardımcı olamadılar
Parola belgelenmişti ama MFA'yı kaldırmanın bir yolu yoktu; AWS destek, hesap yöneticisi ve başkalarıyla görüştük ama çözülemedi
Sonunda root hesaba erişim kilitlendi ve karmaşık bir ortamı tamamen yeni bir hesaba taşımamız gerekebilir
AWS, artı işareti eklenmiş e-postaları ayrı adresler olarak görüyor
Onu yalnızca gerçekten ciddi bir sorun çıktığında kullanmak en iyisi
Sonuçta bir phishing saldırganı müşteri destek ekibini kandırıp 10 puanlık değerlendirme alırsa her şey çökebilir
Pratikte kullanımı engelleyen mekanizmanın ne olduğunu bilmek isterim
Yazarın Azure Blob Storage'taki account name kavramını yanlış anlamış gibi görünüyor
Bu fiilen S3'teki bucket adıyla aynı seviyede ve küresel olarak benzersiz olmak zorunda olduğu için hâlâ büyük bir rahatsızlık kaynağı
Özellikle ad uzunluğunun 24 karakterle sınırlı olması daha da can sıkıcı
Microsoft'un da AWS gibi müşteri başına namespace getirmesini isterim
Ama ilk tasarımın kısıtları yüzünden değiştiremediler
Kişisel olarak neden hâlâ S3 v2 API yapmadıklarını anlamıyorum
Yeni API ile kademeli geçişi teşvik edebilirlerdi, ama bunun yerine hem müşteriler hem mühendisler gereksiz yere acı çekiyor
Yani yalnızca rakam ve küçük harf kullanabiliyor olmak çok rahatsız edici
Keşke S3 ya da GCS gibi en azından tireye izin verilse
Container registry gibi başka kaynaklarda da durum aynı
Paket adı, bucket adı, GitHub hesap adı gibi şeylerde Discord'daki gibi @isim-rastgele4hane formatı kullanılabilir mi diye düşünüyorum
Bu şekilde ad alanı daha demokratik olur ve squatting ya da yeniden kullanım saldırıları engellenebilir
Hesap silinince tüm adın emekli edilmesi de temiz bir çözüm olur
Gerekçesi resmî duyuruda anlatılıyor;
4 haneli sayıyı hatırlama ve büyük-küçük harf ayrımını yönetme zorluğu yüzündendi
Özellikle chat uygulamalarında dahili ID kullanıp kullanıcıya yalnızca takma ad göstermek daha temiz
Bucket'larda ise insanın okuyabileceği bir ad önemli olduğundan, orada kendi domaininizi kullanmak daha mantıklı olabilir
Hatta sadece yazım hatası riskini artırır
Çevrimiçi topluluklarda isim çakışması gayet doğal bir şeyken,
neden ille de küresel benzersiz isimler dayatılıyor, emin değilim
Yazının sahibi Ian Mckay'e teşekkürler
AWS'nin resmî olarak hesap ve bölge bazlı namespace getirmesi iyi bir değişiklik
Terraform gibi IaC araçlarının bu kuralı varsayılan olarak benimsemesi daha da iyi olurdu
Terraform zaten bucket adı sonuna rastgele hash soneki ekleyerek çakışmaları önlüyor
İlgili bilgi AWS resmî blogunda da var
Bulut sağlayıcılarının dahili scratch alanlarında tahmin edilebilir bucket adları kullanırken ortaya çıkan bucket squatting saldırıları ilginç
AWS'de hash yüzünden gerçek saldırı zordu ama GCP yakın zamanda da benzer sorunlar yaşadı
İlgili sunumlar: DC32 AWS bucket squatting konuşması,
GCP açığı: CVE-2026-1727
Bucket adlarının tahmin edilebilir olduğunu gördüğüm anda tehlikeyi hissettim
Bucket squatting + public bucket + CloudFormation'ın TOCTOU sorunu birleşince
başka hesaplara bile kaynak dağıtımı yapılabilirdi
AWS güvenlik ekibinin bunu daha erken fark etmemiş olmasına şaşırdım
DNS adlarında da benzer bir sorun var
Domain yenilenmezse başkası tarafından yeniden kaydedilebilir,
biri MX kaydı ekleyip parola sıfırlama e-postaları gibi iletileri ele geçirebilir
AWS bucket'ları hâlâ yalnızca hostname ile aynı ada sahip olduklarında özel işlevler sunuyor
İlgili belge: Virtual Hosting in S3
Bir ad, işaret ettiği şeyle aynı olmamalı
Ad yeniden kullanıldığında bambaşka bir şeyi işaret eder,
anlamı da bağlama göre değişir
Yalnızca adı kendiniz yeniden atadığınızda aynı şey olarak kabul edilebilir
Hesap kimliğini açık etmenin güvenlik açısından riskli olup olmadığını merak ediyordum
resmî belgelere göre,
dikkatli ele alınmalı ama hassas bilgi sayılmıyor
Fazla yaymazsanız sorun olmaz
IAM kurallarında saldırgan zaten * kullanabildiği için, asıl önemli olan savunma tarafının politika yapılandırmasıdır
Bunu base32 ile decode ederseniz Account ID'yi çıkarabilirsiniz
Not: ilgili analiz yazısı
S3'ün bucket adını tek başına erişim anahtarı olarak kullanması, tasarımdaki en sinir bozucu kararlardan biriydi