Hacknite Wiki

Race condition je tip ranjivosti, koji je se najčešće pojavljuje i koristi u web sustavima kao ranjivost, no može se pojaviti i u drugim kategorijama sustava i u kombinacijama s drugim ranjivostima. Karakterizira ga tip izvedbe, gdje se skup dviju ili više akcija rade uzastopno jedna za drugom s vrlo malim vremenskim razmakom između njih, koji se naziva „race window“ ili prozor utrke. Ciljevi i posljedice ovog tipa napada su razni, jer se ova ranjivost pojavljuje u mnogo oblika i u više različitih okruženja. Postoje mnogo različitih metoda kako bi se skup akcija za race condition izveo unutar ranjivog vremenskog perioda (eng. race window), koji je često jako malen, manji od sekunde. Od metoda koje serijski šalju velik broj akcija, jednu za drugom što većom brzinom, do metoda koje paralelno izvršavaju akcije, pa i do metoda koje koriste određene tehničke funkcionalnosti različitih protokola kako bi „dostavile“ skup akcija istovremeno žrtvi, iako zahtjevi ne moraju biti inicijalno generirani unutar kratkog vremenskog razmaka. Najjednostavniji primjer ovog napada jest iskorištavanje jednokratnog poklon bona ili koda za popust na web shopu više puta. Zamislimo da na serverskoj strani postoji sljedeća logika za iskorištavanje poklon bona: pri zahtjevu za korištenje bona, prvo se provjerava je li bon već iskorišten, ako nije onda se poklon bon dodaje u obračun i postavlja se zastavica da je poklon bon iskorišten. Vremenski prozor između ove dvije operacija, provjere je li poklon bon već iskorišten i dodavanja poklon bona u obračun te postavljanja zastavice jest vrlo mali, često u milisekundama. Ako prikladne mjere opreza nisu implementirane, taj vremenski prozor omogućava izvršavanje race condition ranjivosti. Ovisno o korištenom HTTP protokolu, šalje se veći broj zahtjeva ili paralelno ili serijski preko jedne konekcije uzastopno u velikom broju odgovarajućom tehnikom, s istim bonom. Nakon pristizanja prvog zahtjeva, vrši se provjera je li bon već iskorišten, ako nije, prelazi se na sljedeću operaciju obračunavanja bona i postavljanja zastavice. Istovremeno pristiže drugi zahtjev koji u trenutku provjeravanja zastavice prolazi provjeru jer se pri obradi prvog zahtjeva zastavica još nije postavila. Na kraju oba zahtjeva prolaze provjeru i isti bon se obračunava dva puta. Ovisno o ranjivom vremenskom periodu (eng. race window), korištenoj tehnici i drugih karakteristika mreže i sustava, mogu i više od dva zahtjeva proći provjeru. Nakon što prođe vremenski period ranjivosti, ostali zahtjevi će biti odbačeni. Ovaj Napad je prikazan na slici 1.

Jednostavne race condition ranjivosti uglavnom zahtijevaju slanje većeg broja istih zahtjeva unutar ranjivog vremenskog perioda i mogu se ostvariti korištenjem alata kao što su Burp Suite turbo Intruder ili Burp Suite Repeater stvaranjem skupa zahtjeva, te slanjem zahtjeva paralelno ili serijski, preko jedne konekcije. Isto tako se mogu napisati i vlastite skripte, od jednostavnih JavaScript skripti, koje se mogu u samoj konzoli web browsera pokrenut, do Python skripti ili Bash skripti. Složenije race condition ranjivosti mogu zahtijevati slanje više različitih zahtjeva na dvije ili više pristupne krajnje točke (eng. Endpoints) aplikacije. Na primjer istovremeno slanje koda za potvrdu e-mail adrese, pristiglog na prvu e-mail adresu zahtjeva za promjenu e-mail adrese, gdje bi se kao rezultat potvrdila promijenjena e-mail adresa sustava, kojoj napadač nema pristup. Također, nekad prisutnost race conditiona ne omogućuje iskorištavanje ranjivosti ili napad samo po sebi, ali se može kombinirati sa drugim ranjivostima kako bi se ostvario kompleksan napad. Primjer napada pri kojoj se kombiniraju više ranjivosti bi bila neka PHP aplikacija sa funkcionalnošću koja omogućava učitavanje (eng. Upload) slike na stranicu, koja se nakon učitavanja provjerava da nije zlonamjerna datoteka. Tip kombiniranih napada bi mogao biti uzastopno slanje dviju datoteka, prva koja je slika koja prolazi provjeru, a druga koja je zlonamjerna skripta koja omogućava shell pristup. Nakon što datoteka sa slikom prođe provjeru, zamjenjuje se zlonamjernom skriptom koja ostaje u sustavu. Kompliciraniji primjer napada bio slučaju gdje se poslana datoteka provjerava procesom koji traje pola sekunde, nakon čega se uklanja iz sustava, ali se u unutar tih pola sekunde zlonamjerna skripta može dohvatiti i pokrenuti na drugoj pristupnoj krajnjoj točki. Ovo je primjer korištenja race condition ranjivosti kako bi se omogućilo izvršavanje naredbi. Ovaj napad je prikazan na slici 2.

