Log4Shell'den Bir Yıl Sonra Dahi Çoğu Şirket Hala Saldırılara Maruz Kalıyor

Her ne kadar kamuoyuna açıklanan güvenlik açığı kaynaklı saldırıların sayısı beklenenin altında kalsa da kuruluşların yaklaşık dörtte üçü bu saldırılara maruz kalmaya devam ediyor.

Apache Software Foundation tarafından geçen Kasım ayında ortaya koyulan Log4j güvenlik açığı, bu açıktan kaynaklanan saldırıların sayısı başta beklenenin altında kalsa da bir yıl geçmesine rağmen kurumsal şirketler için büyük bir tehdit oluşturmaya devam ediyor.

Güvenlik araştırmacıları, birçok sistemin hala bu açığa karşı bir yamaya sahip olmadığını ve kuruluşların sorunu tespit ederek düzeltme ve yeniden ortaya çıkmasını önleme konusunda zorluk yaşadığını söylüyor.

Constrast Security'nin Bilgi Güvenliği Başkanı David Lindner'e göre "Log4j'nin Java uygulamalarının (neredeyse) %64'ünde kullanılması ve bunların yalnızca %50'sinin tamamen sabit bir sürüme sahip olması, saldırganlar tarafından hedef alınmaya devam edeceğini gösteriyor." "Şu anda saldırganlar, alay eder gibi Log4j üzerinden yeni siber saldırılar gerçekleştirebilmenin yollarını arıyorlar."

Birden Fazla Saldırı Olsa da Başlangıçta Öngörülenden Daha Az

Genellikle Log4Shell olarak adlandırılan Log4j zafiyeti (CVE-2021-44228), Log4j'de veri depolamak ve çekmek için kullanılan Java Adlandırma ve Dizin Arabirimi (JNDI)'nde yer alan bir güvenlik açığıdır. Bu zafiyet, saldırganların savunmasız sistemlerin kontrolünü uzaktan oldukça kolay bir şekilde ele geçirebilmesini sağlar. Log4J'nin hemen hemen her Java uygulama ortamında kullanıldığını göz önünde bulundurduğumuzda bu, oldukça büyük bir problemdir. Güvenlik araştırmacıları, yaygınlığı ve saldırganların yararlanabilme kolaylığı nedeniyle bu zafiyeti son yıllardaki en önemli güvenlik açıklarından biri olarak görüyor.

Geçtiğimiz yıl boyunca, saldırganların bir hedef ağa ilk erişimi sağlamak için bu güvenlik açığını hedef aldığına dair çok sayıda haber paylaşıldı. Bu saldırıların çoğunun Çin, Kuzey Kore ve İran gibi ülkelerde devlet tarafından desteklenen gelişmiş kalıcı tehdit (APT) grupları tarafından gerçekleştirildiği belirtiliyor. Örneğin, ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA) kasım ayında, bir VMware Horizon sunucusundaki Log4j güvenlik açığından yararlanarak federal bir ağa kripto madenciliği yazılımı ve kimlik bilgisi toplayıcıları yerleştiren İran hükümeti destekli bir APT grubu hakkında uyarıda bulundu.

Bu uyarı, Mart ayında Fortinet tarafından Çinli bir tehdit grubu olan Deep Panda'nın hedef sistemlere bir arka kapı yerleştirmek için aynı vektörü kullandığına ve Ahn Labs tarafından Kuzey Koreli Lazarus Group'un aynı yöntemle kendi arka kapısını oluşturmasına dair yapılan uyarılar ile benzerlik gösteriyor. Microsoft gibi şirketler de İran menşeili Phosphorous ve Çin menşeili Hafnium gibi devlet destekli aktörlerin Log4'ü kullanarak virüslü sistemlere ters kabuk oturumu aracılığıyla bağlandıklarını bildirdi.

Bu tür gelişmelere ve ekonomik motivasyonlarla Log4j'yi hedef alan siber suç gruplarının varlığı ile ilgili haberlere rağmen, özellikle ProxyLogon ve ProxyShell gibi Exchange Sunucusu güvenlik açıklarını içeren olaylarla karşılaştırıldığında Log4 aracılığı ile gerçekleştirilen ihlallerin sayısının nispeten düşük kaldığı görülüyor. Tenable'ın baş güvenlik sorumlusu Bob Huber'e göre, söz konusu güvenlik açığının büyüklüğü ve bu zafiyet aracılığıyla saldırıda bulunmanın kolaylığı göz önüne alındığında bildirilen siber saldırılar ölçek ve kapsam bakımından şaşırtıcı bir şekilde beklenenden daha düşük kalıyor. Huber, "CISA tarafından da belirtildiği üzere, yalnızca son zamanlarda devlet destekli gruplar tarafından bu güvenlik açığının hedeflendiğine dair bazı ciddi olaylara şahit olduk" dedi.

Tehdit Geçmiş Değil

Ancak güvenlik araştırmacıları, bunun geçtiğimiz yıl içinde Log4j kaynaklı tehditlerin azaldığı anlamına gelmediğinin altını çiziyor.

