Rackspace’de şirketin barındırdığı Microsoft Exchange sunucu ortamını çökerten son fidye yazılımı olayı, dikkatleri güvenlik ekiplerinin bir güvenlik açığı için bir yama uygulamak yerine azaltmayı seçerken genellikle riskli olan kumara odakladı.
Geçen hafta, Rackspace, barındırma şirketinin Exchange sunucu hizmeti ortamına 2 Aralık’ta yapılan bir saldırının, Exchange Server’daki bir sunucu tarafı istek sahteciliği (SSRF) güvenlik açığı için bir yama uygulamayı erteleme kararından kaynaklandığını açıkladı (CVE-2022-41080) Microsoft’un Kasım ayında yama yaptığı. Güvenlik açığı, Exchange Server’da önceden açıklanan başka bir uzaktan kod yürütme (RCE) kusuruyla zincirlendiğinde — şu şekilde izlenir: CVE-2022-41082 — Saldırganlara, etkilenen sunucuların tam denetimini ele geçirmeleri için bir yol sağlar.
Ertelenmiş Yama
Rackspace’in baş güvenlik sorumlusu Karen O’Reilly-Smith’e göre şirket, yıkıcı kimlik doğrulama hatalarına neden olacağı endişesiyle SSRF kusuru için yamayı uygulamayı erteledi. Bunun yerine Rackspace, Microsoft’un etkili bir önlem olacağını düşünerek güvenlik açığı için yayınladığı bir azaltma önlemi uygulamaya karar verdi. O’Reilly-Smith, Microsoft’un CVE-2022-41080 ile ilgili notlarının bunu yalnızca bir ayrıcalık yükseltme güvenlik açığı olarak tanımladığını ve bunun bir RCE zincirinin parçası olduğu gerçeğinden hiç bahsetmediğini söyledi.
Bir Microsoft sözcüsü, Dark Reading’e şirketin şu anda Rackspace’in şirketin SSRF kusuru için yaptığı yamayla ilgili yorumları veya ifşasına eşlik eden notlar hakkında paylaşacak hiçbir şeyi olmadığını söyledi.
Netenrich baş tehdit avcısı John Bambenek, Rackspace’in güvenlik açığını yamalamayı erteleme kararının alışılmadık bir durum olmadığını söylüyor. “Genellikle, özellikle aksama süresine karşı duyarlılığın olduğu yüksek düzeyde kamu kaynaklarında hafifletme yöntemleri tercih edilir” diyor. Aslında, bir uygulama ne kadar halka dönük olursa, o kadar çok kuruluş hafifletme önlemlerine gidecektir, diyor.
Bambenek, “Azaltımların sağlam ve eksiksiz olması çoğu zaman iyi bir bahis olabilir” diyor. “Ama sağlam bir yargıya varmak için satır aralarını okuyabilen gerçekten anlayışlı bir profesyonel gerekiyor.”
Rackspace’in durumunda, daha sonra Play fidye yazılımı grubu olarak tanımlanan bir saldırgan, ortamındaki CVE-2022-41082 RCE kusurunu tetiklemek için CVE-2022-41080’i kullanmanın bir yolunu bulduğu için azaltma stratejisi başarısız oldu. Bu noktaya kadar güvenlik araştırmacıları, yalnızca şu şekilde izlenen farklı bir Exchange Server SSRF güvenlik açığı aracılığıyla RCE kusurunu tetikleyen saldırganları gözlemlemişti: CVE-2022-41040, ProxyNotShell olarak bilinen kombinasyonda. Saldırı, çoğu küçük ve orta ölçekli işletme olan Rackspace müşterileri için yaygın hizmet kesintilerine neden oldu.
Rackspace’in harici bir danışmanı Dark Reading’e, “Rackspace, yamalar kullanıma sunulmadan önce Eylül ayı sonunda Microsoft tarafından açıklanan ProxyNotShell zinciriyle ilgili hafifletme önlemlerini uygulamaya koydu,” dedi.
Danışman, yamalar kullanıma sunulduğunda, yamalarla ilgili bildirilen kimlik doğrulama sorunlarıyla ilgili endişeler ve şirketin zaten uygun hafifletme önlemlerine sahip olması nedeniyle Rackspace’in bunları uygulamayı ertelediğini söylüyor.
Danışman, “O zamanlar, CrowdStrike’ın Rackspace olayını araştırırken keşfettiği CVE-2022-41080 ile ilişkili bilinen veya ifşa edilmiş hiçbir uzaktan kod yürütme riski yoktu” diye ekliyor.
Güvenlik Yamalarını Atlamak: Riskli Bir Gambit
Vulcan Cyber’de kıdemli teknik mühendis olan Mike Parkin, bu olayın, kuruluşların kendilerini güvenlik açığı açıklarından korumak için yalnızca hafifletmelere çok fazla güvendiklerinde aldıkları riskleri vurguladığını söylüyor..
“Bilinen bir güvenlik açığı için satıcı tarafından önerilen hafifletme önlemlerinin dağıtılmasının sorunun sonu olmaması gerekiyor” diyor. “Söz konusu satıcı bir yama geliştirene ve siz onu dağıtana kadar yaptığınız şeyler bunlar.”
Parkin’e göre, azaltmanın yama yapmamanın uygun olduğu tek an, satıcının güvenlik açığı için henüz bir yaması olmadığı veya bir kuruluşun bunu hedef bir ortamda konuşlandıramamasının teknik bir nedeninin olduğu zamandır.
“Değişiklik yönetimi prosedürlerinin yamanın dağıtılmasını geciktirdiği durumlar olacaktır. Ancak hem değişiklik yönetimi hem de güvenlik açısından iyi bir süreç, yamaların kararlılıkla ilgili kaygıları karşılarken mümkün olan en kısa sürede uygulamaya konulmasıdır.” özellikle, belirli bir güvenlik açığını hedef alan vahşi doğada bilinen açıklardan yararlanmalar olduğunda doğrudur.
Genel olarak yama uygulama ve güvenlik açığı iyileştirme, kuruluşlar için büyük bir zorluk olmaya devam ediyor. Güvenlik açığı yönetimi satıcısı Edgescan’in geçen yıl yürüttüğü bir çalışma, kuruluşların hala kritik güvenlik açıklarını düzeltmek ortalama 60 gün sürer Rackspace’i tetikleyen türden.
Çalışma, kurumsal ağlarda gözlemlenen güvenlik açıklarının %57’sinin iki yaşından büyük olduğunu ve şaşırtıcı bir şekilde %17’sinin beş yaşından büyük olduğunu buldu. Tüm bu güvenlik açıkları, vahşi ortamda işleyen açıklara sahipti ve ulus-devlet aktörleri ve siber suç grupları da dahil olmak üzere düşmanlar, bunların birçoğundan yararlanmıştı.
Sömürü için Azalan Zaman
Daha da kötüsü, siber suçluların yeni güvenlik açıklarından yararlanma konusunda çok daha hızlı hale gelmesidir. ilk ifşa ve yararlanma kullanılabilirliği hızla küçülmüştür.
Bu eğilim, ABD Siber Güvenlik ve Altyapı Güvenliği Teşkilatını (CISA), Kasım 2021’de tüm federal sivil şube teşkilatlarının bilinen kötüye kullanılan güvenlik açıklarını düzeltin belirli bir — genellikle iki haftalık — zaman çerçevesi içinde. CISA ayrıca tüm kuruluşların, saldırganların vahşi ortamda hangi güvenlik açıklarından yararlandığını görmek ve böylece bunları hemen düzeltebilmek için Bilinen Yararlanılan Güvenlik Açıkları (KEV) kataloğuna düzenli olarak başvurmasını savunmuştur. CISA, yalnızca etkilenen satıcıdan bir düzeltme eki veya düzeltme eylemi mevcutsa kataloğuna yeni güvenlik açıkları ekler.
IT-Harvest baş araştırma analisti Richard Stiennon, görevin karmaşıklığı göz önüne alındığında, özellikle büyük kuruluşlar için birçok şirketin kritik güvenlik açıklarını düzeltmesinin hala 60 gün sürmesinin şaşırtıcı olmadığını söylüyor. Yama uygulama, çoğu kuruluş için genellikle hafta sonu sabahlarının erken saatlerinde olan programlanmış kesintileri içerir, diyor. Görev, etkilenen tüm sunucuları kaldırmayı, yamayı yüklemeyi ve sistemleri geri getirmeden önce yeniden başlatıp test etmeyi içerir.
Stiennon, “Acil durum yamasına ihtiyaç duyan 2.000 sunucuya sahip büyük bir şirket olduğunuzu hayal edin” diyor. “Tabii önce bir hafifletme uygularsın. Aynı gün yapamazsın.”
Steinnon, bulut benimsemenin birçok kuruluşta güvenlik açığı yönetimi süreçlerini değiştirmeye başladığını söylüyor. Bu günlerde yama yapılması gereken bir sistem bir konteyner veya sanal makine olabilir. “Artık süreç, üretim sistemini yansıtmak, yama yapmak, test etmek ve güncellenmiş örnekleri kesinti olmadan üretime geçirmek.”
