Log4j güvenlik açığı, Apache Yazılım Vakfı'nın geçen Kasım ayında açıklanmasından bir yıl sonra bile kurumsal kuruluşlar için büyük bir tehdit oluşturmaya devam ediyor - Her ne kadar kusurun kendisini hedef alan kamuya açıklanmış saldırıların sayısı çoğu kişinin başlangıçta beklediğinden daha az olsa da.

Güvenlik araştırmacıları, sistemlerin büyük bir yüzdesinin hâlâ kusura karşı yama yapılmadan kaldığını ve kuruluşların sorunu bulup düzeltme ve ardından kusurun çevreye yeniden yayılmasını önleme konusunda zorluklarla karşı karşıya kaldığını söylüyor.

Contrast Security'nin CISO'su David Lindner, "Log4j'nin Java uygulamalarının [neredeyse] %64'ünde kullanılması ve bunların yalnızca %50'sinin tamamen sabit bir sürüme güncellenmesi, saldırganların onu hedeflemeye devam edeceği anlamına geliyor" diyor. "En azından şimdilik, saldırganlar Log4j aracılığıyla yararlanmanın yollarını bulmak için bir gün geçirmeye devam ediyor."

Birden Fazla Saldırı Ancak Beklenenden Daha Az

Log4j kusuru (CVE-2021-44228Genellikle Log4Shell olarak anılan , veri depolama ve alma için Log4j'nin Java Adlandırma ve Dizin Arayüzü (JNDI) işlevinde bulunur. Uzaktaki saldırganlara savunmasız sistemlerin kontrolünü ele geçirmek için son derece kolay bir yol sağlar; Log4J'nin hemen hemen her Java uygulama ortamında kullanıldığı göz önüne alındığında bu bir sorundur. Güvenlik araştırmacıları, yaygınlığı ve saldırganların kolaylıkla istismar edebilmesi nedeniyle bunu son yıllardaki en önemli güvenlik açıklarından biri olarak görüyor.

Geçtiğimiz yıl boyunca, tehdit aktörlerinin hedef ağa ilk erişim sağlamanın bir yolu olarak kusuru hedeflediğine dair çok sayıda rapor yayınlandı. 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çeriyordu. Ö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 yapılmamış bir VMware Horizon sunucusundaki Log4j güvenlik açığından yararlandığı konusunda uyarıda bulundu. kripto madenciliği yazılımını ve kimlik bilgisi toplayıcılarını dağıtın federal bir ağda.

Uyarı, Fortinet'in Mart ayında Çinli tehdit aktörü Deep Panda'nın kullandığı uyarıya benzerdi. özdeş vektör hedef sistemlere bir arka kapı yerleştirmek ve Ahn Labs'tan Kuzey Kore'nin Lazarus Grubu hakkında bir başka kapı açmak kendi arka kapısını dağıtıyor aynı yol. Microsoft gibi diğerleri de İran'ın Fosfor grubu ve Çin'in Hafniyum tehdit aktörü gibi devlet aktörlerinin Log4'ü kullanarak gözlemlediklerini bildirdi. Etkilenen sistemlere ters mermiler bırakın.

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 kamuya açık olarak bildirilen ihlallerin gerçek sayısı, özellikle Exchange Server güvenlik açıklarını içeren olaylarla karşılaştırıldığında nispeten düşük kalmıştır. ProxyOturum açma ve ProxyKabuğu. Tenable'ın güvenlik şefi Bob Huber, güvenlik açığının basitliği 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 beklenenden şaşırtıcı derecede düşük olduğunu söylüyor. Huber, "CISA'nın son zamanlardaki ulus devlet faaliyetlerinde de belirtildiği gibi, hedeflemeye ilişkin bazı önemli kanıtları ancak yakın zamanda gördük" diyor.

Azaltılmamış Tehdit

Ancak güvenlik araştırmacıları, bunun Log4j'den kaynaklanan tehdidin geçen yıl azaldığı anlamına gelmediğini belirtiyor.

Öncelikle kuruluşların büyük bir yüzdesi, tehdide karşı bir yıl önceki kadar savunmasız durumda. Tenable'ın yakın zamanda gerçekleştirdiği hatayla ilgili telemetri analizi şunu gösterdi: Kuruluşların %72'si savunmasız durumdaydı 4 Ekim itibarıyla Log1j'ye. Tenable, küresel çapta kuruluşların %28'inin hatayı tamamen giderdiğini tespit etti. Ancak Tenable, sistemlerini iyileştiren kuruluşların, ortamlarına yeni varlıklar ekledikçe Log4j ile sıklıkla tekrar tekrar karşılaştıklarını buldu.

Pek çok durumda (aslında %29) sunucular, Web uygulamaları, konteynerler ve diğer varlıklar ilk düzeltmeden hemen sonra Log4j'ye karşı savunmasız hale geldi.

Huber, "Kurumların düzeltmeyi denklemin sol tarafında (yazılım için üretim hattı sırasında) oluşturduğunu varsayarsak, yeniden sunma oranları azalacaktır" diyor. "Yeniden sunma ve değişim oranının büyük bir kısmı, büyük ölçüde bir kuruluşun yazılım sürüm döngüsüne bağlıdır."

Ayrıca, siber güvenlik camiasındaki kusurun neredeyse her yerde farkında olmasına rağmen, Log4j'nin savunmasız versiyonlarını, uygulamaların onu kullanma şekli nedeniyle birçok kuruluşta bulmak can sıkıcı derecede 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.

Fox, Apache Vakfı'nın Log4Shell'i ilk kez ortaya çıkardığı çoğu durumda şirketlerin binlerce dahili e-posta göndermek, sonuçları elektronik tablolarda toplamak ve dosya sistemlerini yinelemeli olarak taramak zorunda kaldığını söylüyor. "Bu, şirketlerin bileşene yama yapmak için değerli zamanlarına ve kaynaklarına mal oldu ve güvenlik açığının kötü niyetli etkisinin boyutunu uzattı" diyor.

Sonatype'in muhafaza ettiği Maven Central Java deposundaki veriler şunu gösteriyor: Log35 indirmelerinin %4'i şu anda yazılımın savunmasız sürümleri olmaya devam ediyor. Fox, "Birçok şirket hâlâ bir müdahaleye 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ğil" diyor.

Tüm bu sorunlar nedeniyle, ABD İç Güvenlik Bakanlığı inceleme kurulu bu yılın başlarında Log4'ün bir yaygın güvenlik riski kuruluşların yıllarca uğraşması gerekecek. Yönetim kurulu üyeleri, Log4j'nin savunmasız örneklerinin sistemlerde uzun yıllar kalacağını ve kuruluşları öngörülebilir gelecekte saldırı riskine sokacağını değerlendirdi.

Tek Olumlu Sonuç

Hatayı takip eden güvenlik araştırmacıları, Log4j'nin olumlu etkisinin, yazılım kompozisyon analizi ve yazılım malzeme listesi (SBOM) gibi uygulamalara artan ilgiden kaynaklandığını söylüyor. Kuruluşların yalnızca savunmasız olup olmadıklarını veya güvenlik açığının çevrelerinde nerede bulunabileceğini belirlerken karşılaştıkları zorluklar, kod tabanlarındaki tüm bileşenlerin (özellikle açık kaynak ve üçüncü taraf kaynaklardan gelenler) görünürlük ihtiyacının daha iyi anlaşılmasını sağladı.

ReversingLabs'ın CISO'su Matthew Rose, "Log4J sorununa ilişkin soruşturma, DevOps'un hızına ayak uydurabilen SBOM'lara ek olarak daha iyi yazılım tedarik zinciri doğrulaması ihtiyacını yeniden doğruladı" diyor. “Uygulama güvenliği ve mimari ekipleri, uygulamanın kaynak kodu, API'ler veya açık kaynak paketleri gibi bölümlerinde risk aramanın yeterli olmadığını fark etti. Artık uygulamanın mimarisini tam olarak anlamanın, SQLI veya siteler arası komut dosyası hatalarını (XSS) bulmak kadar önemli olduğunun farkına varıyorlar” diyor.

• Akıllı para. Avrupa'nın En İyi Bitcoin ve Kripto Borsası.Buraya Tıkla
• Plato blok zinciri. Web3 Metaverse Zekası. Bilgi Güçlendirildi. Buradan Erişin.
• Kaynak: https://www.darkreading.com/application-security/one-year-later-log4shell-exposed-attack