EresusSecurity
Araştırmalara Dön
Zafiyet Analizi

Qubole Güvenilir AWS Erişim İhlali: Müşterilerini Ziyaret Eden Satıcı Rolü

Yiğit İbrahim SağlamOfansif Güvenlik Uzmanı
9 Kasım 2026
3 dk okuma
Çatlamış taş bulut kasası ve parçalanmış ışık yayan asma kilit, turuncu ışıklı raflar arasında karanlık sunucu odasında duruyor.
VulnerabilityAnalysisCloud Security

Qubole Güvenilir AWS Erişim İhlali: Satıcı Rolü Müşterilerini Ziyade Eden Saldırı

Saldırgan, 14-26 Ekim arasında birden fazla Qubole müşterisinin AWS hesabına girdi ve saklı secret'ları çaldı; Wiz'in teknik analizi bunu kamuoyuna açıkladı.

Saldırgan, Qubole platformunun bu müşterilere ulaşmak için kullandığı bir AWS hesabının kimlik bilgilerini kullandı. Kimlik bilgilerinin nasıl ele geçirildiği açıklanmadı.

Satıcı Rolleri Nasıl Çalışır

Idera'ya ait bir veri gölü platformu olan Qubole, müşterilerinin AWS hesaplarının içinde çalışır. İçeri girebilmesi için müşteri bir IAM rolü oluşturur — bu, kendi izin kümesine sahip bir AWS kimliğidir. Rolün güven politikası, Qubole'nin AWS hesabının bu rolü üstlenmesine (AssumeRole) izin verir. Her AssumeRole isteği, Qubole'den gelen eşleşen bir kod olan External ID içermek zorundadır.

Saldırı dışında, saldırganın üstlendiği roller çoğunlukla kullanılmıyordu — ama her biri Qubole'nin hesabına güvendiği için saldırganın istekleri çalıştı.

Saldırgan İçeride Neler Yaptı

İncelenen hesaplarda saldırgan saklı kimlik bilgisi aradı: Lambda ortam değişkenlerini okudu, Secrets Manager'dan secret çekti ve SSM Parameter Store değerlerini okudu. Bulduğu kimlik bilgilerini TruffleHog ile test etti — bunlar kurbanların kendi AWS erişim anahtarları, Entra ID istemci secret'ları ve Okta istemci bilgileriydi.

Ayrıca S3'ten veri kopyaladı. Belirli veri aramak yerine, bir rolün erişebildiği her şeyi çekti ve bazen tek oturumda bütün bir bucket'ı indirdi.

Qubole, müşterilerinin AWS erişim anahtarlarıyla da bağlanmasına izin verir. 8-11 Ekim arasında ayrı bir saldırgan, Qubole için kurulduğu düşünülen müşterilerin kendi anahtarlarını kullanarak birkaç kurban ortamını ele geçirdi. İki saldırı birbirine bağlanmadı.

External ID Sorunu

Rahatsız edici ders, External ID'nin gizli olmadığıdır. Saldırganın her AssumeRole isteği geçerli bir External ID taşıdı ve kabul edildi. AWS'in kendi External ID rehberi bu kodun rolü erişebilen herkesçe görülebileceğini söyler. CloudTrail'de düz metin olarak loglanır; satıcılar ve IaC dosyaları çoğu zaman saklar.

Alıntılanan bir sensör bunu özetler: araştırmacılar "tek başına bir kaynak IP koşulunun gözlemlenen her rol üstlenmesini engelleyeceğini" söyledi. Çözüm mekaniktir — satıcı desteklediği yerlerde aws:SourceIp veya aws:SourceVpce ile sınırlayın.

Hesaplarınızı Nasıl Denetlemelisiniz

