Birkaç hafta önce, Log4j'nin güvenlik sorunlarıyla ilgili haberler ağdaki birçok kullanıcıyı alt üst ediyordu ve bu, en çok yararlanılan ve birçok uzmanın "en tehlikeli" olarak etiketlediği kusurlardan biri olmasıdır. uzun zamandır », Ağda bilinen güvenlik açıklarından bazıları hakkında konuşuyoruz burada blogda ve bu sefer bir başkasının haberini bulduk.
Ve bu birkaç gün önce Log4j 2 kütüphanesinde başka bir güvenlik açığı tespit edildiği haberi yayınlandı. (Zaten CVE-2021-45105 altında listelenmiştir) ve önceki iki sayıdan farklı olarak tehlikeli olarak sınıflandırılmıştır, ancak kritik değildir.
yeni sorun hizmet reddine izin verir ve döngüler ve anormal sonlandırmalar şeklinde kendini gösterir belirli satırları işlerken.
Güvenlik Açığı $ {ctx: var} gibi bağlam aramayı kullanan sistemleri etkiler, günlük çıktı biçimini belirlemek için.
W Log4j 2.0-alpha1 - 2.16.0 sürümleri, kontrolsüz yinelemeye karşı korumadan yoksundune bir saldırganın ikame için kullanılan değeri manipüle etmesine izin verdi yığında yer kalmayacak ve işlemin askıda kalmasına neden olacak sonsuz bir döngüye neden olmak. Özellikle "$ {$ {:: - $ {:: - $$ {:: - j}}}}" gibi değerler değiştirilirken sorun oluştu.
Buna ek olarak, Blumira araştırmacılarının, savunmasız Java uygulamalarına bir saldırı önerdiği belirtilebilir. örneğin harici ağlardan gelen istekleri kabul etmeyen, geliştiricilerin sistemleri veya Java uygulamalarının kullanıcıları bu şekilde saldırıya uğrayabilir.
Yöntemin özü, savunmasız Java süreçleri varsa yalnızca yerel ana bilgisayardan (yerel ana bilgisayar) ağ bağlantılarını kabul eden veya RMI isteklerini işleyen (Uzaktan Yöntem Çağırma, bağlantı noktası 1099) kullanıcının sisteminde, saldırı, yürütülen JavaScript koduyla gerçekleştirilebilir kullanıcı tarayıcıda kötü amaçlı bir sayfa açtığında. Böyle bir saldırıda bir Java uygulamasının ağ bağlantı noktasına bağlantı kurmak için, HTTP isteklerinin aksine aynı kaynak kısıtlamasının uygulanmadığı WebSocket API'si kullanılır (WebSocket, yerel ağ bağlantı noktalarını taramak için de kullanılabilir). Kullanılabilir ağ sürücülerini belirlemek için ana bilgisayar).
Google tarafından yayınlanan Log4j ile bağımlılıklarla ilişkili kütüphanelerin güvenlik açığının değerlendirilmesinin sonuçları da ilgi çekicidir. Google'a göre, sorun Maven Central deposundaki tüm paketlerin %8'ini etkiliyor.
Özellikle doğrudan ve dolaylı bağımlılıklara sahip 35863 Log4j ile ilgili Java paketi güvenlik açıklarına maruz kaldı. Buna karşılık Log4j, vakaların yalnızca %17'sinde birinci düzeyin doğrudan bağımlılığı olarak kullanılır ve güvenlik açığının kapsadığı paketlerin %83'ünde bağlama, Log4j'ye bağlı ara paketler aracılığıyla yapılır, yani anlatılır. ikinci ve en yüksek düzeyin bağımlılıkları (%21 - ikinci düzey, %12 - üçüncü, %14 - dördüncü, %26 - beşinci, %6 - altıncı).
Zafiyetin onarım oranı hala arzulanandan çok şey bırakıyor, güvenlik açığı tespit edildikten bir hafta sonra, tespit edilen 35863 paketten sorun şu ana kadar sadece 4620'de, yani %13'e kadar düzeltildi.
Bağımlılık gereksinimlerini güncellemek ve eski sürüm bağlarını Log4j 2'nin sabit sürümleriyle değiştirmek için paket değişiklikleri gereklidir (Java paketleri, en son sürümün yüklenmesine izin veren açık bir aralık değil, belirli bir sürüme bağlama uygular).
Java uygulamalarındaki güvenlik açığının ortadan kaldırılması, programların genellikle teslimatta kitaplıkların bir kopyasını içermesi ve sistem paketlerinde Log4j 2 sürümünün güncellenmesinin yeterli olmaması nedeniyle engellenmektedir.
Bu arada, ABD Altyapı Koruma ve Siber Güvenlik Ajansı, federal kurumların Log4j güvenlik açığından etkilenen bilgi sistemlerini tanımlamasını ve sorunu engelleyen güncellemeleri yüklemesini gerektiren bir acil durum yönergesi yayınladı. 23 Aralık'tan önce.
Öte yandan, 28 Aralık'a kadar kuruluşlara yapılan çalışmaları raporlama yükümlülüğünün bulunduğu bir yönerge verildi. Sorunlu sistemlerin tanımlanmasını kolaylaştırmak için, bir güvenlik açığının tezahürünün doğrulandığı ürünlerin bir listesi hazırlanmıştır (listede 23 binden fazla uygulama vardır).
Son olarak, Birkaç gün önce yayınlanan Log4j 2.17'de zafiyetin giderildiğini belirtmekte fayda var. ve güncellemeleri devre dışı bırakan kullanıcıların, sorunun yalnızca Java 8'li sistemlerde ortaya çıkması gerçeğiyle güvenlik açığı tehlikesinin hafifletilmesine ek olarak, ilgili güncellemeyi yapmaları önerilir.
kaynak: https://logging.apache.org/