Log4j güvenlik açığı, Apache Software Foundation’ın geçen Kasım ayında ifşa etmesinden bir yıl sonra kurumsal kuruluşlar için büyük bir tehdit oluşturmaya devam ediyor. — kusurun kendisini hedef alan kamuya açıklanmış saldırıların sayısı birçok kişinin başlangıçta beklediğinden daha az olmasına rağmen.
Güvenlik araştırmacıları, sistemlerin büyük bir yüzdesinin kusura karşı hala yama yapılmadığını ve kuruluşların sorunu bulup düzeltme ve ardından kusurun ortama yeniden girmesini önleme konusunda zorluklarla karşılaştığını söylüyor.
“Log4j’nin kullanıldığı gerçeği [nearly] Java uygulamalarının %64’ü ve bunların yalnızca %50’si tamamen sabit bir sürüme güncellendi, saldırganların onu hedeflemeye devam edeceği anlamına geliyor,” diyor Contrast Security’de CISO olan David Lindner. “En azından şimdilik, saldırganlar bir gün geçirmeye devam ediyor. Log4j aracılığıyla yararlanmanın yollarını bulmak.”
Çoklu Saldırılar Ancak Beklenenden Daha Az
Log4j kusuru (CVE-2021-44228), genellikle Log4Shell olarak adlandırılan, Log4j’nin veri depolama ve alma için Java Adlandırma ve Dizin Arayüzü (JNDI) işlevinde bulunur. Uzaktaki saldırganlara savunmasız sistemlerin kontrolünü ele geçirmek için önemsiz derecede kolay bir yol sağlar – Log4J’nin hemen hemen her Java uygulama ortamında kullanılması düşünüldüğünde bir sorun. Güvenlik araştırmacıları, yaygınlığı ve saldırganların yararlanabilme kolaylığı nedeniyle bunu son yıllardaki en önemli güvenlik açıklarından biri olarak görüyor.
Geçen yıl boyunca, tehdit aktörlerinin bir hedef ağa ilk erişimi elde etmenin bir yolu olarak kusuru hedef aldığına dair çok sayıda rapor geldi. Bu saldırıların çoğu Çin, Kuzey Kore, İran ve diğer ülkelerden ulus-devlet destekli gelişmiş kalıcı tehdit (APT) gruplarını içeriyor. Örneğin, Kasım ayında ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA), İran hükümeti destekli bir APT grubunun yama uygulanmamış bir VMware Horizon sunucusundaki Log4j güvenlik açığından yararlanarak kripto madenciliği yazılımı ve kimlik bilgisi toplayıcıları dağıtın federal bir ağda.
Çinli tehdit aktörü Deep Panda’nın Mart ayında Fortinet’ten aldığı uyarıya benziyordu. özdeş vektör hedef sistemlere bir arka kapı ve Kuzey Kore’nin Lazarus Grubu hakkında Ahn Labs’tan bir arka kapı konuşlandırmak kendi arka kapısını dağıtmak aynı yol. Microsoft gibi diğerleri de İran’ın Fosfor grubu ve Çin’in Hafnium tehdit aktörü gibi devlet aktörlerinin Log4’ü kullanarak virüslü sistemlere ters mermiler attığını gözlemlediklerini bildirdi.
Bu tür raporlara ve Log4j’yi hedef alan mali amaçlı siber suç grupları hakkındaki diğer birkaç rapora rağmen, Log4’ü içeren genel olarak bildirilen ihlallerin gerçek sayısı, özellikle ProxyLogon ve ProxyShell gibi Exchange Server güvenlik açıklarını içeren olaylarla karşılaştırıldığında, nispeten düşük kalmıştır. Tenable’ın baş güvenlik sorumlusu Bob Huber, güvenlik açığının ve saldırı yolunun basitliği göz önüne alındığında, bildirilen saldırıların ölçeğinin ve kapsamının şaşırtıcı bir şekilde beklenenden daha düşük olduğunu söylüyor. Huber, “CISA’nın yakın tarihli ulus devlet faaliyetleri tarafından belirtildiği gibi, ancak son zamanlarda bazı önemli hedefleme kanıtları gördük” diyor.
Kesintisiz Tehdit
Ancak güvenlik araştırmacıları, bunun Log4j’den gelen tehdidin geçen yıl içinde azaldığı anlamına gelmediğini belirtiyor.
Her şeyden önce, kuruluşların büyük bir yüzdesi tehdide karşı bir yıl önceki kadar savunmasız durumda. Tenable’ın yakın zamanda yürüttüğü hatayla ilgili bir telemetri analizi, Kuruluşların %72’si savunmasızdı 1 Ekim’den itibaren Log4j’ye. Tenable, küresel olarak kuruluşların %28’inin hatayı tamamen iyileştirdiğini tespit etti. Ancak Tenable, sistemlerini iyileştiren kuruluşların, ortamlarına yeni varlıklar ekledikçe Log4j ile tekrar tekrar karşılaştığını keşfetti.
Çoğu durumda – aslında %29’u – sunucular, Web uygulamaları, kapsayıcılar ve diğer varlıklar, ilk düzeltmenin hemen ardından Log4j’ye karşı savunmasız hale geldi.
Huber, “Kuruluşların düzeltmeyi denklemin sol tarafına yerleştirdiğini varsayarsak – yazılım için derleme hattı sırasında – yeniden sunma oranları azalmalıdır” diyor. “Yeniden kullanıma sunma ve değiştirme oranının çoğu, büyük ölçüde bir kuruluşun yazılım yayınlama döngüsüne bağlıdır.”
Ayrıca, siber güvenlik topluluğundaki kusurun neredeyse her yerde bulunabilen farkındalığına rağmen, Log4j’nin savunmasız sürümlerini, uygulamaların onu kullanma şeklinden dolayı birçok kuruluşta bulmak can sıkıcı bir şekilde zor olmaya devam ediyor. Sonatype CTO’su Brian Fox, bazı uygulamaların açık kaynak günlük kaydı bileşenini uygulamalarında doğrudan bir bağımlılık olarak kullanabileceğini ve diğer durumlarda bir uygulamanın Log4j’yi geçişli bir bağımlılık veya başka bir bağımlılığın bağımlılığı olarak kullanabileceğini söylüyor.
Fox, “Geçişli bağımlılıklar, doğrudan bağımlılık seçimlerinizden ortaya çıktığı için, geliştiricileriniz tarafından her zaman bilinmeyebilir veya doğrudan görülemeyebilir” diyor.
Birçok durumda, Apache Foundation Log4Shell’i ilk kez ifşa ettiğinde, şirketler binlerce dahili e-posta göndermek, sonuçları elektronik tablolarda toplamak ve dosya sistemlerini tekrar tekrar taramak zorunda kaldı, diyor Fox. “Bu, şirketlerin bileşene yama uygulamak için değerli zamanına ve kaynaklarına mal oldu ve güvenlik açığının kötü niyetli etkisinin boyutunu uzattı” diyor.
Sonatype’ın elinde bulundurduğu Maven Central Java deposundan alınan veriler şunu gösteriyor: Log4 indirmelerinin %35’i şu anda yazılımın savunmasız sürümleri olmaya devam ediyor. Fox, “Pek çok şirket, bir yanıta bile başlamadan önce yazılım envanterini oluşturmaya çalışıyor ve geçişli bağımlılıkların sonuçlarının farkında değiller” diyor.
Tüm sorunlar nedeniyle, ABD İç Güvenlik Bakanlığı inceleme kurulu bu yılın başlarında Log4’ün kuruluşların yıllarca mücadele etmesi gereken yaygın bir güvenlik riski olduğu sonucuna vardı. Yönetim kurulu üyeleri, Log4j’nin savunmasız örneklerinin uzun yıllar sistemlerde kalacağını ve kuruluşları yakın gelecekte saldırı riskiyle karşı karşıya bırakacağını değerlendirdi.
Tek Olumlu Sonuç
Hatayı takip eden güvenlik araştırmacıları, Log4j’den gelen olumlu yansımanın, yazılım bileşimi analizi ve yazılım malzeme listesi (SBOM) gibi uygulamalara çektiği artan ilgi olduğunu söylüyor. Kuruluşların yalnızca savunmasız olup olmadıklarını veya güvenlik açığının ortamlarında nerede bulunabileceğini belirlemede karşılaştıkları zorluklar, kod tabanlarındaki tüm bileşenlere, özellikle de açık kaynak ve üçüncü taraf kaynaklardan gelenlere yönelik görünürlük ihtiyacının daha iyi anlaşılmasını sağlamıştır.
ReversingLabs CISO’su Matthew Rose, “Log4J sorunuyla ilgili soruşturma, DevOps’un hızına ayak uyduran SBOM’lara ek olarak daha iyi yazılım tedarik zinciri onayına duyulan ihtiyacı yeniden doğruladı” diyor. “Uygulama güvenliği ve mimarisi ekipleri, uygulamanın kaynak kodu, API’ler veya açık kaynak paketleri gibi bölümlerinde risk aramanın yeterli olmadığını anladılar. Artık uygulama mimarisinin tam olarak anlaşılmasının, SQLI bulmak kadar önemli olduğunun farkındalar. veya siteler arası komut dosyası çalıştırma hataları (XSS)” diyor.