AWS Güvenlik Açıkları Black Hat Araştırmacıları Tarafından Ortaya Çıkarıldı


Güvenlik araştırmacıları, AWS hizmetlerinde uzaktan kod yürütmeye (RCE), veri sızdırmaya, yapay zeka modeli manipülasyonuna ve hatta hesap ele geçirmeye yol açabilecek altı kritik güvenlik açığı keşfetti.

AWS, bugün Black Hat güvenlik konferansında ortaya çıkan güvenlik açıklarını düzeltti, ancak araştırmacılar, güvenlik açıklarının diğer AWS ve açık kaynaklı hizmetlerde de bulunabileceği konusunda uyardı ve bu nedenle genel bir hafifletme kılavuzu sundular.

AWS, Müşterilerin Güvenlik Açıklarından Etkilenip Etkilenmediğini Araştırıyor

Aqua’nın Team Nautilus araştırma ekibinde Baş Güvenlik Araştırmacısı olan Yakir Kadkoda liderliğindeki Aqua Security araştırmacıları, AWS güvenlik açıklarını Şubat 2024’te keşfetti.

Etkilenen AWS hizmetleri şunlardır:

  • Bulut Oluşumu
  • Zamk
  • EMR
  • Adaçayı üreticisi
  • ServisKatalogu
  • Kod Yıldızı

Araştırmacılar, “Bu güvenlik açıkları, bu hizmetlerden herhangi birini kullanmış dünyadaki herhangi bir kuruluşu etkileyebilirdi” dedi. Sorunları çözmek için AWS ile aylarca süren bir çalışma sürecini ayrıntılı olarak açıkladılar ve bulut hizmeti sağlayıcısının saldırganların daha önce güvenlik açıklarını istismar etmek için saldırı vektörünü kullanıp kullanmadıklarını araştırdığını ve “bildirilen sorunlardan herhangi birinden etkilenmeleri durumunda müşterilerle doğrudan iletişime geçeceklerini” belirttiler.

Kadkoda anlattı Siber Ekspres AWS ile ifşa ve azaltma sürecinde çalışmanın iyi bir deneyim olduğunu söyledi.

“Bulut güvenlik sağlayıcılarıyla ifşa süreci çok önemlidir ve biz her zaman süreci iyileştirmeyi hedefliyoruz,” dedi Kadkoda. “Bazen zorlayıcı olabilir, ancak bu durumda AWS’nin güvenlik ekibiyle çok iyi bir deneyim yaşadık. İfşa taleplerimize derhal yanıt verdiler ve boşluklar ve düzeltmeler hakkında bilgi paylaştılar. Güvenlik ekibi profesyoneldi ve bunu titizlikle ve uygun aciliyet duygusuyla ele aldı.”

Araştırma, bu hafta sonu DEFCON konferansı sırasında yayınlanacak uzun bir blog yazısında ayrıntılı olarak açıklanacak; yayınlandığında yazıya bağlantı vereceğiz.

AWS ‘Gölge Kaynakları’ Saldırı Vektörü Ayrıntılı

Araştırmacılar, keşfettikleri AWS saldırı vektörüne “Gölge Kaynaklar” adını verdiler. Bu, çeşitli hizmetleri desteklemek için oluşturulan AWS S3 kovalarını içeriyor ve “Gölge S3 kova kaynaklarını kullanan saldırıların başarı oranını önemli ölçüde artırabilen” “Kova Tekelciliği” adını verdikleri bir teknik buldular.

AWS CloudFormation’ı kullanırken, yeni bir bölgede yeni bir yığın oluşturmak için AWS Yönetim Konsolu aracılığıyla hizmeti ilk kez kullandığınızda, hizmetin otomatik olarak AWS’yi CloudFormation şablonlarını depolamak için bir S3 kovası oluşturması için tetiklediğini fark ettiler; kullanıcılar bunun farkında olmayabilir. Hizmet, bölgenin adı dışında tüm AWS bölgelerinde aynı kova adını kullanır.

