Race Condition
Last updated
Last updated
Tumia Trickest kujenga na kuandaa kazi kwa urahisi kwa kutumia zana za jamii zilizoendelea zaidi duniani. Pata Ufikiaji Leo:
Ili kupata uelewa wa kina wa mbinu hii angalia ripoti asili katika https://portswigger.net/research/smashing-the-state-machine
Kikwazo kikuu katika kuchukua faida ya hali za race ni kuhakikisha kwamba maombi mengi yanashughulikiwa kwa wakati mmoja, kwa tofauti ndogo sana katika nyakati zao za usindikaji—kwa kawaida, chini ya 1ms.
Hapa unaweza kupata mbinu za Kuisawazisha Maombi:
HTTP/2: Inasaidia kutuma maombi mawili kupitia muunganisho mmoja wa TCP, kupunguza athari za jitter za mtandao. Hata hivyo, kutokana na tofauti za upande wa seva, maombi mawili yanaweza kutotosha kwa shambulizi la race condition linaloendelea.
HTTP/1.1 'Usawazishaji wa Byte ya Mwisho': Inaruhusu kutuma sehemu nyingi za maombi 20-30 kabla, ikizuia kipande kidogo, ambacho kitatumwa pamoja, na kufikia seva kwa wakati mmoja.
Maandalizi ya Usawazishaji wa Byte ya Mwisho yanajumuisha:
Kutuma vichwa na data ya mwili bila byte ya mwisho bila kumaliza mtiririko.
Kusimamisha kwa 100ms baada ya kutuma awali.
Kuzima TCP_NODELAY ili kutumia algorithm ya Nagle kwa kuunganisha fremu za mwisho.
Kupiga simu ili kuimarisha muunganisho.
Kutuma fremu zilizoshikiliwa baadaye inapaswa kusababisha kufika kwao katika packet moja, inayoweza kuthibitishwa kupitia Wireshark. Mbinu hii haitumiki kwa faili za statiki, ambazo kawaida hazihusiki katika mashambulizi ya RC.
Kuelewa usanifu wa lengo ni muhimu. Seva za mbele zinaweza kuelekeza maombi tofauti, kuathiri nyakati. Kuimarisha muunganisho wa upande wa seva, kupitia maombi yasiyo na maana, kunaweza kuleta kawaida kwa nyakati za maombi.
Mifumo kama vile handler ya kikao ya PHP inasawazisha maombi kwa kikao, ambayo inaweza kuficha udhaifu. Kutumia tokeni tofauti za kikao kwa kila ombi kunaweza kuondoa tatizo hili.
Ikiwa kuimarisha muunganisho hakufanyi kazi, kuanzisha ucheleweshaji wa mipaka ya kiwango au rasilimali za seva za wavuti kwa makusudi kupitia mafuriko ya maombi ya dummy kunaweza kuwezesha shambulizi la packet moja kwa kuleta ucheleweshaji wa upande wa seva unaofaa kwa hali za race.
Tubo Intruder - shambulizi la HTTP2 packet moja (1 endpoint): Unaweza kutuma ombi kwa Turbo intruder (Extensions -> Turbo Intruder -> Send to Turbo Intruder), unaweza kubadilisha katika ombi thamani unayotaka kujaribu kwa nguvu kwa %s kama katika csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s na kisha chagua examples/race-single-packer-attack.py kutoka kwenye orodha:
Ikiwa unataka kutuma thamani tofauti, unaweza kubadilisha msimbo na huu unaotumia orodha ya maneno kutoka kwenye clipboard:
Ikiwa wavuti haitegemei HTTP2 (tu HTTP1.1) tumia Engine.THREADED au Engine.BURP badala ya Engine.BURP2.
Tubo Intruder - HTTP2 shambulio la pakiti moja (Mikondo kadhaa): Ikiwa unahitaji kutuma ombi kwa mkingo 1 kisha kadhaa kwa mkingo mwingine ili kuanzisha RCE, unaweza kubadilisha skripti ya race-single-packet-attack.py na kitu kama:
Inapatikana pia katika Repeater kupitia chaguo jipya la 'Send group in parallel' katika Burp Suite.
Kwa limit-overrun unaweza tu kuongeza ombile lile lile mara 50 katika kundi.
Kwa connection warming, unaweza kuongeza mwanzoni mwa kundi baadhi ya ombile kwa sehemu zisizo za kudumu za seva ya wavuti.
Kwa delaying mchakato kati ya kushughulikia ombile moja na nyingine katika hatua 2 za substate, unaweza kuongeza ombile za ziada kati ya ombile zote mbili.
Kwa multi-endpoint RC unaweza kuanza kutuma ombile ambalo linakwenda kwenye hali ya siri na kisha ombile 50 mara tu baada yake ambayo inatumia hali ya siri.
Automated python script: Lengo la script hii ni kubadilisha barua pepe ya mtumiaji huku ikithibitisha kila wakati hadi tokeni ya uthibitisho ya barua pepe mpya ifike kwa barua pepe ya mwisho (hii ni kwa sababu katika msimbo ilikuwa inaonekana RC ambapo ilikuwa inawezekana kubadilisha barua pepe lakini uthibitisho ukatumwa kwa ile ya zamani kwa sababu variable inayonyesha barua pepe ilikuwa tayari imejaa na ile ya kwanza). Wakati neno "objetivo" linapatikana katika barua pepe zilizopokelewa tunajua tumepokea tokeni ya uthibitisho ya barua pepe iliyobadilishwa na tunamaliza shambulio.
Katika utafiti wa awali, imeelezwa kwamba shambulio hili lina kikomo cha 1,500 bytes. Hata hivyo, katika post hii, imeelezwa jinsi inavyowezekana kupanua kikomo cha 1,500-byte cha shambulio la pakiti moja hadi 65,535 B kikomo cha dirisha cha TCP kwa kutumia upasuwaji wa tabaka la IP (kugawanya pakiti moja kuwa pakiti nyingi za IP) na kuzituma kwa mpangilio tofauti, kumekuwa na uwezo wa kuzuia kuunganishwa tena kwa pakiti hadi vipande vyote vifikie seva. Mbinu hii ilimwezesha mtafiti kutuma maombi 10,000 ndani ya takriban 166ms.
Kumbuka kwamba ingawa kuboresha hii kunafanya shambulio kuwa na uaminifu zaidi katika RC inayohitaji pakiti mamia/maelfu kufika kwa wakati mmoja, inaweza pia kuwa na baadhi ya vikwazo vya programu. Seva maarufu za HTTP kama Apache, Nginx na Go zina mipangilio ya SETTINGS_MAX_CONCURRENT_STREAMS ya 100, 128 na 250. Hata hivyo, zingine kama NodeJS na nghttp2 zina mipangilio isiyo na kikomo.
Hii inamaanisha kwamba Apache itazingatia tu muunganisho wa HTTP 100 kutoka kwa muunganisho mmoja wa TCP (ikizuia shambulio hili la RC).
Unaweza kupata mifano kadhaa ukitumia mbinu hii katika repo https://github.com/Ry0taK/first-sequence-sync/tree/main.
Kabla ya utafiti wa awali, hizi zilikuwa baadhi ya payloads zilizotumika ambazo zilijaribu kutuma pakiti haraka iwezekanavyo ili kusababisha RC.
Repeater: Angalia mifano kutoka sehemu ya awali.
Intruder: Tuma ombile kwa Intruder, weka idadi ya nyuzi kuwa 30 ndani ya menyu ya Chaguo na, chagua kama payload Null payloads na tengeneza 30.
Turbo Intruder
Python - asyncio
Hii ni aina ya msingi zaidi ya race condition ambapo vulnerabilities ambazo zinaonekana katika maeneo ambayo yanapunguza idadi ya nyakati unaweza kufanya kitendo. Kama kutumia nambari ya punguzo sawa katika duka la mtandaoni mara kadhaa. Mfano rahisi sana unaweza kupatikana katika ripoti hii au katika bug hii.
Kuna matoleo mengi ya aina hii ya shambulio, ikiwa ni pamoja na:
Kutumia kadi ya zawadi mara kadhaa
Kutoa alama kwa bidhaa mara kadhaa
Kutoa au kuhamasisha pesa zaidi ya salio la akaunti yako
Kutumia suluhisho moja la CAPTCHA tena
Kupita kikomo cha kiwango cha kupambana na nguvu
Kuchochea race conditions ngumu mara nyingi kunahusisha kuchukua faida ya fursa za muda mfupi za kuingiliana na unintended machine substates. Hapa kuna jinsi ya kukabiliana na hili:
Tafuta Potenshiali za Hidden Substates
Anza kwa kutambua mwisho ambao hubadilisha au kuingiliana na data muhimu, kama vile profaili za mtumiaji au michakato ya kurekebisha nywila. Lenga kwenye:
Hifadhi: Prefer mwisho ambao hubadilisha data ya kudumu upande wa seva kuliko wale wanaoshughulikia data upande wa mteja.
Kitendo: Tafuta operesheni zinazobadilisha data iliyopo, ambazo zina uwezekano mkubwa wa kuunda hali zinazoweza kutumika ikilinganishwa na zile zinazoongeza data mpya.
Keying: Shambulio lililofanikiwa mara nyingi linahusisha operesheni zilizofungiwa kwenye kitambulisho kimoja, mfano, jina la mtumiaji au token ya kurekebisha.
Fanya Uchunguzi wa Awali
Jaribu mwisho ulioainishwa kwa shambulio la race condition, ukitazama kwa mabadiliko yoyote kutoka kwa matokeo yanayotarajiwa. Majibu yasiyotarajiwa au mabadiliko katika tabia ya programu yanaweza kuashiria vulnerability.
Onyesha Vulnerability
Punguza shambulio hadi idadi ndogo ya maombi yanayohitajika ili kuchochea vulnerability, mara nyingi ni mbili tu. Hatua hii inaweza kuhitaji majaribio mengi au automatisering kutokana na muda sahihi unaohusika.
Usahihi katika wakati wa maombi unaweza kufichua vulnerabilities, hasa wakati mbinu zinazoweza kutabiriwa kama vile alama za muda zinapotumika kwa token za usalama. Kwa mfano, kuunda token za kurekebisha nywila kulingana na alama za muda kunaweza kuruhusu token sawa kwa maombi ya wakati mmoja.
Ili Kuchochea:
Tumia wakati sahihi, kama shambulio la pakiti moja, kufanya maombi ya kurekebisha nywila kwa wakati mmoja. Token sawa zinaonyesha vulnerability.
Mfano:
Omba token mbili za kurekebisha nywila kwa wakati mmoja na ulinganishe. Token zinazolingana zinaonyesha kasoro katika uzalishaji wa token.
Angalia hii PortSwigger Lab kujaribu hii.
Angalia hii PortSwigger Lab kuona jinsi ya kulipa katika duka na kuongeza kipengee ambacho hutaweza kulipia.
Wazo ni kuhakiki anwani ya barua pepe na kuibadilisha na nyingine kwa wakati mmoja ili kugundua ikiwa jukwaa linathibitisha ile mpya iliyobadilishwa.
Kulingana na utafiti huu Gitlab ilikuwa na vulnerability ya kuchukuliwa kwa njia hii kwa sababu inaweza kutuma token ya uthibitisho wa barua pepe ya barua pepe moja kwa barua pepe nyingine.
Angalia hii PortSwigger Lab kujaribu hii.
Ikiwa kuandikwa tofauti 2 zinatumika ku ongeza habari ndani ya database, kuna sehemu ndogo ya muda ambapo tu data ya kwanza imeandikwa ndani ya database. Kwa mfano, wakati wa kuunda mtumiaji jina la mtumiaji na nywila vinaweza kuandikwa na kisha token ya kuthibitisha akaunti mpya iliyoundwa inaandikwa. Hii inamaanisha kwamba kwa muda mfupi token ya kuthibitisha akaunti ni null.
Kwa hivyo kujiandikisha akaunti na kutuma maombi kadhaa na token tupu (token= au token[]= au toleo lolote lingine) ili kuthibitisha akaunti mara moja kunaweza kuruhusu kuhakiki akaunti ambayo hujatumia barua pepe.
Angalia hii PortSwigger Lab kujaribu hii.
Kifungu kinachofuata ni dhaifu kwa race condition kwa sababu katika muda mfupi sana 2FA haitekelezwi wakati kikao kinaundwa:
Kuna watoa huduma kadhaa wa OAUth. Huduma hizi zitakuruhusu kuunda programu na kuthibitisha watumiaji ambao mtoa huduma amesajili. Ili kufanya hivyo, mteja atahitaji kuruhusu programu yako kufikia baadhi ya data zao ndani ya mtoa huduma wa OAUth. Hivyo, hadi hapa ni kuingia kwa kawaida na google/linkedin/github... ambapo unakumbana na ukurasa ukisema: "Programu <InsertCoolName> inataka kufikia taarifa zako, je, unataka kuiruhusu?"
authorization_codeTatizo linaonekana unapokubali na moja kwa moja kutuma authorization_code kwa programu mbaya. Kisha, programu hii inatumia Hali ya Mbio katika mtoa huduma wa OAUth ili kuunda zaidi ya AT/RT moja (Authentication Token/Refresh Token) kutoka kwa authorization_code kwa akaunti yako. Kimsingi, itatumia ukweli kwamba umekubali programu kufikia data zako ili kuunda akaunti kadhaa. Kisha, ikiwa utakoma kuruhusu programu kufikia data zako, jozi moja ya AT/RT itafutwa, lakini zingine zitabaki kuwa halali.
Refresh TokenMara tu unapokuwa umepata RT halali unaweza kujaribu kuitumia kuunda AT/RT kadhaa na hata kama mtumiaji anafuta ruhusa kwa programu mbaya kufikia data zake, RT kadhaa bado zitakuwa halali.
Katika WS_RaceCondition_PoC unaweza kupata PoC katika Java kutuma ujumbe wa websocket kwa sawa ili kutumia Hali za Mbio pia katika Web Sockets.
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
