Hacknite Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====Race condition====

Race condition je zapravo pogreška u programiranju. Događa se kad dva korisnika, ili programa, ili instance istog programa ili dva cijela sustava žele koristiti isti resurs kojeg istovremeno smije koristiti samo jedan.

Zamislimo jednostavan, školski primjer u kojem postoji memorijska lokacija u kojoj piše broj preostalih ulaznica.
Jedan program ili njegova instanca pročita taj podatak, smanji ga za jedan i ponovno zapiše u istu memorijsku lokaciju.
Sve je u redu ako drugi program pročita taj broj nakon što je prvi zapisao novu vrijednost.
Ali problem nastaje ako drugi program pročita taj broj prije nego prvi zapiše novu vrijednost. Tada će drugi zapisati svoj broj „preko“ već izmijenjenog broja. Evo slijeda:
^ U memoriji piše ^ Prvi program ^ Drugi program ^
|  4  | pročita 4  | |
|  4  | | pročita 4  |
|  4  | smanji 4 za jedan  | |
|  3  | i zapiše 3  | |
|  3  | | ne zna da je broj sada već smanjen na 3 i ne umanjuje za jedan od 3 već od 4  |
|  3  | | pa ne zapisuje ispravnih 2, već zapisuje 3  |

Race condition se ispravno izbjegava tako da prvi program mora prvo zabraniti pristup toj memorijskoj lokaciji, zatim pročita, promijeni i zapiše podatak u nju, i onda tek dozvoli da itko drugi pristupa tom resursu, toj memorijskoj lokaciji.

Race condition 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. Iskorištava se tako da 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.

Postoji 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, u tom vremenskom prozoru moguće je iskoristiti race condition ranjivost. Ovisno o korištenom HTTP protokolu, odgovarajućom tehnikom šalje se veliki broj zahtjeva ili paralelno ili serijski preko jedne konekcije uzastopno, svi s istim bonom. Nakon pristizanja prvog zahtjeva, napadnuti program provjerava 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 kojeg provjerava druga instanca napadnutog programa i odobrava provjeru jer u tom trenutku prvi zahtjev još nije postavio zastavicu da je bon iskorišten. Na taj način 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.

{{  racecondition:slika1.png  }}

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 pokrenuti u samoj konzoli web browsera, do Python skripti ili Bash skripti.

Složenije race condition ranjivosti mogu zahtijevati slanje više različitih zahtjeva na dvije ili više pristupnih krajnjih točkaka (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 sama po sebi, ali se može kombinirati s drugim ranjivostima kako bi se ostvario kompleksan napad. 

Primjer napada pri kojoj se kombinira više ranjivosti bi bila neka PHP aplikacija s funkcionalnošću koja omogućava učitavanje (eng. Upload) slike na stranicu, a koju nakon učitavanja provjerava da nije zlonamjerna datoteka. Tip kombiniranog 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. Dok program provjerava prvu datoteku, učitana je i druga, pa će odobrenje za prvu datoteku vrijediti i za drugu, zlonamjernu.

Kompliciraniji primjer napada bio bi u slučaju kad se poslana datoteka provjerava procesom koji traje pola sekunde, nakon čega se uklanja iz sustava, ali se u unutar tih pola sekunde ta datoteka, zapravo 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.

{{  racecondition:slika2.png  }}


===PRIMJER - Zadatak s Hacknite platforme - Pizza===

<file>
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
</file>
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 tu opciju, no ostaje gumb za promjenu glasa za drugu opciju. Prikazano na slici 8.

{{  racecondition:slika8.png  }}

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

{{  racecondition:slika9.png  }}

Analizom izvornog koda za glasanje na putanji „/vote“, vidi se da se koristi puno asinkronih funkcija poput „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.

{{  racecondtion:slika10.png  }}

Koristeći isti pristup stvaranja JavaScript skripte za slanje više uzastopnih zahtjeva, skripta je definirana u sljedećem izrazu:
<code>
for (let i = 0; i < N; i++) {
fetch("/vote", { method: "POST",
headers: { "Content-Type": "application/x-www-form-urlencoded" }, 
body: new URLSearchParams({ vote: "noPineapple" }) }); 
}
</code>
Gdje je N broj uzastopnih zahtjeva koji će se slati. Pokretanjem ove skripte, s 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.

{{  racecondition:slika11.png  }}

Znamo da je race window pri inicijalnom postavljanju glasa dovoljno velik da uspijemo broj glasova povećati za 6, a 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 je 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 potom 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 s još jednom for petljom, koja će nakon svakog slanja skupa zahtjeva za željenu opciju, poslati jedan zahtjev za drugu opciju, čime će opet otvoriti mogućnost slanja novog skupa zahtjeva za željenu opciju. Modificirana skripta je prikazana u nastavku.

<code>
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" }) });
}
</code>
Gdje je broj N, broj slanja uzastopnih glasova za željenu opciju, a broj M je 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ćan iznad broja glasova za pizzu koje traži zadatak, čime je zadatak uspješno riješen, te je flag prikazan pri osvježavanju stranice.









===Zaštita od race conditiona===
Race condition ranjivost se može pojaviti u više oblika i u raznim funkcionalnostima, pa 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 resursa 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 ukloniti 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 programskom jeziku Java. 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 postupno stvaranje objekata, gdje je objekt tijekom stvaranja 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 ostatka 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 transakcije 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čku analizu koda koji imaju mogućnost detekcije race conditiona te se ciljani dio koda također može testirati pod opterećenjem, funkcionira li ispravno 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/\\