Hack op Nederlandse politie vermoedelijk uitgevoerd via gestolen cookies

De hack op de Nederlandse politie van eind september werd vermoedelijk uitgevoerd via een gekaapte inlogsessie. Dat meldt de politie zelf. Bij de cyberaanval van eind september werden de gegevens van alle 63.000 politiewerknemers buitgemaakt.

In een persbericht op de website van de politie schrijft hoofd Operatiën bij de Eenheid Landelijke Opsporing en Interventies Stan Duijf dat de hackers vermoedelijk een zogenoemde pass-the-cookie-aanval hebben uitgevoerd. Bij een dergelijke succesvolle aanval kunnen cybercriminelen een actieve gebruikerssessie overnemen, inclusief de daarbij behorende rechten. Het verkrijgen van die toegang kan op verschillende manieren gebeurd zijn, bijvoorbeeld door phishing.

Bij de hack hebben de cybercriminelen allerlei privégegevens van de 63.000 werknemers te pakken gekregen. De politie onderzoekt nog wat de hackers hebben gedaan met de buitgemaakte data. Begin oktober werd bekend dat de inlichtingen- en veiligheidsdiensten het zeer waarschijnlijk achten dat een statelijke actor verantwoordelijk is. Het gaat naar verluidt om Russische hackers, die via een malwarelink een vrijwilliger bij de politie hebben getroffen.

Reacties (126)

[Werelds]

Ik lees hierboven veel gebakken lucht verhalen over cookies, tokens, 2FA, enzovoort.

Cookies zijn niets meer dan een opslag methode. Één van slechts 2 permanente opslag methodes waar je in een browser toegang toe hebt. Een cookie was vroeger letterlijk slechts een tekst bestandje, tegenwoordig gebruiken browsers daar vaak een SQLite database voor, maar het stelt nog steeds niets voor.

In dat cookie kan een sessie ID zitten, een token (maakt niet uit of dat een JWT set is of niet), volledige authenticatie gegevens in gecodeerde (encrypted) vorm - kan allemaal. Het is een opslag methode. Geen authenticatie methode.

2FA past men doorgaans ook alleen toe tijdens het login proces, eenmaal ingelogd en authenticatie bemachtigd, wordt dat niet herhaaldelijk gedaan omdat dat de gebruikers ervaring in de weg zou zitten.

[Arietje]

Het natuurlijk is wel mogelijk om *iets* met het IP-adres te doen of Geo informatie.

[daft_dutch]

iets de doen? Weer een walled garden principe. waar je als je een maal binnen bent niet meer gecontroleerd wordt..
(Je moet proberen met officiële papieren een politie bureau binnen gaan en dan van 63000 gebruikers de info uit print. Zeker dat je wordt tegen gehouden)
Daarbij wat moet iemand met alle gegevens van politie agenten?! geen enkele quota of beperking. Dan is het geen hoe maar is het wanneer.

ook geen vpn gebruikt. Zal me niet verbazen als het van een laptop kwam die niet alleen voor werk werd gebruikt.

[Werelds]

Probleem met IP adressen is dat mobiele gebruikers regelmatig wisselen. In het geval van de politie lijkt me dat een zinvolle afweging om te maken, maar voor veel andere toepassingen ga je de gebruiker dan behoorlijk in de weg zitten.

Geo informatie daarentegen niet. Daar kun je niet echt op vertrouwen, zelfs als het uit een GPS sensor komt omdat dat vrij eenvoudig te spoofen is. Geolocatie informatie over IP adressen is in feite een Gentleman's Agreement tussen eigenaars van IP adressen - er is geen wettelijke noodzaak om daar iets over vrij te geven. Er zijn talloze blocks waar je überhaupt geen informatie over kunt krijgen en, afhankelijk van de eigenaar, de precisie is onbetrouwbaar. Verder moet je ook meerdere GeoIP databases onderhouden en vaak updaten, omdat ze niet allemaal dezelfde gegevens bevatten.

Neem bijvoorbeeld Ziggo. Bij beide kan het IP adres dat aan jouw verbinding thuis gekoppeld is de ene dag geregistreerd staan als Almere, de dag erna als Meerssen en daarna weer als Amsterdam. Ziggo's beleid is om dat grotendeels privé te houden. Toen ik nog Ziggo had, kwam mijn eigen IP adres maar zelden naar voren als Meerssen (dichtsbijzijnde lokale knooppunt).

Daarnaast is de interpretatie van GeoIP gegevens ook een grijs gebied, want het gaat om een radius, geen exacte coördinaten. Daarom gaf mijn iPhone toen ik hem voor het eerst instelde Duitsland als locatie aan, omdat het centrum van dat punt aan de oostgrens van de provincie lag en zij kijken naar welk land het grootste deel van die radius in valt. En dat was dus Duitsland

[Arietje]

Dat is zo, dat maakt de zaak niet eenvoudig of zwart wit. Maar er zijn tal van functies te bedenken waarmee je meer kunt doen. Soms wijzigt alleen het laatste octet bijvoorbeeld. Je kunt ook kijken naar de user agent of fingerprint. En qua Geo gegevens van het IP er wel naar kijken en bij te grote verschillen in ieder geval wel de sessie laten verlopen en de gebruiker op de hoogte brengen. Wie weet is er wel gewoon met een Russisch IP-adres ingelogd en vanuit een andere browser en is dat nooit opgemerkt. Je kunt ook IP-adressen en bijbehorende Geo info opslaan en als factor laten meewegen. De eerste keer dat er een 'nieuwe' locatie gebruikt wordt die net te veel afwijkt, moet er nog een nieuwe code ingevoerd worden. Daarmee wordt de eigenaar van die locatie bevestigd. De volgende keer dat hij daar weer naartoe springt, weegt dat feit niet zwaar genoeg om een nieuwe code te triggeren.

[Werelds]

Tuurlijk kun je wel iets met Geo doen, maar je moet alsnog heel voorzichtig zijn. Puur afstand werkt niet, vanwege bovengenoemd voorbeeld van Ziggo. 200 km verschil is sowieso al niet veel, maar is in zo'n geval ook geen reden tot paniek.

Helaas is het inderdaad wel zinvol om dingen als IP's die als Russisch (of India, Filipijnen, Indonesië...enzovoort) aangemerkt staan meteen te blokkeren. Daar komt nu eenmaal veel scriptkiddie zooi (en spam) vandaan, dus ik heb enkele sites waar mensen uit die landen op een whitelist gezet moeten worden. Veel van die landen hebben m'n klanten geen echte basis in, maar Hong Kong valt er helaas ook onder en dat is wel een belangrijk land.

Dat gezegd hebbende zou dat in een geval als dit niets uit maken. Dit zouden ze allemaal via een VPN gedaan hebben; en geen bekend VPN, maar een eigen ding. En dan valt GeoIP plat op z'n neus. Ook daar heb ik helaas zat ervaring mee

[Arietje]

Als er op dit moment niets gedaan wordt aan detectie op Geo, dan zou het constateren van gebruik van een sessie in Nederland in Rusland, een bel kunnen doen rinkelen. Waarop verdere stappen ondernomen kunnen worden om het account uit te schakelen bijvoorbeeld. Dan heb je dus meer aan monitoring dan op voorhand blokkeren, want dan is meteen al duidelijk dat je een VPN moet gebruiken. En een willekeurige VPN in Nederland zal qua Geo of ASN nogal afwijken in de basis. Dit is mijn optiek echt meer doen dan 'nodig' en moet je obfuscation ook inzetten. Je moet er niet vanuit gaan dat een Russische hacker precies weet wat jij allemaal met 2FA en user gegevens doet.
Als je alleen eenmalig de sessie valideert en als die gestolen wordt er geen enkel gevolg is; vs de situatie met allerlei detecties hierop, dan heb je bij dat laatste gewoon een vele grotere kans om problemen te voorkomen. En dat kun je fine tunen dat het nog te doen is voor een gebruiker. Het gaat er bij mij niet in dat je zegt dat heeft allemaal geen zin en/of zit de gebruiker te veel in de weg.

[mooiboy]

Zoiets heet continuous authentication maar dat is lastig te implementeren De sessie moet dan eerst op de applicatielaag worden beëindigd.