Saldırganların kullanılmayan AWS bölgelerinde kovalar kurabileceğini ve kurbanın yeni bir bölgede CloudFormation hizmetini kullanmasını bekleyebileceğini ve “saldırgan tarafından kontrol edilen S3 kovalarını CloudFormation hizmetinin bir parçası olarak gizlice kullanabileceğini” keşfettiler. Daha sonra bu tekniği diğer AWS hizmetlerinde kullandılar.

Saldırganlar, S3 kovasının yapılandırmasını herkesin erişimine açık olacak şekilde değiştirerek saldırılarını artırabilirler. Ayrıca, S3 kovasında izin verici kaynak tabanlı bir politika oluşturmak, başka bir IAM sorumlusuna, özellikle savunmasız AWS hizmetine açıkça izin verebilir ve bu da kurbanın savunmasız hizmetinin saldırgan tarafından kontrol edilen kovaya veri okumasına ve yazmasına olanak tanır.

Bir saldırgan tüm bunları yaptıktan sonra, CloudFormation hizmeti kovanın zaten var olduğunu anlayacak ve şablon dosyasını içine bırakacak ve bu da bilgi ifşasına ilişkin bir güvenlik açığı yaratacaktır.

CloudFormation şablonlarını yürütülmeden önce değiştirerek, “teknik daha etkili olacak çünkü saldırı vektörümüzün başarılı olması için orijinal koşulların ve ön koşulların çoğu artık gerekli değil.”

Saldırganlar, yalnızca CloudFormation’ın benzersiz karma değerini bilerek hedef kuruluşta bir yönetici rolü oluşturabilirler; bu, “bulutta elde edebileceğimiz en kötü sonuçtur, çünkü kurbanın hesabını ele geçirmemize olanak tanır.”

Neyse ki, karma değerleri rastgele olduğundan kolayca belirlenemiyor; ancak araştırmacılar, GitHub regex aramaları, Sourcegraph, açık sorunları tarama ve benzeri teknikleri kullanarak farklı AWS hesapları tarafından kullanılan çok sayıda karma değeri tespit edebildiler.

“Araştırmalarımı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” dediler.

AWS Güvenlik Açıklarının Azaltılması

Araştırmacılar, saldırı vektörünün diğer AWS servislerine veya açık kaynaklı projelere de uygulanabileceği konusunda uyararak, üç azaltma stratejisi önerdiler:

aws:KaynakHesabı Koşulu: Bir kullanıcının veya hizmet rolünün güvenilmeyen bir kovaya erişmesini önlemek için, hizmet tarafından kullanılan veya üstlenilen rol için kapsamlı bir politika tanımlayabilir ve JSON politikasına Condition öğesini ekleyebilirsiniz. Örneğin, EMR Studio’nun kullanıcılar için oluşturduğu varsayılan hizmet rolü AmazonEMRStudio_ServiceRole_{ID} olarak adlandırılır ve hizmetin çalışması için gerekli izinleri içerir. Bu rolde, AWS, EMR tarafından kullanılan S3 kovasının AWS hesap kimliğinin kullanıcıya ait olduğunu ve bir saldırgana ait olmadığını kontrol etmek için politikada aws:ResourceAccount koşulunu uygular. Bazı AWS hizmetleri, başka bir AWS hesabında barındırılan kaynaklara erişim gerektirir, bu nedenle bunun kontrol edilmesi gerekir.

Beklenen kova sahibini doğrulayın: S3 kovasının sahibini şu şekilde doğrulayın: komut. “Her AWS bölgesi için tutkal kovası sahibini AWS hesap kimliğinizle kontrol etmeniz gerekecek. Erişim Engellendi mesajı alırsanız, bu kovanın hesabınız altında olmadığını gösterir ve kovanın sahibini ve bu hesaba güvenip güvenmediğinizi doğrulamanız gerekir.” -expected-bucket-owner kontrolü, operasyonlarının bir parçası olarak S3 kovaları oluşturan açık kaynaklı projeler için de değerlidir, dediler.

S3 kovalarının isimlendirilmesi: Kova adında öngörülebilir veya statik tanımlayıcılar kullanmak yerine, her bölge ve hesap için benzersiz bir karma değer veya rastgele bir tanımlayıcı üretmeli ve bu değeri S3 kova adına dahil ederek saldırganların kovanızı vaktinden önce ele geçirmesini önlemelisiniz.



Source link