Wiz’in son incelemesine göre, Qubole’un AWS üzerinde çalışan müşteri entegrasyonları üzerinden yürüyen saldırıda çalınmış kimlik bilgileri kullanıldı ve birden fazla müşterinin hesabında veri toplandı. Saldırgan, Qubole’un platformunun müşteriler adına rol üstlenmek için kullandığı AWS hesabına ait yetkilerle, müşterilerin daha önce Qubole’a güvenmek için oluşturduğu IAM rolleri devraldı.
Saldırı Ekim ayı boyunca izlendi. Wiz, olayın 14 Ekim’de başladığını, faaliyetin 26 Ekim’e kadar sürdüğünü ve ilk erişimin VPN ile barındırma altyapıları üzerinden geldiğini bildirdi. İncelemeye göre saldırgan, Qubole’un cross-account erişim modelini hedef aldı; yani bir tedarikçi hesabının müşterinin AWS hesabındaki rolü üstlenmesine izin veren yapıyı suistimal etti.
Qubole’a güvenen IAM rolleri nasıl açıldı
Qubole, Idera bünyesindeki bir veri gölü platformu olarak müşterilerin kendi AWS hesapları içinde çalışıyor. Kurulum sırasında müşteri, Qubole’un AWS hesabının üstlenebileceği bir IAM rolü oluşturuyor. Bu rolde yer alan trust policy, Qubole’un hesabını yetkili taraf olarak tanımlıyor ve her AssumeRole isteği için bir External ID eşleşmesi bekliyor.
AWS dokümantasyonuna göre External ID, üçüncü taraf erişiminde rolü üstlenen tarafın durumu doğru biçimde beyan etmesini sağlıyor; ancak sır gibi saklanması gerekmiyor. Her iki tarafın da bildiği bu değer, rolün trust policy’sinde kontrol amaçlı kullanılıyor. Qubole’un kendi dokümanları da müşterilere cross-account IAM role kullanma seçeneği sunduğunu, bunun AWS erişim anahtarlarına alternatif olduğunu gösteriyor.
Wiz araştırmacıları, saldırganın kullandığı AssumeRole çağrılarının tamamında geçerli bir External ID bulunduğunu ve isteklerin kabul edildiğini aktardı. Kurallı bir trust policy olduğu için AWS, doğru hesap ve doğru External ID ile gelen talebi onayladı. Buradaki kritik nokta, saldırganın bu erişimi alabilmek için rolün sahibinden bir AWS gizli anahtarı çalmak zorunda olmamasıydı; Qubole’un hesabı zaten güvenilen taraf olarak tanımlanmıştı.
İnceleme sırasında kullanılan IAM kullanıcı kimliği AIDA3W7DIFLYOLTK63SFS oldu. Araştırmacılar, inceledikleri ortamlarda bu kimliğin saldırı dışındaki herhangi bir faaliyette görünmediğini söyledi. 14 Ekim’de ilk çağrı Mullvad VPN’e ait 45.83.220[.]211 adresinden geldi. 15 Ekim’den itibaren ise trafiğin çoğu OVH üzerinde barındırılan 57.129.54[.]120 adresinden aktı.
Wiz, 18 Ekim’den itibaren aynı IAM kullanıcısının farklı bir davranışla da görüldüğünü, ancak Qubole’un normal trafiğinde de kullanılan başka bir kimlik olan AIDAJYRRH5Y3A7AAJM2HW ile bağlantılı istekler bulunduğunu belirtti. Bu nedenle araştırmacılar, bu kimlikle eşleşen tüm faaliyetlerin kaynak adresine bakılarak ayrıca incelenmesini önerdi. Saldırganın kullandığı IP’ler arasında 2001:41d0:70d[:]7800:: adresi de yer aldı.
Secrets Manager, SSM ve S3 üzerinden veri toplandı
Saldırgan, içeri girdikten sonra ortamdaki varlıkları tek tek saydı, yapılandırmaları çekti ve gizli bilgileri toplamaya yöneldi. Özellikle Lambda işlevlerinin ortam değişkenlerini okudu, Secrets Manager içindeki sırları aldı ve SSM Parameter Store’daki değerleri çekti. Ardından bulduğu kimlik bilgilerini TruffleHog ile test etti. Bu aşamada kurbanlara ait AWS access key’ler, Entra ID client secret’ları ve Okta client credential’ları doğrulanmaya çalışıldı.
Wiz’in bulgularına göre saldırgan, S3 tarafında da rolün erişebildiği depolara yöneldi. Belirli bir dosya ya da klasör aramak yerine, rolün ulaşabildiği her bucket içinden veri aldı; bazı durumlarda tüm bucket’ı tek oturumda indirdi. Ancak CloudTrail yönetim olayları yalnızca AssumeRole isteğini ve bucket listelemelerini kaydettiği için, hangi nesnelerin okunduğu her zaman anlaşılamadı. Bazı mağdurların S3 data events ya da server access log’ları olmadığı için müdahale ekipleri okunan objeleri netleştiremedi.
Araştırma, bu kampanyayı daha önce kamuya yansımış başka bir operasyonla eşleştirmedi. Hedefleme biçiminin de devlet destekli grupların tipik ilgi alanıyla örtüşmediği ifade edildi. Sentra, kendi müşteri ortamlarında benzer şüpheli faaliyetleri görüp araştırmacıları uyardı; inceleme bu bildirim üzerine genişletildi.
Qubole’un erişim modelinde yalnızca IAM rolleri yok. Platform, bazı müşteriler için kendi AWS access key’leriyle bağlanma seçeneği de sunuyor. Wiz, 8 Ekim ile 11 Ekim arasında bir saldırganın bu yöntemle, yani müşterilere ait access key’leri kullanarak farklı ortamlara girdiğini ve birkaç kurbanın cloud çevresini ele geçirdiğini bildirdi. Araştırmacılar bu faaliyetin, AssumeRole suistimaliyle bağlantılı olmadığını söyledi.
Bulut ekipleri hangi izleri arıyor
Wiz’in avcılık rehberi, 1 Ekim’den sonraki CloudTrail kayıtlarında Qubole rolü bulunan tüm AWS hesaplarının kontrol edilmesini istiyor. İlk bakılacak işaret, userIdentity.accountId değeri 805246085872 olan ve sourceIPAddress alanı AWS dışından gelen AssumeRole istekleri. Araştırmacılar, Qubole’un normal trafiğinin yalnızca AWS içinden geldiğini vurguladı.
İnceleme sırasında öne çıkan bir diğer unsur, AIDA3W7DIFLYOLTK63SFS principal ID’si. Bu kimlikle ilgili herhangi bir aktivite, araştırmacılara göre ayrıntılı olarak incelenmeli. AIDAJYRRH5Y3A7AAJM2HW içinse yalnızca kaynak adresi AWS dışında olduğunda alarm üretilmesi öneriliyor. Saldırganın kullandığı diğer IP’ler arasında 57.129.54[.]120, 2001:41d0:70d[:]7800::, 45.83.220[.]211, 185.209.199[.]73 ve 89.37.63[.]175 sayılıyor; bunların bir kısmı OVH ve Mullvad VPN altyapılarında yer alıyor.
Oturum adlarında quiam- ile başlayan kalıplar, örneğin quiam-enum, saldırganın iz bıraktığı başka bir ayrıntı olarak öne çıktı. TruffleHog user agent’ı ile yapılan GetCallerIdentity çağrıları da özellikle bu IP’lerden geliyorsa şüpheli kabul ediliyor. Aynı user agent’ın kurumun kimlik sağlayıcısındaki oturum açma günlüklerinde de aranması gerekiyor.
Wiz, şüpheli bir oturum görüldüğünde sonrasında yapılan her işlemin ayrı ayrı incelenmesini istedi. Özellikle Secrets Manager, SSM Parameter Store, Lambda ve S3 içinde hangi işlemlerin gerçekleştiği netleştirilmeli. Çünkü saldırgan bir kez rolü ele geçirdikten sonra yalnızca rolün tanımlı yetkilerini kullanıyor; yani yetki kapsamı genişse erişebileceği alan da genişliyor.
Şirket, saldırının nasıl durdurulacağına dair teknik adımları da sıraladı. Eğer saldırgan kurumun bir Qubole rolünü üstlendiyse, o role erişebilen tüm secret, parameter ve Lambda ortam değişkenlerinin yenilenmesi gerekiyor. Aktif oturumların iptali de gerekli; çünkü bir kimlik bilgisini değiştirmek, önceden verilmiş geçici oturumları otomatik olarak sonlandırmıyor.
Wiz ayrıca artık ihtiyaç duyulmayan Qubole rollerinin kaldırılmasını ya da Qubole’un hesabının trust policy’den çıkarılmasını önerdi. Qubole’un desteklediği durumlarda, trust policy içindeki account-wide :root tanımı yerine Qubole’un kullandığı belirli IAM principal’ının yazılması da tavsiye ediliyor. Böylece tüm hesap yerine tek bir kimlik sınırlandırılmış oluyor.
Bir başka öneri, AssumeRole isteklerine aws:SourceIp ya da aws:SourceVpce koşulu eklenmesi. Araştırmacılara göre bu saldırıda sadece kaynak IP şartı bile gözlenen tüm rol devralma girişimlerini engelleyebilirdi. Ancak bunun tek başına yeterli bir güvenlik önlemi olarak görülmemesi gerektiği de raporda açıkça not edildi; External ID’nin CloudTrail’de düz metin olarak kaydedildiği ve altyapı-kod dosyalarında da sıkça tutulduğu hatırlatıldı.
Qubole rolleri geniş yetkilerle kurulabiliyor. Şirketin kurulum rehberindeki örnek S3 politikası, role hesap içindeki tüm bucket’ları okuma izni verebiliyor. Araştırmacılar, tedarikçi rollerine pratiklik uğruna Lambda ayarlarına, Secrets Manager’a, SSM parametrelerine ve geniş S3 okuma izinlerine sıkça erişim tanındığını belirtti. Bu nedenle her vendor rolünün nereye ulaşabildiği ayrıca gözden geçirilmeli.
Son olarak Wiz, vendor hesabından gelen AssumeRole istekleri için VPN ya da daha önce kullanılmamış bir hosting sağlayıcıdan gelen oturumlara alarm kurulmasını istedi. Organizasyonların tüm hesap ve bölgeleri kapsayan bir organization trail kullanması, ayrıca hassas veri tutan bucket’larda S3 data events ya da server access log’larını açması da öneriler arasında yer aldı.