Hacking Kolačića

Reading time: 14 minutes

Atributi Kolačića

Kolačići dolaze sa nekoliko atributa koji kontrolišu njihovo ponašanje u korisnikovom pretraživaču. Evo pregleda ovih atributa u pasivnijem tonu:

Expires i Max-Age

Datum isteka kolačića određuje atribut Expires. Nasuprot tome, atribut Max-age definiše vreme u sekundama do brisanja kolačića. Odaberite Max-age jer odražava savremenije prakse.

Domen

Domaćini koji primaju kolačić su određeni atributom Domain. Podrazumevano, ovo je postavljeno na domaćina koji je izdao kolačić, ne uključujući njegove poddomenke. Međutim, kada je atribut Domain eksplicitno postavljen, obuhvata i poddomenke. Ovo čini specifikaciju atributa Domain manje restriktivnom opcijom, korisnom za scenarije gde je deljenje kolačića između poddomenki neophodno. Na primer, postavljanje Domain=mozilla.org čini kolačiće dostupnim na njegovim poddomenama kao što je developer.mozilla.org.

Putanja

Specifična URL putanja koja mora biti prisutna u zahtevanom URL-u da bi Cookie zaglavlje bilo poslato označena je atributom Path. Ovaj atribut smatra karakter / kao separator direktorijuma, omogućavajući podudaranja u poddirektorijumima.

Pravila Redosleda

Kada dva kolačića imaju isto ime, onaj koji je izabran za slanje zasniva se na:

• Kolačiću koji se podudara sa najdužom putanjom u zahtevanom URL-u.
• Najnovije postavljenom kolačiću ako su putanje identične.

SameSite

• Atribut SameSite određuje da li se kolačići šalju na zahteve koji potiču sa trećih domena. Nudi tri podešavanja:
• Strict: Ograničava kolačić da se ne šalje na zahteve trećih strana.
• Lax: Omogućava kolačiću da se šalje sa GET zahtevima koje pokreću veb sajtovi trećih strana.
• None: Dozvoljava kolačiću da se šalje sa bilo kog trećeg domena.

Zapamtite, dok konfigurišete kolačiće, razumevanje ovih atributa može pomoći da se osigura da se ponašaju kako se očekuje u različitim scenarijima.

Tabela iz Invicti i malo izmenjena.
Kolačić sa SameSite atributom će ublažiti CSRF napade gde je potrebna prijavljena sesija.

*Napomena da od Chrome80 (feb/2019) podrazumevano ponašanje kolačića bez SameSite atributa će biti lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Napomena da će privremeno, nakon primene ove promene, kolačići bez SameSite politike u Chrome-u biti tretirani kao None tokom prvih 2 minuta, a zatim kao Lax za POST zahtev na vrhunskom nivou između sajtova.

Zastavice Kolačića

HttpOnly

Ovo sprečava klijenta da pristupi kolačiću (putem JavaScript-a, na primer: document.cookie)

Obilaženja