[MrFax]

Hoe krijg je het eigenlijk voor elkaar? Zo'n cookie hoort toch geweigerd te worden als deze van een vreemd IP komt!?

[Snow_King]

Nee, want je wisselt vaak genoeg van IP. Cookies zijn niet IP gebonden.

[MrFax]

In principe kan dat wel gewoon hoor, en wordt dat in veel gevallen ook gewoon gedaan. Bij Tweakers.net zelf kon je voor een hele lange tijd ook je cookie-sessie handmatig aan je IP-adres binden. Dus echt raar is dat niet.

Of gewoon niet meer met sessie-cookies werken voor iets gevoeligs als een politiemedewerkerdatabase en ga over op token-based auth met 2FA. Zoiets is veel moeilijker te kapen, zeker als je de sessielengtes heel kort houdt en werkt met refresh tokens.

[Reactie gewijzigd door MrFax op 8 november 2024 21:41]

[Lucb1e]

zeker als je de sessielengtes heel kort houdt en werkt met refresh tokens

Ik werk in de IT-beveiliging maar heb dat hele refreshtokenverhaal nog niet gesnapt (en vermoed inmiddels dat het gebakken lucht is). De browser heeft dat refreshtoken nodig om de sessie actief te kunnen houden, dus dat werkt feitelijk hetzelfde als je traditionele sessie-cookie. Dan heeft het toch geen veiligheidsvoordeel om een kortdurend token steeds te laten verlopen wanneer je op hetzelfde systeem nog een tweede token moet bewaren waarmee je dan weer een nieuwe kan ophalen?

Ik snap wel het voordeel qua schaalbaarheid: je rolt één keer een sleutel uit naar al je systemen, en die kunnen nu allemaal los van elkaar de signatures op sessietokens controleren. Eens in de zoveel tijd (elke 5 minuten, bijv.) laat je die dan verlopen zodat de client aan de centrale authenticatieserver moet gaan vragen om een nieuw token, en dán wordt er wel in de database gekeken of je nog toegang zou moeten hebben. Dan zit je niet bij elk request in de database te kijken, maar slechts elke paar minuten per gebruiker. Als je dus op Google- of Netflixschaal werkt met gedistribueerde systemen dan heeft dit een voordeel. Bij klanten is het echter superhip om dit voor álles te doen (ook embedded devices!), maar het is zoveel complexer omdat je nu een header hebt (aanvallen als alg=none, of alg van rsa aanpassen naar hs256 waardoor je een public key als hmac-key kan gebruiken, dat soort dingen), alle sessiedata bij de client hebt staan (áls daar een probleem mee is, zoals wanneer je het wachtwoord van de gebruiker daarin opslaat, staat dat gelijk op iedereens systeem), de signature zelf (moet je bijvoorbeeld zeker van zijn dat het algoritme constant time is), en je verstuurt kilobytes data waar je vroeger misschien 32 bytes nodig had (Google stelt neem ik aan niet voor niks dingen voor als HTTP header compression in SPDY wat nu HTTPv2 geworden is)

Maar lang verhaal kort, ik denk dus niet dat korte sessielengtes + refresh tokens iets uithalen. Korte sessies uiteraard wel, maar dan niet een langdurig-geldig token tezamen met je kortstondige token opslaan

[Reactie gewijzigd door Lucb1e op 9 november 2024 03:03]

[Werelds]

[...]
Ik werk in de IT-beveiliging maar heb dat hele refreshtokenverhaal nog niet gesnapt (en vermoed inmiddels dat het gebakken lucht is). De browser heeft dat refreshtoken nodig om de sessie actief te kunnen houden, dus dat werkt feitelijk hetzelfde als je traditionele sessie-cookie.

Een refresh token is op zichzelf geen geldige authenticatie. Met andere woorden, een refresh token kan gebruikt worden om een geldig authenticatie (access) token te genereren. En dát is waar de combinatie iets veiliger wordt, omdat de methode om het refresh token om te ruilen voor een access token extra stappen kan bevatten, zoals bijvoorbeeld PKCE. Als je vervolgens refresh tokens óók telkens vernieuwt, voeg je een tijd-gebonden element toe. En om een refresh token om te zetten in een access token moet de aanvaller uitvogelen hoe dat moet, wat een beetje obfuscatie toe voegt.

Extra stappen als PKCE even negerend, stel dat jij in logt om 10:00. Je krijgt een access token dat 60 seconden geldig is, een refresh token dat een maand geldig is. De eerste sla je enkel in het geheugen op (een variabele in je applicatie), de tweede in permanente opslag (cookie, localstorage, applicatie data in native apps). Zolang de sessie actief is, wissel je telkens als het access token verloopt het refresh token uit voor een nieuw access token - en daarbij geef je ook meteen een nieuw refresh token uit, waardoor beide tokens vaak vernieuwd worden. Als een aanvaller het refresh token weet te bemachtigen maar niet gebruikt voordat je applicatie het gebruikt, is dat refresh token dus niet meer geldig. Dus jij als gebruiker maakt om 10:01 een request, beide tokens worden vernieuwd en de aanvaller heeft dan slechts 60 seconden gehad om iets met je eerste tokenset te doen. Combineer dat met extra stappen als PKCE en dergelijke en het wordt lastiger iets met die tokens te doen. Niet onmogelijk, maar lastiger.

Je zou als ontwikkelaar dat kunnen combineren met het controleren van IP adressen tussen requests die elkaar opvolgen en en dan iets inbouwen waardoor je in zo'n geval een email waarschuwing stuurt of simpelweg de tokens blokkeert. In de praktijk wil je dat niet doen omdat met name met mobiel gebruik (of het schakelen van Wi-Fi naar mobiele data) het IP adres regelmatig wisselt en gebruikers zich daar dood aan gaan ergeren, maar het kán wel.

[Reactie gewijzigd door Werelds op 9 november 2024 10:28]

[Lucb1e]

Thanks! Interessante constructie. Het doet me denken aan het Signal-protocol waarbij je ook steeds de keys bij elk bericht vernieuwt waardoor de aanvaller een voortdurende toegang moet hebben en niet alleen eenmalig de keys kan stelen (niet het eerste protocol wat dit doet, maar wellicht de bekendste). In dit geval is het dan niet elk "bericht" (request) maar volgens een timer, wat ook wel logisch is wanneer iemand meer dan één tab open heeft en die anders gedesynchroniseerd raken. Of aan autosleutels, waarbij je strakke timings zou moeten hebben zodat je niet het signaal van de sleutel vanaf een hele andere locatie kan relayen naar de auto, of in ieder geval heb ik gehoord dat het zo zou moeten zijn (of fabrikanten dit eindelijk voor elkaar hebben in alle nieuwe modellen, weet ik niet)

Anyway terug naar de refresh tokens: oké ik snap nu een potentiëel voordeel. Zoals je zegt is het niet waterdicht, maar

• je moet als aanvaller alert zijn en direct toeslaan (of het goed geautomatiseerd hebben, wat ook weer extra complexiteit is), en
• óf de aanvaller verliest toegang wanneer de legitieme gebruiker diens refreshtoken na (gemiddeld) 30 seconden refresht (aangenomen dat de aanvaller geen voortdurende toegang tot het systeem van het slachtoffer heeft), óf de gebruiker krijgt die foutmelding.

Idealiter zou je dan dus ook een detectie hebben wanneer een gebruiker een refreshtoken probeert te gebruiken dat net al ingewisseld is, en daarop alle sessies van de persoon uitloggen zodat het laatstgenoemde scenario leidt tot ontzegging van de toegang voor de aanvaller. (Wellicht zelfs IT/SOC waarschuwen en/of het account blokkeren, als dit niet vaak gebeurt onder normaal gebruik.) Dan moet de aanvaller zich weer opnieuw toegang verschaffen tot het systeem van het slachtoffer om het nieuwe token te vangen. En wanneer de aanvaller zo'n toegang toch al had, dan kan geen enkele constructie nut hebben omdat de aanvaller dan alles kan/weet dat de legitieme client ook kan/weet, dus een "baat het niet dan schaadt het niet"-situatie denk ik

