Race Condition
Last updated
Last updated
Koristite Trickest za lako kreiranje i automatizaciju radnih tokova pokretanih najnaprednijim alatima zajednice na svetu. Pribavite pristup danas:
Za sticanje dubokog razumevanja ove tehnike proverite izvorni izveštaj na https://portswigger.net/research/smashing-the-state-machine
Glavna prepreka u iskorišćavanju race condition-a je osiguranje da se više zahteva obrađuje u isto vreme, sa vrlo malom razlikom u vremenima obrade—idealno, manje od 1ms.
Ovde možete pronaći neke tehnike za sinhronizaciju zahteva:
HTTP/2: Podržava slanje dva zahteva preko jedne TCP veze, smanjujući uticaj mrežnog jitter-a. Međutim, zbog varijacija na strani servera, dva zahteva možda neće biti dovoljna za dosledno iskorišćavanje race condition-a.
HTTP/1.1 'Sinhronizacija poslednjeg bajta': Omogućava prethodno slanje većine delova 20-30 zahteva, zadržavajući mali fragment, koji se zatim šalje zajedno, postizajući simultano stizanje na server.
Priprema za Sinhronizaciju poslednjeg bajta uključuje:
Slanje zaglavlja i podataka tela minus poslednji bajt bez završavanja toka.
Pauza od 100ms nakon inicijalnog slanja.
Onemogućavanje TCP_NODELAY kako bi se iskoristio Nagle-ov algoritam za grupisanje finalnih okvira.
Pingovanje za zagrevanje veze.
Sledeće slanje zadržanih okvira trebalo bi da rezultira njihovim stizanjem u jednom paketu, što se može proveriti putem Wireshark-a. Ova metoda se ne primenjuje na statične datoteke, koje obično nisu uključene u RC napade.
Razumevanje arhitekture cilja je ključno. Front-end serveri mogu drugačije usmeravati zahteve, što utiče na vreme. Preventivno zagrevanje veze na strani servera, kroz beznačajne zahteve, može normalizovati vreme zahteva.
Okviri poput PHP-ovog upravljača sesijama serijalizuju zahteve po sesiji, potencijalno prikrivajući ranjivosti. Korišćenje različitih tokena sesije za svaki zahtev može zaobići ovaj problem.
Ako zagrevanje veze nije efikasno, namerno izazivanje kašnjenja u ograničenju brzine ili resursa web servera putem poplave lažnih zahteva može olakšati napad sa jednim paketom izazivajući kašnjenje na strani servera pogodno za race condition.
Tubo Intruder - HTTP2 napad sa jednim paketom (1 krajnja tačka): Možete poslati zahtev na Turbo intruder (Extensions
-> Turbo Intruder
-> Send to Turbo Intruder
), možete promeniti u zahtevu vrednost koju želite da brute force-ujete za %s
kao u csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s
i zatim odabrati examples/race-single-packer-attack.py
iz padajućeg menija:
Ako planirate da pošaljete različite vrednosti, možete izmeniti kod sa ovim koji koristi rečnik iz clipboard-a:
Ako web ne podržava HTTP2 (samo HTTP1.1), koristite Engine.THREADED
ili Engine.BURP
umesto Engine.BURP2
.
Tubo Intruder - HTTP2 napad sa jednim paketom (Više krajnjih tačaka): U slučaju da treba da pošaljete zahtev ka 1 krajnjoj tački, a zatim više ka drugim krajnjim tačkama da aktivirate RCE, možete promeniti race-single-packet-attack.py
skriptu sa nečim poput:
Takođe je dostupno u Repeater putem nove opcije 'Send group in parallel' u Burp Suite.
Za limit-overrun možete jednostavno dodati istu zahtev 50 puta u grupu.
Za connection warming, možete dodati na početku grupe neke zahteve ka nekoj nestatičnoj delu web servera.
Za delaying procesa između obrade jednog zahteva i drugog u 2 podstanja, možete dodati dodatne zahteve između oba zahteva.
Za multi-endpoint RC možete početi slati zahtev koji ide u skriveno stanje i zatim 50 zahteva odmah nakon njega koji iskorišćava skriveno stanje.
Automatizovani python skript: Cilj ovog skripta je da promeni email korisnika dok neprekidno verifikuje dok verifikacioni token novog emaila ne stigne na poslednji email (to je zato što je u kodu viđena RC gde je bilo moguće modifikovati email, ali poslati verifikaciju na stari jer je promenljiva koja označava email već bila popunjena prvim). Kada se reč "objetivo" pronađe u primljenim emailovima, znamo da smo primili verifikacioni token promenjenog emaila i završavamo napad.
U originalnom istraživanju objašnjeno je da ovaj napad ima limit od 1.500 bajtova. Međutim, u ovom postu, objašnjeno je kako je moguće proširiti ograničenje od 1.500 bajtova napada sa jednim paketom na 65.535 B ograničenje prozora TCP-a korišćenjem fragmentacije na IP nivou (deljenje jednog paketa na više IP paketa) i slanje u različitom redosledu, što je omogućilo sprečavanje ponovnog sastavljanja paketa dok svi fragmenti ne stignu do servera. Ova tehnika je omogućila istraživaču da pošalje 10.000 zahteva za otprilike 166ms.
Napomena: iako ovo poboljšanje čini napad pouzdanijim u RC-u koji zahteva stotine/hiljade paketa da stignu u isto vreme, može imati i neka softverska ograničenja. Neki popularni HTTP serveri kao što su Apache, Nginx i Go imaju strogo podešavanje SETTINGS_MAX_CONCURRENT_STREAMS
na 100, 128 i 250. Međutim, drugi kao što su NodeJS i nghttp2 nemaju ograničenje.
To u suštini znači da će Apache uzeti u obzir samo 100 HTTP konekcija iz jedne TCP konekcije (ograničavajući ovaj RC napad).
Možete pronaći neke primere korišćenja ove tehnike u repozitorijumu https://github.com/Ry0taK/first-sequence-sync/tree/main.
Pre prethodnog istraživanja, ovo su bili neki payload-ovi koji su korišćeni i koji su samo pokušavali da pošalju pakete što je brže moguće da izazovu RC.
Repeater: Proverite primere iz prethodne sekcije.
Intruder: Pošaljite zahtev na Intruder, postavite broj niti na 30 unutar menija Opcije, i izaberite kao payload Null payloads i generišite 30.
Turbo Intruder
Python - asyncio
Ovo je najosnovnija vrsta race condition gde ranjivosti koje se pojavljuju na mestima koja ograničavaju broj puta na koji možete izvršiti neku radnju. Kao korišćenje istog koda za popust u veb prodavnici više puta. Veoma lak primer može se naći u ovom izveštaju ili u ovoj grešci.
Postoji mnogo varijacija ove vrste napada, uključujući:
Otkup poklon kartice više puta
Ocenjivanje proizvoda više puta
Podizanje ili prebacivanje gotovine u iznosu većem od stanja na računu
Ponovno korišćenje jednog CAPTCHA rešenja
Zaobilaženje anti-brute-force ograničenja brzine
Eksploatacija složenih race condition često uključuje korišćenje kratkih prilika za interakciju sa skrivenim ili nepredviđenim mašinskim podstanjem. Evo kako pristupiti ovome:
Identifikujte Potencijalna Skrivena Podstanja
Počnite tako što ćete odrediti krajnje tačke koje modifikuju ili interaguju sa kritičnim podacima, kao što su korisnički profili ili procesi resetovanja lozinke. Fokusirajte se na:
Skladištenje: Preferirajte krajnje tačke koje manipulišu podacima koji su trajni na serveru u odnosu na one koje obrađuju podatke na klijentskoj strani.
Akcija: Tražite operacije koje menjaju postojeće podatke, koje su verovatnije da će stvoriti uslove za eksploataciju u poređenju sa onima koje dodaju nove podatke.
Ključ: Uspešni napadi obično uključuju operacije koje su ključne na istom identifikatoru, npr. korisničko ime ili token za resetovanje.
Sprovedite Početno Istraživanje
Testirajte identifikovane krajnje tačke sa napadima race condition, posmatrajući bilo kakve odstupanja od očekivanih rezultata. Neočekivani odgovori ili promene u ponašanju aplikacije mogu signalizirati ranjivost.
Demonstrirajte Ranjivost
Sužavajte napad na minimalan broj zahteva potrebnih za eksploataciju ranjivosti, često samo dva. Ovaj korak može zahtevati više pokušaja ili automatizaciju zbog preciznog tajminga uključenog.
Preciznost u tajmingu zahteva može otkriti ranjivosti, posebno kada se koriste predvidljive metode poput vremenskih oznaka za sigurnosne tokene. Na primer, generisanje tokena za resetovanje lozinke na osnovu vremenskih oznaka moglo bi omogućiti identične tokene za simultane zahteve.
Za Eksploataciju:
Koristite precizan tajming, poput napada jednim paketom, da izvršite simultane zahteve za resetovanje lozinke. Identični tokeni ukazuju na ranjivost.
Primer:
Zatražite dva tokena za resetovanje lozinke u isto vreme i uporedite ih. Podudaranje tokena sugeriše grešku u generisanju tokena.
Proverite ovo PortSwigger Lab da probate ovo.
Proverite ovo PortSwigger Lab da vidite kako da platite u prodavnici i dodate dodatnu stavku za koju nećete morati da platite.
Ideja je da verifikujete email adresu i promenite je na drugu u isto vreme da biste saznali da li platforma verifikuje novu promenjenu.
Prema ovoj studiji Gitlab je bio ranjiv na preuzimanje na ovaj način jer bi mogao poslati token za verifikaciju emaila jedne email adrese na drugu email adresu.
Proverite ovo PortSwigger Lab da probate ovo.
Ako se koriste 2 različita pisanja za dodavanje informacija unutar baze podataka, postoji mali deo vremena kada je samo prvi podatak napisan unutar baze podataka. Na primer, kada se kreira korisnik, korisničko ime i lozinka mogu biti napisani i onda se piše token za potvrdu novokreiranog naloga. To znači da za kratak period token za potvrdu naloga je null.
Stoga registracija naloga i slanje nekoliko zahteva sa praznim tokenom (token=
ili token[]=
ili bilo koja druga varijacija) za trenutnu potvrdu naloga mogla bi omogućiti potvrdu naloga gde ne kontrolišete email.
Proverite ovo PortSwigger Lab da probate ovo.
Sledeći pseudo-kod je ranjiv na race condition jer u veoma kratkom vremenu 2FA nije primenjen dok se sesija kreira:
Postoji nekoliko OAUth provajdera. Ove usluge će vam omogućiti da kreirate aplikaciju i autentifikujete korisnike koje je provajder registrovao. Da biste to uradili, klijent će morati da dozvoli vašoj aplikaciji pristup nekim od njihovih podataka unutar OAUth provajdera. Dakle, do sada je to samo uobičajeni prijavljivanje putem google/linkedin/github... gde se prikazuje stranica sa porukom: "Aplikacija <InsertCoolName> želi da pristupi vašim informacijama, da li želite da to dozvolite?"
authorization_code
Problem se pojavljuje kada prihvatite i automatski šalje authorization_code
zloćudnoj aplikaciji. Tada, ova aplikacija zloupotrebljava Race Condition u OAUth servisu da generiše više od jednog AT/RT (Authentication Token/Refresh Token) iz authorization_code
za vaš nalog. U suštini, zloupotrebiće činjenicu da ste prihvatili aplikaciju da pristupi vašim podacima da kreira više naloga. Tada, ako prestaneš da dozvoljavaš aplikaciji da pristupi tvojim podacima, jedan par AT/RT će biti obrisan, ali ostali će i dalje biti validni.
Refresh Token
Kada ste dobili validan RT, mogli biste pokušati da zloupotrebite to da generišete nekoliko AT/RT i čak i ako korisnik otkaže dozvole za zloćudnu aplikaciju da pristupi njegovim podacima, nekoliko RT-ova će i dalje biti validno.
U WS_RaceCondition_PoC možete pronaći PoC u Javi za slanje websocket poruka u paraleli da zloupotrebi Race Conditions takođe u Web Sockets.
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Učite i vežbajte 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)