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 (CVE-2022-41080) bir sunucu tarafı istek sahteciliği (SSRF) güvenlik açığı için bir yama uygulamayı erteleme kararından kaynaklandığını açıkladı. ) Microsoft’un Kasım ayında yama yaptığı. Güvenlik açığı, Exchange Server’da daha önce açıklanan ve CVE-2022-41082 olarak izlenen başka bir uzaktan kod yürütme (RCE) kusuruyla zincirlendiğinde, saldırganlara etkilenen sunucuların tam kontrolünü ele geçirmenin bir yolunu sunar.
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ı, saldırganların yalnızca ProxyNotShell olarak bilinen kombinasyonda CVE-2022-41040 olarak izlenen farklı bir Exchange Server SSRF güvenlik açığı aracılığıyla RCE kusurunu tetiklediğini gözlemlemişti. 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 ortamda 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 yaptığı bir araştırma, kuruluşların Rackspace’i tetikleyen türden kritik güvenlik açıklarını düzeltmesinin hala ortalama 60 gün sürdüğünü gösterdi.
Ç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 yararlanmada çok daha hızlı hale gelmesi ve bu nedenle ilk ifşa ile açıklardan yararlanmanın kullanılabilirliği arasındaki sürenin hızla daralmasıdı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 kötüye kullanıldığı bilinen güvenlik açıklarını belirli bir (genellikle iki haftalık) zaman dilimi içinde düzeltmesini gerektiren bir yönerge yayınlamaya itti. 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 temizleme 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. Düzeltme eki genellikle planlanmış kesintileri içerir ve bu, birçok kuruluş için genellikle hafta sonu sabahlarının erken saatlerinde olur, 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.”