2023 Şükran Günü Cloudflare Güvenlik Olayı
(blog.cloudflare.com)- Cloudflare, 23 Kasım 2023'te kendi barındırdığı Atlassian sunucularında bir tehdit aktörü tespit ettiğini, ancak müşteri verilerinin, müşteri sistemlerinin, küresel ağ sistemlerinin ve yapılandırmaların etkilenmediğini açıkladı
- Sızma yolu, Ekim 2023'teki Okta ihlalinden sonra döndürülmemiş 1 erişim token'ı ve 3 hizmet hesabı kimlik bilgisiydi; erişim Jira, Confluence, Bitbucket gibi Atlassian ortamına odaklandı
- Tehdit aktörü 14-17 Kasım'da keşif ve iç belgelere erişim gerçekleştirdikten sonra, 22 Kasım'da ScriptRunner for Jira üzerinden kalıcı erişim sağlamak için Sliver kurdu
- Cloudflare, “Code Red” yanıtı kapsamında 5.000'den fazla üretim kimlik bilgisini döndürdü, 4.893 sistemi adli açıdan triyaj incelemesinden geçirdi ve küresel ağdaki tüm makineleri ve Atlassian ürünlerini yeniden imajlayıp yeniden başlattı
- CrowdStrike'ın bağımsız incelemesinde de gözden kaçan bir faaliyet bulunmadı; son tehdit faaliyeti kanıtı 24 Kasım 2023 10:44 UTC olarak doğrulandı
Olayın özeti ve etki kapsamı
- Cloudflare, 23 Kasım 2023'te kendi barındırdığı Atlassian sunucularında bir tehdit aktörü tespit etti
- Güvenlik ekibi hemen soruşturma başlattı ve erişimi engelledi
- 26 Kasım'da bağımsız analiz yürütmesi için CrowdStrike adli bilişim ekibini çağırdı
- Bu olaydan müşteri verileri veya müşteri sistemleri etkilenmedi
- Hizmetler olaya dahil olmadı
- Küresel ağ sistemlerinde veya yapılandırmalarında da değişiklik olmadı
- Erişim kontrolleri, güvenlik duvarı kuralları ve kendi Zero Trust araçlarıyla zorunlu kılınan donanım güvenlik anahtarları yatay hareketi sınırladı
- Tehdit aktörünün erişim kapsamı, iç wiki olan Atlassian Confluence, hata veritabanı Jira, kaynak kod yönetim sistemi Bitbucket ve Atlassian'ın çalıştığı sunucularla sınırlı kaldı
Sızmada kullanılan kimlik bilgileri
- Sızma, Ekim 2023'teki Okta ihlalinden sonra sızdırılmış ancak döndürülmemiş 1 hizmet token'ı ve 3 hizmet hesabıyla başladı
- Moveworks hizmet token'ı: Atlassian sistemlerine uzaktan erişim için kullanıldı
- Smartsheet hizmet hesabı: Atlassian Jira örneğinde yönetici yetkisine sahipti
- Bitbucket hizmet hesabı: Kaynak kod yönetim sistemine erişim için kullanıldı
- AWS ortamı hesabı: Küresel ağa, müşteri verilerine veya hassas verilere erişim yetkisi yoktu
- Söz konusu token ve hesapların kullanılmadığı yanlış biçimde değerlendirildiği için döndürme kapsamı dışında kaldı
- Cloudflare, bu sorunun Atlassian, AWS, Moveworks veya Smartsheet'in hatası değil, Cloudflare'ın kimlik bilgilerini döndürememesinin sonucu olduğunu belirtti
Saldırı zaman çizelgesi
- 14 Kasım 09:22:49'dan itibaren tehdit aktörü sistem keşfi ve keşif faaliyetlerine başladı
- Okta örneğine giriş denemesi reddedildi
- Cloudflare Dashboard erişimi de engellendi
- Cloudflare Apps marketplace'ini çalıştıran AWS ortamına erişti, ancak bu ortam küresel ağdan ve müşteri verilerinden ayrılmıştı
- 15 Kasım 16:28:38'de Atlassian Jira ve Confluence erişiminde başarılı oldu
- Moveworks hizmet token'ıyla ağ geçidinden geçti ve Smartsheet hizmet hesabıyla Atlassian ürün ailesine erişti
- Wiki'de remote access, secret, client-secret, openconnect, cloudflared, token gibi terimleri aradı
- 2.059.357 Jira kaydından 36'sına, 194.100 wiki sayfasından 202'sine erişti
- Erişilen Jira kayıtları; zafiyet yönetimi, secret döndürme, MFA atlatma, ağ erişimi ve Okta olayı yanıtıyla ilgili öğeleri içeriyordu
- 16 Kasım 14:36:37'de Smartsheet kimlik bilgileriyle normal bir Cloudflare kullanıcısı gibi görünen bir Atlassian hesabı oluşturdu ve bunu çeşitli gruplara ekledi
- Bu, Smartsheet hizmet hesabı kaldırılsa bile Atlassian ortamına erişimi sürdürmeye yönelik bir adımdı
- 17 Kasım 14:33:52'den 20 Kasım 09:26:53'e kadar, kısa erişim testleri dışında Cloudflare sistemlerine erişim durdu
- 22 Kasım 14:18:22'de Smartsheet hizmet hesabının Jira yönetici yetkisini kullanarak ScriptRunner for Jira eklentisiyle Sliver Adversary Emulation Framework kurdu
- Sliver, red team'ler ve saldırganlar tarafından C2, bağlantı ve kalıcı/gizli erişim için kullanılan bir araç ve framework'tür
- Bununla Atlassian sunucularına kalıcı erişim sağladı ve yatay hareket denemeleri yaptı
- Brezilya'nın São Paulo kentinde, henüz üretime alınmamış bir veri merkezindeki üretim dışı konsol sunucusuna erişim girişimi başarısız oldu
Kaynak kod ve belge erişimi
- Tehdit aktörü, 22 Kasım'dan sonraki bir gün içinde 11.904 depodan 120 kod deposunu görüntüledi
- Bunlardan 76 depo, Atlassian Bitbucket'ın git archive işlevi kullanılarak Atlassian sunucusuna indirildi
- Cloudflare dışarıya sızdırılıp sızdırılmadığını doğrulayamadı, ancak sızdırılmış kabul ederek yanıt verdi
- 76 depo çoğunlukla şu alanlarla ilgiliydi
- Yedeklemelerin çalışma biçimi
- Küresel ağ yapılandırması ve yönetimi
- Cloudflare'ın kimlik sistemleri
- Uzaktan erişim
- Terraform ve Kubernetes kullanımı
- Bazı depolarda şifrelenmiş secret'lar bulunuyordu; Cloudflare bunlar güçlü biçimde şifrelenmiş olsa da hemen döndürdü
- Cloudflare, kaynak kodun kendisinden ziyade koda gömülü yerleşik secret'lara, zafiyetlere ve sonraki saldırılarda kullanılabilecek yollara odaklanarak inceleme yaptı
- Cloudflare, birçok kaynak kodunu açık kaynak olarak yayımladığını ve kullandığı algoritmaları ve teknikleri blogunda kamuya açık biçimde ele aldığını açıkladı
Tespit ve engelleme
- 23 Kasım 16:00'da güvenlik ekibi, tehdit aktörünün varlığına ilişkin bir uyarı aldı
- 15:58: Tehdit aktörü Smartsheet hizmet hesabını yönetici grubuna ekledi
- 16:00: Bu değişiklikle ilgili otomatik uyarı güvenlik ekibine iletildi
- 16:12: Cloudflare SOC soruşturma başlattı
- 16:35: Smartsheet hizmet hesabı devre dışı bırakıldı
- 17:23: Tehdit aktörünün oluşturduğu Atlassian kullanıcı hesabı bulundu ve devre dışı bırakıldı
- 17:43: İç Cloudflare olayı ilan edildi
- 21:31: Tehdit aktörünün bilinen IP adreslerini engelleyen güvenlik duvarı kuralları uygulandı
- 24 Kasım'da son faaliyet ve Sliver'ın kaldırıldığı doğrulandı
- 10:44: Bilinen son tehdit aktörü faaliyeti
- 11:59: Sliver kaldırıldı
- Tehdit aktörü iç metrikler, ağ yapılandırmaları, derleme sistemi, uyarı sistemi, sürüm yönetim sistemi gibi çeşitli sistemlere erişmeyi denedi, ancak başarılı olamadı
- Küresel ağa, veri merkezlerine, SSL anahtarlarına, müşteri veritabanlarına veya yapılandırma bilgilerine, Cloudflare Workers'a, yapay zeka modellerine, ağ altyapısına, Workers KV, R2, Quicksilver gibi veri depolarına erişildiğine dair kanıt bulunmadı
“Code Red” yanıtı ve güçlendirme çalışmaları
- Cloudflare, 24 Kasım'da tehdit aktörünü ortamdan çıkardıktan sonra, sızmayı araştırmak ve erişim kapsamını doğrulamak için şirket genelinde personel görevlendirdi
- 27 Kasım'dan itibaren güvenlik ekibinin içinden ve dışından çok sayıda teknik personel Code Red projesine odaklandı
- Gelecekteki sızmalara karşı ortamın kontrollerini güçlendirdi, doğruladı ve düzeltti
- Tehdit aktörünün erişimi sürdüremediğini doğruladı
- Tüm sistemleri, hesapları ve günlükleri inceleyerek kalıcı erişim olup olmadığını ve hangi hedeflere erişildiğini ya da erişilmeye çalışıldığını belirledi
- Başlıca önlemler şunlardı
- 5.000'den fazla üretim kimlik bilgisinin döndürülmesi
- Test ve staging sistemlerinin fiziksel olarak ayrılması
- 4.893 sistemin adli triyaj incelemesi
- Küresel ağdaki tüm makinelerin yeniden imajlanması ve yeniden başlatılması
- Jira, Confluence, Bitbucket dahil tüm Atlassian ürünlerinin yeniden imajlanması ve yeniden başlatılması
- São Paulo veri merkezi ekipmanı üreticiye iade edildi
- Üreticinin adli bilişim ekibi, erişim veya kalıcılık sağlanıp sağlanmadığını araştırdı
- Hiçbir şey bulunmadı, ancak Cloudflare donanımı değiştirdi
- Ayrıca güncellenmemiş yazılım paketleri, oluşturulmuş olabilecek kullanıcı hesapları, kullanılmayan aktif çalışan hesapları, Jira kayıtlarında veya kaynak kodda kalmış olabilecek secret'lar ve wiki'ye yüklenmiş HAR dosyaları incelendi
- HAR dosyaları, token içermiş olabilecekleri ihtimaline karşı silindi
- Acil Code Red çalışmaları 5 Ocak 2024'te sona erdi, ancak kimlik bilgisi yönetimi, yazılım güçlendirme, zafiyet yönetimi ve ek uyarı iyileştirmeleri sürüyor
CrowdStrike incelemesi ve IOC'ler
- CrowdStrike, tehdit aktörü faaliyetinin kapsamını ve kalıcılık kanıtlarını bağımsız olarak değerlendirdi
- Cloudflare soruşturmasında gözden kaçan bir faaliyet bulunmadı
- Son tehdit faaliyeti kanıtının 24 Kasım 2023 10:44 UTC olduğu sonucuna vardı
- Cloudflare, sektör ve kamu kurumlarındaki muhataplarıyla iş birliğine dayanarak, bu saldırının Cloudflare küresel ağına kalıcı ve geniş kapsamlı erişim elde etmeye çalışan devlet destekli bir saldırgan tarafından gerçekleştirildiği değerlendirmesini yaptı
- Cloudflare, Okta ihlalinden etkilenmiş olabilecek diğer kuruluşların günlüklerini kontrol edebilmesi için ihlal göstergelerini yayımladı
193.142.58[.]126: Başlıca tehdit aktörü altyapısı, M247 Europe SRL'ye ait198.244.174[.]214: Sliver C2 sunucusu, OVH SAS'ye aitidowall[.]com: Sliver payload sağlayan altyapıjvm-agent: Sliver payload dosya adı, SHA256bdd1a085d651082ad567b03e5186d1d46d822bb7794157ab8cce95d850a3caaf
1 yorum
Hacker News yorumları
Cloudflare’ın bu tür açık analizleri ve müdahaleleri sayesinde verilerimi ve işimi onlara emanet edebileceğimi düşünüyorum.
Mükemmel değiller ve katılmadığım şeyler de yapıyorlar, ama şirket genelinde paylaşılan mühendislik zihniyeti ve bu tür olayları ciddiyetle ele alma tavırları nedeniyle güvenilir olduklarını hissediyorum.
Rakiplerinden daha yüksek bütünlüğe sahip olduklarını vurguluyorlar ve yakın zamandaki güvenlik olayından sonra bazı operasyonel incelemeleri paylaşıyorlar.
Ancak Cloudflare, PCI/DSS ödeme kartı işleyicisi olarak SOC risk analizi sunmuyor; yetkileri yükselmiş hesapları neden kaçırdıklarını veya bu hesapların en başta nasıl ele geçirildiğini de açıklamıyor. Sorumluluktan ziyade yalnızca remediation’ı anlatıyor.
Üçüncü taraf denetiminden söz ediyorlar, ama bu kullanıcıları düşündükleri için değil; PCI/DSS, ödeme kartı bilgileri ihlal edilen kuruluşlardan her yıl yerinde denetim talep ettiği için. Aksi halde büyük kart şirketleri ödeme işlemeyi durdururdu.
Hiçbir şey kaybetmediklerini söylemelerine inanmak zor; gördüğüm Jira/Confluence kurulumlarının çoğunda gizli bilgiler yığılıydı.
“Erişilen wiki sayfalarını, hata veritabanı issue’larını ve kaynak kod depolarını analiz ettiğimizde, küresel ağın mimarisi, güvenliği ve yönetimiyle ilgili bilgi aradıkları anlaşılıyor” kısmına bakınca, bir devlet aktörü için en kolay yöntem sadık bir vatandaşı hedef şirketin çalışanı olarak içeri sokmak ve o kişinin bu bilgileri göndermesini sağlamak olur.
İlginç ama doğruluğu belirsiz bir hikâyeye göre, 10 yıldan da uzun süre önce Google’ın SRE sosyal buluşmalarından birinde birkaç kişi kendi ülkelerinin istihbarat kurumlarından maaş aldıklarını kabul etmiş.
Değilse, böyle bir buluşmada ne kadar güçlü bir madde dönüyordu da bu kadar korkunç bir operasyon güvenliği hatası yaşandı, merak ediyorum.
Avustralyalılar, vatandaşlığın temel şartıymış gibi bu tür casusluk faaliyetlerine katılma “fırsatı” elde ediyor: https://en.wikipedia.org/wiki/Mass_surveillance_in_Australia...
Artı yanı varsa, zero trust süreçleri ve sistemleri geliştirirken iyi uygulamaları zorunlu kılmaya yardımcı olabilir.
“Okta sisteminin ihlalinden ikinci kez zarar gördük” kısmına bakınca, Cloudflare’ın Okta kullanımını yeniden değerlendirip değerlendirmediğini merak ediyorum.
Okta da eleştirilmeli, ama bu Cloudflare’ın kendi hatasını örtmek için sorumluluğu aşağıya itmesi gibi hissettiriyor.
Ben “ilk dönemlerde” aldığım eski MacBook’u kullanmaya devam ediyorum, bu yüzden üzerinde hiçbir yönetim yazılımı yok. O zamanlar IT yoktu; sadece el değmemiş yeni bir dizüstü almıştım.
Şirket M1/M2 Pro’ya yükseltme teklif etti, ama iş bilgisayarında tek bir kişisel parolam ya da anahtarım bile varsa Okta oturum açma sistemini kullanmak istemediğimi söyleyerek reddettim.
Bu yüzden işimde ciddi bir aksama yaşanana kadar yükseltme yapamam. Belki bu tür olayları IT departmanına düşüncemi haklı çıkarmak için dayanak olarak kullanabilirim.
“Bir hizmet token’ı ve üç hesap, kullanılmadıkları yanlış düşüncesiyle döndürülmedi” ifadesi tuhaf. Kullanılmıyorlarsa neden tamamen iptal edilmediklerini anlamıyorum.
Bir şey eksik ya da aktarım sırasında kaybolmuş olabilir, ama cümleyi olduğu gibi okuyunca pek anlaşılmıyor.
Örneğin veritabanının bir yerinde ilgili hizmet hesabı “iptal edildi” veya “temizlendi” gibi pasif bir durumda işaretlenmiş, ama bu işaret yanlış olabilir. Bu yüzden aktif hesapların parolalarının hepsi döndürülmüş, pasif hesaplar ise atlanmış olabilir.
İyi bildiğim açık anahtar altyapısı ve sertifika iptali bağlamından bakarsam, sertifikayı süresinin dolmasına bırakmak, “artık kullanılmıyor” diye işaretlemek ve tamamen iptal etmek birbirinden epey farklıdır. Sertifika otoritesi ilk durumda hiçbir şey yapmak zorunda değildir; ikincisinde hiçbir şey yapmayabilir ya da iptal edebilir; üçüncüsünde ise iptal listesini aktif olarak tutup dağıtması gerekir. Biri “özel anahtarı yanlışlıkla üzerine yazdım, yeni anahtar için sertifika verin” dediğinde genelde eski sertifikayı iptal listesine koymazsınız.
“Bu, AWS, Moveworks veya Smartsheet’in hiçbir hatası değildir; yalnızca bizim döndüremediğimiz kimlik bilgileridir” diye açıkça yazmaları iyi bir nokta.
Cloudflare, saldırganın erişiminin sınırlı olduğuna inanıp bunu daha sonra doğrulamış olmasına rağmen, 5.000’den fazla üretim kimlik bilgisinin tamamını döndürdü, test ve staging sistemlerini fiziksel olarak ayırdı, 4.893 sistemi adli olarak inceledi ve dünya çapındaki ağındaki tüm makineleri yeniden imajlayıp yeniden başlattı.
Henüz üretime alınmamış São Paulo veri merkezindeki konsol sunucusuna erişim girişimi de başarısız oldu; buna rağmen Brezilya veri merkezi ekipmanlarını adli inceleme için üreticiye geri gönderdi ve hiçbir şey bulunmamasına rağmen donanımı değiştirdi.
Bu kadarını yapmak zorunda değillerdi ve yapmamak da kolay olurdu; gerçekten yapmış olmaları övgüyü hak ediyor.
Yeni bir veri merkezi kurulumunun ilk aşamalarına sızmak neredeyse nihai exploit sayılır. Yeni bir Meet-Me room’un (https://en.wikipedia.org/wiki/Meet-me_room) ortasına girip çekirdek switch’e kalıcı erişim elde ettiğinizi düşünün.
Cloudflare veri merkezleri çoğu zaman devasa miktarda veri trafiğinin hub’ı konumunda. Saldırganın “üretim öncesi” bir veri merkezinin değerini biliyor olması, Cloudflare’ın da düzenli güvenlik düzeni kurulmadan önce orada bir dayanak oluşursa bunun %100 oyun bitti anlamına geldiğini fark ettiği anlamına geliyor olmalı. Kurulum ve devreye alma aşamasındaki bir veri merkezinin içine biri yerleşmeyi başarırsa bu şirketi bitirebilecek türden bir olaydır.
Veri merkezi kurulumunun başlarında tüm switch’lerin ve ekipmanların varsayılan ya da boş root parolaları (admin/admin) kullandığını, firmware’lerin de eski olup çok sayıda açığa sahip olduğunu unutmamak gerekir. Otomasyon tüm firmware’leri yamalamadan önce böyle bir saldırı gerçekleştiyse, bu “tüm ekipmanı iade edelim, üretici yenilerini göndersin” seviyesinde bir olaydır.
Yalnızca kanıtlanabilir erişim kapsamına saldırganın eriştiğini varsayarsanız, saldırganın hayatta kalabileceği bir boşluk bırakmış olursunuz. Bunu yapmaya gerek olmadığını söylemek için birden fazla kişinin yeter sayıyla onayı gerekmesi gerekir.
Elbette bu ideal bir dünyadan bahsediyor. Ekibimizin doğrudan parasal ya da kullanıcı faydası olmayan özellikleri uygulamak için zaman alabilmesini şans sayıyorum.
Bu tür bir kimlik bilgisi döndürme operasyonunu yürütmeye hazır olmak disiplin ve hazırlık gerektirir; açıkçası çoğu ekip bu yatırımı yapmaz. Akıllı ve kaynakları bol ekipler için de durum aynı.
Cloudflare güvenlik ekibi tüm secret’ları döndürmeye ve tüm makineleri yeniden imajlamaya karar verebiliyor ve bu makul bir süre içinde gerçekten gerçekleşiyorsa bu oldukça etkileyici.
† https://twitter.com/badthingsdaily?lang=en
Buradaki en şaşırtıcı kısım Cloudflare’ın Bitbucket kullanıyor olması.
Veri sızıntısı bir kez dışarı çıktı mı, bu durumda kaynak kodu kalıcı olarak dışarıdadır ve kimin aldığını hiçbir şekilde kontrol edemezsiniz.
Olaydan sonra istediğiniz kadar sertleştirme yapabilir ve bunu ne kadar anlatırsanız anlatın, engellemeye çalıştığınız şey çoktan gerçekleşmiştir. Kırılan yumurtayı geri koyamazsınız.
Eski kodlarda başka Easter egg’ler de bulunabilir. Neredeyse her şirkette belgelenmemiş backdoor’lar vardır.
Müşteri verilerinin sızması daha kötü olurdu ama bu da gerçekten kötü.
Gelecek yılın müşteri verileri de bu yılın müşteri verileriyle aynı değil.
Atlassian Confluence’ta yalnızca yerleşik Apache Lucene arama motoru bile hassas bilgilerin sızmasına yol açabilir ve bu tür erişimin izlenmesi/tespit edilmesi çok zor olabilir.
Hassas bilgiler arama sonuçları sayfasında zaten gösteriliyorsa saldırganın Confluence sayfasını açmasına bile gerek yoktur.
“Bir servis token’ı ve üç hesabın kullanılmadığına yanlışlıkla inandığımız için döndürmedik” kısmı tuhaf. Kullanılmayan kimlik bilgileri muhtemelen döndürülmemeli, silinmeli.
“Bu hesaplar ne?” “Aa, kullanılmıyorlar. Loglarda da görünmüyorlar.” “Yine de döndürmemiz lazım.” “Hayır, ihlal edilmiş olabilecek eski kimlik bilgilerine sahip rastgele hesapları öylece bırakalım… sebepleri falan var işte” gibi bir durum mu?
Okta olayından sonra sızan kimlik bilgilerini döndürdülerse, onların üzerine bir honeypot kurup saldırganların ne yaptığını beklemeleri gerektiğini düşünüyorum.
Honeypot, yakalanma korkusuyla saldırganın devam etmesini engelleme etkisine de sahiptir.