Her şeyden önce, şirketlerin büyük bir kısmı, söz konusu tehdide karşı önceki yıl oldukları kadar savunmasız durumda. Tenable'ın yakın zamanda Log4j güvenlik açığı ile ilgili gerçekleştirdiği bir telemetri analizi, 1 Ekim itibarıyla kuruluşların %72'sinin Log4j'ye karşı savunmasız olduğunu gösteriyor. Analiz, dünya çapındaki kuruluşların %28'inin bu zafiyeti tamamen giderdiğini ancak sistemlerini iyileştiren kuruluşların, ortamlarına yeni varlıklar ekledikçe Log4j güvenlik açığı ile tekrar tekrar karşılaştığını ortaya koyuyor.

Birçok durumda (tam olarak kuruluşların %29'unda) ilk iyileştirmenin hemen ardından sunucular, web uygulamaları, kapsayıcılar ve diğer varlıkların Log4j'ye karşı savunmasız hale geliyor.

Bob Huber konuyla ilgili olarak, "Kuruluşların yazılımlar için boru hattı oluşturulurken düzeltmeyi denklemin sol tarafına yerleştirdiğini varsaydığımız bir senaryoda, yeniden ortaya çıkma oranının azalması gerekiyor" sözleriyle düşüncelerini dile getirirken, "Yeniden ortaya çıkma ve değişme örneklerinin çoğu, büyük ölçüde kuruluşların yazılım yayınlama döngüsüne bağlı." dedi.

Ayrıca, siber güvenlik topluluğunun söz konusu zafiyet konusundaki ortak farkındalığına rağmen, uygulamalarda kullanılma şeklinden ötürü Log4j'nin savunmasız sürümlerini birçok kuruluşta tespit etmek oldukça zor olmaya devam ediyor. Sonatype Baş Teknoloji Sorumlusu Brian Fox'a göre bazı uygulamalar, doğrudan bağımlılık olarak açık kaynak günlükleme bileşenini kullanabilir ve diğer durumlarda bir uygulama, geçişli bağımlılık veya başka bir bağımlılığın bağımlılığı olarak Log4j'yi kullanabilir.

Fox, sözlerine "Geçişli bağımlılıklar, doğrudan bağımlılık seçimlerinizden doğduğu için geliştiricileriniz tarafından her zaman bilinmeyebilir veya doğrudan görülemeyebilir" şeklinde devam etti.

Ayrıca, Apache Vakfı Log4Shell'i ilk kez duyurduktan sonra birçok şirketin binlerce dahili e-posta göndermek, sonuçları çalışma tablolarında toplamak ve dosya sistemlerini tekrar tekrar taramak zorunda kaldığının da altını çizdi. Fox'a göre "Şirketlerin söz konusu bileşene yama uygulama süreci ciddi zamana ve kaynağa mal oldu ve zafiyetin olumsuz etkilerini daha da kötüleştirdi."

Sonatype'ın Maven Central Java deposundan alınan veriler, halihazırda Log4 sürümlerinin %35'inin savunmasız sürümler olduğunu gösteriyor. Fox, bu durumu "Pek çok şirket, bu zafiyete bir çare bulmaya başlamadan yazılım envanterini oluşturmaya çalışıyor ve geçişli bağımlılıkların sonuçlarının farkında değil" şeklinde yorumladı.

ABD İç Güvenlik Bakanlığı inceleme kurulu, tüm bu sorunlar nedeniyle bu yılın başlarında Log4'ü, kuruluşların yıllarca mücadele etmesi gereken endemik bir güvenlik açığı olarak değerlendirdi. İnceleme kurulu üyeleri, savunmasız Log4j sürümlerinin uzun yıllar sistemlerde kalacağını ve kuruluşları yakın gelecekte siber saldırı riskiyle karşı karşıya bırakacağını belirtti.

Yaşananların Tek İyi Yanı

Log4j güvenlik açığını takip eden güvenlik araştırmacıları, bu açık nedeniyle yaşananların tek iyi yanının yazılım bileşimi analizi ve yazılım malzeme listesi (SBOM) gibi uygulamalara artan ilgi olduğunu belirtiyor. Kuruluşların sırf savunmasız olup olmadığını veya sistemlerinin zayıf noktasının ne olduğunu öğrenmek için çektikleri zahmetler, özellikle açık kaynaklı ve üçüncü taraf kaynaklardan gelenler olmak üzere kod tabanlarındaki tüm bileşenlerin neden şeffaf olması gerektiğini daha iyi anlamalarını sağladı.

ReversingLabs Bilgi Güvenliği Başkanı Matthew Rose düşüncelerini paylaşırken, "Log4J güvenlik açığı ile ilgili araştırmalar, DevOps'un hızına ayak uyduran SBOM'lara ek olarak daha iyi bir yazılım tedarik zincirine duyulan ihtiyacı yeniden ortaya koydu" dedi ve Rose sözlerini şöyle sürdürdü: "Uygulama güvenliği ve yazılım mimarisi ekipleri; uygulamaların kaynak kodu, API'ler veya açık kaynak paketleri gibi belli başlı bölümlerinde risk aramanın yeterli olmadığını fark etti. Artık yazılımların mimarisini tam olarak anlamanın, SQLI veya siteler arası komut dosyası çalıştırma hatalarını (XSS) bulmak kadar önemli olduğunu biliyorlar."

Kaynak: Dark Reading