Ik ga eens letten op of dit is hoe het bij klanten geïmplementeerd is, dus dat zo'n refresh token wordt verwisseld bij gebruik. Meestal zijn het van die JWT dingen die een vooraf-bepaalde verlooptijd hebben, dus als ze 'm niet op een denylist zetten dan zou die blijven werken en heb je geen voordeel van deze constructie, wat dan een aanbeveling kan zijn

[Reactie gewijzigd door Lucb1e op 9 november 2024 18:25]

[Werelds]

Je zult waarschijnlijk veel zien dat de tokens alsnog een relatief lange expiry hebben, omdat het bovenstaande wat meer requests naar de server vereist en wat intelligentere code om constant de expiries te checken. En daar doen velen de moeite niet voor

OAuth, JWT's, tokensets en alle dingen die hier in de comments veel genoemd worden zijn geen van allen veilig op zichzelf en al zeker niet per definitie veilig. Het hele proces moet gewoon zo waterdicht mogelijk gemaakt worden, maar zolang je permanente opslag wil hebben (lees: gebruikers niet opnieuw in laten loggen bij elke sessie) blijft dát de zwakste schakel.

Als je geen noodzaak voor 3rd party toegang hebt, zijn dit soort methodes wat mij betreft ook onnodig complex. Een HttpOnly + Secure cookie kun je op bijna dezelfde manier roteren (met elke geldige request vanuit de server geef je dan een nieuwe waarde terug; lastigste daarbij is de timing tussen requests, maar daar is ook mee om te gaan), maar daar kun je als aanvaller veel moeilijker aan komen (zoals gezegd, dan moet je malware op de doel machine hebben). Het verschil is dat je client-side code dan niet zélf kan controleren of de authenticatie nog geldig zou moeten zijn*, dat moet je dan aan de server over laten en kost dus meer HTTP requests.

* zou moeten zijn, omdat je lokale tokens wellicht een expiry in de toekomst hebben maar server-side ingetrokken zijn

[Lucb1e]

