Criminelen claimen beveiliging tegen cookiediefstal in Chrome te kunnen omzeilen

Cybercriminelen claimen dat ze een nieuwe beveiligingsmaatregel in Google Chrome die het stelen van cookies moet tegengaan, kunnen omzeilen. Google zegt op de hoogte te zijn van de nieuwe aanvallen die dit mogelijk maken.

Google introduceerde eind juli het zogenaamde Application-Bound Encryption in Chrome 127 voor Windows. Daarmee kan Chrome cookies en opgeslagen wachtwoorden versleutelen aan de hand van een Windows-dienst die met systeemprivileges draait. Dergelijke data wordt op zo'n manier versleuteld dat de encryptie gekoppeld is aan de appidentiteit, vergelijkbaar met hoe de Keychain op macOS werkt.

Application-Bound Encryption voorkomt dat infostealermalware ingezet kan worden om cookies en wachtwoorden die in de Chrome-browser zijn opgeslagen te stelen. Om die data toch te stelen, zou malware systeemprivileges moeten hebben of code moeten injecteren in Chrome. Volgens Google zijn dat echter acties die waarschijnlijk worden gedetecteerd door beveiligingstools.

Toch zijn er al makers van infostealermalware die zeggen dat ze de beveiliging kunnen omzeilen, melden beveiligingsonderzoekers g0njxa en RussianPanda9xx op X. Het gaat onder meer om Lumma Stealer, MeduzaStealer en Whitesnake. De onderzoekers zeggen tegenover BleepingComputer dat ze de claims van Lumma Stealer, Vidar en Lumma geverifieerd hebben en deze malwarevarianten inderdaad cookies uit Chrome kunnen stelen op Windows, ondanks Application-Bound Encryption.

Hoe de cybercriminelen de beveiliging van Chrome precies weten te omzeilen, is niet bekendgemaakt. De makers van malware genaamd Rhadamanthys stellen echter dat het hen slechts tien minuten kostte om de versleuteling van data terug te draaien. Google zelf zegt tegenover BleepingComputer dat het bedrijf op de hoogte is van de ontwikkelingen en dat het met partners werkt aan manieren om deze aanvallen goed te detecteren.

Reacties (35)

[grasmanek94]

Als ik het plaatje bekijk dan ben ik benieuwd hoe het onder de motorkap is geïmplementeerd..

Voor zover ik weet kan je op Windows gewoon memory van andere apps uitlezen die op hetzelfde account met hetzelfde of lager privilege en integrity niveau draaien.. en rara, Chrome en Malware draaien als normale non-admin user met medium integrity (standaard), en Chrome dropt ook nog tokens voor sandboxed processen zodat deze dus met lagere privileges draaien.

Ik vind het artikel van Google een beetje te kort door de bocht.

Oh en niet alleen kan je memory uitlezen maar ook debuggen en schrijven bij hetzelfde of lager veiligheid executieniveau (alleen dat kan je soms wel detecteren in een proces, maar soms ook niet).

Weet iemand hoe het onder de motorkap werkt?
Want voor mij oogt het gewoon als een security through obscurity mechanisme.

[Reactie gewijzigd door grasmanek94 op 26 september 2024 08:09]

[kdekker]

Buiten je eigen proces mag en kun je niet lezen, anders dan door een gemeenschappelijke noemer, bijv. kernel modules (waarmee je communiceert) of file systeem. Dat is hoe Windows memory mapping in de kernel doet. Hoe dat precies verhoud in chrome (die ook eigen procesbeheer doet) weet ik niet.

Het woord app is daarom een beetje te weinig zeggend, omdat daarmee het verschil tussen (in-process) plug-in en los proces weg is.

[grasmanek94]

Buiten je eigen proces mag en kun je niet lezen, anders dan door een gemeenschappelijke noemer, bijv. kernel modules (waarmee je communiceert) of file systeem. Dat is hoe Windows memory mapping in de kernel doet.

Grootste onzin ooit, iedereen kan gewoon een debuger koppelen aan / OpenProcess aanroepen op een bestaand proces en daar ReadProcessMemory/WriteProcessMemory op aanroepen zolang het ander proces van gelijke of lagere security context is voorzien.
Compileer eens een simpele executable met die calls die bijvoorbeeld naar een notepad proces attached, misschien zul je wel verbaasd zijn over de resultaten.

