Cookies Hacking
Last updated
Last updated
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Cookies kom met verskeie eienskappe wat hul gedrag in die gebruiker se blaaiers beheer. Hier is 'n oorsig van hierdie eienskappe in 'n meer passiewe stem:
Die vervaldatum van 'n koekie word bepaal deur die Expires eienskap. Omgekeerd definieer die Max-age eienskap die tyd in sekondes totdat 'n koekie verwyder word. Kies Max-age aangesien dit meer moderne praktyke weerspieël.
Die gasheer wat 'n koekie ontvang, word gespesifiseer deur die Domain eienskap. Standaard is dit ingestel op die gasheer wat die koekie uitgereik het, sonder om sy subdomeine in te sluit. Wanneer die Domain eienskap egter eksplisiet ingestel word, sluit dit ook subdomeine in. Dit maak die spesifikasie van die Domain eienskap 'n minder beperkende opsie, nuttig vir scenario's waar koekie deel tussen subdomeine nodig is. Byvoorbeeld, om Domain=mozilla.org in te stel maak koekies beskikbaar op sy subdomeine soos developer.mozilla.org.
'n Spesifieke URL-pad wat teenwoordig moet wees in die versoekte URL vir die Cookie kop om gestuur te word, word aangedui deur die Path eienskap. Hierdie eienskap beskou die / karakter as 'n gids skeidingsteken, wat ooreenkomste in subgidse moontlik maak.
Wanneer twee koekies dieselfde naam het, word die een wat gekies word om te stuur, gebaseer op:
Die koekie wat die langste pad in die versoekte URL ooreenstem.
Die mees onlangse koekie as die pades identies is.
Die SameSite eienskap bepaal of koekies gestuur word op versoeke wat afkomstig is van derdeparty domeine. Dit bied drie instellings:
Strict: Beperk die koekie om nie op derdeparty versoeke gestuur te word nie.
Lax: Laat die koekie toe om gestuur te word met GET versoeke wat deur derdeparty webwerwe geïnisieer word.
None: Laat die koekie toe om van enige derdeparty domein gestuur te word.
Onthou, terwyl jy koekies konfigureer, kan die begrip van hierdie eienskappe help om te verseker dat hulle soos verwag oor verskillende scenario's optree.
Versoek tipe
Voorbeeld kode
Koekies gestuur wanneer
Skakel
<a href="..."></a>
NotSet*, Lax, None
Prerender
<link rel="prerender" href=".."/>
NotSet*, Lax, None
Vorm GET
<form method="GET" action="...">
NotSet*, Lax, None
Vorm POST
<form method="POST" action="...">
NotSet*, None
iframe
<iframe src="..."></iframe>
NotSet*, None
AJAX
$.get("...")
NotSet*, None
Beeld
<img src="...">
NetSet*, None
Tabel van Invicti en effens gewysig. 'n Koekie met SameSite eienskap sal CSRF-aanvalle verlig waar 'n ingelogde sessie nodig is.
*Let daarop dat vanaf Chrome80 (feb/2019) die standaard gedrag van 'n koekie sonder 'n koekie samesite eienskap sal lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/). Let daarop dat tydelik, na die toepassing van hierdie verandering, die koekies sonder 'n SameSite beleid in Chrome sal as None behandel word gedurende die eerste 2 minute en dan as Lax vir top-level cross-site POST versoek.
Dit verhoed dat die klient toegang tot die koekie het (Via Javascript byvoorbeeld: document.cookie)
As die bladsy die koekies as die antwoord van 'n versoek stuur (byvoorbeeld in 'n PHPinfo bladsy), is dit moontlik om die XSS te misbruik om 'n versoek na hierdie bladsy te stuur en die koekies uit die antwoord te steel (kyk 'n voorbeeld in https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/.
Dit kan omseil word met TRACE HTTP versoeke aangesien die antwoord van die bediener (as hierdie HTTP metode beskikbaar is) die koekies wat gestuur is, sal weerspieël. Hierdie tegniek word Cross-Site Tracking genoem.
Hierdie tegniek word vermy deur moderne blaaiers deur nie toe te laat om 'n TRACE versoek van JS te stuur nie. Tog is daar sekere omseilings in spesifieke sagteware gevind, soos om \r\nTRACE in plaas van TRACE na IE6.0 SP2 te stuur.
'n Ander manier is die uitbuiting van nul/dag kwesbaarhede van die blaaiers.
Dit is moontlik om HttpOnly koekies te oorwrite deur 'n Cookie Jar overflow aanval uit te voer:
Dit is moontlik om Cookie Smuggling aanval te gebruik om hierdie koekies te ekfiltreer.
Die versoek sal slegs die koekie in 'n HTTP versoek stuur as die versoek oor 'n veilige kanaal (tipies HTTPS) oorgedra word.
Koekies wat met __Secure- ge-prefiks is, moet saam met die secure vlag van bladsye wat deur HTTPS beveilig is, ingestel word.
Vir koekies wat met __Host- ge-prefiks is, moet verskeie voorwaardes nagekom word:
Hulle moet met die secure vlag ingestel word.
Hulle moet afkomstig wees van 'n bladsy wat deur HTTPS beveilig is.
Hulle is verbode om 'n domein te spesifiseer, wat hul oordrag na subdomeine voorkom.
Die pad vir hierdie koekies moet op / ingestel wees.
Dit is belangrik om op te let dat koekies wat met __Host- ge-prefiks is, nie toegelaat word om na superdomeine of subdomeine gestuur te word nie. Hierdie beperking help om toepassingskoekies te isoleer. Dus, om die __Host- voorvoegsel vir alle toepassingskoekies te gebruik, kan beskou word as 'n goeie praktyk om sekuriteit en isolasie te verbeter.
So, een van die beskermings van __Host- ge-prefiks koekies is om te voorkom dat hulle van subdomeine oor geskryf word. Dit voorkom byvoorbeeld Cookie Tossing aanvalle. In die praatjie Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) word aangebied dat dit moontlik was om __HOST- ge-prefiks koekies van subdomein in te stel, deur die parser te bedrieg, byvoorbeeld, om "=" aan die begin of aan die begin en die einde by te voeg...:
Of in PHP was dit moontlik om ander karakters aan die begin van die koekie naam by te voeg wat vervang sou word deur onderstreep karakters, wat dit moontlik maak om __HOST- koekies oor te skryf:
As 'n pasgemaakte koekie sensitiewe data bevat, kyk daarna (veral as jy 'n CTF speel), aangesien dit kwesbaar mag wees.
Sensitiewe data wat in koekies ingebed is, moet altyd ondersoek word. Koekies wat in Base64 of soortgelyke formate gekodeer is, kan dikwels ontleed word. Hierdie kwesbaarheid laat aanvallers toe om die koekie se inhoud te verander en ander gebruikers na te boots deur hul gewysigde data weer in die koekie te kodeer.
Hierdie aanval behels die steel van 'n gebruiker se koekie om ongeoorloofde toegang tot hul rekening binne 'n toepassing te verkry. Deur die gesteelde koekie te gebruik, kan 'n aanvaller die wettige gebruiker naboots.
In hierdie scenario bedrieg 'n aanvaller 'n slagoffer om 'n spesifieke koekie te gebruik om in te log. As die toepassing nie 'n nuwe koekie toeken nie wanneer daar ingelog word, kan die aanvaller, wat die oorspronklike koekie besit, die slagoffer naboots. Hierdie tegniek staat op die slagoffer wat met 'n koekie wat deur die aanvaller verskaf is, inlog.
As jy 'n XSS in 'n subdomein gevind het of jy beheer 'n subdomein, lees:
Cookie TossingHier oortuig die aanvaller die slagoffer om die aanvaller se sessie koekie te gebruik. Die slagoffer, wat glo dat hulle in hul eie rekening ingelog is, sal onbewustelik aksies in die konteks van die aanvaller se rekening uitvoer.
As jy 'n XSS in 'n subdomein gevind het of jy beheer 'n subdomein, lees:
Cookie TossingKlik op die vorige skakel om toegang te verkry tot 'n bladsy wat moontlike foute in JWT verduidelik.
JSON Web Tokens (JWT) wat in koekies gebruik word, kan ook kwesbaarhede hê. Vir diepgaande inligting oor potensiële foute en hoe om dit te benut, word dit aanbeveel om die gekoppelde dokument oor die hack van JWT te raadpleeg.
Hierdie aanval dwing 'n ingelogde gebruiker om ongewenste aksies op 'n webtoepassing uit te voer waarin hulle tans geverifieer is. Aanvallers kan koekies wat outomaties met elke versoek na die kwesbare webwerf gestuur word, benut.
(Kyk verder besonderhede in die oorspronklike navorsing) Blaaiers laat die skepping van koekies sonder 'n naam toe, wat deur JavaScript soos volg demonstreer kan word:
Die resultaat in die gestuurde koekie kop is a=v1; test value; b=v2;. Interessant genoeg, dit stel die manipulasie van koekies in staat as 'n leë naam koekie gestel word, wat moontlik ander koekies kan beheer deur die leë koekie na 'n spesifieke waarde te stel:
Dit lei daartoe dat die blaaiert 'n koekie-kop stuur wat deur elke webbediener geïnterpreteer word as 'n koekie met die naam a en 'n waarde b.
In Chrome, as 'n Unicode surrogate codepoint deel is van 'n stel koekie, word document.cookie beskadig, wat 'n leë string daarna teruggee:
This results in document.cookie outputting an empty string, indicating permanent corruption.
(Check further details in theoriginal research) Verskeie webbedieners, insluitend dié van Java (Jetty, TomCat, Undertow) en Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), hanteer koekie stringe verkeerd as gevolg van verouderde RFC2965 ondersteuning. Hulle lees 'n dubbel-aanhalingstekens koekiewaarde as 'n enkele waarde, selfs al sluit dit puntkommas in, wat normaalweg sleutel-waarde pare moet skei:
(Check further details in theoriginal research) Die onakkurate ontleding van koekies deur bedieners, veral Undertow, Zope, en dié wat Python se http.cookie.SimpleCookie en http.cookie.BaseCookie gebruik, skep geleenthede vir koekie-inspuitaanvalle. Hierdie bedieners slaag nie daarin om die begin van nuwe koekies behoorlik te begrens nie, wat dit moontlik maak vir aanvallers om koekies na te maak:
Undertow verwag 'n nuwe koekie onmiddellik na 'n aangehaalde waarde sonder 'n puntkomma.
Zope soek 'n komma om die volgende koekie te begin ontleed.
Python se koekieklasse begin ontleed op 'n spasiekarakter.
Hierdie kwesbaarheid is veral gevaarlik in webtoepassings wat op koekie-gebaseerde CSRF-beskerming staatmaak, aangesien dit aanvallers in staat stel om nagebootste CSRF-token koekies in te spuit, wat moontlik sekuriteitsmaatreëls kan omseil. Die probleem word vererger deur Python se hantering van duplikaat koekiename, waar die laaste voorkoms vroeëre oorskry. Dit wek ook kommer vir __Secure- en __Host- koekies in onveilige kontekste en kan lei tot magtiging omseilings wanneer koekies aan agtergrondbedieners oorgedra word wat vatbaar is vir nabootsing.
Volgens hierdie blogpos, mag dit moontlik wees om die koekie-attribuut $Version=1 te gebruik om die agtergrond 'n ou logika te laat gebruik om die koekie te ontleed weens die RFC2109. Boonop kan ander waardes soos $Domain en $Path gebruik word om die gedrag van die agtergrond met die koekie te verander.
Hierdie ontleding dui aan om ontsnapte waardes binne die koekies te ontsnap, sodat "\a" "a" word. Dit kan nuttig wees om WAFS te omseil soos:
eval('test') => verbode
"\e\v\a\l\(\'\t\e\s\t\'\)" => toegelaat
In die RFC2109 word aangedui dat 'n komma as 'n skeidingsteken tussen koekiewaardes gebruik kan word. En dit is ook moontlik om spasies en tabulasies voor en na die gelyk teken by te voeg. Daarom genereer 'n koekie soos $Version=1; foo=bar, abc = qux nie die koekie "foo":"bar, admin = qux" nie, maar die koekies foo":"bar" en "admin":"qux". Let op hoe 2 koekies gegenereer word en hoe admin die spasie voor en na die gelyk teken verwyder is.
Laastens sou verskillende agterdeure in 'n string verskillende koekies wat in verskillende koekie-kopstukke oorgedra word, saamgevoeg word soos in:
Wat kan toelaat om 'n WAF te omseil soos in hierdie voorbeeld:
Die koekie is die selfde elke keer wanneer jy aanmeld.
Meld uit en probeer om dieselfde koekie te gebruik.
Probeer om met 2 toestelle (of blaaiers) na dieselfde rekening aan te meld met dieselfde koekie.
Kontroleer of die koekie enige inligting daarin het en probeer om dit te wysig.
Probeer om verskeie rekeninge met amper dieselfde gebruikersnaam te skep en kyk of jy ooreenkomste kan sien.
Kontroleer die "onthou my" opsie as dit bestaan om te sien hoe dit werk. As dit bestaan en kwesbaar kan wees, gebruik altyd die koekie van onthou my sonder enige ander koekie.
Kontroleer of die vorige koekie werk selfs nadat jy die wagwoord verander.
As die koekie dieselfde bly (of amper) wanneer jy aanmeld, beteken dit waarskynlik dat die koekie verband hou met 'n veld van jou rekening (waarskynlik die gebruikersnaam). Dan kan jy:
Probeer om baie rekeninge met gebruikersname wat baie soortgelyk is te skep en probeer om te raai hoe die algoritme werk.
Probeer om die gebruikersnaam te bruteforce. As die koekie slegs as 'n verifikasietegniek vir jou gebruikersnaam gestoor word, kan jy 'n rekening met die gebruikersnaam "Bmin" skep en elke enkele bit van jou koekie bruteforce, want een van die koekies wat jy sal probeer, sal die een wees wat aan "admin" behoort.
Probeer Padding Oracle (jy kan die inhoud van die koekie ontsleutel). Gebruik padbuster.
Padding Oracle - Padbuster voorbeelde
Padbuster sal verskeie pogings maak en sal jou vra watter voorwaarde die foutvoorwaarde is (die een wat nie geldig is nie).
Dan sal dit begin om die koekie te ontsleutel (dit kan 'n paar minute neem)
As die aanval suksesvol uitgevoer is, kan jy probeer om 'n string van jou keuse te enkripteer. Byvoorbeeld, as jy enkripteer user=administrator wil.
Hierdie uitvoering sal jou die koekie korrek versleuteld en gekodeer met die string user=administrator binne-in gee.
CBC-MAC
Miskien kan 'n koekie 'n waarde hê en kan dit met CBC onderteken word. Dan is die integriteit van die waarde die handtekening wat geskep is deur CBC met dieselfde waarde te gebruik. Aangesien dit aanbeveel word om 'n nulvektor as IV te gebruik, kan hierdie tipe integriteitskontrole kwesbaar wees.
Die aanval
Kry die handtekening van gebruikersnaam administ = t
Kry die handtekening van gebruikersnaam rator\x00\x00\x00 XOR t = t'
Stel in die koekie die waarde administrator+t' in (t' sal 'n geldige handtekening wees van (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00
ECB
As die koekie met ECB versleuteld is, kan dit kwesbaar wees. Wanneer jy aanmeld, moet die koekie wat jy ontvang altyd dieselfde wees.
Hoe om te detecteer en aan te val:
Skep 2 gebruikers met byna dieselfde data (gebruikersnaam, wagwoord, e-pos, ens.) en probeer om 'n patroon binne die gegewe koekie te ontdek.
Skep 'n gebruiker genaamd byvoorbeeld "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" en kyk of daar enige patroon in die koekie is (aangesien ECB met dieselfde sleutel elke blok versleuteld, kan dieselfde versleutelde bytes verskyn as die gebruikersnaam versleuteld word).
Daar moet 'n patroon wees (met die grootte van 'n gebruikte blok). So, deur te weet hoe 'n klomp "a" versleuteld is, kan jy 'n gebruikersnaam skep: "a"*(grootte van die blok)+"admin". Dan kan jy die versleutelde patroon van 'n blok van "a" uit die koekie verwyder. En jy sal die koekie van die gebruikersnaam "admin" hê.
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