Als je geen noodzaak voor 3rd party toegang hebt, zijn dit soort methodes wat mij betreft ook onnodig complex. Een HttpOnly + Secure cookie kun je op bijna dezelfde manier roteren (met elke geldige request vanuit de server geef je dan een nieuwe waarde terug

Ha! Dat was deel van wat ik getypt had, maar ik had besloten het niet in mijn vorige reactie te zetten omdat je nergens claimt dat JWT (of vergelijkbaar) de oplossing is. Ik had letterlijk getypt dat je dit alles ook met de veel simpelere traditionele constructie (van een secure-random sessiecookie heen en weer sturen) kan doen... je neemt me de woorden uit de mond

Enige aanmerking die ik nu heb is dat je het waarschijnlijk alsnog met een timer wil doen zodat alle tabs weten wanneer het tijd is om een nieuw token aan te vragen, en je niet zo'n desync-effect hebt waarbij de ene tab een request maakt en alle andere tabs nu geen geldig token meer hebben. Of misschien kun je met postMessage werken om dat te fixen zonder timer nodig te hebben. Implementatiedetail. Ik ben het in ieder geval op de hoofdlijn volledig met je eens

[Werelds]

Als je het token enkel in geheugen bewaart wel ja. Als je cookies of localstorage gebruikt en dat bij elke request opnieuw daaruit op haalt (of in het geval van cookies, gewoon mee laat gaan) dan is het token zelf niet zo'n probleem, maar zul je inderdaad wel moeten zorgen dat je niet parallelle refresh-requests hebt. Heb er nooit al te diep over nagedacht (geen noodzaak gehad) maar ik denk dat je dat wel met shared workers kunt doen. Betrouwbaarder en flexibeler dan postMessage, geen onzinnige timers. Soort van mutex op de token refresh via de worker.

Ik had letterlijk getypt dat je dit alles ook met de veel simpelere traditionele constructie (van een secure-random sessiecookie heen en weer sturen) kan doen... je neemt me de woorden uit de mond

Ik reageer doorgaans niet zo diep op dit soort artikelen, maar ik zag deze keer wel erg veel misconcepties

Omdat ik dit werk al zo lang doe, heb ik al deze dingen op zien komen (en sommige ook weer zien gaan...) en het wordt door nieuwere devs vaak volledig verkeerd begrepen omdat je met een beetje Googlen vaak eerst van die lyrische blog posts tegen komt die doen alsof bijvoorbeeld JWT's gebruiken alles op lost. Het is hetzelfde met hoe velen helemaal niet begrijpen hoe Node.js werkt en roepen dat het multithreaded is en alles in parallel doet en dergelijke.

[Lucb1e]

Ik wil niet claimen dat ik het werk zólang doe dat ik zo vanalles heb zien komen en gaan, maar de hype rond nodejs en jwt is inderdaad ook nog altijd "nieuw" voor mij

Ga jij naar de tweakers abodag later deze maand? (Gratis behalve natuurlijk eventuele reiskosten.) Ik zie toevallig op je profiel maastricht staan; je zou met mij en Linksquest kunnen samenreizen vanaf bijv. Sittard (we dubben nog over auto of trein dus beide zijn mogelijk)

[Falcon]

Authentication Code Flow met PKCE wordt daarom aangeraden.

[Lucb1e]

Heb de RFC erbij gepakt, maar dat gaat hier niet helpen:

OAuth 2.0 [RFC6749] public clients are susceptible to the
authorization code interception attack.

In this attack, the attacker intercepts the authorization code
returned from the authorization endpoint within a communication path
not protected by Transport Layer Security (TLS), such as inter-
application communication within the client's operating system.

[...]

To mitigate this attack, this extension utilizes a dynamically
created cryptographically random key called "code verifier". A
unique code verifier is created for every authorization request, and
its transformed value, called "code challenge", is sent to the
authorization server to obtain the authorization code. The
authorization code obtained is then sent to the token endpoint with
the "code verifier", and the server compares it with the previously
received request code so that it can perform the proof of possession

Dit is de derde of vierde pagina die ik erover open en ik denk dat ik eindelijk het nieuw-uitgevonden jargon snap (je had de argumentatie ook gewoon zelf mogen geven trouwens hoor). In gewone-mensentaal: om te voorkomen dat de ene app een token steelt bestemd voor een andere app, doet de server een challenge-response met de client. De kwaadaardige app kan de challenge niet beantwoorden omdat die de sleutel ("code verifier") niet heeft dat door de originele aanvrager is gegenereerd

Als de situatie zo is als in het artikel geschetst, waarbij de aanvallers op de een of andere manier het juiste token gepassed hebben, helpt dit de situatie niet. Ofwel hadden ze toegang tot de opslag van de app (bijv. browser), waardoor ze die code verifier ook gewoon hadden gevist, ofwel was het iets als een XSS waardoor de originele app degene is die de requests maakt en dus ook de juiste challenge-response zou gebruiken

Corrigeer me als ik iets over het hoofd zie; het liefst met meer dan vijf woorden zodat ik snap waar je heen wilt

[Reactie gewijzigd door Lucb1e op 9 november 2024 17:48]

[rob12424]

Zou je met een OS zoals Qubes dan wel een scheidingswand hebben of is de gebruiker nog steeds de zwakste schakel?

[Lucb1e]

Ligt eraan hoe het binnenkomt. Wij gebruiken op het werk VM's (vergelijkbaar met Qubes) om te beperken wat de schade is van, bijvoorbeeld, een kwetsbaarheid in de e-mailclient die we gebruiken. Als iemand dus in de e-mail VM komt via een e-mail met malware erin, dan heeft xij toegang tot alle e-mails die op dat moment daar nog staan, maar niet tot bijvoorbeeld de bevindingen in de security audits die we recent gedaan hebben: die versturen we immers nooit per e-mail en de onversleutelde versies staan in de VM specifiek voor de klant waar het om gaat. Dataminimalisatie, in dit voorbeeld oude e-mails archiveren naar een offline systeem, is het andere deel van de puzzel om schade te beperken.

Stel dat de aanvaller bij de politiemedewerk(st)er is binnengekomen via een phishing-e-mail of een kwaadaardige advertentie, maar de medewerk(st)er in een ándere VM (of Qube dus) het politiesysteem benadert, dan zal de aanvaller eerst een manier moeten vinden om die andere VM binnen te dringen. Wellicht wordt er data van de e-mail-VM richting het politiesysteem gekopiëerd, zoals wanneer er zaakrelevante informatie wordt gedeeld per e-mail. Het kan alsnog een ingang zijn als je een kwetsbaarheid in het politiesysteem weet en die kan uitbuiten door van zo'n kopiëeractie gebruik te maken, maar je hebt als aanvaller in ieder geval niet zomaar per direct alle toegang.

Van de andere kant, als het een XSS-aanval was dan zou je hier niks aan hebben omdat de kwaadaardige code in dat geval wordt uitgevoerd in de juiste VM (op de juiste origin zelfs, in web-jargon)

Ik moet ook zeggen dat het een redelijk vervelende manier van werken is als je alles netjes compartmentaliseert volgens het boekje en steeds dingen heen en weer moet schuiven om je werk gedaan te krijgen. Of dat het waard is, of dat er andere maatregelen zijn die je kan treffen om dergelijke aanvallen te voorkomen of de impact te verminderen, is een afweging die ik niet kan maken met de momenteel beschikbare informatie

[Reactie gewijzigd door Lucb1e op 11 november 2024 01:30]

[Yongshi]

Een 2fa eindigd toch gewoon in een sessie cookie? Als iemand je cookie steelt dan maakt het toch niet uit wat voor fratsen je hebt uitgehaald om die te krijgen?

[MrFax]

Zoek even op wat "stateless authentication" is. Dat is jusit geen traditionele cookie. Het werkt dan ook niet 1-2-3 in een standaardbrowser maar moet het besturingssysteem aanspreken. OAuth, Firebase, Android JWT, etc, hoef je niet te laten werken met cookies. Dat kan, maar hoeft niet. Je kan ook een auth token en refresh token opsturen. Deze kan je zelfs in de TPM laten opslaan. Dan wordt het al heel lastig om de sessie te kapen.

Op een moderne Android-telefoon is dit niet zo moeilijk meer om dit gebruiksvriendelijk te houden. Bij een gewone browser op je Windows-PC zitten er wel meer haken en ogen.

2FA zorgt ervoor dat iemand niet gewoon je inloggegevens kaapt en zelf een sessie kan opstarten. Want dat kan hier ook gewoon gebeurd zijn, de Politie weet het niet.

[Reactie gewijzigd door MrFax op 8 november 2024 21:56]

[Werelds]

Zoek even op wat "stateless authentication" is. Dat is jusit geen traditionele cookie. Het werkt dan ook niet 1-2-3 in een standaardbrowser maar moet het besturingssysteem aanspreken. OAuth, Firebase, Android JWT, etc, hoef je niet te laten werken met cookies. Dat kan, maar hoeft niet. Je kan ook een auth token en refresh token opsturen. Deze kan je zelfs in de TPM laten opslaan. Dan wordt het al heel lastig om de sessie te kapen.

Uh, nee, nee, nee en nee.

Je kunt niets in de TPM opslaan. Daar heb je vanuit een browser geen enkele toegang toe. Je kunt wel 2FA hebben die *mogelijk* op dingen als de TPM (of T2 bijvoorbeeld) leunt, maar daar heb je geen rechtstreekse controle over. Keychain en soortgelijke dingen kun je ook niets mee.

Met al die authenticatie methodes moet je alsnog je token(s) ergens op slaan om ze vervolgens te kunnen gebruiken. Je doet het voorkomen alsof OAuth en JWT authenticatie methodes zijn (wellicht een fout in de manier waarop je het stelt), maar dat is niet zo. OAuth is een standaard voor authorisatie (waar je als gebruiker toegang toe hebt), niet authenticatie (bevestigen van de identiteit van de gebruiker; inloggen dus). Daarvoor heb je OIDC, dat bovenop OAuth2 zit. JWT is dan weer een data structuur standaard waarmee je de benodigde gegevens tussen verschillende systemen heen en weer stuurt. Dan zijn er ook dingen als WebAuthN, maar het zijn allemaal slechts standaarden en geen van allen zegt ook maar iets over hoe je de authenticatie methode opslaat en verifiëert.

Ongeacht welke standaarden je wel of niet gebruikt, je token moet ergens in de browser opgeslagen worden en de enige realistische methodes daarvoor zijn cookies en/of local-/sessionstorage. Ook zonder OAuth en dergelijke kun je "stateless authentication" zonder problemen doen - en zo doen de meeste sites dat ook. Stateless betekent alleen dat de server jouw sessie niet bij hoeft te houden; met andere woorden, de ene HTTP request staat los van de volgende en de server zal bij beide requests opnieuw je gegevens verifiëren. Cookies kunnen dus wél stateless zijn, want als de inhoud van het cookie enkel een token bevat dat vervolgens geverifiëerd moet worden door de server, is er geen state die bijgehouden wordt. Of dat een sessie cookie of een HTTP cookie is doet er verder niet toe, een sessie cookie betekent enkel dat het cookie verloopt als je je browser afsluit. De permanente methodes zijn daarnaast ook uit te lezen búiten de browser; ik kan je zonder meer een stukje malware geven dat al jouw cookies of applicatie data uit leest, op alle besturingssystemen.

Op jouw Android telefoon is niets van dit alles ook maar een greintje veiliger in de browser. In native apps deels wel, door de sandboxing van de app gegevens. Maar net als in de browser is je client-secret bijvoorbeeld niet veilig, dat kun je gewoon achterhalen door de app te decompilen, dus ook dan zijn dingen als PKCE gewenst.

En nee, cookies zijn nooit en te nimmer IP-gebonden. Dat kan niet. Ze zijn hooguit domein- en/of protocol-gebonden. Een HttpOnly + secure cookie met de correcte domein setting wordt enkel naar het betreffende domein verzonden met een beveiligde verbinding en kan niet vanuit JavaScript uitgelezen worden. Wél kan je login-sessie IP-gebonden zijn, maar dat zit niet in het cookie, dat zit in de authenticatie gegevens die de server opgeslagen heeft en doet pas iets nadat je de gegevens in het cookie naar de server gestuurd hebt.

Of gewoon niet meer met sessie-cookies werken voor iets gevoeligs als een politiemedewerkerdatabase en ga over op token-based auth met 2FA. Zoiets is veel moeilijker te kapen, zeker als je de sessielengtes heel kort houdt en werkt met refresh tokens.

Nope. Dat refresh token moet gewoon in de browser opgeslagen worden en als ik dat uit kan lezen en weet hoe het voor een access token uitgewisseld moet worden, kan ik jouw sessie gewoon kapen. Als ik zelf toegang tot de site in kwestie heb, heb ik dat zo uitgevogeld.


Al het bovenstaande voegt niets toe aan de beveiliging van sessies. Daarvoor moet je andere dingen doen. Zolang je enkel op een token vertrouwt voor authenticatie, is het te kapen. Zelfs als je PKCE toe voegt is dat niet per definitie veiliger, omdat je ook daar dingen lokaal op moet slaan en zowel in browsers als in native apps zijn er manieren om aan die gegevens te komen.

[Reactie gewijzigd door Werelds op 9 november 2024 10:30]

[MrFax]

Het gaat er toch om dat een pass the cookie attack niet uitgevoerd kan worden door forgery? Dat is wel te voorkomen door over te stappen van ouderwetse authenticatie cookies.

Als iemand bij je lokale cookie cache kan, dan is je device al gehackt op een andere manier.

[Reactie gewijzigd door MrFax op 9 november 2024 11:55]

[Werelds]

Het gaat er toch om dat een pass the cookie attack niet uitgevoerd kan worden door forgery? Dat is wel te voorkomen door over te stappen van ouderwetse authenticatie cookies.

Je mist het punt. Elke authenticatie methode moet je credential ergens opslaan. Ook met access/refresh tokens gebruik je gewoon localstorage/sessionstorage of de cookie equivalenten daarvan. Het verschil is dat cookies door de server uitgelezen kunnen worden zonder specifieke client-side code (en HttpOnly cookies niet via JS uitgelezen kunnen worden) waar dat met *storage wel nodig is, maar uiteindelijk moet de inhoud toch naar de server gestuurd worden. Als jij een manier hebt (phishing, injection) om een cookie uit te lezen, dan kun je op dat moment vrijwel zeker ook aan localstorage komen, wat cookies dus niet onveiliger maakt. Nogmaals: cookies zijn slechts een opslagmethode.

Ik weet dus niet wat jij met "ouderwetse authenticatie cookies" bedoelt. Het opslagmedium en de authenticatiemethode staan los van elkaar.

De enige manier om permanente opslag te voorkomen is door überhaupt geen langetermijn login sessies te hebben en alles enkel in de huidige sessie te houden en de gebruiker dus te forceren elke keer opnieuw in te loggen. Maar ook dan kun je als aanvaller aan de inhoud (tokens bijvoorbeeld) daarvan komen.

Als iemand bij je lokale cookie cache kan, dan is je device al gehackt op een andere manier.

Precies. En dat is dan ook wat hier gebeurd is. Ze zijn er via malware aan gekomen.

[Yongshi]

Mijn vraag ging enkel even over 2fa, maar dat staat dus inderdaad los van het stelen van cookies

[latka]

Zoek even op wat "stateless authentication" is. Dat is jusit geen traditionele cookie.

Ik leer graag, dus de 1e hit op google en dat is gewoon een cookie die je kunt stelen. Refreshen van een security token zonder 2fa stap ertuseen is ook niet heel veel veiliger als de aanvaller kort op de bal zit. Dus ik snap je verhaal niet helemaal. Maar ik leer graag, dus welk artikel over stateless authentication raad je aan waarbij het stelen van sessie cookies niet mogelijk is.

[Lucb1e]

Deze kan je zelfs in de TPM laten opslaan. Dan wordt het al heel lastig om de sessie te kapen.

Als de hacker er niet bij kan, hoe kan de browser er dan nog bij? Als je een linkje hebt over web-sessiedata in je TPM stoppen, dan zou ik zeer geïnteresseerd zijn!

De enige manier waarop ik me kan bedenken dat dit kán werken is dat je TPM (of vergelijkbare tech) een verzoek krijgt van de browser voor het signeren van een HTTP-request (of een hash daarvan) en daardoor het authenticatietoken zelf niet prijs hoeft te geven, maar ook dan kan een aanvaller elk HTTP-request doen wat xij wil (zolang die toegang blijft houden tot het systeem van het slachtoffer) door, net als de browser, de TPM te verzoeken om te signeren whatever xij wilt versturen. Dit is hoe het ook werkt met bijvoorbeeld een PGP-sleutel op een Yubikey, maar daar is het verkeersvolume laag genoeg dat je kan aanzetten dat je voor elke operatie de Yubikey moet aanraken, waardoor je doorhebt wanneer er gek veel verzoekjes gedaan worden. Het lijkt me daarnaast nogal traag (waarschijnlijk enkele milliseconden op z'n best? Voor élk HTTP-request hè) en het zou het uploaden van grote bestanden ook veel langzamer maken omdat je browser eerst het hele bestand door een hashalgoritme moet halen, dan laten signeren, en dan beginnen met uploaden. Ik heb van dit alles nog niks voorbij zien komen in HTTP specs, dus hoewel je dit natuurlijk custom bovenop je server kunt bouwen als politiedienst, twijfel ik dat dit bestaat als standaardfunctionaliteit die ze hadden kunnen gebruiken. En zelfs dan twijfel ik aan de voordelen gezien een aanvaller in de browser alles kan wat de browser ook kan

Kan het misschien zijn dat je een loginmethode als WebAuthn (wat wel met een hardwarefactor werkt) en authenticatietokens à la sessie-cookies door elkaar haalt? WebAuthn vervangt als het ware je gebruikersnaam en wachtwoord door een hardwaresleutel (zoals een TPM), maar uiteindelijk heb je alsnog een cookie-achtig iets nodig om je van pagina tot pagina (en resource tot resource) te authenticeren bij de webserver om het praktisch te houden

(Daarnaast twijfel ik aan de claims in deze reactie over de voordelen van niet-cookie-authenticatie, maar daar had ik al op gereageerd in een hogerliggende reactie)

[Reactie gewijzigd door Lucb1e op 9 november 2024 03:17]

[R4gnax]

Bij een gewone browser op je Windows-PC zitten er wel meer haken en ogen.

Ook niet meer. WebAuthN staat toe dat je koppelt met FIDO-compatible authenticators voor password-less login of 2FA. En Windows 10 en 11 hebben een virtuele FIDO authenticator ingebouwd zitten die als backing store de TPM kan gebruiken.

[mbbs1024]

Maar hoe komen die hackers dan aan een cookie dat voor iemand anders bestemd is ?

[Li0nHeart]

Dat is eigenlijk relatief simpel, dit doen ze door een Man-in-the Middle aanval. Hier is vrij briljante software voor te koop (EvilGinx bijvoorbeeld). Hiermee maak je mooie gelijkende pagina, waarop een slachtoffer kan inloggen. EvilGinx handelt het de hele inlog sequence met bv Microsoft af, inclusief 2FA. En slaat daarna het cookie op

Daarna moet een aanvaller alleen nog bijvoorbeeld een phishing campagne opzetten om slachtoffers naar zijn eigen inlogpagina te lokken. Maar aangezien het klikpercentage op phishing mails relatief best hoog is, is dat ook wel te doen. En je hebt maar 1 iemand nodig.

[computerjunky]

Ik heb al letterlijk 3 jaar hetzelfde ip adres voor thuis internet. Het lijkt wel een een ISP tegenwoordig gewoon een ip aan je account linkt voor de tijd van je contract.

[Room42]

Ik heb nu Odido Klik&Klaar en daarmee heb ik elke dag een nieuw IP.

[Lucb1e]

Kun je dan überhaupt nog portforwarden en een spelletje hosten zolang je in de chatgroep het nieuwe IP-adres post wanneer je wilt gaan spelen, of moet je daarvoor een server gaan huren ergens?

[Djerro123]

Je kan dan dynamic DNS gebruiken, maar je modem moet daar wel ondersteunen. KPN doet dat wel, odido weet ik niet.

[Christoxz]

Hoeft niet persee op je modem. Kan ook een app zijn ergens op een pc/server draait.

[scsirob]

Je kan ook bij Odido gebruik maken van een eigen modem die DDNS wel ondersteunt. Ik gebruikte een hardware pfSense firewall rechtstreeks op Odido glasvezel, DDNS werkte daarmee prima.

[Room42]

Dat kan wel. Ik zou inderdaad gewoon een no-ip.com hostname gebruiken, dan hoef je niet steeds een nieuw adres door te geven.

[robvh99]

Is odido niet carrier grade nat?
(waarbij je je ip met meerdere klanten deelt)
Of ben ik nu in de war met een andere provider

[Frame164]

Net als met je mobiele telefoon. Klik&klaar is immers gewoon een mobiele verbinding.

[renecl]

Dat lijkt me raar, tenzij je je router steeds uitzet.

[Room42]

Nope. Elke 24h. Lees meer in het forumtopic: [Odido Klik&Klaar - 5G vast internet] Ervaringen & Discussie.

[faim]

Voor mobiele netwerken heel vervelend als je cookie aan een IP hangt, om nog maar te zwijgen over wisselingen tussen IPv4 en IPv6.
Cookies zijn echter op andere manieren goed te beveiligen zodat ze niet gekaapt kunnen worden, maar blijkbaar was dat niet geïmplementeerd.

[latka]

Oh, op welke wijze krijg jij cookies waterdicht? Agent string vergelijken oid?

[faim]

Ik heb het over cookies kapen, een HttpOnly flag zorgt ervoor dat JavaScript niet bij de cookie kan, dit maakt het opvragen en doorsturen van een cookie op afstand onmogelijk.

[latka]

Cookies kapen via Javascript kan, maar het kan natuurlijk ook via een stuk malware die bij je C-schijf kan. Dat haal ik niet uit het originele stuk.

[Archcry]

Het artikel zoals ik hem las op nos.nl suggereert dat de cookie mogelijk gestolen is via een stukje malware. De politie heeft het probleem kunnen reproduceren.

Tweakers had dat wel iets explicieter naar voren mogen laten komen in dit artikel.

[Reactie gewijzigd door Archcry op 9 november 2024 09:34]

[batjes]

nvm

[Reactie gewijzigd door batjes op 9 november 2024 12:08]

[IJuanTM]

Mijn ISP vind het leuk om eens in de paar maanden mijn IP te wijzigen, wat betekend dat ik telkens alle configuratie voor mijn server moet updaten...

[thatent]

Welnee, je kunt toch voor een dynamische DNS-service gaan? Bijvoorbeeld van https://www.dynu.com/en-us/, maar er zijn vele anderen. Vaak gratis voor privégebruik.

[scsirob]

Dat lukt niet voor alles. Ik heb iets in Azure draaien waarbij de firewall rules alleen verkeer van één IP adres toelaten. DNS namen kan je niet ingeven in die firewall. Als mijn IP adres wisselt dan moet ik dat handmatig aanpassen. Natuurlijk kan je dat weer scripten, maar dat betekent weer een extra proces wat ergens moet draaien.

[thatent]

Fair enough, dat is een specifiek geval waarin dat wellicht niet werkt. Maar afhankelijk van hoe vaak je ip-adres verandert zou ik liever een scriptje hebben draaien dat binnen enkele seconden de boel automatisch aanpast, dan dat ik dit handmatig zou moeten doen en tijdelijk die services niet zouden werken. Zo'n scriptje gebruikt echt verwaarloosbaar weinig aan resources, zelfs op minimale hardware. Dat gezegd hebbende: ieder z'n ding!

[Accretion]

Ja, of een provider zoeken die niet je IP adres steeds aanpast.

[haam]

xs4all deed dat vroegah. Ik weet niet of Freedom dat ook nog doet

[keesdewit]

Cloudflare tunnels kan daar een mooie oplossing voor zijn

[_soh]

Gewoon je ISP bellen en zeggen dat je een vast IP wil. Was bij mij met 1 belletje geregeld.

[DukeBox]

Als je gewoon binnen het verstrijken van de lease renewed (en vaak ook enige tijd daarna) krijg je normaalgesproken het zelfde ip.

[Richh]

Voor vast internet wel, maar als je eenmaal op 5G zit is het natuurlijk al snel een ander verhaal
Om die reden is het niet echt een best practice om een cookie te koppelen aan een IP adres als het om webdevelopment gaat, het kan heel goed dat een IP wisselt tijdens een sessie.

Nu is het mij niet heel duidelijk wat voor software van de politie dit betrof, waarbij zo'n mobiele usecase mogelijk onwaarschijnlijker is.

[crazyboy01]

Die zijn al zolang ik me kan herinneren zo goed als statisch, meer betalen voor een écht dedicated IP doe je doorgaans enkel voor de garantie. Maar, heeel soms krijg ik zeer willekeurig toch opeens een nieuw IP-adres, midden in het jaar. En dit is ook niet in alle landen zoals het werkt, dat weinige wisselen van IP.

Maar, los van je thuisverbinding is het ook niet zo dat we alleen gebruik maken van het internet zoals we dat deden in 2004 door achter ons bureau te kruipen. Je wisselt ook op andere manieren van IP. We slepen onze laptops en telefoons de hele dag mee en wisselen daarbij continue tussen mobiele- en Wi-Fi netwerken waardoor je steeds met een ander IP gebruik maakt van een dienst. En toch hoef je niet iedere keer overal opnieuw in te loggen. Dat kan anders worden ingericht natuurlijk en ik zie dat op sommige plekken ook wel, maar voor de gemiddelde eindgebruiker is een vloeiende overgang wel het meest gebruiksvriendelijk. En zo zijn er bvb ook een boel mensen die standaard bij het surfen gebruik maken van VPN diensten waarbij ze geregeld van IP veranderen.

[computerjunky]

Ik heb nu 7 jaar glas maar bij ziggo was het gekoppeld aan het eerste mac adres achter de modem. Als je dus een nieuwe router kocht of het mac van je router veranderde kreeg je een nader IP geen idee of dat nog steeds het geval is.

[crazyboy01]

Ook mijn ervaring inderdaad, echter laatst van provider gewisseld (die achter de schermen beide een KPN verbinding leveren) en toen ik mijn nieuwe Experiabox modem aansloot kreeg deze gek genoeg hetzelfde IP-adres als het vorige modem van hetzelfde type (en alle instellingen werden overigens ook automatisch overgenomen). Ik stap jaarlijks over en voorheen betekende dat inderdaad, ook bij KPN, een ander IP-adres.

[ANdrode]

Helemaal icm IPv6.

Een goede monitoringtool zou wel kunnen volgen of sessies tussen ASN wisselen en of dit verwacht is.

Eigenlijk gek dat je bij login op een andere locatie een pushbericht krijgt maar bij sessie die verplaatst niet (en natuurlijk gebruiken competente aanvallers residential proxies)

[sygys]

De echte vraag is hoe kan een vrijwilliger bij de politie ingodsnaam bij die gegevens.

[Snow_King]

Dit was gewoon het adresboek uit Outlook, zo simpel was het. Daar kan je iedereen binnen die tenant bij Microsoft in vinden.

[telenut]

En zit daar meer in dan email naam telefoonnummer en werklocatie?

[Snow_King]

Je kan als medewerker zelf je profiel nog aanvullen met gegevens. Zoals een foto, je mobiele nummer, etc.

Deze hele 'hack' lijkt gewoon op een download van het adresboek uit Outlook.

[Davy de Vries]

Je zou wel verwachten als iemand zoveel privileges heeft, dat die gene wat vaker 2FA zou mogen krijgen om bepaalde acties te doen.

[RedDragon]

2fa gaat je niet redden als je de cookie al weet te bemachtingen.

Meer info zie:

https://blog.netwrix.com/...h-pass-the-cookie-attack/

[Reactie gewijzigd door RedDragon op 8 november 2024 21:37]

[Cyb]

Hoeft niet. Hangt af van de implementatie. Als je naast de cookie ook andere metrieken meeneemt, ben je niet je niet per se verloren als iemand een cookie in handen heeft.

[latka]

Metrieken zoals de browser agent? Het ip-adres? Het klik-gedrag van de gebruiker? Allemaal dingen die te faken zijn en als de aanvaller er van weet zeker gefaked zullen worden. Bind de login aan een SSL sessie en je bent een beetje op weg om het echt moeilijk te maken cookies te herbruiken.

[Lucb1e]

Oef, moet je je voorstellen dat je opnieuw moet inloggen elke keer dat je browser besluit een nieuwe TLS-sessie te openen. Marginaal veiliger is het wel, maar bruikbaar is anders! En de aanvaller krijgt duizend kansen om de inloggegevens af te vangen, of bij 2FA krijgt de aanvaller een regelmatige stroom van nieuwe tokens

Het ip-adres? Het klik-gedrag van de gebruiker? Allemaal dingen die te faken zijn en als de aanvaller er van weet zeker gefaked zullen worden.

IP-adres is niet te faken via TLS tenzij je een BGP-aanval doet omdat je anders de antwoorden niet ontvangt en dus de random waardes die de server toestuurt niet kan opvangen. (Sowieso is het via TCP al behoorlijk lastig omdat je een 32-bit counter moet bruteforcen voor één TCP-pakket van ~1500 bytes te kunnen versturen.) Je moet daadwerkelijk legitiem dat IP-adres hebben, of op het pad zitten tussen client en server door bijvoorbeeld zo'n BGP-aanval of het hacken van een (transit)provider.

Ik zie dus opzich wel het voordeel in de IP-controle omdat de aanvaller dan toegang verliest zodra de exploit stopt met werken of ze van het netwerkpad gekickt worden, wat dus minder stabiel is (voor de aanvaller) dan wanneer xij alle benodigde informatie lokaal heeft staan. Het voordeel is echter redelijk marginaal want sessiecookies stelen komt naar mijn weten bijzonder weinig voor, of ja, het wordt gefaciliteerd door andere aanvallen zoals malware op het systeem weten te krijgen die de browserstate uitlezen of een XSS-kwetsbaarheid in de applicatie vinden waardoor je een zwak-beveiliged (niet-HttpOnly) cookie eruit kan vissen. In plaats van cookievissen kun je dan ook gewoon JS in de pagina injecteren die de HTTP-requests doet die je als aanvaller wilt doen. Beter dus dat je gewoon die basisdingen oplost in plaats van dergelijke pleisters plakt (bijv. XSS kom ik in React-applicaties nauwelijks nog tegen; het is dus op te lossen door de manier van programmeren zelf veiliger te maken)

[Reactie gewijzigd door Lucb1e op 9 november 2024 03:42]

[Rolfie]

Je IP address kan heel gemakkelijk veranderen. Meerdere keren per dag bijvoorbeeld.

Maar hangt er vanaf welke techniek gebruikt wordt. Bij buitenlandse ISP kan bijvoorbeeld dagelijks je IP veranderen.
Zscaler of umbrella technieken, ik heb gerust meerdaags dat van mijn werk, mijn externe IP veranderd.

[ANdrode]

IPv6 privacy extensions. Meerdere keren per dag.

NAT64 van je provider (zoals KPN doet). Per TCP sessie mogelijk een ander IP. Ze proberen wel sticky te zijn.

Maar kom je bij een ander IP van een CDN uit? Jouw sessie komt dan vanaf een ander IP.

[emphy]

> 2fa gaat je niet redden als je de cookie al weet te bemachtingen.

Bepaalde implementaties zijn echter wel gevoeliger voor koekjes-kapers. Extra 2fa verificaties gedurende de sessie zorgen ervoor dat de aanvaller meerdere malen zo een koekje moet bemachtigen.

Helemaal lastig wordt het als de 2fa dan ook nog eens afhankelijk is van de handeling zelf. Bij sommige banken (waarvan de naam niet begint met een "b"), bijvoorbeeld, is dat zo goed geregeld dat de bedriegers het niet eens meer proberen, maar zich meer richten op het overtuigen van het slachtoffer om zelf geld over te boeken.

[Reactie gewijzigd door emphy op 9 november 2024 05:53]

[Cyb]

Nee, gelukkig niet, anders zou ik om de haverklap opnieuw op Tweakers moet inloggen.

Het is een afweging tussen usability en security. I.p.v. je te beperken tot een IP adres kan je ook andere metrieken gebruiken om usability te verhogen, bijv. ASN, geo locatie, browser info, enz.

[MrFax]

Voor een hele lange tijd kon je je sessie aan je IP-adres vastbinden. Dat moest je dan wel aanvinken, maar het was er wel... Natuurlijk is dat weggehaald omdat het meeste nu mobiel gebeurd.

[Reactie gewijzigd door MrFax op 8 november 2024 21:44]

[emphy]

Nee, gelukkig niet, anders zou ik om de haverklap opnieuw op Tweakers moet inloggen.

Het is een afweging tussen usability en security. I.p.v. je te beperken tot een IP adres kan je ook andere metrieken gebruiken om usability te verhogen, bijv. ASN, geo locatie, browser info, enz.

Nu is een tweakers-account ook wel een iets minder sappig doelwit dan de politie, met een gebruikersprofiel waarbij minder voorspelbare ip adressen te verwachten zijn.

[berchtold]

Er zijn idd detectie mogelijkheden zoals vreemde IP adressen detecteren. Maar idk wat de politie heeft aan implementatie. Kan best zijn dat het bij hun niet op orde is op sommige stukken. Er zijn ook wat secure cookie settings die het een en ander tegen kunnen houden. Vraag me vooral af hoe ze bij de cookie zelf gekomen zijn. Kan nog steeds van alles zijn. Malware, XSS, packet sniffing (http) of gwn social engineering

[xbeam]

Het is wat ik van de kenners ik het veld hoor mamba 2fa geweest.

https://www.bleepingcompu...s-microsoft-365-accounts/

First found: en uitwerking hoe het onze werk gaat.
https://any.run/cybersecu...of-the-phishing-campaign/


How to protect your self
https://potsolutions.net/...-for-microsoft-365-teams/

[Reactie gewijzigd door xbeam op 9 november 2024 06:23]

[mutsje]

Als ze Microsoft MFA gebruiken dan is het heel eenvoudig te spoofen om een cookie session te kapen. Er staan meerdere youtube filmpjes hoe het werkt. Ze bouwen de website tot in detail na en jij logt gewoon in zonder te controleren. Hierna heeft de hacker je cookie en kan die doen en laten wat die wil. Er is nog geen oplossing hiervoor zover mij bekend is.

[tim_md]

Een oplossing hiervoor is gebruik maken van een Yubikey FIDO2 hardware security key. Ik gebruik het voor Microsoft, Google , X en andere omgevingen. Yubikey FIDO2 / PIV zijn phishing resistant MFA.

Ik gebruik 3 Yubikeys ( 1 actief gebruikte key voor in de PC / android etc en 2 backup hardware keys )

[Reactie gewijzigd door tim_md op 8 november 2024 23:29]

[R.van.M]

Hoe verhelpt dat het probleem van het cookie stelen?

[tim_md]

Lees dit eens door op je gemak. Er staan op YT veel video's over dit onderwerp.
https://www.yubico.com/re...y/phishing-resistant-mfa/

Yubikey Hardware security key's zijn niet goedkoop , maar better safer than sorry.

Bekend voorbeeld van Linus Tech Tips session cookies hack.
https://www.theverge.com/...ken-elon-musk-crypto-scam

[Reactie gewijzigd door tim_md op 9 november 2024 00:05]

[Lucb1e]

Phishing-resistent-MFA ben ik bekend mee, kortgezegd checkt dat het domein (zoals Firefox diens ingebouwde wachtwoordmanager sinds jaar en dag al doet), maar dat beveiligt het inlogproces en niet wanneer je al op het punt bent waarbij je bent ingelogd en de aanvaller je browserstate (de cookies) meeneemt op de een of andere manier

Uit de LTT link:

this [document] actually included malware that accessed “all user data from both their installed browsers” — including session tokens — which effectively gave the bad actor “an exact copy” of the browsers

Dus daar gaat je cookie.

Deze links beantwoorden de vraag niet. Ik denk dat je mogelijk door de war haalt dat je hiermee het stelen van inloggegevens vermindert maar niet de herkenningstokens (die met elk HTTP-request moeten worden meegestuurd omdat HTTP op zichzelf stateless is)

[Reactie gewijzigd door Lucb1e op 9 november 2024 04:07]

[mutsje]

Ik denk niet dat de politie yubikeys heeft lopen uitdelen aan hun personeel maar je hebt een goed punt.

[banaj]

https://github.com/kgretzky/evilginx2

[wesleey]

Als aanvulling hierop, een playbookscenario dat hiervan gebruikmaakt in combinatie met Office 365: https://janbakker.tech/ho...h-office-365-credentials/

Dit betreft ook net als bij de politie een exchange omgeving waarin data uit de Global Address List is gehaald.

Een van de oplossingen van Microsoft:

Token Protection for sign-in sessions:

https://techcommunity.mic...-sign-in-sessions/3815756

[deadinspace]

Als ze Microsoft MFA gebruiken dan is het heel eenvoudig te spoofen om een cookie session te kapen. Er staan meerdere youtube filmpjes hoe het werkt. Ze bouwen de website tot in detail na en jij logt gewoon in zonder te controleren.

Dat is toch gewoon standaard wachtwoord phishing, en dus niet een session cookie stelen?

Of begrijp ik je uitleg verkeerd?

[xbeam]

Klopt gebruikte techniek was ook Mamba 2fa
https://any.run/cybersecu...of-the-phishing-campaign/

[ibmpc]

Als je met Entra P2 Token Protection gebruikt, mitigeer je dan deze specifieke hack?

[mcchicken]

Volgens mij kom je met P1 al een heel eind door compliant of managed devices in CA af te dwingen. De cookies komen waarschijnlijk namelijk ineens van een ander device. Dit scenario met Evilginx zelf al eens getest.

[ibmpc]

Ik kom met Evilginx al niet eens meer door device compliance heen. Met P2 kun je wel een authentication strength instellen, en dan kom ik er ook niet meer doorheen met Evilginx. Ik mag toch hopen dat overheidsinstellingen minimaal device compliance hebben

[telenut]

Wil dit aan het management verkocht krijgen. Hoe ga ik best te werk? :-)

[ibmpc]

Hier is alles te vinden:
forumtopic: Microsoft Intune ervaringentopic

En als je echt vanaf scratch moet beginnen zonder basiskennis dan zijn er veel baselines die je gratis kunt gebruiken. De Australische overheid (Google) heeft een Intune baseline beschikbaar gesteld die redelijk oke is, maar vooral goed wordt uitgelegd.

[Reactie gewijzigd door ibmpc op 11 november 2024 17:49]

[telenut]

thx, maar ik bedoelde specifiek: een demo van hoe onveilig het is om toestellen die niet 'compliant' zijn toe te staan...
Intune hebben we al draaien, maar van thuis uit kunnen mensen met elke pc/smartphone wel aan hun email

[ibmpc]

Opzich is dat niet heel moeilijk. Je zet een Evilginx as a Service op en je laat mensen inloggen. Ik zet vaak live malware sites in tijdens presentaties die ik op dat moment ken, omdat sommigen al direct beginnen met inloggen zodra ze credentials hebben. Sommigen wachten een paar dagen. Ik gebruik er drie soorten accounts voor. 1) met MFA, 2) met Device Compliance, 3) met Windows Hello als minimum strength. De eerste wordt eigenlijk altijd succesvol overgenomen, de andere twee falen vooralsnog altijd.