Meer info hier: https://learn.microsoft.c...ecurity-and-access-rights

Wil je geen code schrijven hier: https://www.codeproject.c...-another-process-s-memory

Op Linux gebaseerde systemen is het niet zo simpel als op Windows, maar ook niet onmogelijk.

Zie bijvoorbeeld https://serverfault.com/q...x-processs-memory-to-file , geen root nodig.

Op Android draait elk process / app weer als een andere gebruiker, en dat is dus niet hetzelfde security context, ofwel van elkaar geïsoleerd en daar moeten wel standaard communicatiekanalen via kernel/zygote daemon gebruikt worden.

[Reactie gewijzigd door grasmanek94 op 26 september 2024 13:34]

[kdekker]

Een debugger draait met hogere rechten dus die mag meer. En je mag alleen maar attachen naar processen jezelf. Dat is dus nog niet hetzelfde als dat proces x zomaar rond kan neuzen bij proces y.

En je kunt inderdaad geheugen bekijken, maar daar kun je weinig mee als bijv randomization voor adres spaces aan staan.

[Reactie gewijzigd door kdekker op 26 september 2024 18:44]

[grasmanek94]

Een debugger draait niet met hogere rechten, tenzij door de gebruiker expliciet toegewezen (run as admin / sudo / root / setguid bit / debugging via privileged service). Een debugger kan prima zonder deze rechten draaien zolang de rest hiervoor geconfigureerd is (wat het out of the box is op Windows en Debian) en naar een process verbind dat in hetzelfde of lager security context draait.
Elke app kan gewoon debugging functies aanroepen. Het systeem/kernel doet de security checks en kijkt of een app die debug functies mag aanroepen (strace, Open/Read/WriteProcessMemory, etc.).

Stop aub met onzin verspreiden.

Hooguit bij een fysieke debugger zoals een J-LINK or MCU-LINK of SWDIO debugger die fysiek verbonden zit aan een debug header, of een kernel-level-debugger vanuit een externe machine, dat die meer rechten heeft, maar een embedded systeem is zelden voorzien van rechten management (behalve misschien a'la iets als een secure execution environment die is gescheiden van normale cores).

Kernel level debugging staat voor zover ik weet in geen enkele release branch van Windows of Debian standaard aan, dus daar hoeven we het niet over te hebben want geen malware gaat dat kunnen gebruiken (en al helemaal niet zonder admin/root rechten).

Het context hierin is, wat kan een normale app zonder admin/root access, en dat is best veel op Windows en Debian (nogmaals, out-of-the-box clean install).

[Reactie gewijzigd door grasmanek94 op 26 september 2024 19:32]

[kdekker]

Wil je zelf ook even stoppen met onzin en graag een iets normalere toon aanslaan. Ik snap al eigenlijk niet waarom ik reageer, maar goed, je vertelt ook dingen die niet kloppen. Hopelijk heeft iemand anders er wat aan.

Op Windows heb je geen setui, setguid, s-bit of andere Linux (of beter: UNIX) achtige zaken. Dus haal er geen dingen bij die niet kloppen. Het artikel over Chrome gaat over Windows.

Zoals ik al eerder zei: een app is zo'n breed woord, dat je daar geen verschil kan zien tussen webapps, .net, native Win32 etc. En we hebben het hier ook niet over embedded systemen. Houd het svp on-topic. Dus Windows. En mijn context was: native Win32 programma's.

En ja: daar kun met ReadProcessMemory een ander proces lezen, maar daar heb je werkelijk niets aan. In een bittenbak kun je nauwelijks iets doen. En ook ja: hackers kunnen daar soms wel wat.

De debugger is een verhaal apart, daar Microsoft met z'n (remote) debugger (ook voor lokaal debuggen is dat ding 'remote') van alles kan doen (en het is Microsoft, die ook ongedocumenteerde hooks van Windows kan gebruiken). Het msvsmon.exe proces draait als normale user, maar ik weet niet hoe ze het doen, maar je kunt ook naar een ander account switchen + attachen aan elevated processen. Dus daar heeft Microsoft dingen, die wellicht ook uitgebuit kunnen worden door hackers.

Maar hoewel bovenstaande leuke info is, ik weet niet of dit in de Chrome context relevant is. Zoals ik al zei: Chrome heeft zijn eigen scheduler (wat ook andere chrome.exe processen zijn), waar die processen prima met elkaar kunnen communiceren (wat ze ook doen), want Google is de auteur van de code.

Je hebt gelijk dat je best wat kunt zien, maar of dat veel is c.q. nuttig is, dat is, zelfs al heb je de debug symbols en alles van Chrome, dan nog is met ASLR wat op welk adres staat random (de R uit ASLR) en dus zomaar geheugen bekijken is geen receptenboek. Of roman waar je direct de cookies uit kunt vissen. Je reactie suggereert dat het makkelijk is om het te doen. En spreek ik tegen. Niet meer en niet minder.

Ik vergiste me wel dat je zomaar een adress space van een ander proces kunt lezen. Dat kan inderdaad wel. Met nog wat mitsen en maren, zoals ook op MSDN staat bij ReadProcessMemory: The entire area to be read must be accessible, and if it is not accessible, the function fails. Wanneer iets accessible is, dat heb ik niet paraat (daarvoor doe ik het te weinig).

[cibrhusk]

Ik heb de oplossingen bij je link naar serverfault allemaal even bekeken en doorgeklikt naar de bronnen en zover ik zie hebben ze uiteindelijk allemaal root nodig voor het echte werk (en zijn (vrijwel?) allemaal afhankelijk van gdb). Met genoeg rechten is het natuurlijk logisch dat zoiets kan.
Maar als ik daarin iets gemist heb, voel je vrij om het even aan te wijzen ;-)

