Log4Shell, Apache Log4j 2 kütüphanesinin loglara yazdığı metin içinde özel bir ifadeyi işleme sokmasından doğan ve CVE-2021-44228 kimliğiyle kayıtlı bir uzaktan kod çalıştırma açığıdır. Aralık 2021’de açıklandığında CVSS puanı azami 10.0 olarak belirlendi, çünkü sömürüsü kimlik doğrulaması gerektirmiyor ve saldırganın tek yapması gereken uygulamanın loglayacağı bir alana zararlı bir dize yerleştirmekti.

Log4Shell, loglanan sıradan bir metnin içine gizlenmiş tek bir ifadeyle sunucuyu saldırganın kontrolündeki koda yönlendiren, kimlik doğrulaması istemeyen bir kod çalıştırma açığıdır.

Zafiyet Nasıl Çalışır?

Sorunun kaynağı, Log4j’nin desteklediği JNDI (Java Naming and Directory Interface) araması özelliğidir. Uygulama bir HTTP başlığı, kullanıcı adı veya arama kutusu gibi saldırganın kontrol ettiği bir veriyi loglarken, içindeki jndi:ldap ile başlayan ifade değerlendirmeye alınır. Log4j bu ifadeyi görünce saldırganın gösterdiği uzak LDAP sunucusuna bağlanır ve oradan dönen Java sınıfını indirip çalıştırır.

Saldırgan pratikte User-Agent gibi bir başlığa bu ifadeyi yerleştirir, sunucu isteği loglar loglamaz kendi denetimindeki sunucuya çağrı gider ve zararlı sınıf hedef üzerinde koşar. İfadenin iç içe aramalarla gizlenebilmesi (örneğin karakterlerin parçalanması), basit imza tabanlı filtrelerin atlatılmasını kolaylaştırdı ve ilk yamalardan sonra bile bypass varyantlarının ortaya çıkmasına yol açtı.

Neden Bu Kadar Yaygın Etki Yarattı?

Log4j, Java ekosisteminde neredeyse standart bir loglama bileşeni olduğu için doğrudan kullanılmadığı projelere bile başka kütüphanelerin bağımlılığı olarak sızmıştı. Kurumların çoğu hangi uygulamalarında hangi sürümün gömülü olduğunu bilmiyordu; bu görünürlük eksikliği açığı klasik bir Tedarik zinciri saldırısı yüzeyine dönüştürdü. Bileşen envanterini çıkarmadan yamalamak mümkün olmadığı için Yazılım bileşim analizi araçları kriz yönetiminin merkezine oturdu.

Tespit ve Kapatma

Kalıcı çözüm Log4j’yi güvenli sürüme (2.17.1 ve sonrası) yükseltmektir; ara dönemde JndiLookup sınıfının paketten çıkarılması veya güvenlik açığını tetikleyen mesaj arama davranışının kapatılması azaltıcı önlem olarak uygulanmıştır. Güncellemenin bütünsel yönetimi için Yama yönetimi süreçlerinin bağımlılık düzeyine kadar inmesi gerekir.

• Tüm Java uygulamalarında gömülü Log4j sürümlerini SCA araçlarıyla envanterleyin
• Log4j’yi resmî güvenli sürüme yükseltin; mümkün değilse JndiLookup sınıfını kaldırın
• WAF üzerinde jndi arama kalıplarını engelleyin, ancak bunu tek savunma katmanı saymayın
• Giden ağ trafiğini kısıtlayarak sunucuların rastgele LDAP/RMI adreslerine bağlanmasını önleyin

Bir sunucunun bu açıkla sömürülüp sömürülmediğini anlamak çoğu zaman giden bağlantı ve şüpheli süreç izlerinin geriye dönük analizini gerektirir; Privia Security’nin olay inceleme ve olay müdahalesi hizmeti bu tür istismar sonrası tespit ve temizlik çalışmalarını yürütür. Uygulama katmanındaki benzer enjeksiyon risklerini erkenden yakalamak için Web uygulama sızma testi de tamamlayıcı bir adımdır.