[kokx]

Token Protection werkt alleen op managed devices (specifiek Entra joined devices). Dus dan zou het beheer van alle apparaten van de gebruikers door de Politie gedaan moeten worden in dit geval.

Eerder was echter bericht dat de initiële toegang via een vrijwilliger van de politie verliep. Waarschijnlijk hebben deze vrijwilligers geen apparaat van de Politie, maar wel een email van de Politie, die ze dan via een eigen apparaat uitlezen.

[ibmpc]

Op Entra Registered (BYOD) devices kan een Authentication Strength worden afgedwongen tegen phishing. Opzich kun je prima veilig toegang verlenen tot bijv. Windows 365 vanaf persoonlijke devices, zonder de devices daadwerkelijk te beheren.

[Tmaster]

Ik vermoed dat het hier gaat om een Citrix portaal cookie. Ik heb deze 'truuk' toevallige enkele weken geleden getest met een collega. Wij gebruiken Citrix xendesktop waarbij je via een Citrix netscaler met gateway inlogd op de Citrix storefront.
Persoon gaat via zijn laptop of pc naar zij Citrix portaal. Werkplek,bedrijfsnaam.nl
Daar geef je je gebruikersnaam je wachtwoord en je token in (wij gebruiken rsa token) vervolgens wordt je geauthenticeerd en kom je op een Citrix portaal waar je of applicaties kan publiceren of virtual machines bv een Windows 11 werkplek (vdi)
Op het moment dat je je vdi werkplek aanklikt download je pc een Ica bestand en als je die opent ga je eigenlijk via een soort vpn tunnel naar je werkplek vdi. De portal waar je net bent ingelogd logt dan automatisch weer uit.(Je sessie wordt beëindigd en je cookie wordt verwijderd) En hier zit dus de crux. Nadat je op de portal bent ingelogd staat er een cookie met jouw sta ticket in je browser. Als je dit cookie aan iemand geeft op een andere pc en die gaat vervolgens naar werkplek.bedrijsnaam.nl dan komt ie meteen,zonder authenticatie, ingelogd en wel op die Citrix portaal terecht met de inlog gegevens van de andere persoon. Hij//zij kan dan ook die Ica file downloaden en die werkplek openen! Het is dus zeer belangrijk om een zeer korte timeout te zetten op die eerste Citrix portaal na inlog. Ik vraag mij af hoe lang de timeout ingesteld stond bij politie.