• Ako stranica šalje kolačiće kao odgovor na zahteve (na primer, na PHPinfo stranici), moguće je zloupotrebiti XSS da se pošalje zahtev na ovu stranicu i ukrade kolačiće iz odgovora (proverite primer u https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• Ovo se može zaobići sa TRACE HTTP zahtevima jer će odgovor servera (ako je ova HTTP metoda dostupna) odražavati poslata kolačiće. Ova tehnika se naziva Cross-Site Tracking.
• Ova tehnika se izbegava od strane modernih pretraživača koji ne dozvoljavaju slanje TRACE zahteva iz JS-a. Međutim, neka obilaženja su pronađena u specifičnom softveru kao što je slanje \r\nTRACE umesto TRACE u IE6.0 SP2.
• Drugi način je iskorišćavanje zero-day ranjivosti pretraživača.
• Moguće je prepisati HttpOnly kolačiće izvođenjem napada Cookie Jar overflow:

Cookie Jar Overflow

• Moguće je koristiti Cookie Smuggling napad za eksfiltraciju ovih kolačića.

Secure

Zahtev će samo poslati kolačić u HTTP zahtevu samo ako je zahtev prenet preko sigurnog kanala (tipično HTTPS).

Prefiksi Kolačića

Kolačići sa prefiksom __Secure- moraju biti postavljeni zajedno sa secure zastavicom sa stranica koje su zaštićene HTTPS-om.

Za kolačiće sa prefiksom __Host-, mora biti ispunjeno nekoliko uslova:

• Moraju biti postavljeni sa secure zastavicom.
• Moraju poticati sa stranice zaštićene HTTPS-om.
• Zabranjeno im je da specificiraju domen, sprečavajući njihovu transmisiju na poddomene.
• Putanja za ove kolačiće mora biti postavljena na /.

Važno je napomenuti da kolačići sa prefiksom __Host- ne smeju biti poslati superdomenima ili poddomenama. Ova restrikcija pomaže u izolaciji aplikacionih kolačića. Stoga, korišćenje __Host- prefiksa za sve aplikacione kolačiće može se smatrati dobrom praksom za poboljšanje sigurnosti i izolacije.

Prepisivanje kolačića

Dakle, jedna od zaštita kolačića sa prefiksom __Host- je sprečavanje da budu prepisani iz poddomena. Sprečavanje, na primer, Cookie Tossing napada. U predavanju Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (rad) predstavljeno je da je bilo moguće postaviti kolačiće sa prefiksom __HOST- iz poddomena, varajući parser, na primer, dodavanjem "=" na početak ili na kraj...:

Ili u PHP-u je bilo moguće dodati druge karaktere na početak imena kolačića koji će biti zamenjeni donjim crticama, omogućavajući prepisivanje __HOST- kolačića:

Napadi na Kolačiće

Ako prilagođeni kolačić sadrži osetljive podatke, proverite ga (posebno ako učestvujete u CTF-u), jer može biti ranjiv.

Dekodiranje i Manipulacija Kolačićima

Osjetljivi podaci ugrađeni u kolačiće uvek treba da budu pažljivo ispitani. Kolačići kodirani u Base64 ili sličnim formatima često se mogu dekodirati. Ova ranjivost omogućava napadačima da izmene sadržaj kolačića i da se predstavljaju kao drugi korisnici tako što će ponovo kodirati svoje izmenjene podatke u kolačić.

Otimanje Sesije

Ovaj napad uključuje krađu korisničkog kolačića kako bi se dobio neovlašćen pristup njihovom nalogu unutar aplikacije. Korišćenjem ukradenog kolačića, napadač može da se predstavi kao legitimni korisnik.

Fiksacija Sesije

U ovom scenariju, napadač prevari žrtvu da koristi određeni kolačić za prijavu. Ako aplikacija ne dodeli novi kolačić prilikom prijave, napadač, posedujući originalni kolačić, može se predstaviti kao žrtva. Ova tehnika se oslanja na to da žrtva prijavi sa kolačićem koji je obezbedio napadač.

Ako ste pronašli XSS u poddomeni ili kontrolišete poddomenu, pročitajte:

Cookie Tossing

Donacija Sesije

Ovde, napadač uverava žrtvu da koristi napadačev kolačić sesije. Žrtva, verujući da je prijavljena na svoj nalog, nenamerno će izvršiti radnje u kontekstu napadačevog naloga.

Ako ste pronašli XSS u poddomeni ili kontrolišete poddomenu, pročitajte:

Cookie Tossing

JWT Kolačići

Kliknite na prethodni link da biste pristupili stranici koja objašnjava moguće nedostatke u JWT-u.

JSON Web Tokens (JWT) korišćeni u kolačićima takođe mogu predstavljati ranjivosti. Za detaljne informacije o potencijalnim nedostacima i kako ih iskoristiti, preporučuje se pristup povezanom dokumentu o hakovanju JWT-a.

Cross-Site Request Forgery (CSRF)

Ovaj napad prisiljava prijavljenog korisnika da izvrši neželjene radnje na veb aplikaciji u kojoj su trenutno autentifikovani. Napadači mogu iskoristiti kolačiće koji se automatski šalju sa svakim zahtevom na ranjivi sajt.

Prazni Kolačići

(Proverite dalje detalje u originalnom istraživanju) Pregledači dozvoljavaju kreiranje kolačića bez imena, što se može demonstrirati putem JavaScript-a na sledeći način:

document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
document.cookie = "b=v2"

Rezultat u poslatom cookie header-u je a=v1; test value; b=v2;. Zanimljivo, ovo omogućava manipulaciju kolačićima ako je postavljen kolačić sa praznim imenom, potencijalno kontrolišući druge kolačiće postavljanjem praznog kolačića na specifičnu vrednost:

function setCookie(name, value) {
document.cookie = `${name}=${value}`
}

setCookie("", "a=b") // Setting the empty cookie modifies another cookie's value

To dovodi do toga da pregledač šalje zaglavlje kolačića koje svaki veb server interpretira kao kolačić nazvan a sa vrednošću b.

Chrome Bug: Unicode Surrogate Codepoint Issue

U Chrome-u, ako je Unicode surrogate codepoint deo postavljenog kolačića, document.cookie postaje oštećen, vraćajući prazan string kasnije:

document.cookie = "\ud800=meep"

Ovo rezultira time da document.cookie ispisuje prazan string, što ukazuje na trajnu korupciju.

Krađa kolačića zbog problema sa parsiranjem

(Pogledajte dalje detalje uoriginalnom istraživanju) Nekoliko veb servera, uključujući one iz Jave (Jetty, TomCat, Undertow) i Pythona (Zope, cherrypy, web.py, aiohttp, bottle, webob), pogrešno obrađuju stringove kolačića zbog zastarele podrške za RFC2965. Oni čitaju vrednost kolačića u dvostrukim navodnicima kao jednu vrednost čak i ako uključuje tačke i zareze, koji bi obično trebali da razdvajaju parove ključ-vrednost:

RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";

Cookie Injection Vulnerabilities

(Check further details in theoriginal research) Neispravno parsiranje kolačića od strane servera, posebno Undertow, Zope, i onih koji koriste Pythonov http.cookie.SimpleCookie i http.cookie.BaseCookie, stvara mogućnosti za napade putem injekcije kolačića. Ovi serveri ne uspevaju pravilno da odvoje početak novih kolačića, omogućavajući napadačima da lažiraju kolačiće:

• Undertow očekuje novi kolačić odmah nakon citirane vrednosti bez tačke-zareza.
• Zope traži zarez da započne parsiranje sledećeg kolačića.
• Pythonove klase kolačića započinju parsiranje na razmak.

Ova ranjivost je posebno opasna u web aplikacijama koje se oslanjaju na CSRF zaštitu zasnovanu na kolačićima, jer omogućava napadačima da ubace lažirane CSRF-token kolačiće, potencijalno zaobilazeći bezbednosne mere. Problem se dodatno pogoršava načinom na koji Python obrađuje duple nazive kolačića, gde poslednja pojava preuzima prethodne. Takođe, postavlja zabrinutosti za __Secure- i __Host- kolačiće u nesigurnim kontekstima i može dovesti do zaobilaženja autorizacije kada se kolačići proslede back-end serverima podložnim lažiranju.

Cookies $version

WAF Bypass

Prema ovom blogu, može biti moguće koristiti atribut kolačića $Version=1 da se backend koristi starom logikom za parsiranje kolačića zbog RFC2109. Štaviše, druge vrednosti kao što su $Domain i $Path mogu se koristiti za modifikaciju ponašanja backenda sa kolačićem.

Cookie Sandwich Attack

Prema ovom blogu, moguće je koristiti tehniku kolačić sendviča za krađu HttpOnly kolačića. Ovo su zahtevi i koraci:

• Pronađite mesto gde se očigledno beskoristan kolačić odražava u odgovoru
• Kreirajte kolačić nazvan $Version sa vrednošću 1 (možete to uraditi u XSS napadu iz JS) sa specifičnijim putem kako bi dobio početnu poziciju (neki okviri poput Pythona ne zahtevaju ovaj korak)
• Kreirajte kolačić koji se odražava sa vrednošću koja ostavlja otvorene dvostruke navodnike i sa specifičnim putem kako bi bio pozicioniran u bazi kolačića nakon prethodnog ($Version)
• Tada će legitiman kolačić ići sledeći u redu
• Kreirajte lažni kolačić koji zatvara dvostruke navodnike unutar svoje vrednosti

Na ovaj način, kolačić žrtve se zarobljava unutar novog kolačića verzije 1 i biće odražen kad god se odražava.

document.cookie = `$Version=1;`;
document.cookie = `param1="start`;
// any cookies inside the sandwich will be placed into param1 value server-side
document.cookie = `param2=end";`;

WAF bypasses

Cookies $version

Proverite prethodnu sekciju.

Bypassing value analysis with quoted-string encoding

Ova analiza ukazuje na to da se neizbežene vrednosti unutar kolačića moraju ponovo obraditi, tako da "\a" postaje "a". Ovo može biti korisno za zaobilaženje WAFS-a kao:

• eval('test') => forbidden
• "\e\v\a\l\(\'\t\e\s\t\'\)" => allowed

Bypassing cookie-name blocklists

U RFC2109 je naznačeno da se zarez može koristiti kao razdvojnik između vrednosti kolačića. Takođe je moguće dodati razmake i tabove pre i posle znaka jednakosti. Stoga kolačić poput $Version=1; foo=bar, abc = qux ne generiše kolačić "foo":"bar, admin = qux" već kolačiće foo":"bar" i "admin":"qux". Obratite pažnju na to kako su generisana 2 kolačića i kako je admin uklonio razmak pre i posle znaka jednakosti.

Bypassing value analysis with cookie splitting

Na kraju, različiti backdoor-ovi bi se spojili u string različitih kolačića prosleđenih u različitim zaglavljima kolačića kao u:

GET / HTTP/1.1
Host: example.com
Cookie: param1=value1;
Cookie: param2=value2;

Što bi moglo omogućiti zaobilaženje WAF-a kao u ovom primeru:

Cookie: name=eval('test//
Cookie: comment')

Resulting cookie: name=eval('test//, comment') => allowed

Dodatne provere ranjivih kolačića

Osnovne provere

• kolačić je isti svaki put kada se prijavite.
• Odjavite se i pokušajte da koristite isti kolačić.
• Pokušajte da se prijavite sa 2 uređaja (ili pregledača) na isti nalog koristeći isti kolačić.
• Proverite da li kolačić sadrži neku informaciju i pokušajte da je izmenite.
• Pokušajte da kreirate nekoliko naloga sa gotovo istim korisničkim imenom i proverite da li možete primetiti sličnosti.
• Proverite opciju "zapamti me" ako postoji da vidite kako funkcioniše. Ako postoji i može biti ranjiva, uvek koristite kolačić zapamti me bez bilo kog drugog kolačića.
• Proverite da li prethodni kolačić funkcioniše čak i nakon što promenite lozinku.

Napadi na kolačiće

Ako kolačić ostaje isti (ili gotovo isti) kada se prijavite, to verovatno znači da je kolačić povezan sa nekim poljem vašeg naloga (verovatno korisničkim imenom). Tada možete:

• Pokušajte da kreirate mnogo naloga sa korisničkim imenima vrlo sličnim i pokušajte da pogodite kako algoritam funkcioniše.
• Pokušajte da bruteforce-ujete korisničko ime. Ako se kolačić čuva samo kao metoda autentifikacije za vaše korisničko ime, onda možete kreirati nalog sa korisničkim imenom "Bmin" i bruteforce-ovati svaki pojedinačni bit vašeg kolačića jer će jedan od kolačića koje ćete pokušati biti onaj koji pripada "admin".
• Pokušajte Padding Oracle (možete dekriptovati sadržaj kolačića). Koristite padbuster.

Padding Oracle - Padbuster primeri

padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# When cookies and regular Base64
padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf

# If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example:
padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2

Padbuster će napraviti nekoliko pokušaja i pitaće vas koja je uslov greške (onaj koji nije validan).

Zatim će početi da dekriptuje kolačić (može potrajati nekoliko minuta).

Ako je napad uspešno izveden, onda možete pokušati da enkriptujete string po vašem izboru. Na primer, ako želite da encrypt user=administrator

padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator

Ova izvršavanje će vam dati kolačić ispravno enkriptovan i kodiran sa stringom user=administrator unutra.

CBC-MAC

Možda kolačić može imati neku vrednost i može biti potpisan koristeći CBC. Tada je integritet vrednosti potpis koji je kreiran korišćenjem CBC sa istom vrednošću. Kako se preporučuje korišćenje nultog vektora kao IV, ova vrsta provere integriteta može biti ranjiva.

Napad

1. Dobijte potpis korisničkog imena administ = t
2. Dobijte potpis korisničkog imena rator\x00\x00\x00 XOR t = t'
3. Postavite u kolačić vrednost administrator+t' (t' će biti validan potpis (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00

ECB

Ako je kolačić enkriptovan koristeći ECB, može biti ranjiv.
Kada se prijavite, kolačić koji dobijate mora uvek biti isti.

Kako otkriti i napasti:

Kreirajte 2 korisnika sa gotovo istim podacima (korisničko ime, lozinka, email, itd.) i pokušajte da otkrijete neki obrazac unutar datog kolačića.

Kreirajte korisnika nazvanog, na primer, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" i proverite da li postoji neki obrazac u kolačiću (pošto ECB enkriptuje sa istim ključem svaki blok, isti enkriptovani bajtovi mogu se pojaviti ako je korisničko ime enkriptovano).

Trebalo bi da postoji obrazac (sa veličinom korišćenog bloka). Tako, znajući kako je gomila "a" enkriptovana, možete kreirati korisničko ime: "a"*(veličina bloka)+"admin". Tada biste mogli da obrišete enkriptovani obrazac bloka "a" iz kolačića. I imaćete kolačić korisničkog imena "admin".

References

• https://blog.ankursundara.com/cookie-bugs/
• https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd
• https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie