Qubole Müşteri AWS Hesapları Güvenlik İhlali: Veri Hırsızlığı ve Erişim İpuçları

Qubole Müşteri AWS Hesapları Güvenlik İhlali: Veri Hırsızlığı ve Erişim İpuçları

Bulut güvenlik şirketi Wiz’in açıklamasına göre, 14 Ekim ile 26 Ekim tarihleri arasında Qubole’un birden fazla müşterisine ait AWS hesaplarına bir saldırgan sızdı. Saldırgan, depolanan gizli bilgileri ve verileri ele geçirdi. Bu sızma, Qubole platformunun müşterilere erişmek için kullandığı bir AWS hesabına ait kimlik bilgileri aracılığıyla gerçekleşti. Saldırganın bu kimlik bilgilerini nasıl elde ettiği henüz açıklanmadı.

Idera’ya ait bir veri gölü platformu olan Qubole, müşterilerinin AWS hesapları içinde çalışır. Bu erişimi sağlamak için müşteriler, kendi izin setine sahip bir AWS kimliği olan bir IAM rolü oluşturur. Rolün güven politikası, Qubole’un AWS hesabının bu rolü üstlenmesine izin vererek ilgili izinleri verir. “AssumeRole” olarak adlandırılan bu işlemi gerçekleştiren her istek, Qubole’dan gelen eşleşen bir Harici Kimlik (External ID) kodu içermelidir.

Wiz araştırmacılarına göre, saldırganın üstlendiği rollerin çoğu kullanılmıyordu. Ancak her rol yine de Qubole’un hesabına güveniyordu, bu nedenle saldırganın istekleri başarılı oldu. Qubole’u AWS’ye bağlamış olan, hatta artık kullanmayan her kuruluş, 1 Ekim’den itibaren CloudTrail günlüklerini kontrol etmelidir. Aranacak işaret, Qubole platformunun kullandığı 805246085872 numaralı hesaptan gelen ve AWS dışındaki bir adresten kaynaklanan bir AssumeRole isteğidir.

Araştırmacılar, kimlik bilgilerinin devre dışı bırakılıp bırakılmadığını veya faaliyetin durup durmadığını belirtmedi. The Hacker News’in kontrol ettiği tarihte ne Qubole ne de Idera, web sitelerinde saldırıyla ilgili bir açıklama yayınlamıştı.

Saldırganın Rolleri Neden Kullanabildiği

Araştırmacılar, teknik analizlerinde, saldırganla ilişkili her AssumeRole isteğinin bir Harici Kimlik taşıdığını ve kabul edildiğini belirtti. AWS, bu tür bir rol için AssumeRole isteğini, güvenilen hesaptan geldiğinde ve doğru Harici Kimliği içerdiğinde kabul eder. AWS’nin Harici Kimlik rehberine göre, kod bir sır olarak kabul edilmez ve role erişimi olan herkes tarafından görüntülenebilir.

Sentra, faaliyetleri birkaç müşterisinin ortamında tespit etti ve araştırmacıları uyardı. Araştırmacıların incelediği hesaplarda, saldırgan depolanmış kimlik bilgilerini aradı. Lambda fonksiyonlarının ortam değişkenlerini okudu, Secrets Manager’dan gizli bilgileri çekti ve SSM Parameter Store’dan değerleri okudu. Daha sonra bulduğu kimlik bilgilerini TruffleHog aracıyla test ederek çalışıp çalışmadıklarını kontrol etti. Bunlar, kurbanların kendi AWS erişim anahtarları, Entra ID istemci sırları ve Okta istemci kimlik bilgileriydi.

Saldırgan ayrıca S3’ten veri kopyaladı. Belirli verileri aramak yerine, bir rolün erişebileceği herhangi bir kovadan veri aldı ve bazen tek bir oturumda tüm bir kovayı indirdi. Araştırmacılar bu kampanyayı başka hiçbir kamuya açıklanmış faaliyetle ilişkilendirmediler. Hedeflenen grupların devlet destekli grupların genellikle peşinden gittiği gruplarla eşleşmediğini belirtiyorlar.

Qubole ayrıca müşterilerin bir rol yerine AWS erişim anahtarlarıyla bağlanmasına da izin verir. 8 Ekim’den 11 Ekim’e kadar, bir saldırgan, araştırmacıların Qubole için ayarlandığına inandığı müşterilerin kendi AWS erişim anahtarlarını kullandı. Bu saldırgan daha sonra kurbanların birkaç bulut ortamını tehlikeye attı. Bu faaliyet, AssumeRole kötüye kullanımıyla ilişkilendirilmemiştir.