[Reactie gewijzigd door Tmaster op 9 november 2024 00:18]

[3DDude]

Die time-out staat heel laag. dat is echt 2 minuten ofzo.
Dan moet ik al opnieuw inloggen en is die STA / ICA ticket ongeldig.


Ik verwacht dat het eerder Teams / Session cookie is geweest; van eens in de 3 maanden MFA gebruiken naar nu elke dag zal wel een reden hebben.

[Lucb1e]

Als ik het kort samenvat, gaat het om je cookie dat jouw browser krijgt van de Citrix-server op het moment dat je inlogt, en dat geldig is tot het moment dat je een server kiest om mee te verbinden. Zeg ik het dan goed?

In dat geval, met welke website zou dit niet zo werken? Hoe moet een website anders herkennen dat jij het bent bij het volgende HTTP-request als er geen state in de browser opgeslagen is waarmee het die authenticering kan doen? Dezelfde "truc" kun je uithalen bij Tweakers, mijn website, en elke andere website (soms moet je eventueel ook localStorage meekopiëren, of soms is het alleen een JavaScript-state en heb je geen opslag, maar ook dan staat èrgens een variabele ingesteld die dan in een HTTP-veld terecht komt en dus een vergelijkbaar mechanisme gebruikt)

[xbeam]

Nee. Outlook cookie

