BLACK HAT USA – Las Vegas – Perşembe, 8 Ağustos – Amazon Web Services’taki (AWS) altı kritik güvenlik açığı, tehdit aktörlerinin kuruluşları uzaktan kod yürütme (RCE), sızdırma, hizmet reddi saldırıları veya hatta hesap ele geçirme yoluyla hedef almasına olanak tanımış olabilir.

Aqua’nın baş güvenlik araştırmacısı Yakir Kadkoda, Dark Reading’e yaptığı açıklamada, “Çoğu güvenlik açığı, saldırganın bakış açısından diğer hesaplara minimum çabayla erişim sağlaması nedeniyle kritik olarak değerlendirildi.” dedi.

Çarşamba günü bir brifing sırasında Siyah Şapka ABD Las Vegas’ta Aqua Security araştırmacıları, “Bucket Monopoly” ve “Shadow Resources” hatalarını kullanarak yeni saldırı vektörleri keşfettiklerini açıkladılar. Etkilenen AWS servisleri arasında Cloud Formation, CodeStar, EMR, Glue, SageMaker ve Service Catalog yer alıyor.

Aqua araştırmacıları Şubat ayında güvenlik açıklarını keşfettikten sonra bunları AWS’ye bildirdiler, AWS de sorunları doğruladı ve Mart ile Haziran arasında ilgili hizmetlere parça parça azaltma önlemleri uyguladı. Ancak açık kaynaklı yinelemeler hala güvenlik açığı içerebilir.

‘Kova Tekelciliği’: Genel AWS Hesap Kimliklerine Saldırı

Araştırmacılar ilk olarak, dosyalar veya görüntüler gibi nesneleri yönetmek için kullanılan çevrimiçi depolama kapları ve operasyonel verileri depolamak için gereken kaynaklar olan AWS S3 kovalarını kullanan saldırıların başarı oranını önemli ölçüde artırabilen bir saldırı yöntemi olan Bucket Monopoly’yi ortaya çıkardılar.

Sorun, S3 depolama kovalarının her kova adı için bir karma veya niteleyici kullanan benzersiz bir tanımlayıcı yerine öngörülebilir, tahmin edilmesi kolay AWS hesap kimlikleri kullanacak şekilde tasarlanmış olmasıdır.

Kadkoda, “Bazen bir saldırganın bir kuruluş hakkında bilmesi gereken tek şey, şu anda hassas veri olarak kabul edilmeyen AWS’deki genel hesap kimliğidir; ancak bunun bir kuruluşun gizli tutması gereken bir şey olduğunu öneriyoruz” diyor.

Sorunu hafifletmek için AWS varsayılan yapılandırmaları değiştirdi.

“AWS, tüm hizmetleri artık kova adını otomatik olarak oluşturmayacak şekilde düzeltti,” diye açıklıyor. “AWS artık istenen kova adı zaten mevcutsa rastgele bir tanımlayıcı veya sıra numarası ekliyor.”

Güvenlik araştırmacıları ve AWS müşterileri uzun süredir tartışılan AWS hesap kimliklerinin herkese açık mı yoksa özel mi olması gerektiği. AWS, müşterilerini kimlik bilgilerini paylaşmamaları konusunda uyarır ve hesap kimliklerini dikkatli bir şekilde kullanmalarını ve paylaşmalarını önerir. Ancak, AWS’nin hesap kimlikleriyle ilgili belgelerine göre, hesap kimlikleri “gizli, hassas veya gizli bilgi olarak kabul edilmez.”

Aqua araştırmacıları ise aynı fikirde değil.

“Araştırmamıza dayanarak, hesap kimliklerinin gizli olarak kabul edilmesi gerektiğine inanıyoruz çünkü bir hesap kimliğini bilmeye dayalı olarak gerçekleştirilebilecek başka türden benzer istismarlar olabilir,” diyor Kadkoda Cuma günü yayınlanacak olan güvenlik açıkları hakkındaki ayrıntılı bir teknik raporda. “Genel varsayım, bir hesap kimliğini bilmenin tek başına bir hesabı hacklemek için yeterli olmadığı olsa da, saldırganlar yine de bunu kullanabilir bilgi toplamak AWS hesabınız ve daha fazlası hakkında.”