Een goed afgeconfigureerde SELinux zal ook wel de nodige barieres moeten opwerpen.

[Reactie gewijzigd door cibrhusk op 26 september 2024 15:39]

[grasmanek94]

Ik weet niet op welke Windows versie of Linux distributies jij test, maar wat je beweert komt gewoon niet overeen met Windows 7, Windows 10, Windows 11 en Debian 12 (allemaal out-of-the-box experience). Voor OpenProcess, ReadProcessMemory en WriteProcessMemory / gdb -p <pid> geen admin/root rechten nodig voor processen die in hetzelfde security context zitten.

rafal@GXTRD:~$ ls
Desktop Documents Downloads Music Pictures Public Templates Videos thinclient_drives
rafal@GXTRD:~$ nano xxx.txt &
[1] 378
rafal@GXTRD:~$ gcore -a 378
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGTTOU, Stopped (tty output).
0x00007fd425d7028b in tcsetattr () from /lib/x86_64-linux-gnu/libc.so.6
warning: target file /proc/378/cmdline contained unexpected null characters
Saved corefile core.378
[Inferior 1 (process 378) detached]

[1]+ Stopped nano xxx.txt
rafal@GXTRD:~$ xxd core.378 | head
00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000 .ELF............
00000010: 0400 3e00 0100 0000 0000 0000 0000 0000 ..>.............
00000020: 4000 0000 0000 0000 6043 1300 0000 0000 @.......`C......
00000030: 0000 0000 4000 3800 1700 4000 1900 1800 ....@.8...@.....
00000040: 0400 0000 0400 0000 4815 1300 0000 0000 ........H.......
00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060: 002e 0000 0000 0000 0000 0000 0000 0000 ................
00000070: 0100 0000 0000 0000 0100 0000 0400 0000 ................
00000080: 4805 0000 0000 0000 0040 83e3 8f55 0000 H........@...U..
00000090: 0000 0000 0000 0000 0050 0000 0000 0000 .........P......
rafal@GXTRD:~$ whoami
rafal
rafal@GXTRD:~$ kill -9 378
rafal@GXTRD:~$
[1]+ Killed nano xxx.txt
rafal@GXTRD:~$ kill -9 378
-bash: kill: (378) - No such process
rafal@GXTRD:~$ which gcore
/usr/bin/gcore
rafal@GXTRD:~$ ls -al $(which gcore)
-rwxr-xr-x 1 root root 3511 May 13 2023 /usr/bin/gcore
rafal@GXTRD:~$ which gdb
/usr/bin/gdb
rafal@GXTRD:~$ ls -al $(which gdb)
-rwxr-xr-x 1 root root 10395104 May 13 2023 /usr/bin/gdb
rafal@GXTRD:~$

Bovenstaand laat gewoon de memory contents van een process dumpen. Chromium kan gezien worden als nano, en gcore als Malware.
gcore is gewoon gdb met een schil, en met gdb kan je ook gewoon schrijven naar memory. gcore heeft geen setguid bit, dus draait zeker niet als root. GDB idem.

En als we het over Windows hebben, je beweringen met een out-of-the-box experience zul je niet waar kunnen maken.

Op Linux distributies met AppArmor/SELinux met `deny_ptrace 1` als standaard (bij vele sinds 2012) zal dit inderdaad niet werken en zouden je beweringen kloppen.

[Reactie gewijzigd door grasmanek94 op 26 september 2024 19:24]

[cibrhusk]

ik weet niet waar jij leest dat ik iets beweer en ik heb helemaal niets over Windows geschreven, ik schrijf niet voor niets 'bij je link naar serverfault', dat is omdat ik je qua Windows sowieso niet tegenspreek.

Qua Linux spreek ik je er enkel op aan dat alle zover ik zie oplossingen genoemd in je link naar serverfauilt uiteindelijk een sudo gdb gebruiken, inclusief de Linux variant van sysinternals procdump.

Je communicatiestijl naar anderen vind ik verder erg aanvallend dus laat ik het hierbij houden.

[GertMenkel]

Ik heb er nog niet diep naar gekeken, maar de broncode staat hier. Lijkt me met een paar gehookte functies niet heel moeilijk om om die beperkingen heen te komen, maar een expert zal vast binnenkort een keer een artikel uitschrijven met hoe het echt werkt.

Het idee zelf is natuurlijk valide: zet je geheimen op een plek waar niemand anders bij kan zonder kernel-mode of hogere rechten, valideer iedereen die met je service communiceert, en geef alleen de broodnodige informatie weg. Dit is niet makkelijk te bouwen, maar dit is bijvoorbeeld ook hoe password-managers op Android en iOS werken, met als kanttekening dat het daarop ook grotendeels de sandbox tussen applicaties is die ongein voorkomt.

[wooha]

Mijn Windows kennis is erg roestig en C++ heb ik indertijd niet gebruikt. Wel C met DCOM. Desalniettemin is onderstaande misschien nuttig.

De os_crypt code doet vanuit DecryptAppBoundString in app_bound_encryption_win.cc een COM aanroep naar DecryptData in de elevation_service. Die service draait in een apart proces, als het goed is met SYSTEM privilege. De code daarvan staat op een andere plek in de source tree.

In elevator.cc staat Elevator::DecryptData die als enige input parameter een ciphertext mee krijgt. Die doet een CryptUnprotectData als zichzelf (SYSTEM) en op het resultaat daarvan een tweede CryptUnprotectData als de gebruiker waaronder Chrome draait (COM impersonation van de caller). Het resultaat wordt in tweeën gesplitst. Het eerste stuk wordt gebruikt om de COM caller te valideren (validation_data). Het tweede stuk is de opgevraagde plain text en wordt als output van de DecryptData aanroep gebruikt als de validatie slaagt.

De validatie gebeurt op basis van het aanroepende process en de validation_data in ValidateData in caller_validation.cc. De eerste byte hiervan bepaalt het soort validatie (NONE, PATH_VALIDATION of anders faalt de validatie). Normaal zal het PATH_VALIDATION zijn.

PATH_VALIDATION bepaalt het path van de executable van het process, controleert dat dat geen netwerk path is en uiteindelijk of dat path hetzelfde is als in de validation_data (na de eerste byte voor de 'soort') staat. Hiervoor wordt QueryFullProcessImageNameW gebruikt met dwFlags 0, wat Win32 path format inhoudt. Volgens mij begint dat dus met een drive letter en is het geen NT path zonder drive letters.

Als dat allemaal vrij van bugs is, dan zou je de plain text dus alleen kunnen verkrijgen door:

• Als SYSTEM te draaien, of
• De aanroep vanuit Chrome te doen, of
• De aanroep vanuit een andere executable te doen die hetzelfde executable path gebruikt, bijvoorbeeld door de Chrome executable even opzij te schuiven

Wie weet is er iets met het executable path te knoeien. Anders zie ik het probleem niet echt.

[Reactie gewijzigd door wooha op 27 september 2024 02:54]

[GertMenkel]

Dankjewel! Ik mag helaas geen plusjes uitdelen op reacties van mijn eigen berichten.

Dat laatste punt is wel iets onhandigs, maar ik kan me voorstellen dat daar nog wat aan gedaan kan worden (bijvoorbeeld een signature check op de executable en ingeladen DLL's, want die zou een proces met SYSTEM moeten kunnen vinden).

[wooha]

Het probleem met zo'n signature check is dat de data dan niet meer te ontsleutelen is na een update van Chrome. Je moet dan tijdens de upgrade beide versies van Chrome draaien om al je encrypted data om te zetten. Je kan dan geen controle op het volledige path van de executable meer doen maar dat is niet nodig als je in jouw voorbeeld alle geladen code in het process meeneemt in de validatie.

Maar hetzelfde probleem van niet meer kunnen ontsleutelen geldt in die situatie ook na een upgrade van OS DLL's. Die moet je dan weer uitsluiten.

Een controle op de signer van de executable is dan handiger. Die is uiteindelijk verantwoordelijk voor wat er geladen wordt.

Hoe dan ook ligt de grootste attack surface in Chrome zelf. Misschien gebruiken ze DLL sideloading of andere code die onder controle van de gebruiker in te laden is. Native code plugins of COM objecten of zoiets.

Hm. @grasmanek94 had het over debuggers. Ze kunnen natuurlijk Chrome laden en code in het process toevoegen die hetzelfde doet als de os_crypt code of de os_crypt code rechtstreeks aanroept. Als Chrome zich niet tegen zo'n debugger aanpak beschermt, dan helpt natuurlijk niets meer. Wat @grasmanek94 al schreef: Obscurity.

Mijn Windows kennis is roestig, maar je zal inmiddels toch wel een bitje in een binary kunnen zetten voor een opt-out van toegang vanuit andere processen?

Edit: verwijzing naar @grasmanek94 in plaats van @GertMenkel .
Edit: suggestie voor controle op signer van executable toegevoegd.

[Reactie gewijzigd door wooha op 27 september 2024 13:50]

[MiesvanderLippe]

Tsja. Leuke poging maar iets dat als gebruiker moet draaien beschermen tegen malware die als gebruiker draait is een lastige taak. Het is een schande dat Microsoft hun secrets API niet gewoon fixt. Of naar de historie van Microsoft; geen extra secrets API introduceert...

[The Zep Man]

Tsja. Leuke poging maar iets dat als gebruiker moet draaien beschermen tegen malware die als gebruiker draait is een lastige taak.

Je kan bijvoorbeeld verplichte sandboxing implementeren. Dan kan de gebruiker alleen applicaties in losstaande sandboxes starten, die draaiende code van elkaar isoleert. Dat is nog steeds geen perfecte beveiliging, uiteraard. Maar het is beter. Niet elke applicatie hoeft interactie te hebben met iedere andere applicatie.

Dan heb je natuurlijk nog steeds het probleem dat geheimen die beschikbaar zijn voor een applicatie (zoals in een browser) vanuit dezelfde applicatie gestolen kunnen worden. Daar beschermt sandboxing niet tegen.

[Reactie gewijzigd door The Zep Man op 26 september 2024 08:50]

[GertMenkel]

Dat heeft Microsoft een paar keer geprobeerd ("S mode" was daar de grootste kanshebber voor, al kwam dat wel met de vereiste om Microsoft's app store te gebruiken) maar dat komt met een hele hoop extra problemen, zoals het alleen ondersteunen van moderne applicaties, het onmogelijk maken voor gebruikers om zomaar een .exe te draaien, enzovoorts. Maakte ook een hele hoop bloatware van andere makers kapot.

Microsoft zal een losse versie van Windows moeten maken willen ze zoiets voor elkaar kunnen krijgen, waar gebruikers niet verwachten dat applicaties die het voorheen deden (zoals Steam overlays, FPS-tellers, antivirus) willen ze zoiets succesvol gaan maken.

Wat overigens wél kans maakt is de aanpak die Microsoft voor Edge z'n super-duper-secure mode heeft gedaan, namelijk de hele browser in een VM draaien. Dan verlies je hardwareacceleratie, maar het schermt je wel af tegen dit soort aanvallen. Op Windows zit je dan wel weer met stomme vraagstukken als "hoe zit het met de Windows-licenties" omdat je niet zomaar een tweede (kleine) kopie van Windows mag draaien, maar toch.

[The Zep Man]

Dat heeft Microsoft een paar keer geprobeerd ("S mode" was daar de grootste kanshebber voor, al kwam dat wel met de vereiste om Microsoft's app store te gebruiken) maar dat komt met een hele hoop extra problemen, zoals het alleen ondersteunen van moderne applicaties, het onmogelijk maken voor gebruikers om zomaar een .exe te draaien, enzovoorts. Maakte ook een hele hoop bloatware van andere makers kapot.

Ik denk dat dit een zwakke implementatie betrof waarin Microsoft te veel de touwtjes in handen wilde hebben in een omgeving waarin een gebruiker normaliter vrij code kan draaien. Een sandboxmogelijkheid zou kunnen voor .exe bestanden. Voor zaken als Steam zou je uitzonderingen kunnen maken, zoals voor de overlayfunctionaliteit. Een probleem is dat een gebruiker dat zelf in zou moeten stellen, want de verspreiders van "losse" win32-applicaties gaan qua permissies uit van een open omgeving waarin hun applicaties draaien. Het is niet alsof die opeens om permissies gaan vragen (zoals wat bij Android gebruikelijk is).

[BobJung]

Is het bekend of dit ook in Edge zit. Gebruik Chrome dus nooit. Zakelijk is het onze standaard browser, snap ik echt niks van. Chrome en Google op Windows ws systemen is een gevecht. Die twee weten niet wat samen werken is.
Als ik dan kies, gebruik ik pc technisch alleen Microsoft.
In Android ook, mijd zoveel mogelijk Gebruik Google.
Google Maps is daar en tegen onverslaanbaar op een mobiel voor fietsen.

[GertMenkel]

De secrets API van Windows werkt gewoon prima, maar je kunt niet voorkomen dat deze misbruikt wordt zonder zware sandboxing toe te passen die andere dingen weer kapot maakt. In theorie is het met dingen als virtualisation-based security mogelijk om op moderne Windows-installaties dit soort dingen veiliger in te bouwen, maar dan zullen er ook een hele hoop applicaties kapot gaan.

Zodra een proces met gelijke of hogere rechten dan jij draait, kun je als applicatie niet heel veel doen om jezelf te beschermen tegen dit soort dingen.

[MiesvanderLippe]

Het werkt prima maar andere software kan de secrets ook uitlezen betekent voor mij dat het niet prima werkt KeyChain doet dit veel beter maar je hebt daarin wel gelijk - Apple is ook minder bang om dingen kapot te maken.

[GertMenkel]

Apple's Keychain heeft soortgelijke kwetsbaarheden als die van Microsoft (al wordt macOS minder bij bedrijven gebruikt dus is er ook minder tooling voor die je zo kan downloaden voor een pentest). Als iemand het geheugen van Keychain.app kan lezen (of op Windows, lsass) dan kunnen ze de ontgrendelde credentials dumpen. Als een programma op dat niveau kan opereren, zijn je wachtwoorden op geen enkel platform veilig.

Microsoft wil dan ook maar al te graag dat mensen Windows Hello gaan gebruiken (de TPM-gebaseerde authenticatie, die bij Windows 10 een UI-refresh heeft gekregen die hem bruikbaar maakt). Dan heb je dit hele probleem niet en inloggen is voor de gebruiker nog makkelijker ook.

[Reactie gewijzigd door GertMenkel op 26 september 2024 12:28]

[Johnny D]

Dus eigenlijk zijn het niet zo'n goede (slimme) criminelen , want waarom zou je het melden of bekend maken

[watercoolertje]

Als je iets wilt verkopen dan moet je toch kenbaar maken wat je wilt verkopen? Dat geldt ook voor criminelen

[Reactie gewijzigd door watercoolertje op 26 september 2024 09:57]

[raro007]

Omdat ze ook weten dat Google het weet?

[jeffhuys]

Rep.

En als het binnenkort onbruikbaar is, hebben ze hun buit én nu de rep.

[Reactie gewijzigd door jeffhuys op 26 september 2024 09:07]

[Verwijderd]

Is het nu ook zo dat ze dus MFA kunnen omzeilen als ze die cookie in handen hebben?

Edit: bedankt voor de reacties. Het komt er dus op neer dat we moeten stoppen met die cookie melding op websites en stoppen met MFA, tijd voor iets nieuws!

[Reactie gewijzigd door Verwijderd op 27 september 2024 08:07]

[grasmanek94]

Websites die een cookie niet binden aan een ip + iets (browser fingerprint bijvoorbeeld) zullen inderdaad "MFA omzeilbaar" zijn. Afweging tussen gebruiksgemak / hoe vaak iemand moet inloggen en veiligheid.

Google / YouTube bijvoorbeeld kiest voor gebruiksgemak, maar als ik mij niet vergis kwam of is er een optie om sessies te binden aan een IP.

[bazzi]

sessies binden op ipadres is een crime. Je wordt steeds uitgelogd als je op ene ander netwerk zit. Dat kan door lopen van ene netwerk (thuis) naar bv vrienden een stukje verder op. Of je VPN aanslingeren.

Maar wat veel vaker voorkomt is dual wan, en dat ze of een round robin of een andere reden hebben qua switchen hebben. (Denk een storing). Dan ben je in een uitgelogd. En als de lijn dan flappert krijg je als aanbieder van de dienst gezeik, want steeds uitgelogd.

Want het ligt niet door hun ICT (afdeling) want die zegt toch: er is toch internet, dus wat is het probleem?

Kortom vooral als je zakelijke diensten aanbied aan een hoop gebruikers die werken op iets grotere netwerken (maar niet zo groot dat ze BGP gebruiken voor de dual wan) wil je sessies niet binden aan ip.

Om je een idee te geven. Wij zijn overgestapt op fingerprinting in combo met sessies. Kortom afzwakking qua veiligheid, maar een hoop ontevreden klanten minder.

[oezie]

Wel als je al ben ingelogd op een site. Dan kunnen ze met je sessie cookie jouw sessie overnemen. Als je dan ook nog heb aangegeven dat je ingelogd wil blijven op die site, dan krijgt de aanvaller ook gewoon steeds een nieuwe sessiecookie wanneer deze verlopen is.

Hier staat het nog wat beter uitgelegd.

[Reactie gewijzigd door oezie op 26 september 2024 09:21]

[Verwijderd]

Ligt aan de appbouwer hoe die de cookie heeft geprogrammeerd. Maar meestal kun je nog iets doen met het ip adres controleren, is die anders dan nieuwe cookie nodig

[Vexxon]

Geldt dit dan voor alle Chromium based browsers?

[laurens0619]

Meestal zie ik dat (MFA) cookies/sessies gesteeld worden dmv een Man In the Middle Phishing pagina. Daar hoeft dus geen malware voor op de computer.

Als je wel malware op de computer hebt dan is denk ik het hek van de dam en zal het altijd lukken zoiets te stelen. Aanvaller kan ook iets als HiddenDesktop draaien waardoor de cookie niet eens gestolen wordt maar de browser bij het slachtoffer op de PC draait en de hacker de output ziet op mijn scherm (even gesimplicifeerd)

[zordaz]

De titel van dit artikel zou dus eigenlijk moeten zijn "Criminelen claimen beveiliging tegen cookiediefstal in de MS Windows versie van Chrome te kunnen omzeilen". Met de huidige titel is het clickbait gehalte van dit artikel me iets te groot... Of mis ik iets?

Sowieso zou het van journalistieke kunde getuigen als er door de Tweakers redactie iets zou worden toegevoegd over de impact van dit issue op andere Chromium gebaseerde browsers en andere platformen dan MS Windows. Ook als dat nog niet duidelijk is, is dat vermeldenswaardig.

[Reactie gewijzigd door zordaz op 26 september 2024 09:18]

[FrostyPeet]

Die criminelen hebben het buskruit ook niet uitgevonden met hun claims. Je zou denken dat ze zoiets wel stilletjes zouden uitbuiten in plaats van het van de daken te schreeuwen.

[Dekar]

Ik gebruik Firefox met Ghostery (auto reject cookies, anti track en ad blocking) en uBlock Origin en indien alsnog reprompt, weiger ik alle cookies.

Zijn er dan nog kwetsbaarheden qua cookies te stelen van mijn PC?

[Reactie gewijzigd door Dekar op 27 september 2024 08:44]