Wat ik van de kenners dicht bij het vuur begrepen gaat hem ook de ManBa 2fa

https://any.run/cybersecu...of-the-phishing-campaign/

https://www.bleepingcompu...s-microsoft-365-accounts/

[Reactie gewijzigd door xbeam op 9 november 2024 14:29]

[Scriptkid]

Wacht even je oath token zit toch niet in je cookie?

Dat zijn toch totaal andere params.

Cookies zitten in de header en je token zit in de payload ? Ben toevallig deze week oauth flows aan het programeren en alles doe ik encrypten behalve cookies want met alleen cookie komt je nergens en geeft de server auth fails.

Andersom met alleen oauth tokens en geen cookies kom je wel binnen.

Of wordt hier voor het gemak de naamgeving op 1 hoop gegoi?

[Werelds]

Nee, jij verwart hier juist dingen.

De OAuth tokens die jij genereert moet je client-side ergens op slaan. En een cookie is dan één van de methodes. Dat is niet meer of minder onveilig dan localstorage gebruiken als je er HttpOnly cookies van maakt.

[Scriptkid]

Ahh dus na ontvangs maakt je er zelf een local cookie van.

[Werelds]

Juist. Er wordt hier veelal te veel gefocust op het feit dat het om cookies ging, maar cookies zelf doen geen reet. En een HttpOnly + Secure cookie is eigenlijk veiliger dan een token in localstorage opslaan, omdat je er veel lastiger aan kunt komen via de browser zelf. Met externe malware maakt het geen reet uit, dan kom je toch overal aan.