¸¸ Jura je jako voli utrke pa je odlučio napraviti svoj web shop u kojem će prodavati stvari na temu formula i utrka. Za sad je dostupan samo jedan proizvod, dok još ne proširi svoju ponudu. Kako bi promovirao svoj web shop i potaknu ljude na kupnju, svim stvorenim računima Jura je odlučio dodijeliti 10 Eura i jednokratni popust za prvu kupnju od 25%. Iako na računu nemate dovoljno iznosa za kupovinu artikla, postoji li način da ga ipak uspješno kupite? ¸¸

Čitajući tekst zadatka, mogu se primijetiti hintovi koji ukazuju na race condition. Tema zadatka su formule i utrke (Race), a cilj zadatka je kupiti artikl za koji nemamo dovoljno stanje na računu, no imamo bon koji možemo iskoristiti za 25% popusta. Nakon iskorištavanja popusta, na kratko se prikaže prazna stanica s natpisom „Postavljanje popusta“, koja može naznačiti nekakvo među stanje sustava u kojemu se postavlja popust. Nakon toga se ponovno prikazuje stranica, sa iskorištenim popustom od 25% i sniženom cijenom prikazanom na slici 3.

Gumbi „Iskoristi popust“ i „makni popust“ oba šalju POST request na istu putanju „/discount“, što može naznačivati da postoji „switch“ varijabla koja naznačuje je li popust postavljen ili nije, koja mijenja vrijednost pri izvršavanju akcije za postavljanje ili micanje popusta. Kako bi se testiralo je li ova funkcionalnost ranjiva na race condition, može se koristiti Burp Suite alat „Repeater“ za slanje više istovremenih zahtjeva paralelno ili serijski preko jedne ili više konekcija. Ovaj alat je opisan na ovom linku: https://portswigger.net/burp/documentation/desktop/tools/repeater/send-group Može se koristiti i drugi pristup, pisanja jednostavne JavaScript skripte koja će se izvršiti unutar konzole web preglednika. Ovaj pristup pruža manje mogućnosti, ali je dovoljan za jednostavne slučajeve, dok je u složenijim slučajevima bolje koristiti prethodno spomenuti alat. Oblik skripte je definiran sljedećim izrazom: ¸¸ for (let i = 0; i < N; i++) { fetch(“/discount”,{method: “POST”}); } ¸¸ Gdje je N broj uzastopnih zahtjeva koji se šalju. Ova skripta se može pokrenuti na stranici zadatka u konzoli web preglednika, pristupom razvojnih alata preglednika (F12). Prikazano na slici 4.

Nakon pokretanje skripte za N = 10 i osvježavanja stranica, iskorišteni popust je -175%, a cijena još veća nego prije. Ovo naznačuje da je race condition ranjivost prisutna. Prikazano na slici 5.

Uzevši u obzir da je prije pokretanja skripte, akcija pridružena putanji bila „Makni popust“, može se zaključiti da se ta akcija izvršila 8 puta, oduzimajući 200% popusta od originalnih 25%, rezultirajući krajnjim popustom od -175%.

Stvaranjem novog korisnika ponovno se dolazi do početnog stanja bez iskorištenog popusta gdje je akcija pridružena uz putanju „/discount“ postavljena na iskoristi popust. Prikazano na slici 6.

Ponovnim pokretanjem skripte, uz N=4, u stanju sustava dok popust nije postavljen a predviđena akcija je postavljanje popusta, uspješno se upotrjebljuje popust od 25% 4 puta, rezultirajući popustom od 100%, nakon čega je cijena 0. Prikazano na slici 7.

