Apache Log4J kütüphanesini kullanan uygulamaların kabaca% 38'i, yamaların iki yıldan fazla bir süredir mevcut olmasına rağmen, maksimum şiddet derecesini taşıyan CVE-2021-442228 olarak tanımlanan kritik bir güvenlik açığı da dahil olmak üzere güvenlik sorunlarına karşı savunmasız bir sürüm kullanıyor.
Log4Shell, Log4J 2.0-beta9 ve 2.15.0'a kadar sistemler üzerinde tam kontrol almaya izin veren kimlik doğrulanmamış bir uzaktan kod yürütme (RCE) kusurudur.
Kusur, 10 Aralık 2021'de aktif olarak sömürülen bir sıfır günü olarak keşfedildi ve yaygın etkisi, sömürü kolaylığı ve büyük güvenlik sonuçları, tehdit aktörlerine açık bir davet olarak işlev gördü.
Durum, etkilenen proje bakımcılarını ve sistem yöneticilerini bilgilendirmek için kapsamlı bir kampanya başlattı, ancak çok sayıda uyarıya rağmen, önemli sayıda kuruluş, yamalar kullanılabilir hale geldikten çok sonra savunmasız versiyonları kullanmaya devam etti.
Güvenlik açığı açıklanmasından ve düzeltmeler yayınlanmasından iki yıl sonra, Log4shell'e karşı hala savunmasız birçok hedef var.
15 Ağustos ve 15 Kasım arasında toplanan verilere dayanan uygulama güvenlik şirketi Veracode'un bir raporu, eski sorunların kapsamlı bir dönem için devam edebileceğini vurgulamaktadır.
Veracode, 1.1 ve 3.0.0-alpha1 arasındaki sürümlerle Log4J'ye dayanan 38.278 başvuru kullanan 3.866 kuruluştan 90 gün boyunca veri topladı.
Bu uygulamaların% 2.8'i, doğrudan Log4shell'e karşı savunmasız olan 2.0-beta9 ila 2.15.0 Log4J varyantları kullanır.
Log4Shell'e karşı savunmasız olmasa da, çerçevenin 2.17.1 sürümünde sabitlenmiş bir uzaktan kod yürütme kusuru olan CVE-2021-44832'ye duyarlı olan% 3.8 kullanım Log4J 2.17.0 kullanır.
Son olarak,% 32'si Ağustos 2015'ten bu yana desteğin sonuna ulaşan Log4J sürüm 1.2.x kullanıyor. Bu sürümler, CVE-2022-23307, CVE-2022-23305 ve CVE dahil 2022 yılına kadar yayınlanan çoklu şiddetli güvenlik açıklarına karşı savunmasızdır. -2022-23302.
Toplamda, Veracode, görünürlüğü içindeki uygulamaların yaklaşık% 38'inin güvensiz bir Log4J sürümü kullandığını buldu.
Bu, Sonatype'deki yazılım tedarik zinciri yönetimi uzmanlarının, geçen hafta kütüphanenin indirmelerinin% 25'inin savunmasız sürümlerle ilgili olduğu Log4J kontrol panelinde rapor verdiklerine yakındır.
Eski kütüphane sürümlerinin sürekli kullanımı, Veracode'un gereksiz komplikasyonlardan kaçınmak isteyen geliştiricilere atfettiği devam eden bir sorunu göstermektedir.
Veracode’un bulgularına göre, geliştiricilerin% 79'u, işlevselliği kırmaktan kaçınmak için kod tabanlarına ilk dahil olduktan sonra üçüncü taraf kütüphanelerini asla güncellememeyi tercih ediyor.
Açık kaynaklı kütüphane güncellemelerinin% 65'i küçük değişiklikler içerse ve fonksiyonel sorunlara neden olma olasılığı düşük olsa bile bu doğrudur.
Dahası, çalışma, yüksek şiddetli kusurları ele almanın 65 gün boyunca projelerin% 50'sini aldığını gösterdi. Azaltıldığında birikmiş işlerin yarısını düzeltmek normalden 13,7 kat daha uzun sürer ve bilgi eksikken% 50'sini ele almak için yedi aydan fazla.
Ne yazık ki, Veracode’un verileri Log4Shell'in güvenlik endüstrisindeki birçok kişinin olacağını umduğu uyandırma çağrısı olmadığını gösteriyor.
Bunun yerine, Log4J tek başına 3 vakanın 1'inde bir risk kaynağı olmaya devam eder ve saldırganların belirli bir hedefi tehlikeye atmak için yararlanabileceği çoklu yollardan biri olabilir.
Şirketler için öneri, çevrelerini taramak, açık kaynaklı kütüphanelerin versiyonlarını kullanmak ve daha sonra hepsi için acil bir yükseltme planı geliştirmektir.
Sophos Backports RCE Desteklenmemiş Güvenlik Duvarlarına Saldırılardan Sonra Fix
Böcek zinciri yoluyla RCE saldırılarına maruz kalan 1.450'den fazla PFSense sunucusu
WordPress, Web sitelerini açığa çıkaran pop zincirini RCE saldırılarına düzeltiyor
Yedekleme eklentisinde kritik hata tarafından RCE saldırılarına maruz kalan 50K WordPress siteleri
Atlassian yamaları Kritik RCE kusurları birden çok ürün boyunca
Kaynak: Bleeping Computer