AWS arızasından sonra hesap ele geçirilmesi

Son zamanlarda AWS'de yaşanan bir hizmet kesintisi sonrası bir kullanıcının kendi AWS hesabının dış saldırgan tarafından ele geçirilmesi olayıyla karşılaştığı bildirildi.

İhlal yöntemi ve sorun durumu

• Kesinti sırasında bazı güvenlik politikalarının düzgün çalışmayabileceği belirtilmişti
• Saldırgan, kesintiden sonra hesap günlüklerinde anormal erişim izleri bıraktı ve bazı kaynaklarda beklenmedik şekilde oluşturma/silme olayı yaşandı
• Kullanıcı, kesintiye ek olarak izin değişiklikleri veya kimlik bilgisi sızıntısı olasılığına ilişkin endişesini dile getirdi

Zarar ve yanıt

• Maliyet artışı, veri sızıntısı gibi somut zararlar oluştu
• AWS destek ekibiyle iletişime geçilerek olay geçmişi ve müdahale yöntemi konusunda bilgi talep edildi
• Topluluk, iki faktörlü kimlik doğrulama etkinleştirme, rol tabanlı erişim yetkisinin minimuma indirilmesi gibi önleyici güvenlik adımlarının önemini vurguladı

[GN⁺]

Hacker News Yorumları

• Bu tip olayları genelde rastlantı kabul ederim ama ben de bir müşteri hesabının ele geçirildiği bir örneğe sahibim. Müşteri küçük bir organizasyondu ve beş yıldan fazla kullanılmayan iki eski IAM hesapta aniden konsol oturum açma ve parola değiştirme geçmişi oluştu. Araştırma sonucunda bugüne kadar bulunan tek şey, AWS SES production erişiminin açılması ve günlük 50.000 e-posta limitini yükseltmek için bir destek bileti bırakılmasıydı. Beş yılın üstünde inaktif kalan hesabın tam o anda etkinleşmesi çok tuhaf.

  • Bu, phishing saldırısı kokusu veriyor. Örneğin birisine AWS kesinti bildirimi gibi görünen bir e-posta gönderilip konsol oturumuna yönlendirilirse ve kötü niyetli bir wrapper ile kimlik doğrulama yapılırsa hesap güvenliği aşılabilir.
  • Neredeyse aynı olayı bir yıl önce de yaşadık. Çok eski bir hesapla giriş yapıldı, ardından SES erişimi alınıp e-posta limiti artırma talebinde bulunuldu. Bizim hızlı müdahale edebilmemizin nedeni, limit artışı için bir biletin zorunlu olmasıydı. Henüz kontrol etmediyseniz yeni oluşturulan rolleri de kontrol etmelisiniz. Biz ele geçirilen hesabı anında kaldırdık; genel olarak rolleri gözden geçirirken bir aydan genç veya admin yetkisi olanları da sildik. Ayrıca ihlalin gerçekten benim anahtarlarımdan başladığını da gördük. İlk kullanıcının oluşturulma zamanı, gerçek SES talebinden neredeyse bir ay önceydi; saldırganın zaten bizi ele geçirmiş olduğu anda AWS arızasını fırsat bilmiş olması da mümkün. Diğer AWS sorunlarına karıştığı için bunun fark edilmesi zorlaştı.

• Zaten erişimi ele geçiren birinin, AWS altyapısındaki kargaşa gibi bir olayın patlak vermesini bekleyip o an saldırıya geçip kaosa saklanması mümkün mü diye düşünmeden edemiyorum. Tokenlar haftalarca veya aylarca önce sızmış bile olsa, hemen harekete geçmek yerine büyük bir olayın olmasını beklemek bir strateji olabilir. Ben saldırgan olsaydım böyle bir yöntemi denemek isterdim.

  • Elbette mümkün. Mümkün olan bu senaryoyu denetim tarafında da çok duydum. Saldırganlar her şeyi önceden hazırlar, şirket satışı gibi kritik bir olay olana kadar bekler ve sonra harekete geçerler. Daha ileri saldırganlar bu fırsatları avlamak için proaktif şekilde hazır olur.
  • Aynı ekipten biri olarak, bugün istismar edilen anahtarla ilgili bir uyarı e-postasını iki yıl önce rastgele birinden aldığımı ekleyeyim. Ama dünden önce hiç bir istismar tespit edilmemişti.
  • Hatta bu durum aslında saldırı için kötü bir zamanlama olabilir. Herkes şu anda AWS’ye bakıyor ve çok giriş yapıyor; bu yüzden anormalliklere daha hassas bakacağını düşünüyorum. Eğer şirketimiz AWS kullanıyorsa böyle bir durumda her şeyi daha da dikkatle izlerdik.

• Ben saldırgan olsaydım saldırı zamanını seçerken, log toplamının bile düzgün çalışmadığı büyük bir arıza durumunu iyi bir fırsat olarak görürdüm. Gerçekte sistem zaten ihlal edilmişken bu anda kötüye kullanım yapılmış olabilir veya AWS arızasını kullanıp kendi kaynaklarımla farklı bir saldırı yürütmüş olabilirler.