[kimborntobewild]

Raar dat een vrijwilliger zoveel rechten heeft. Ook raar dat zelfs de politie zijn inlogmethodes niet goed heeft beveiligd. Of misschien is dat toch niet zo raar: in het bedrijfsleven kunnen beveiligingsexperts waarschijnlijk meer verdienen, dus moet de politie het doen met personeel met mindere capaciteiten.

[Frame164]

Vandaar dat er ook zoveel bedrijven gehackt worden....

[xbeam]

Omdat politie vrijwilligers gewoon 100% politie beëdigde agenten of rechercheurs zijn. Juridisch is ook geen verschil alleen word de vrijwilliger niet betaald.

[Reactie gewijzigd door xbeam op 9 november 2024 14:35]

[kimborntobewild]

Omdat politie vrijwilligers gewoon 100% politie beëdigde agenten of rechercheurs zijn. Juridisch is ook geen verschil alleen word de vrijwilliger niet betaald.

Het lijkt me dat er juridisch gezien wel verschil is, al was het maar omdat je van een vrijwilliger het loon niet kunt afpakken (door hem te ontslaan).
Zelfs voor een normale beëdigde agent of rechercheur vind ik het vreemd dat die bij zoveel gegevens kan.

[FrostyPeet]

Tja, gestolen cookies en niet controleren op active dual login sessies...

[Thc_Nbl]

Echt he.. hoe moeilijk is het om gewoon je cookies te verwijderen bij sluiten van je browser..

[ebras]

Nog een gelukje dat we niets hebben te verbergen.