Apache Foundation’ın kötü şöhretli Lo4j güvenlik açığını açıklamasından üç ay sonra [CVE-2021-44228] ve bunun için bir düzeltme yayınladı, günlük kaydı aracının Maven Central Java paket deposundan indirilen 10’dan 4’ünden fazlası, savunmasız sürümler olarak bilinmeye devam ediyor.
Maven Central yöneticisi Sonatype’ın sözde Log4Shell kusurunun ilk ortaya çıkmasından hemen sonra başlattığı bir gösterge panosu, 4 Şubat ile 10 Mart 2022 arasında indirilen Log4j paketlerinin %41’inin Log4j 2.15.0’dan önceki sürümler olduğunu gösteriyor. Bu, Log4Shell kusurunun ilk açıklandığı 10 Aralık 2021’de Apache Foundation’ın yayınladığı günlük kaydı aracının yamalı sürümüdür. Bundan sonra, Vakıf, Log4Shell’in ifşa edilmesinden sadece birkaç gün sonra günlüğe kaydetme aracında ortaya çıkarılan iki ardışık – ve nispeten daha az ciddi – güvenlik açığını gidermek için iki güncelleme daha yayınladı.
Sonatype’ın kontrol paneli 10 Aralık 2021’den bu yana Log4j’nin toplamda 31,4 milyondan fazla indirildiğini gösterdi. Bunlardan kaçının savunmasız sürüm olduğu belli değil, ancak en son indirme istatistiklerine göre sayı 10’a yakın veya 10’u aşan olabilir. milyon.
Log4j ve Katmanlar
Öyleyse, kuruluşlar ve geliştiriciler neden Log4j paketlerinin bilinen savunmasız sürümlerini indiriyor ve özellikle kusurun yaygınlığı ve istismar edilebilme kolaylığı göz önüne alındığında, bu sürümler neden ilk etapta indirilebilir durumda?
Qualys’te kötü amaçlı yazılım tehdidi araştırması başkan yardımcısı Travis Smith, indirmelerin devam etmesi için birkaç nedene işaret ediyor. “Asıl suçlu, muhtemelen bağımlılıklarının belirli bir sürüm derlemesini indirmek üzere yapılandırılmış otomatik derleme sistemleridir” diyor. Daha az bakım gerektiren projeler, güncellenen yazılımlarla çakışmaları önlemek için özellikle belirli bir sürümü otomatik olarak indirebilir. “Bu yazılımın sahibi Log4j’yi çevreleyen haberlere dikkat etmediyse, uygulamaları istismar riskine açık bırakılır.”
Log4j’nin birçok Java uygulamasının ayrılmaz bir parçası olması ve çoğu zaman onlarla birkaç katmanın derinlerine gömülü olması, birçok kuruluşun sorunu algılamasını ve düzeltmesini son derece zorlaştırdı. Smith, “Korunmasız sürümün mevcut indirmelerinin çoğunun, yükseltme için harcanan süreyi haklı çıkaramayan projeler için olduğu sonucuna varılabilir” diyor.
Smith’e göre, savunmasız Log4j indirmelerinin yüksek yüzdesinin bir başka açıklaması, araştırmacıların bunu savunmaları test etmek için yapıyor olması ve rakiplerin de açıklarını test etmek için yapıyor olabilir.
Sonatype’ın saha CTO’su İlkka Turunen, başka bir sorunun da birçok kuruluşta temel yazılım tedarik zinciri yönetiminin eksikliği olduğunu söylüyor. Yeterli yazılım bileşimi analiz araçları ve bir yazılım malzeme listesi olmadan, kuruluşlar hangi bileşenlerin hangi sürümlere çıktığını bulmakta zorlanabilir.
Turunen, “Birçok kuruluşta Log4j yangın tatbikatı hakkında gözlemlediğimiz zor kısım, üretimlerinde hangi üçüncü taraf bileşenlerin kullanıldığı konusunda tam bir farkındalık ve görünürlük eksikliğiydi.” Kuruluşlar genellikle uygulamalarında ne olduğunu anlamazlar ve bu nedenle etkilenen uygulamaları hızlı bir şekilde hedefleyip yükseltme yapamazlar. “Kısacası, birçok şirket hala tepki vermeye başlamadan önce yazılım envanterini oluşturmaya çalışıyor.”
Qualys’in bulut güvenlik platformundan aldığı son veriler, aslında şirkete göre, İnternet’teki Log4j örneklerinin yaklaşık %30’unun açıktan yararlanmaya açık olduğunu gösteriyor. Vulcan Cyber’de kıdemli teknik mühendis olan Mike Parkin, “Apache Foundation’ın Log4J’si sayısız yerde kullanılıyor ve yüzlerce paketle birlikte geliyor” diyor. “Bu geniş kullanım, onu ilk etapta bu kadar büyük bir güvenlik açığı yapan şeyin bir parçasıydı.”
Her geliştiricinin Log4J’yi paketlerine aynı şekilde uygulamadığı gerçeği, yamalamanın önemli bir sorun haline gelmesinin bir başka nedeni olduğunu söylüyor.
Güvenlik Açığı Olan Log4J Sürümleri Neden Hala Kullanılabilir?
Bu arada, Smith ve diğerleri, savunmasız Log4j paketlerinin Maven Central aracılığıyla indirilmeye devam etmesinin nedeninin yazılım bağımlılıkları olduğunu söyledi. Birçok yazılım parçası Log4j’nin savunmasız sürümlerine bağlıdır ve bunların aniden kaldırılması sistemlerin bozulmasına neden olabilir. tarafından bir analiz Google araştırmacıları Log4Shell açığının açıklanmasından bir hafta sonra Maven Central’daki yaklaşık 17.000 Java paketinin güvenlik açığı içerdiğini gösterdi. O sırada Google, etkilenen paketlerin %25’i için sabit sürümlerin mevcut olduğunu keşfetti. O zamandan beri, muhtemelen daha pek çoğu yamalı.
Yine de savunmasız sürümleri Maven deposundan kaldırmak risklidir. Turunen, “Maven Central’ın ilk vekilharçları olduğumuzda, koyduğumuz kilit emirlerden biri ‘bir yapıyı yıkmayacaksın’ idi” diyor. Güvenlik açıklarını ortadan kaldırabilecek kendi yargımızı öne sürmek cazip gelse de, toplum için aslında en iyi olan şey herkesin kendi yargılarını vermesidir.”
Sonatype’ın kurucu ortağı ve CTO’su Brian Fox, Maven Central’ın kullanıcının her seferinde oktan seviyesini seçtiği bir benzin istasyonundan çok bir doğal gaz boru hattına benzediğini söylüyor. “Bu indirmeleri depodan indirirsek, dünya çapında onu arayan her yapı aniden başarısız olur” diyor.
Bir programcının kendi geliştirdiği left-pad adlı paketi npm JavaScript kayıt defterinden kaldırdığı 2016 olayına işaret ediyor. bir anlaşmazlık yüzünden. Paket yalnızca 11 satır koddan oluşmasına rağmen, kaldırılması binlerce bağımlı projeyi bozdu ve İnternet genelinde önemli kesintilere neden oldu. Fox, Log4j ile aynı şeyi yapmanın, muhtemelen haklı olmadığı ve yarardan çok zarara yol açabileceği kesintilere neden olacağını söylüyor.