Apache, CVE-2021-44832 olarak izlenen 2.17.0’da yeni keşfedilen bir uzaktan kod yürütme (RCE) güvenlik açığını düzelten 2.17.1 başka bir Log4j sürümünü yayınladı.
Bugünden önce 2.17.0, Log4j’nin en yeni sürümüydü ve yükseltilecek en güvenli sürüm olarak kabul edildi, ancak bu tavsiye artık evrim geçirdi.
Beşinci Log4j CVE, bir aydan kısa sürede
Orijinalin toplu kullanımı Log4Shell güvenlik açığı (CVE-2021-44228) tarafından tehdit aktörleri tarafından 9 Aralık civarında başladı. PoC istismarı çünkü GitHub’da ortaya çıktı.
Log4j’nin Java uygulamalarının çoğunda geniş kullanımı göz önüne alındığında, Log4Shell kısa sürede bir işletmeler ve hükümetler için kabus Dünya çapında.
Orijinal Log4Shell istismarının oluşturduğu kritik risk çok önemli olsa da, Log4j sürümlerinde, daha önce tamamen yama yapıldığına inanılan 2.15 ve 2.16 dahil olmak üzere, güvenlik açığının daha hafif varyantları ortaya çıktı.
BleepingComputer daha önce bildirildi Log4j’yi etkileyen dört farklı CVE ve bir tanesi ‘logback’ çerçevesinde keşfedildi. 2.16 sürümünde bir DoS kusurunun keşfedilmesinden sonra, tavsiyeler hızla 2.17.0 sürümüne yükseltme, en güvenlisi olarak kabul edilir.
Ama şimdi beşinci bir güvenlik açığı—CVE-2021-44832 olarak izlenen bir RCE hatası, 2.17.0’da keşfedildi ve bir yama uygulandı. en yeni sürüm 2.17.1 hangisi çıktı.
Önem derecesi ‘Orta’ olarak derecelendirilen ve CVSS ölçeğinde 6,6 puan atanan güvenlik açığı, log4j’de JDNI erişimi üzerinde ek kontrollerin bulunmamasından kaynaklanmaktadır.
“JDBC Appender, JNDI’ye erişirken JndiManager’ı kullanmalıdır. JNDI erişimi bir sistem özelliği aracılığıyla kontrol edilmelidir”, BleepingComputer tarafından görülen sorun açıklaması belirtir.
“Günlük yapılandırma dosyasını değiştirme iznine sahip bir saldırganın, uzak kod yürütebilen bir JNDI URI’sine başvuran bir veri kaynağına sahip bir JDBC Ekleyici kullanarak kötü amaçlı bir yapılandırma oluşturabildiği CVE-2021-44832 ile ilgilidir.”
Checkmarx güvenlik araştırmacısı Yaniv Nizry güvenlik açığını Apache’ye bildirdiği için hak talebinde bulundu:
Blog yazısı için takipte kalın 😉 pic.twitter.com/D56WpVsuF3
— Yaniv Nizry (@YNizry) 28 Aralık 2021
Nizry’nin tweet’i trafikte hızla patladı, yorumları çekti ve Mizah güvenlik uzmanlarından ve devam eden log4j-yama yorgunluğunun ‘kurbanlarından’.
“Umarım bu bir şakadır, umarım çok dalgın surat #log4j” tweetlendi yanıt olarak bir kullanıcı.
“Yapılacak tek sorumlu şeyin ‘LOG4J DÜZELTİLEMEZ, HİÇBİR ŞEY İÇİN KULLANMAYIN’ yazan dev bir yanıp sönen neon tabela asmak olduğu noktayı çoktan geride bıraktık.” alaylı bir diğeri.
Güvenlik uzmanı Kevin Beaumont etiketli örnek tatiller sırasında başka bir “başarısız Log4j ifşası hareket halinde”.
Çok erken mi açıklandı?
Nizry’nin tweet’i sırasında, BleepingComputer log4j 2.17’de bir RCE hatasının varlığını gösteren resmi bir tavsiye veya not görmedi.
Tweet’in kendisi güvenlik açığı veya nasıl istismar edilebileceği hakkında hiçbir ayrıntı içermiyordu, ancak birkaç dakika içinde bir grup güvenlik uzmanı ve netizen’in iddiayı araştırmaya başlamasına neden oldu.
Güvenlik açıklarını zamanından önce ifşa etmek, 9 Aralık’taki Log4Shell istismar sızıntısından da anlaşılacağı gibi, tehdit aktörlerini kötü niyetli tarama ve istismar faaliyetleri yürütmeye çekebilir.
Okta’daki siber güvenlikten sorumlu başkan yardımcısı Marc Rogers, ilk olarak güvenlik açığı tanımlayıcısını (CVE-2021-44832) ve hatanın kullanılmasının, yapılandırmanın uzak bir sunucudan yüklendiği, varsayılan olmayan bir log4j kurulumuna bağlı olduğunu açıkladı:
Görünüşe göre log4j CVE-2021-44832 varsayılan olmayan ön koşullara sahip: “Konfigürasyonu uzak bir sunucudan yüklüyorsunuz ve/veya birisi log4j yapılandırma dosyanızı ele geçirebilir/değiştirebilir
JDBC günlük ekleyiciyi dinamik bir URL adresiyle kullanıyorsunuz.”— Marc Rogers (@marcwrogers) 28 Aralık 2021
Şimdiye kadar, log4j güvenlik açıklarından her türlü tehdit aktörü tarafından istismar edildi. devlet destekli hackerlar ile fidye yazılımı çeteleri ve diğerleri Monero madencilerini enjekte et savunmasız sistemlerde.
Conti fidye yazılımı çetesinin izlediği görüldü savunmasız VMWare vCenter sunucuları. Oysa saldırganlar log4shell aracılığıyla Vietnam kripto platformu ONUS’u ihlal ediyor 5 milyon dolar fidye istedi.
Log4j kullanıcıları hemen en son sürüme yükseltme yapmalıdır. 2.17.1 sürümü (Java 8 için). Düzeltmeyi içeren 2.12.4 (Java 7) ve 2.3.2 (Java 6) sürümlerinin de kısa süre içinde yayınlanması bekleniyor.
BleepingComputer, yazmadan önce yorum için Checkmarx’a ulaştı ve yanıtlarını bekliyoruz.