Wiz'in av rehberi, Qubole rolü barındıran her AWS hesabında 1 Ekim sonrası CloudTrail log'larını kapsar:

  • Hesap: userIdentity.accountId değeri 805246085872 olan ve sourceIPAddress'i AWS adresi olmayan AssumeRole istekleri — Qubole'nin gerçek trafiği yalnızca AWS'ten gelir.
  • Principal ID: AIDA3W7DIFLYOLTK63SFS — incelenen hesaplarda yalnızca saldırgan kullandı.
  • Principal ID: AWS dışı kaynaktan AIDAJYRRH5Y3A7AAJM2HW — saldırgan 18 Ekim'den itibaren kullandı, ancak Qubole'nin normal trafiği de bunu kullanır.
  • IP'ler: 57.129.54[.]120, 2001:41d0:70d[:]7800:: (OVH) ve Mullvad VPN çıkışları — eşleşme tek başına kanıt değil.
  • Oturum adları quiam- ile başlayanlar, örn. quiam-enum.
  • User agent: Yukarıdaki IP'lerden GetCallerIdentity çağrılarında TruffleHog.

CloudTrail yönetim olayları, her AssumeRole ve bucket listeleme işlemini loglar ancak hangi S3 nesnelerinin okunduğunu göstermez. Bunun için S3 veri olayları veya sunucu erişim log'ları gerekir — birkaç kurbanın bunlar yoktu; yanıt verenler hangi nesnelerin okunduğunu belirleyemedi.

Bu Yolu Nasıl Kapatırsınız

  1. Ele geçirilen rolün ulaşabildiği tüm secret, parametre ve Lambda ortam değişkenlerini döndürün ve rolün aktif oturumlarını iptal edin. Kimlik bilgisini döndürmek zaten verilmiş oturumları bitirmez.
  2. Kullanılmayan Qubole rollerini kaldırın ya da Qubole'nin hesabını güven politikasından çıkarın.
  3. Qubole desteklediğinde hesabı değiştiren :root principal'leri, kullandığı spesifik IAM principal'iyle değiştirin.
  4. AssumeRole isteklerini satıcının belgelenmiş ağ aralıklarıyla sınırlayan aws:SourceIp / aws:SourceVpce koşulları ekleyin.
  5. External ID'yi rol başına değiştirin; bir kontrol olarak değil, tanımlayıcı olarak kabul edin.
  6. Satıcı rollerinin erişebildiği alanları gözden geçirin — Qubole'nin kendi kurulum rehberi, hesapta her bucket'tan okumaya izin veren bir örnek S3 politikası içerir.
  7. Satıcı hesabından gelen AssumeRole istekleri VPN veya bilinmeyen hosting üzerinden geldiğinde uyarı verin.
  8. Kuruluş genelinde bir CloudTrail bulun ve hassas veriler için S3 veri olaylarını etkinleştirin.

Kaynaklar

AI Security Başlangıç Eğitimi

Prompt injection, RAG veri sızıntısı, MCP riskleri ve model dosyası güvenliği için pratik kontrol listesini e-posta ile isteyin.

Prompt injection ve koruma kuralı atlatma kontrolleri.
RAG veri sızıntısı ve izin sınırı incelemesi.
MCP kimlik, taşıma ve komut riski kontrolleri.

Spam yok. Yalnızca kaynağı ve ilgili güvenlik notlarını paylaşmak için kullanılır.

İlgili Hizmetler

Kapsam Tahmini

Kapsam görüşmesinden önce tahmini çalışma büyüklüğünü öğrenin.

Bu derinlik neyi kapsar
Kapsamdaki hedefler için OWASP test planının tam uygulaması: kırık erişim kontrolü, enjeksiyon, kimlik doğrulama ve yetkilendirme kusurları, iş kuralı kötüye kullanımı, yeniden üretim adımlarıyla bulgular.
Neyi kapsamaz
Haftalar süren rakip simülasyonu, fiziksel ve oltalama vektörleri, özel istismar geliştirmesi, kaynak kod incelemesi.

Tahmini efor

~5 testci-günü

Bu bir tahmindir, teklif değil. Yukarıdaki üç faktörle ölçeklenir; hedeflerin test penceresi içinde erişilebilir olduğunu ve test hesaplarının sağlandığını varsayar.

Kesin kapsam talebi