Bu tanıdık bir hikaye: Kolaylık için tasarlanmış bir özellik, güvenlik önlemlerinden kaçınmak için kullanılır. Black Hat USA 2021’den bu sunumda, bir çift araştırmacı AWS’de hesaplar arasında geçiş yapmanın üç ayrı yolunu nasıl bulduklarını gösteriyor. Bu güvenlik açıkları için düzeltmeler hızlı bir şekilde yayınlansa da, delikler bulut hizmetlerinin beklenen yalıtım düzeyini sağlamadığını ortaya koyuyor. Uzun vadeli çözüm, siber güvenlik sektörünün CVE’leri ele alma şeklini değiştirmek anlamına gelebilir.
İlk iki izolasyon ihlali için Wiz.io CTO’su Ami Luttwak ve araştırma başkanı Shir Tamari, bir kullanıcının başka bir kullanıcının S3 klasörüne yazmasına izin vermek için AWS CloudTrail ve Config’deki yol öneklerini değiştirdi. Üçüncü yöntem, sunucusuz depo aracılığıyla başka bir kullanıcının hesabından dosya indirmek için AWS komut satırını kullandı.
Luttwak ve Tamari sunumlarında “İzolasyonun Kırılması: Hesaplar Arası AWS Güvenlik Açıkları” dediler.
“Bu davranıştan, CloudTrail’in sahip olunan ve başka hesaplarda yönetilen kaynaklara yazabileceğini öğrendim.” Tamari eklendi. “Ve bir güvenlik araştırmacısı olarak benim için bir endişe var.”
Müşteriler Haberdar Oldu Peki Ne Oldu?
Amazon’un yapılandırmaları müşterilerin kendisi için düzeltme gücü olmasa da – çünkü düzeltmeler, yalnızca kullanıcının karar verebileceği, istediğiniz kaynak hesabı ayarlamayı içeriyordu – olası sorunu ve nasıl düzeltileceğini açıklamak için etkilenen tüm müşterilerle iletişime geçti. Ancak Wiz.io beş ay sonra geri döndüğünde, hesapların %90’ının düzeltmeleri uygulamadığını gördü.
Luttwak, AWS’nin sık sık mesajlaştığı güvenlik ekibinin çalıştırdıkları çok sayıda hesap nedeniyle uyarıları almadığına dikkat çekti.
“Bunun yapılması gereken önemli bir düzeltme olduğunu nereden biliyorsun?” O sordu. “Ve bunun hakkında ne kadar çok düşünürsek, o kadar çok anladık ki bu çok büyük bir sorun.”
Şu anda, CVE’ler sistemi, kuruluşların en son güvenlik açıklarını kontrol etmelerine izin veriyor, sayısal bir sınıflandırma sistemi ve satıcıların düzeltmelerine bağlantılar ile tamamlanıyor. Bu, BT’nin çoğu alanında oldukça iyi çalışıyor. Ancak, bulut güvenlik açıkları atanan CVE numaralarını alamayabilir.
“Bunun nedeni, şu anda anladığımız şekliyle bulut hizmetlerinin müşteri kontrollü olmamasıdır.” yazdı Cloud Security Alliance BT direktörü Kurt Seifried ve araştırma analisti Victor Chin. “Sonuç olarak, bulut hizmetlerindeki güvenlik açıklarına genellikle CVE kimlikleri atanmaz.”
Amazon İstisnası
CVE’ler belirtmek için acı çekiyor yazılımın sahibi onları bildiren CVE numaralandırma yetkilisi (CNA) olduğu sürece bulut hizmetleri güvenlik açıkları gerçekten bir CVE kimliği alabilir. Kural 7.4.4 CNA, müşteri tarafından kontrol edilmese bile ürün veya hizmete sahipse bir CVE numarası “atayabilir” ve düzeltme müşterilerin harekete geçmesini gerektiriyor.
Ama işte yapışkan küçük kapı: Kural 7.4.5 “Etkilenen ürün(ler) veya hizmet(ler) CNA’ya ait değilse ve müşteri tarafından kontrol edilmiyorsa, CNA’lar bir güvenlik açığına bir CVE Kimliği ATAMAMALIDIR.”
Kısacası, bu AWS güvenlik açıklarının CVE’ler verilmemesinin asıl nedeni, Amazon bir CNA ortağı değil. Microsoft, Google gibi kendi ürün ve hizmetleri için CVE’ler yayınlayabilir. Uygun düzeltmenin, herhangi bir CNA’nın düzeltmeleri müşterilerin elinde olmayan güvenlik açıklarına kimlik atamasına veya Amazon’u bir CNA olarak kaydettirmesine izin verecek şekilde kuralları değiştirmek olup olmadığı, sizin bakış açınıza bağlıdır. Haziran 2022’de Wiz.io, boşluğu doldurmak için bulut güvenlik açıklarından oluşan bir topluluk veritabanı oluşturarak meseleyi kendi eline aldı.
Luttwak’ın dediği gibi, “AWS’de yüzlerce hizmet var ve bunların çoğu, giderek daha fazla çapraz hesap becerisi kazanıyor çünkü çapraz hesap, günümüzde AWS kullanan kuruluşlar için ana stratejidir. Bu nedenle, saldırı yüzeyi hızla büyüyor.”