Hesaplarınızı Nasıl Kontrol Edebilirsiniz?

Wiz’in avlanma rehberi, Qubole rolü barındıran her AWS hesabındaki 1 Ekim’den itibaren CloudTrail günlüklerini kapsar. Aranacaklar:

• Hesap: userIdentity.accountId‘nin 805246085872 olduğu ve sourceIPAddress‘in bir AWS adresi olmadığı AssumeRole istekleri. Araştırmacılar, Qubole’un gerçek trafiğinin yalnızca AWS’den geldiğini gördüler.
• IAM principal ID: AIDA3W7DIFLYOLTK63SFS. Bu IAM kullanıcısından gelen herhangi bir faaliyet araştırılmalıdır, çünkü araştırmacıların incelediği hesaplarda yalnızca saldırgan bunu kullandı.
• IAM principal ID: AIDAJYRRH5Y3A7AAJM2HW, kaynak adres AWS dışındaysa. Saldırgan bu IAM kullanıcısını 18 Ekim’den itibaren kullandı, ancak Qubole’un normal trafiği de bunu kullanır.
• IP: 57.129.54[.]120 ve 2001:41d0:70d[:]7800::, saldırganın kullandığı OVH tarafından 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şır, bu nedenle yalnızca bir 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. Kimlik sağlayıcınızın oturum açma günlüklerinde aynı kullanıcı aracısını arayın.

Her şüpheli oturum için, özellikle Secrets Manager, SSM Parameter Store, Lambda ve S3’teki tüm sonraki eylemleri gözden geçirin.

CloudTrail yönetim olayları her AssumeRole isteğini ve kova listelemesini kaydeder, ancak hangi S3 nesnelerinin okunduğunu kaydetmez. Bunun için S3 veri olayları veya S3 sunucu erişim günlükleri gereklidir. Birkaç kurban gerekli günlüklere sahip değildi, bu nedenle yanıt verenler saldırganın hangi nesneleri okuduğunu belirleyemedi.

Erişim Yolunu Nasıl Kapatabilirsiniz?

Araştırmacılar şu adımları önermektedir:

1. Saldırgan Qubole rollerinizden birini üstlendiyse, bu rolün erişebildiği tüm gizli bilgileri, parametreleri ve Lambda ortam değişkenlerini döndürün ve rolün etkin oturumlarını iptal edin. Bir kimlik bilgisini döndürmek, zaten verilmiş olan oturumları sonlandırmaz.
2. Artık ihtiyacınız olmayan Qubole rollerini kaldırın veya Qubole’un hesabını güven politikasından çıkarın.
3. Qubole’un desteklediği yerlerde, güven politikasındaki hesap genelindeki :root principal’ı, Qubole’un kullandığı belirli IAM principal’ı ile değiştirin.
4. AssumeRole isteklerini satıcının belgelenmiş ağ aralıklarıyla sınırlayan bir aws:SourceIp veya aws:SourceVpce koşulu ekleyin. Bu saldırıda araştırmacılar, “yalnızca bir kaynak IP koşulunun gözlemlediğimiz her rol üstlenmesini engellediğini” belirtti.
5. Harici Kimliği başkalarının görebileceğini varsayın. CloudTrail’de düz metin olarak günlüğe kaydedilir ve satıcılar ile altyapı-kod dosyaları genellikle bunu depolar, bu nedenle tek kontrolünüz olarak kullanmayın. Böyle bir olaydan sonra, bunu Qubole olarak değiştirin ve mümkünse her rol için farklı bir değer kullanın.
6. Her satıcı rolünün neye erişebileceğini gözden geçirin. Qubole’un kurulum rehberi, rolün hesaptaki her kovayı okumasına izin veren örnek bir S3 politikası içerir. Araştırmacılara göre, satıcı rolleri genellikle kolaylık sağlamak için Lambda ayarlarına, Secrets Manager’a, SSM parametrelerine ve geniş S3 okuma izinlerine erişim sağlar.
7. Bir satıcı hesabından bir VPN veya satıcının daha önce kullanmadığı bir barındırma şirketi aracılığıyla gelen AssumeRole istekleri için uyarılar ayarlayın.
8. Her hesabı ve bölgeyi bir kuruluş iziyle günlüğe kaydedin ve hassas verileri depolayan kovalar için S3 veri olaylarını veya sunucu erişim günlüklerini etkinleştirin.