Pritiskom na gumb „Buy“ uspješno se izvršava kupnja i dobiva rješenje zadatka.

Netko je hakirao stranicu za glasanje - pizza s ili bez ananasa? Nema drugog objašnjenja zašto bi pizza s ananasom imala više glasova.. Možeš li upotrijebiti svoje hakerske vještine i spasiti glasanje - učiniti da ispravna pizza (bez ananasa!!) pobijedi?
Dostupan ti je izvorni kod web aplikacije
http://chal.platforma.hacknite.hr:13006

Uz zadatak je dostupan i izvorni kod zadatka. Pristupom stranici zadatka, prikazane su dvije opcije glasanja, pizza s ananasom i pizza bez ananasa. Nakon odabira jedne opcije pritiskom na gumb “Glasaj”, poveća se broj glasova te opcije, te nestane gumb za glasanje za to opciju, no ostaje gumb za promjenu glasa za drugu opciju. Prikazano na slici 8.

Analizom HTML koda stranice u inicijalnom stanju (brisanjem kolačića, postavlja se u inicijalno stanje) koristeći razvojne alate web preglednika, vidi se oba gumba šalju POST request na putanju „/vote“, jedan s vrijednošću „pineapple“, drugi s vrijednošću „noPineapple“. Prikazano na slici 9.

Analizom izvornog koda za glasanje na putanji „/vote“, vidi se da se koristi puno asinkronih funkcija kao „CekajObraduBazePodataka” i “ZbrajajGlasove” koje se čekaju usred obrađivanja jednog zahtjeva glasanja. Ovo naznačuje da bi race condition ranjivost mogla biti prisutna. Prikazano na slici 10.

Koristeći isti pristup stvaranja JavaScript skripte za slanje više uzastopnih zahtjeva, skripta je definirana u sljedećem izrazu: ¸¸ for (let i = 0; i < N; i++) { fetch(“/vote”, { method: “POST”, headers: { “Content-Type”: “application/x-www-form-urlencoded” }, body: new URLSearchParams({ vote: “noPineapple” }) }); } ¸¸ Gdje je N broj uzastopnih zahtjeva koji će se slati. Pokretanjem ove skripte, sa N = 50, dok je sustav u inicijalnom stanju bez postavljenog glasa, uspješno se poveća broj glasova za pizzu bez ananasa za 6.

Ponovnim pokretanjem skripte, broj glasova se više ne mijenja. Detaljnijom analizom koda, vidi se da nakon što je jednom glas postavljen, ponovno slanje istog glasa izbacuje pogrešku, te ne može promijeniti sustav. Prikazano na slici 11.

Znamo da je race window pri inicijalnom postavljanju glasa dovoljno velik da uspijemo broj glasova povećati za 6, naprednijim tehnikama i više, no potreban broj glasova da bi glasanje za pizzu bez ananasa pobijedilo je preko 200. Analizom koda za promjenu odabira glasa, vidi se da jest taj kod također ranjiv na race condition. Može se zaključiti da se postupak za dodavanje 200 glasova sastoji od slanja većeg broja glasova za željenu opciju, koji prolaze kroz race window te odabira druge opcije kako bi se opet omogućilo slanje novog skupa zahtjeva na željenu opciju koji će opet povećati broj glasova.

Kako bi to postigli, inicijalna skripta se mora proširiti sa još jednom for petljom, koja će nakon svakog slanja skupa zahtjeva za željenu opciju, poslati jedan zahtjev za drugu opciju, kako bi opet otvorilo mogućnost slanja novog skupa zahtjeva za željenu opciju. Modificirana skripta je prikazana u nastavku.

Znamo da je race window pri inicijalnom postavljanju glasa dovoljno velik da uspijemo broj glasova povećati za 6, naprednijim tehnikama i više, no potreban broj glasova da bi glasanje za pizzu bez ananasa pobijedilo je preko 200. Analizom koda za promjenu odabira glasa, vidi se da jest taj kod također ranjiv na race condition. Može se zaključiti da se postupak za dodavanje 200 glasova sastoji od slanja većeg broja glasova za željenu opciju, koji prolaze kroz race window te odabira druge opcije kako bi se opet omogućilo slanje novog skupa zahtjeva na željenu opciju koji će opet povećati broj glasova.

