Selam, bugün biraz eskiye dönüp ama hala epey etkili olan Log4Shell zafiyetini masaya yatıralım. Aslında 2021’in sonlarında patlayan bu açık, birçok insanın “sadece bir log kütüphanesi” diye küçümsediği Log4j’nin içindeki JNDI lookup mekanizmasını kötüye kullanıyordu. Gelin adım adım nasıl çalıştığına bakalım.
Öncelikle zafiyetin temelinde ne var? Log4j 2.0-beta9 ile 2.14.1 arasında, bir log mesajı içinde `${jndi:ldap://...}` gibi bir ifade geçtiğinde Log4j bunu otomatik olarak çözmeye çalışıyor. Bu çözümleme sırasında JNDI üzerinden uzak bir LDAP sunucusuna bağlanıp sınıf indiriyor ve o sınıfı çalıştırıyor. Kısacası saldırgan, loglanan herhangi bir girdiye (User-Agent, HTTP header, vs.) bu ifadeyi soktuğunda sunucu kendi kendini ele veriyor.
Gerçek bir pentest sırasında ben genelde şu şekilde ilerliyorum:
Hidden content - for more
Konuyu Görebilmeniz için "Beğenmeniz ve Yorum yapmaniz" Gerekir.
Yukarıdaki gibi basit bir istek attığında, hedef sunucu LDAP isteği atıyor ve saldırganın kontrolündeki sunucudan kötücül sınıfı indirip çalıştırıyor. Tabii ki güncel JVM’lerde bazı kısıtlamalar var (com.sun.jndi.ldap.object.trustURLCodebase=false gibi), ama hala birçok eski sistemde veya özel konfigürasyonlarda işliyor.
Sömürü sırasında en kritik nokta, LDAP sunucusunu nasıl kurduğun. Ben genelde marshalsec kullanıyorum:
Hidden content - for more
Konuyu Görebilmeniz için "Beğenmeniz ve Yorum yapmaniz" Gerekir.
Sonra da 8080 portunda basit bir HTTP sunucusu açıp Exploit.class dosyasını servis ediyorum. Hedef bunu indirdiğinde reverse shell veya istediğin herhangi bir payload çalışmış oluyor.
Özetle, Log4Shell hâlâ eski sistemlerde ve yamalanmamış kütüphane kullanan uygulamalarda baş ağrısı olmaya devam ediyor. Eğer bir pentest yapıyorsan, loglanan her alanı mutlaka bu tarz JNDI payload’larıyla dene derim.