AWS sözcüsü bu konuda özel bir yorum yapmayı reddetti ancak AWS’nin bu araştırmadan haberdar olduğunu söyledi.

Sözcü, “Bu sorunu çözdüğümüzü teyit edebiliriz, tüm hizmetler beklendiği gibi çalışıyor ve müşterilerden herhangi bir işlem yapılması gerekmiyor” dedi.

Gölge Kaynaklar: Gizli Varlıklar Saldırganlar İçin Koruma Sağlıyor

Kadkoda, ekibinin ayrıca hesap sahibinin bilmediği AWS S3 servis bileşenleri oluşturabilen Shadow Resources saldırı vektörünü de keşfettiğini söylüyor.

Araştırmacılar sorunu ilk olarak AWS CloudFormation hizmetinde keşfettiler; burada bir saldırgan, meşru, mevcut yığınlarla aynı adı taşıyan kullanılmayan AWS coğrafi bölgelerinde hesaplar oluşturarak kaynak işgali gerçekleştirebiliyordu. Kurban iş yüklerini yeni bir bölgede depoladıktan sonra, ona bağlanabilir ve ardından farkında olmadan saldırgan tarafından kontrol edilen S3 kovalarını kullanabilirdi.

Bunun nedeni, yeni bir yığın oluşturmak için AWS Yönetim Konsolu ile hizmeti kullanırken, AWS’nin CloudFormation şablonlarını depolamak için otomatik olarak bir S3 kovası oluşturmasıdır. S3 kovasının adı tüm AWS bölgelerinde aynıdır, bu da bir saldırganın hesap adını tahmin edip ona erişim elde etmesinin yoludur.

“S3 kovanızı ele geçirebilir ve yapılandırmayı zehirleyip değiştirebilirim,” diyor Aqua güvenlik araştırmacısı Assaf Morag. “Bu çok büyük bir şey çünkü satır aralarında, uzaktan kod yürütmeyle dünyadaki herhangi bir şirketin hesaplarını ele geçirebilirsiniz.”

Tüm servisler yapılandırma dosyalarına ihtiyaç duyar ve AWS, yapılandırmaları depolamak için dosya sistemi olarak S3 kovalarını kullanır.

“Çoğu durumda, bu yapılandırmalar gerçekten önemlidir çünkü bunlar hizmetlere yönelik talimatlardır,” diyor Morag. “Bunlar bir YAML dosyası veya hizmetin sahne arkasında kullanması gereken başka şeyler olabilir.”

Müşterilerin dünya çapında bölgelere yayılmış yüzlerce veya binlerce farklı AWS hesabına sahip olabileceği göz önüne alındığında, gölge hizmetlerden kaynaklanan istismarların önemli olabileceğini vurguluyor Morag. Güvenlik açığının kurbanlarının nerede olduğu bilinmiyor.

“Saldırıya uğrama veya kurban olma potansiyeli çok büyük olabilirdi” diyor.

S3 Kovalarındaki Açık Kaynaklı Projeler Hala Savunmasız Olabilir

AWS hizmetlerini etkileyen güvenlik açıklarını azaltmış olsa da Kadkoda, saldırı vektörlerinin AWS ortamlarında konuşlandırılan açık kaynaklı projeleri hâlâ etkileyebileceği konusunda uyarıyor. Birçok açık kaynaklı proje otomatik olarak S3 kovaları veya kullanıcıları bunları dağıtmaya yönlendirebilir, diye belirtiyor.

Kadkoda, “Birçok açık kaynaklı projenin bu saldırıya karşı savunmasız olduğunu gördük çünkü bunları perde arkasında öngörülebilir kova adlarıyla kullanıyorlar” diyor.

Kullanıcılar, var olan her bir kovanın adının başka bir yerde talep edilip edilmediğini kontrol etmeli ve eğer talep edildiyse adını değiştirmelidir.

Her durumda, Kadkoda ve Morag kullanıcıların ilk etapta tahmin edilebilir veya statik tanımlayıcılara sahip S3 kovaları oluşturmaktan kaçınmaları gerektiğini söylüyor. Bunun yerine, saldırganların önce bunları talep etmesini önlemek için her bölge ve hesap için benzersiz bir karma veya rastgele tanımlayıcıya sahip bir S3 kova adı oluşturmaları gerekir.



siber-1