• Cloud ortamında bir şeyler ters giden bir kaynak (ör. EC2) oluştuğunda bunun hangi olayla yaratıldığını CloudTrail’de görebilirsiniz. Örneğin RunInstances olayına bakarsanız genelde yeterli olur.

  • Son zamanlarda AWS kullanmadığım için doğrudan konsola bakamıyorum ama benzer bir şey yaşarsanız kabaca şu adımları öneririm:
    1. EC2’yi oluşturan hesap/aktörü tespit edin (eventSource:ec2.amazonaws.com, eventName:RunInstances)
    2. userIdentity üzerinden takip eden eylemleri inceleyin
    3. Konsol doğrudan oturum açma geçmişini doğrulayın (eventSource:signin.amazonaws.com, userIdentity.type:[Root/IAMUser/AssumedRole/FederatedUser/AWSLambda], eventName:ConsoleLogin)
    4. Security Token Service üzerinden kimlik doğrulama isteği geçmişini kontrol edin (eventSource:sts.amazonaws.com, eventName:GetSessionToken)
    5. STS oturumu üzerinden AssumeRole kullanımı var mı kontrol edin (eventSource:sts.amazonaws.com, eventName:AssumeRole)
    6. Yeni IAM Role/Hesap oluşturma gibi kalıcılığı koruma girişimlerini kontrol edin (eventSource:iam.amazonaws.com, eventName:CreateUser/ DeleteUser)
    7. Var olan Role/Hesapların daha yüksek yetkiye güncellenip güncellenmediğini kontrol edin (eventSource:iam.amazonaws.com, eventName:CreateRole/DeleteRole/AttachRolePolicy/DetachRolePolicy)
    8. Access Key oluşturma/silme geçmişini kontrol edin (eventSource:iam.amazonaws.com, eventName:CreateAccessKey/DeleteAccessKey)
    9. Üretim EC2’de IAMInstanceProfile değişikliğiyle backdoor olasılığını kontrol edin (detaylı referans için AWS Docs örneği referans alın) Daha derin bir ihlal şüphesi varsa, uzmanlardan ortam denetimi ve güvenlik auditi yaptırmanızı öneririm
  • Faydalı bilgiler bunlar, logları mutlaka inceleyeceğim. Ayrıca gözlemlediklerimden bazıları:
    1. Root hesap altında 20 kadar organizasyon oluşturulmuş ve hepsi aynı alan adını (co.jp) kullanan e-postalara sahipti
    2. Saldırgan, birden fazla fargate şablonu hazırlamış
    3. 16-17 AWS bölgesinde kaynak oluşturulmuş
    4. SES, WS Fargate kaynak kotası artırma isteği, SageMaker notebook bakım talebi gibi gereksiz kaynak talepleri oluşmuş (bununla ilgili birden fazla uyarı e-postası alındı)
    5. Bazı e-postalara yeni adlar (random [e-mail]) eklenmiş
    6. RunInstances olayı doğrudan o olaydı

• Bazı Reddit kullanıcıları, AWS arızası sırasında sayfayı yenilerken tamamen farklı bir kullanıcıyla kısa süreli oturum açtıklarını bildirmiş.

  • Benim de eskiden çalıştığım şirkette benzer bir şey olmuştu. Müşterilerin farklı müşteri verilerine erişmesi vardı, kökeni canlı üretim ortamında canlı hata ayıklama yapan yanlış çalışan kişiden gelmişti (mülakatlarda işe alıma karşı çıktığım kişiymişti, araya böyle bir not). Böyle bir sorunu takip edip çözmek gerçekten zordu.
  • Acaba arıza zamanında DynamoDB geçici bir tutarsızlığa düşüp IAM kimlik bilgilerine de etki etmesi mümkün mü? Eğer doğruysa çok ciddi bir mesele olurdu. Bu konuya dair benzer bir örnek için link var mı merak ediyorum.
  • İlgili kanıtlarınız varsa paylaşırsanız iyi olur. Gerçekten çarpıcı.
  • Son zamanlarda ChatGPT’de de benzer bir olay yaşanmadı mı diye düşündüm, bir şeyler aynı gibi.
  • Bu tür güvenlik olayları basit bir geçici hizmet kesintisiyle karşılaştırılamayacak kadar ağır.

• Normalde bu olaylar rastlantı olarak görülebilir ama genelde sebep açığa çıkan access key’ler oluyor. MFA kullanılmayan bir konsol hesabının parolasının açığa çıkmasıyla olanlar da oluyor ama daha nadir.

• Panik anlarında insanlar phishing’e en açık hâle gelir. Her şeyi şifre sıfırlama kampanyasıyla kapatıp AWS yetkililerine durumu bildirmek gerekir. Genelde güvene dayalı olarak işler kolay çözülür.

• us-east-1 bölgesi düşündüğümüzden çok daha büyük. En son açıklanan verilere göre 159 veri merkezinden söz ediliyor. Yüz binlerce değil milyonlarca hesabın orada yoğunlaşmış olması mümkün. Bu durumun AWS arızasıyla bağlantılı olabileceğini de söylüyorlar ama benim fikrimce tesadüf olma ihtimali daha yüksek.

  • 159 tane olması şaşırtıcı. Güvenilir bir kaynak bulursanız lütfen paylaşın.

• Kulağa garip gelecek ama eğer API key gönderirseniz sızıntı listelerinde var mı bakabilirim gibi bir şey düşünüyorum.

  • Bunu bir şaka olduğunu biliyorum, ancak yine de önemli bir uyarı yapmak istiyorum. Şaka dahi olsa, API key veya kimlik bilgisi paylaşımıyla ilgili bir şey paylaşmayın. İnsanlar bunu ciddiye alabilir, bu yüzden dikkatli olmalıyız.