14 Ekim ile 26 Ekim arasında bir saldırgan birden fazla Qubole müşterisine ait AWS hesaplarına sızdı ve saklanan gizli bilgiler ile verileri çaldı; bulut güvenlik şirketi Wiz bugün açıkladı.
Saldırgan, Qubole platformunun müşterilere ulaşmak için kullandığı bir AWS hesabına ait kimlik bilgilerini kullandı. Bu kimlik bilgilerinin nasıl ele geçirildiği açıklanmadı.
İdera'ya ait veri gölü platformu Qubole, müşterilerinin AWS hesapları içinde çalışır. Müşteri, Qubole'un içeri girmesine izin vermek için bir IAM rolü oluşturur.
Rolün güven politikası, Qubole'un AWS hesabının rolü üstlenmesine izin verir ve bu izinleri verir. Bu işlem, AssumeRole olarak adlandırılır ve her istekte Qubole'dan gelen External ID olarak bilinen eşleşen bir kodun bulunması gerekir.
Wiz araştırmacılarına göre saldırının dışında, saldırganın üstlendiği rollerin çoğu kullanılmıyordu. Ancak her rol hâlâ Qubole'un hesabına güveniyordu, bu yüzden saldırganın istekleri çalıştı.
Qubole'a AWS'yi bağlamış olan her kuruluş, artık kullanmasa bile, 1 Ekim'den itibaren CloudTrail kayıtlarını kontrol etmeli. Aranacak işaret, Qubole platformunun kullandığı 805246085872 hesabından gelen ve AWS dışındaki bir adresten yapılan AssumeRole isteğidir.
Araştırmacılar kimlik bilgilerinin daha sonra devre dışı bırakılıp bırakılmadığını ya da etkinliğin durup durmadığını söylemedi. The Hacker News'in bugün yaptığı kontrolde Qubole ya da Idera sitelerinde saldırıyla ilgili bir açıklama yayınlanmamıştı.
Saldırganın Hesaplara Girmesini Sağlayan Roller
Saldırganla ilişkilendirilen her AssumeRole isteği bir External ID taşıyordu ve kabul ediliyordu; araştırmacılar teknik analizlerinde bunu belirtti.
AWS, istek güvenilen hesaptan geldiğinde ve doğru External ID eklendiğinde bu tür bir rol için AssumeRole isteğini kabul eder. Kod bir sır olarak değerlendirilmez ve role erişimi olan herkes AWS'nin dış kimlik rehberine göre bunu görebilir.
Sentra, etkinliği birkaç müşterinin ortamında tespit etti ve araştırmacıları uyardı.
Araştırmacıların incelediği hesaplarda saldırgan saklanan kimlik bilgilerini aradı. Lambda fonksiyonlarının ortam değişkenlerini okudu, Secrets Manager'dan sırları çekti ve SSM Parameter Store'daki değerleri okudu.
Ardından bulduğu kimlik bilgilerini çalışıp çalışmadığını test etmek için TruffleHog'dan geçirdi. Bunlar mağdurların kendi AWS erişim anahtarları, Entra ID istemci sırları ve Okta istemci kimlik bilgileriydi.
Saldırgan S3'ten de veri kopyaladı. Bir rolü erişebildiği her kovadan veri aldı, belirli verileri aramak yerine bazen tek bir oturumda tüm kovayı indirdi.
Araştırmacılar bu kampanyayı başka bir kamuoyuna bildirilen faaliyete bağlamadı ve hedeflemenin devlet destekli grupların genellikle peşinden gittiğiyle uyuşmadığını söyledi.
Qubole, müşterilerin rol yerine AWS erişim anahtarlarıyla da bağlanmasına izin verir. 8 Ekim'den 11 Ekim'e kadar bir saldırgan Qubole için kurulmuş olan müşterilerin kendi AWS erişim anahtarlarını kullandı.
Bu saldırgan daha sonra mağdurların birkaç bulut ortamını tehlikeye attı. Bu etkinlik AssumeRole kötüye kullanımıyla ilişkilendirilmedi.
Hesaplarınızı Nasıl Kontrol Edersiniz
Wiz'in avlanma rehberi, Qubole rolü bulunan her AWS hesabında 1 Ekim'den itibaren CloudTrail kayıtlarını kapsar. Şunlara bakın:
Hesap: userIdentity.accountId değeri 805246085872 olan ve sourceIPAddress AWS adresi olmayan AssumeRole istekleri. Araştırmacılar Qubole'un gerçek trafiğinin yalnızca AWS'den geldiğini gördü.
IAM asıl kimlik ID'si: AIDA3W7DIFLYOLTK63SFS. Araştırmacıların incelediği hesaplarda yalnızca saldırganın kullandığı bu IAM kullanıcısından gelen her etkinlik araştırılmalı.
IAM asıl kimlik ID'si: AIDAJYRRH5Y3A7AAJM2HW, kaynak adresi AWS dışındayken. Saldırgan bu IAM kullanıcısını 18 Ekim'den itibaren kullandı, ancak Qubole'un normal trafiği de bunu kullanıyor.
IP: 57.129.54[.]120 ve 2001:41d0:70d[:]7800::, saldırganın kullandığı OVH barındırılan adresler.
IP: 45.83.220[.]211, 185.209.199[.]73 ve 89.37.63[.]175, Mullvad VPN adresleri. Diğer VPN kullanıcıları da bunları paylaştığı için tek başına eşleşme kanıt değildir.
Oturum adı: quiam- ile başlayan rol oturumları, örneğin quiam-enum.
Kullanıcı aracısı: Yukarıdaki IP adreslerinden birinden gelen GetCallerIdentity çağrılarında TruffleHog. Aynı kullanıcı aracısını kimlik sağlayıcınızın oturum açma kayıtlarında arayın.
Her şüpheli oturum için sonrasında ne yaptığını gözden geçirin, özellikle Secrets Manager, SSM Parameter Store, Lambda ve S3'te.
CloudTrail yönetim etkinlikleri her AssumeRole isteğini ve kova listeleme işlemini kaydeder, ancak hangi S3 nesnelerinin okunduğunu kaydetmez. Bunun için S3 veri etkinlikleri veya S3 sunucu erişim günlükleri gerekir. Bazı mağdurların gerekli günlükleri yoktu, bu yüzden müdahale ekipleri saldırganın hangi nesneleri okuduğunu belirleyemedi.
Erişimi Nasıl Kapatılır
Araştırmacılar şu adımları öneriyor:
Saldırgan Qubole rollerinizden birini üstlendiyse, rolün erişebildiği tüm sırları, parametreleri ve Lambda ortam değişkenlerini döndürün ve rolün aktif oturumlarını iptal edin. Bir kimlik bilgisini döndürmek, daha önce verilmiş oturumların sona ermesini sağlamaz.
Artık ihtiyaç duymadığınız her Qubole rolünü kaldırın veya Qubole'un hesabını güven politikasından çıkarın.
Qubole bunu destekliyorsa, güven politikasındaki hesap geneli :root asıl kimliğini Qubole'un kullandığı belirli IAM asıl kimliğiyle değiştirin.
AssumeRole isteklerini satıcının belgelediği ağ aralıklarıyla sınırlayan bir aws:SourceIp veya aws:SourceVpce koşulu ekleyin. Bu saldırıda araştırmacılar, "bir kaynak IP koşulu tek başına gözlemlediğimiz her rol üstlenme işlemini engellerdi" dedi.
External ID'nin başkaları tarafından görülebileceğini varsayın. CloudTrail'de düz metin olarak kaydedilir ve satıcılar ile altyapı-olarak-kod dosyalarında sıkça saklanır, bu yüzden tek kontrol olarak kullanmayın. Bu tür bir olaydan sonra Qubole için değiştirin ve mümkünse her rol için farklı bir değer kullanın.
Her satıcı rolünün erişebildiği alanları gözden geçirin. Qubole'un kurulum kılavuzu, rolün hesapta her kovayı okumasına izin veren örnek bir S3 politikası içerir. Araştırmacılara göre satıcı rolleri kolaylık için genellikle Lambda ayarlarına, Secrets Manager'a, SSM parametrelerine ve geniş S3 okuma izinlerine erişim verilir.
Satıcı hesabından bir VPN üzerinden veya satıcının daha önce kullanmadığı bir barındırma şirketinden gelen AssumeRole istekleri için uyarı ayarlayın.
Her hesap ve bölge için bir organizasyon izi kaydedin ve hassas veri depolayan kovalar için S3 veri etkinliklerini veya sunucu erişim günlüklerini etkinleştirin.
