19 Temmuz 2019'da Capital One, her modern şirketin korktuğu mesajı aldı: bir veri ihlali meydana geldi. 106 milyondan fazla insanı etkiledi. 140 ABD sosyal güvenlik numarası, bir milyon Kanada sosyal güvenlik numarası. 000 banka hesabı. Hoş değil, sence de öyle değil mi?
Ne yazık ki hack 19 Temmuz'da gerçekleşmedi. Görünüşe göre Paige Thompson, namı diğer düzensiz, bunu 22 Mart ile 23 Mart 2019 tarihleri arasında gerçekleştirdi. Yani neredeyse dört ay önce. Aslında Capital One bir şeylerin olduğunu ancak dışarıdan danışmanların yardımıyla keşfedebildi.
Eski bir Amazon çalışanı tutuklandı ve 250 dolar para cezası ve beş yıl hapis cezasıyla karşı karşıya... ancak hâlâ pek çok olumsuzluk var. Neden? Çünkü hack'lere maruz kalan birçok şirket, siber suçların artmasıyla birlikte altyapılarını ve uygulamalarını güçlendirme sorumluluğunu omuzlarından atmaya çalışıyor.
Neyse, bu hikayeyi kolayca Google'da bulabilirsiniz. Dramaya girmeyeceğiz ama konuşacağız teknik işin tarafı.
Öncelikle ne oldu?
Capital One'da çalışan yaklaşık 700 S3 kovası vardı ve Paige Thompson bunları kopyalayıp sifonladı.
İkincisi, bu da yanlış yapılandırılmış S3 paket politikasının başka bir örneği mi?
Hayır bu sefer değil. Burada, yanlış yapılandırılmış bir güvenlik duvarına sahip bir sunucuya erişim sağladı ve tüm işlemi oradan gerçekleştirdi.
Bekle, bu nasıl mümkün olabilir?
Peki, elimizde çok fazla detay olmasa da sunucuya giriş yaparak başlayalım. Bize yalnızca bunun "yanlış yapılandırılmış bir güvenlik duvarı" aracılığıyla gerçekleştiği söylendi. Bu nedenle, yanlış güvenlik grubu ayarları veya web uygulaması güvenlik duvarının (Imperva) veya ağ güvenlik duvarının (iptables, ufw, shorewall vb.) yapılandırılması kadar basit bir şey. Capital One yalnızca suçunu kabul etti ve açığı kapattığını söyledi.
Stone, Capital One'ın başlangıçta güvenlik duvarı güvenlik açığını fark etmediğini, ancak farkına vardığında hızlı bir şekilde harekete geçtiğini söyledi. Stone, hacker'ın önemli kimlik bilgilerini kamuya açık olarak bıraktığı iddiasının da buna kesinlikle yardımcı olduğunu söyledi.
Bu kısımda neden daha derinlere inmediğimizi merak ediyorsanız, sınırlı bilgi nedeniyle yalnızca spekülasyon yapabileceğimizi lütfen anlayın. Saldırının Capital One'ın bıraktığı bir deliğe bağlı olduğu göz önüne alındığında, bu hiç mantıklı değil. Ve bize daha fazlasını söylemedikleri sürece, Capital One'ın sunucusunu açık bıraktığı tüm olası yolları, birisinin bu farklı seçeneklerden birini kullanabileceği tüm olası yollarla birlikte listeleyeceğiz. Bu kusurlar ve teknikler son derece aptalca gözden kaçırmalardan inanılmaz derecede karmaşık modellere kadar değişebilir. Olasılıkların çeşitliliği göz önüne alındığında, bu, gerçek bir sonucu olmayan uzun bir destan haline gelecektir. Bu nedenle gerçeklerin olduğu kısmı analiz etmeye odaklanalım.
Dolayısıyla ilk çıkarım şu: Güvenlik duvarlarınızın neye izin verdiğini bilin.
YALNIZCA açılması gerekenlerin açılmasını sağlamak için bir politika veya uygun süreç oluşturun. Güvenlik Grupları veya Ağ ACL'leri gibi AWS kaynaklarını kullanıyorsanız, denetlenecek kontrol listesinin uzun olabileceği açıktır... ancak birçok kaynağın otomatik olarak oluşturulduğu gibi (örn. CloudFormation), bunların denetimini de otomatikleştirmek mümkündür. İster yeni nesneleri kusurlara karşı tarayan ev yapımı bir komut dosyası olsun, ister CI/CD sürecindeki güvenlik denetimi gibi bir şey olsun... bundan kaçınmanın birçok kolay seçeneği vardır.
Hikayenin "komik" kısmı şu: Eğer Capital One ilk etapta deliği kapatsaydı... hiçbir şey olmayacaktı. Ve açıkçası, bir şeyin gerçekte nasıl olduğunu görmek her zaman şok edicidir. gayet basit bir şirketin saldırıya uğramasının tek nedeni haline gelir. Özellikle Capital One kadar büyük bir tane.
Peki içerideki hacker, sonra ne oldu?
Bir EC2 örneğine girdikten sonra pek çok şey ters gidebilir. Birinin bu kadar ileri gitmesine izin verirseniz neredeyse bıçak sırtında yürüyorsunuz demektir. Peki S3 kovalarına nasıl girdi? Bunu anlamak için IAM Rollerini tartışalım.
Dolayısıyla AWS hizmetlerine erişmenin bir yolu Kullanıcı olmaktır. Tamam, bu oldukça açık. Peki ya uygulama sunucularınız gibi diğer AWS hizmetlerinin S3 klasörlerinize erişmesine izin vermek istiyorsanız? IAM rolleri bunun içindir. İki bileşenden oluşurlar:
- Güven Politikası - bu rolü hangi hizmetler veya kişiler kullanabilir?
- İzin Politikası - bu rol neye izin veriyor?
Örneğin, EC2 bulut sunucularının bir S3 klasörüne erişmesine izin verecek bir IAM rolü oluşturmak istiyorsunuz: Öncelikle rol, EC2'nin (hizmetin tamamı) veya belirli bulut sunucularının rolü "devralabileceği" bir Güven Politikasına sahip olacak şekilde ayarlanır. Bir rolü kabul etmek, eylemleri gerçekleştirmek için rolün izinlerini kullanabilecekleri anlamına gelir. İkinci olarak, İzin Politikası, "rolü üstlenen" hizmetin/kişinin/kaynağın, ister belirli bir klasöre erişiyor olsun, ister Capital One örneğinde olduğu gibi 3'ün üzerinde olsun, S700 üzerinde herhangi bir şey yapmasına izin verir.
IAM rolüyle bir EC2 bulut sunucusuna girdikten sonra kimlik bilgilerini çeşitli şekillerde alabilirsiniz:
- Örnek meta verilerini şu adresten talep edebilirsiniz:
http://169.254.169.254/latest/meta-dataDiğer şeylerin yanı sıra, bu adresteki erişim anahtarlarından herhangi biriyle IAM rolünü bulabilirsiniz. Tabii ki, yalnızca bir durumdaysanız.
- AWS CLI'yi kullanın...
AWS CLI kuruluysa, varsa IAM rollerinden alınan kimlik bilgileriyle yüklenir. Geriye kalan tek şey örnek üzerinden çalışmaktır. Elbette Güven Politikaları açık olsaydı Paige her şeyi doğrudan yapabilirdi.
Dolayısıyla IAM rollerinin özü, bazı kaynakların DİĞER KAYNAKLAR üzerinde SİZİN ADINA hareket etmesine izin vermesidir.
Artık IAM'in rollerini anladığınıza göre Paige Thompson'ın yaptıklarından bahsedebiliriz:
- Güvenlik duvarındaki bir delikten sunucuya (EC2 örneği) erişim sağladı
İster güvenlik grupları/ACL'ler ister kendi web uygulaması güvenlik duvarları olsun, resmi kayıtlarda belirtildiği gibi açığı kapatmak muhtemelen oldukça kolaydı.
- Sunucuya girdikten sonra sunucunun kendisiymiş gibi “sanki” davranabildi
- IAM sunucusu rolü S3'ün bu 700'den fazla klasöre erişmesine izin verdiği için bunlara erişebildi
O andan itibaren tek yapması gereken komutu çalıştırmaktı. List Bucketsve ardından komut Sync AWS CLI'den...
. Bu tür zararları önlemek, şirketlerin bulut altyapısı korumasına, DevOps'a ve güvenlik uzmanlarına bu kadar çok yatırım yapmalarının nedenidir. Peki buluta geçiş ne kadar değerli ve uygun maliyetli? Öyle ki giderek artan siber güvenlik zorluklarına rağmen !
Hikayenin ana fikri: güvenliğinizi kontrol edin; Düzenli denetimler yapın; Güvenlik politikaları için en az ayrıcalık ilkesine saygı gösterin.
( Yasal raporun tamamını görüntüleyebilirsiniz).
Kaynak: habr.com