Kako bi to postigli, inicijalna skripta se mora proširiti sa još jednom for petljom, koja će nakon svakog slanja skupa zahtjeva za željenu opciju, poslati jedan zahtjev za drugu opciju, kako bi opet otvorilo mogućnost slanja novog skupa zahtjeva za željenu opciju. Modificirana skripta je prikazana u nastavku. ¸¸ for (let i = 0; i < M; i++) { for (let i = 0; i < N; i++) { fetch(“/vote”, { method: “POST”, headers: { “Content-Type”: “application/x-www-form-urlencoded” }, body: new URLSearchParams({ vote: “noPineapple” }) }); } await new Promise(resolve ⇒ setTimeout(resolve, 1000)); fetch(“/vote”, { method: “POST”, headers: { “Content-Type”: “application/x-www-form-urlencoded” }, body: new URLSearchParams({ vote: “pineapple” }) }); } ¸¸ Gdje je broj N, broj slanja uzastopnih glasova za željenu opciju, a broj M broj ponavljanja skupa operacija koji se sastoji od slanja N zahtjeva na željenu opciju te odabira druge opcije kako bi se ponovno omogućilo poslati novi skup zahtjeva za željenu opciju. Računajući da je N = 10, a M = 50, poslat će se ukupno 550 zahtjeva (500 zahtjeva za željenu opciju i 50 zahtjeva za drugu opciju). Zna se da će svaka skupina od 10 glasova za željenu opciju povećati broj glasova za 6, što bi uz 50 ponavljanja trebalo povećati broj ukupnih glasova za željenu opciju za otprilike 300. Nakon pokretanja ove skripte, broj glasova za pizzu bez ananasa je povećano iznad broja glasova za pizzu zadataka i zadatak je uspješno riješen, te je flag prikazan pri osvježavanju stranice.

Race condition ranjivost se može pojaviti u više oblika i u raznim funkcionalnostima, zato nema jednog rješenja koje se može primijeniti u svim situacijama, no najčešće rješenje je korištenje semafora i mutex zaključavanja pri korištenju kritičnih resursa. Mogu se koristiti ključevi za čitanje i ključevi za pisanje, gdje može istovremeno biti postavljeno više ključeva za čitanje na isti resurs, ali ključ za pisanje ne može biti postavljen istovremeno s drugim ključem za čitanje ili pisanje. Ovo rješenje ponekad može biti nepraktično, radi nepoželjnih karakteristika ili šanse da dođe do „deadlocka“, pa se ranjivost treba osigurati drugim načinom. Često su dostupna već gotova rješenja i biblioteke za resurse koji su predviđeni da se koriste u više-dretvenim okruženjima, jedan primjer je ConcurrentHashMap u Java programskom jeziku. Pri korištenju HashMap-a, koji se upotrebljava kao dijeljeni resurs između više dretvi, umjesto da dodatno implementiraju zaključavanja, može se koristiti dostupno rješenje koje je sigurno u više-dretvenim okruženjima. Također treba izbjegavati postepeno stvaranje objekata, gdje je objekt pri stvaranju u nedovršenom međustanju. Na primjer pri stvaranju novog korisnika u sustavu, prvo se izvodi jedna SQL transakcija za stvaranje dijela korisničkih podataka, onda se vrše druge operacije, pa se izvodi druga SQL operacija za stvaranje ostataka korisničkih podataka novog korisnika u bazi. Ovisno o funkcionalnostima, vremenski prozor između prve SQL transakcije gdje se stvara djelomični objekt i druge SQL transakcija nakon koje je objekt dovršen može otvoriti vrata nepredviđenom ponašanju i race condition ranjivosti. Umjesto toga, bolje je izvršiti cijeli proces stvaranja objekta u jednoj atomarnoj operaciji. Važno je biti svjestan postojanja ove ranjivosti pri pisanju koda, paziti na redoslijed i razmak između operacija za provjeravanje i korištenje resursa i napraviti odgovarajuće promjene dizajna ako se uobičajena i gotova rješenja ne mogu koristiti. Napisani kod se može kasnije analizirati alatima za statički analizu koda koji imaju mogućnost detekcije race conditiona te se ciljani dio koda također može testirati pod opterećenjem, je li ispravno funkcionira pri obrađivanju više paralelnih zahtjeva.

Izvori:
https://www.geeksforgeeks.org/race-condition-vulnerability/
https://book.hacktricks.xyz/pentesting-web/race-condition#adapting-to-server-architecture
https://portswigger.net/web-security/race-conditions
https://portswigger.net/burp/documentation/desktop/tools/repeater/send-group
https://platforma.hacknite.hr/