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üzeltmek için başka bir LOG4J sürümünü yayınladı.
Bugünden önce, 2.17.0, log4j'in en son sürümüydü ve yükseltme için en güvenli sürümünü kabul etti, ancak bu tavsiyenin şimdi gelişti.
Orijinal log4shell güvenlik açığının (CVE-2021-44228) tehdit aktörleriyle kütle sömürüsü, 9 Aralık'lık bir POC, GitHub'da ortaya çıktığında bir POC istismar ettiğinde başladı.
Log4j'in Java uygulamalarının çoğunluğunda engin kullanımı göz önüne alındığında, Log4shell yakında dünya çapındaki işletmeler ve hükümetler için bir kabus haline geldi.
Orijinal log4shell istisnası tarafından ortaya çıkan kritik risk, paramount olduğunda, 2,15 ve 2.16 da dahil olmak üzere, 2.15 ve 2.16 da dahil olmak üzere, LOG4J sürümlerinde ortaya çıkan güvenlik açığının daha yumuşak varyantları ortaya çıkmıştır.
BleepingComputer daha önce, log4j'i etkileyen dört farklı CVES'de ve 'Logback' çerçevesinde keşfedilen dört farklı CVES bildirdi. 2.16 sürümündeki bir DOS kusurunun keşfedilmesinden sonra, tavsiyeler 2.17.0 sürümüne yükseltmeye doğru hızla kaydırıldı, hepsinin en güvenliini gördü.
Ancak şimdi Beşinci Bir Güvenlik Açığı - CVE-2021-44832 olarak izlenen bir RCE FAW, 2.17.0'da keşfedildi, en yeni 2.17.1'e uygulanan bir yama.
CVSS ölçeğinde 'ılımlı' olarak derecelendirildi ve 6.6 puan atandı, güvenlik açığı Log4j'deki JDNI erişimi üzerindeki ek kontrollerin olmamasından kaynaklanıyor.
"JDBC Appender, JNDI'ye erişirken JNDimanager'ı kullanmalıdır. JNDI Access, BleepingComputer tarafından görülen konusundaki açıklamayı belirtir.
"CVE-2021-44832 ile ilgili olarak, kayıt yapılandırma dosyasını değiştirme izni olan bir saldırganın, uzak kodu yürütebilecek olan bir JNDI URI'yı içeren bir Veri kaynağına sahip bir JDBC aperding kullanarak kötü amaçlı bir konfigürasyon oluşturabilir."
CheckMarx Güvenlik Araştırmacısı Yaniv Nizry, Apache'ye karşı kırılganlığı bildirmek için kredi talep etti:
Bir blogpost için bizi izlemeye devam edin;) pic.twitter.com/d56wpvsuf3
Nizry'nin Tweet'i hızlı bir şekilde trafikte patladı, güvenlik uzmanlarından ve devam eden log4j-yamalı yorgunluğun 'mağdurlarının' mağdurları ve 'kurbanlarının' sözlerini çekti.
"Umarım bu bir şaka, umarım çok fazla ... # log4j," bir kullanıcıyı yanıt olarak tweeted.
"Yapılacak tek sorumlu şeyin, 'log4j düzeltilemeyeceğini, hiçbir şey için kullanmadığını," ", bir şey için kullanmadığını" okuyan bir yan yanıp sönen bir neon işaretinin ortaya çıktığı noktadan çok geçtik.
Güvenlik Uzmanı Kevin Beaumont, tatillerde "Başarısız Log4J açıklaması" örneğini etiketledi.
Nizry'nin Tweet, BleepingComputer, Log4J 2.17'de bir RCE hatasının varlığını belirten resmi bir danışma veya not görmedi.
Tweet'in kendisi, güvenlik açığı veya nasıl yararlanılabileceği hakkında hiçbir bilgi içermiyordu, ancak birkaç dakika içinde, talebi araştırmaya başlamak için bir paket güvenlik artışı ve netizens'leri önderlik etti.
Güvenlik açığını açıklamak, 9 Aralık'taki log4shell'ten açıkça görüldüğü gibi, kötü amaçlı tarama ve sömürü faaliyetlerini gerçekleştirmek için tehdit aktörlerini canlandırabilir.
Marc Rogers, Okta'daki Siber Güvenlik VP, ilk önce güvenlik açığı tanımlayıcısını (CVE-2021-44832) açıkladı ve hatanın sömürüsünün, yapılandırmanın uzak bir sunucudan yüklendiği varsayılan olmayan bir log4j kurulumuna bağlı olduğunu açıkladı:
LOG4J CVE-2021-44832'ye benziyor. JDBC Log Appender'ı dinamik bir URL adresi ile kullanıyorsunuz. "
Şimdiye kadar, LOG4J güvenlik açıkları, devlet destekli bilgisayar korsanlarından fidye yazılım çetelerinden fidye yazılım çetelerinden ve diğerlerini savunmasız sistemler üzerine enjekte etmek için her türlü tehdit aktöründen yararlandılar.
Conti Ransomware çetesi, göz kamaştırıcı VMware VCenter sunucuları görüldü. Saldırganlar Vietnamca Crypto platformunu ihlal ederken, Log4shell via 5 milyon dolarlık bir fidye istedi.
LOG4J kullanıcıları derhal en son sürüm 2.17.1'e yükseltmelidir (Java 8 için). Desteklenen versiyonlar 2.12.4 (Java 7) ve düzeltmeyi içeren 2.3.2 (Java 6) da kısa bir süre sonra serbest bırakılması bekleniyor.
BleepingComputer, yazmanın önceden yorum için CheckMarx'a ulaştı ve cevaplarını bekliyoruz.
GÜNCELLEME 4:45 PM ET: CHECKMARX, güvenlik açığını açıklayan bir blog yazı yayınladı.
Tüm log4j, logback hataları şimdiye kadar biliyoruz ve neden hendek yapmalısınız 2.15
Araştırmacılar, kritik log4shell güvenlik açığı için 'aşı' yayınladı
NVIDIA, LOG4J güvenlik açığından etkilenen uygulamaları açıklar.
Log4j 2.16'ya yükseltildi mi? Sürpriz, 2.17 sabitleme dosu var
LOG4J: Korunmasız ürünlerin ve satıcı danışmanlarının listesi
Kaynak: Bleeping Computer