Log4J uygulamalarının %30’undan fazlası kitaplığın savunmasız bir sürümünü kullanıyor


Log4J uygulamalarının %30'undan fazlası kitaplığın savunmasız bir sürümünü kullanıyor

Apache Log4j kitaplığını kullanan uygulamaların yaklaşık %38’i, yamaların iki yıldan uzun süredir mevcut olmasına rağmen CVE-2021-44228 olarak tanımlanan ve maksimum önem derecesine sahip kritik bir güvenlik açığı olan Log4Shell dahil olmak üzere güvenlik sorunlarına açık bir sürüm kullanıyor.

Log4Shell, Log4j 2.0-beta9 ve 2.15.0’a kadar olan sistemler üzerinde tam kontrolün ele geçirilmesine olanak tanıyan, kimliği doğrulanmamış bir uzaktan kod yürütme (RCE) kusurudur.

Kusur, 10 Aralık 2021’de aktif olarak kullanılan bir sıfır gün olarak keşfedildi ve yaygın etkisi, kullanım kolaylığı ve büyük güvenlik sonuçları, tehdit aktörlerine açık bir davetiye görevi gördü.

Bu durum, etkilenen proje bakımcıları ve sistem yöneticilerini bilgilendirmek için kapsamlı bir kampanyayı tetikledi, ancak çok sayıda uyarıya rağmen önemli sayıda kuruluş, yamalar kullanıma sunulduktan çok sonra bile savunmasız sürümleri kullanmaya devam etti.

Güvenlik açığının ortaya çıkmasından ve düzeltmelerin yayınlanmasından iki yıl sonra bile Log4Shell’e karşı hala savunmasız olan pek çok hedef var.

Uygulama güvenliği şirketi Veracode’un 15 Ağustos ile 15 Kasım arasında toplanan verilere dayanan raporu, eski sorunların uzun süre devam edebileceğini vurguluyor.

Katılaştırılmış saldırı yüzeyi

Veracode, 1.1 ile 3.0.0-alpha1 arasındaki sürümlere sahip Log4j’ye dayanan 38.278 uygulamayı kullanan 3.866 kuruluştan 90 gün boyunca veri topladı.

Bu uygulamaların %2,8’i, Log4Shell’e karşı doğrudan savunmasız olan Log4J’nin 2.0-beta9 ila 2.15.0 varyantlarını kullanıyor.

Diğer %3,8’lik kısım ise Log4Shell’e karşı savunmasız olmasa da çerçevenin 2.17.1 sürümünde düzeltilen bir uzaktan kod yürütme kusuru olan CVE-2021-44832’ye duyarlı olan Log4j 2.17.0’ı kullanıyor.

Son olarak %32’si, Ağustos 2015’ten bu yana desteği sona eren Log4j 1.2.x sürümünü kullanıyor. Bu sürümler, CVE-2022-23307, CVE-2022-23305 ve CVE dahil olmak üzere 2022’ye kadar yayınlanacak çok sayıda ciddi güvenlik açığına karşı savunmasızdır. -2022-23302.

Toplamda Veracode, görünürlüğü dahilindeki uygulamaların yaklaşık %38’inin güvenli olmayan bir Log4j sürümü kullandığını tespit etti.

Bu, Sonatype’teki yazılım tedarik zinciri yönetimi uzmanlarının Log4j panosundaki raporuna yakın; geçen hafta kütüphanede yapılan indirmelerin %25’i savunmasız sürümlerle ilgili.

Log4j sürüm indirmeleri
Log4j sürüm indirmeleri (Sonatip)

Kötü güvenlik uygulamaları

Güncel olmayan kitaplık sürümlerinin sürekli kullanımı, Veracode’un gereksiz komplikasyonları önlemek isteyen geliştiricilere atfettiği devam eden bir soruna işaret ediyor.

Veracode’un bulgularına göre geliştiricilerin %79’u, işlevselliklerin bozulmasını önlemek için üçüncü taraf kitaplıklarını kod tabanlarına ilk kez ekledikten sonra asla güncellememeyi tercih ediyor.

Açık kaynak kitaplık güncellemelerinin %65’i küçük değişiklikler ve işlevsel sorunlara neden olma olasılığı düşük düzeltmeler içerse bile bu durum geçerlidir.

Ayrıca çalışma, projelerin %50’sinde yüksek önemdeki kusurların giderilmesinin 65 gün sürdüğünü gösterdi. Yetersiz personel olduğunda, birikmiş işlerin yarısını düzeltmek normalden 13,7 kat daha uzun sürüyor ve bilgi eksikliği olduğunda %50’sini halletmek yedi aydan fazla zaman alıyor.

Ne yazık ki Veracode’un verileri Log4Shell’in güvenlik endüstrisindeki birçok kişinin umduğu uyandırma çağrısı olmadığını gösteriyor.

Bunun yerine, Log4j tek başına 3 vakadan 1’inde risk kaynağı olmaya devam ediyor ve saldırganların belirli bir hedefi tehlikeye atmak için kullanabilecekleri birden fazla yoldan biri olabilir.

Şirketlere öneri, ortamlarını taramaları, kullanımda olan açık kaynak kitaplıkların sürümlerini bulmaları ve ardından hepsi için bir acil durum yükseltme planı geliştirmeleridir.



Source link