Onderzoeker kan tweestapsverificatie omzeilen via WebView2 om cookies te stelen

Een beveiligingsonderzoeker heeft een phishingtechniek ontwikkeld waarmee met functies van Microsoft WebView2 inloggegevens en cookies van een slachtoffer gestolen kunnen worden. Hierdoor kan tweestapsverificatie eventueel omzeild worden.

De phishingaanval wordt door de onderzoeker WebView2-Cookie-Stealer genoemd en maakt gebruik van standaardfuncties van website-embedtool WebView2 en een malafide programma om de browsercookies van een gebruiker te stelen. Door specifieke JavaScript-code te injecteren in de loginpagina van anderszins legitieme websites lijkt het alsof het om een gewoon loginproces gaat. Het slachtoffer logt in principe zoals normaal in, maar dan via het malafide programma van de aanvaller. Hierdoor kan bijvoorbeeld met een keylogger de toetsinput van de gebruiker geregistreerd worden.

Als het slachtoffer eenmaal is ingelogd, al dan niet na toepassing van tweestapsverificatie, kan de aanvaller door de browser opgeslagen cookies kopiëren. Een malafide hacker kan deze authenticatiecookies vervolgens gebruiken voor een eigen sessie, waardoor de website de aanvaller als legitieme gebruiker denkt te herkennen. Gestolen cookies inclusief logingegevens kunnen bijvoorbeeld via de Chrome-extensie EditThisCookie geïmporteerd worden in een nieuwe sessie.

De kwetsbaarheid berust volgens de beveiligingsonderzoeker op social engineering; het slachtoffer moet in eerste instantie de WebView2-executable starten alvorens een loginpoging bij een legitieme website gemonitord kan worden. Microsoft benadrukt in een reactie tegenover Bleeping Computer daarom dat gebruikers nooit applicaties moeten starten of installeren als deze van een onbetrouwbare bron komen.

De softwaregigant stelt ook dat gebruikers antivirussoftware zoals Microsoft Defender altijd aan moeten hebben staan om de installatie van malafide applicaties te voorkomen. Ghacks concludeerde overigens dat Defender de installatie van de demoapplicatie van de beveiligingsonderzoeker niet tegenhield, maar alleen een waarschuwing gaf.

De beveiligingsonderzoeker vermomde zijn malafide applicatie als een Office-app, waarna gebruikers via een WebView2-embed officieel bij Microsoft inloggen

Reacties (64)

[MneoreJ]

Stap 1. Overtuig de gebruiker eerst om een willekeurige toepassing van het internet te starten.
Stap 2. Er is geen stap 2. Je hebt al gewonnen. Wat je eventueel met WebView2 uit gaat spoken is niet echt relevant meer, maar eventueel wel grappig.

[boolean]

Je haalt me de woorden uit de mond, chapeaux! Zo heb ik jaren lang "hobby matig" toegang verkregen tot andermans accounts. Hetzelfde is natuurlijk mogelijk met ieder willekeurig Tweakers account. Security is zo sterk als de domheid van de gebruiker.

[Thoit]

domheid onwetendheid vaak

[Andros]

Het hangt er volledig af wat er daarna mee gebeurt is en met welke intentie. Als iemand de deur wagenwijd open laat staan en jij kijkt alleen even binnen en bent daarna weer weg, is dat ook inbraak? Je tweede zin geeft me helemaal koude rillingen overigens...

[Martin.Air]

Huisvredebreuk.

Ook verboden, net zoals 'hacken' voor de hobby trouwens. Zo mag je zelfs de beveiliging van een tool in je eigen huis niet voor de leuk proberen te doorbreken, dit mag wel om te testen of het veilig is maar dan ook enkel dat.
Maar al helemaal niet de systemen van een ander. Er is een gedoog beleid voor het doorbreken, niks doen en informeren dat dit dus met goede intenties gebeurd. Maar het mag nog steeds niet zonder toestemming.

[Reactie gewijzigd door Martin.Air op 22 juli 2024 19:40]

[ELKAY_]

Sterker nog, je mag zelfs niet inbreken in je eigen auto. Maar sinds wanneer zijn we allemaal zo boos om dit soort dingen?

Iedereen in dit topic heeft wel eens iets illegaal gedownload, dus allemaal geen enkel recht van spreken.

[Bo Diddley]

Jawel hoor, dat wordt ook wel "voortschrijdend inzicht" genoemd, of (levens-) ervaring...

[lilmonkey]

Als iemand de deur wagenwijd open laat staan en jij kijkt alleen even binnen en bent daarna weer weg, is dat ook inbraak?

Nee, dat is huisvredebreuk. Een misdrijf dus.

[ELKAY_]

Tenzij het bedoeld was om te kijken of het echt open stond en de eigenaar/bewoner te waarschuwen.

[Tozz]

Nee, dan is het nog steeds huisvredebreuk

[ELKAY_]

Zoo jij bent heilig of niet? Nog nooit wat gedownload? Een game gecracked? Gecheat in een spel? Windows gepirate? etc etc etc.

Wees blij dat mensen dit soort dingen "hobby matig" proberen, anders zouden er geen patches, vuln fixes en uberhaupt algemene waarneming van exploits zijn.

Doe maar aangifte tegen alias @MneoreJ, kijken wat er uit komt kerel.

[Bozebeer38]

Nee, serieus, dat soort shit heb ik nog nooit gedaan.

Single player cheats, in de jaren 90 ja.

[ELKAY_]

Dan moet je heilig zijn. Ik ken bijna niemand boven de 20 jaar die nog nooit iets heeft gedownloaded.

[Bozebeer38]

Gedownload? Je bedoelde illegaal neem ik aan?

Nee, altijd netjes betaalt, zoals een normaal mens.

[ELKAY_]

Hahaha dat gelooft werkelijk waar niemand. Hoe oud ben je? Je hebt je hele leven nog geen muziek, film of game illegaal gedownload?

Dat ontkennen is nog erger dan het feit zelf.

[Bozebeer38]

Projecteer aub niet op mij wat jij zelf blijkbaar wel deed of doet.

Ik kom uit de Commodore 64 tijd, mag je zelf rekenen hoe oud ik ben ongeveer.
Ik heb inderdaad nog nooit, echt letterlijk nog nooit, muziek/games of wat dan ook illegaal gedownload.
Nee ook niet via Kazaa of soortgelijke oude Windows programma’s.

Dat jij je het niet kan voorstellen, betekent niet dat het niet zo is hè.

[ELKAY_]

Dan ben je wel heilig, blijkbaar

[Bozebeer38]

Dat vul jij ook weer helemaal zelf in.

Nee ik ben weer verrot op andere vlakken.

[daredevil__2000]

Het zijn vooral de handelingen die je daarna uitvoert met de verkregen toegang en wat je doet met de buitgemaakte gegevens die bepalen in hoe verre het handelen strafbaar was

[TheVivaldi]

Je doet je naam wel eer aan.

[Keypunchie]

Ik snap hem nog niet helemaal.

Waar zit de kwetsbaarheid en waar draait de "attack" code? Is dit een browser-kwetsbaarheid, is dit een OS kwetsbaarheid? Is dit een kwetsbaarheid specifiek in de diensten van Microsoft?

[3raser]

De kwetsbaarheid zit in dit geval achter het toetsenbord. De gebruiker zelf is namelijk de kwetsbaarheid. Je download een applicatie (noem het een virus) die vervolgens een stukje javascript toevoegt aan de website en een keylogger start. Dit kan blijkbaar niet zonder input van de gebruiker. En als je dan toch al een malafide applicatie hebt gedownload en gestart dan had deze "kwetsbaarheid" net zo goed iedere andere trojan kunnen zijn.

[djwice]

Met een veilig cookie en een goede content security policy is deze aanval dus gewoon af te slaan.

Bijvoorbeeld met:

Set-Cookie: __Host-cookienaam=waarde; Path=/beacon/; Secure; HttpOnly; SameSite=strict

content-security-policy: default-src 'none' ; frame-ancestors 'none' ; base-uri 'self' ; connect-src 'self' ; img-src 'self' ; font-src 'self' ; form-action 'self' ; manifest-src 'self' ; style-src 'self' ; worker-src 'self' ; script-src 'self' ; report-uri /beacon/csp/


De key-logger kun je niet voorkomen, maar het stelen van de sessie cookie en de script injectie zijn gewoon te voorkomen.

Alleen als de executable een eigen versie van een browser bevat kan de injectie plaatsvinden en kan de sessie lekken.

Daarnaast zou het handig zijn om DNSsec en DNS CAA te gebruiken.

Side note m.b.t. Microsoft ID:
Microsoft doet dat niet op o.a. haar O365 en Teams domeinnamen. De keuze dat bedrijven intern een eigen certificaat aan de O365 domeinnamen kunnen hangen (in plaats van het publieke certificaat van Microsoft zelf) - welke wordt verkocht als 'extra veiligheid' feature - zorgt er dus juist voor dat O365 minder veilig is.

[Reactie gewijzigd door djwice op 22 juli 2024 19:40]

[lilmonkey]

Dit, en daarnaast lijkt het me ook dat sites die hun zaakjes een beetje op orde hebben een sessie die ineens op een ander apparaat of een andere browser op hetzelfde apparaat verdergaat zullen invalideren.

[ari]

Browser-detectie en apparaat-detectie zijn voornamelijk gebaseerd op informatie die de browser zelf verstuurt aan de website. Hier een website die uitlegt hoe je die zelf aanpast: https://www.searchenginej...change-user-agent/368448/

Deze website vertelt je wat hij denkt dat je browser en OS zijn: https://www.whatsmybrowser.org/

[lilmonkey]

De User Agent string is slechts één onderdeel daarvan. De volledige set aan parameters is wat lastiger volledig te simuleren. Maar als kwaadwillende zou je die moeite wel kunnen nemen, dat is waar.

(Neemt overigens niet weg dat als de parameters niet overeenkomen dit hoe dan ook een teken is dat er geknoeid is met de sessie dus invalideren is dan altijd aan te raden.)

[joco]

dit werkt toch niet in dit geval? (Want ja de executable heeft de eigen browser, dit is hetzelfde als een electron app die dus chrome embed, dan heb je echt alle rechten)
want de javascript komt gewoon direct van de applicatie vandaan, dus alsof Chrome of Edge dus zelf js injecteert (bv extensions)

en same site? de aanvaller pakt toch gewoon de cookie en gaat echt via een echte browser naar exact de zelfde site toe maar dan met een prefilled cookie die dus de sessie op de server overpakt?

Dus als mensen iets downoaden (wat dus lijkt op een browser) die die gewoon gaan gebruiken als een browser...

[djwice]

Een embedded browser gebruikt de op het systeem geïnstalleerde browser. Daarin zijn de bestaande beveiligingen en domein scheidingen actief (localhost is een ander domein dan bijvoorbeeld mijn.ing.nl ).

Waar ik op doelde met

een eigen versie van een browser

is eigen code. Dus niet een instance van de systeem browser of een embedded versie van de systeem browser maar een eigen install.

De beveilingslaag in de systeem browser zorgt er voor dat de cookie niet gelezen kan worden door JavaScript én dat het cookie niet wordt verstuurd naar andere domeinen (localhost bijvoorbeeld). De DNS records zorgen er voor dat als een verkeert certificaat wordt gebruikt voor het domein - bijvoorbeeld die van de hacker, die het domein tijdelijk wil omleiden en zelfs zijn eigen Certificaat Autoriteit (CA) aan de trust store heeft weten toe te voegen - dat ook dan het cookie niet wordt gestuurd.

De content security policy zorgt er voor dat er geen ander JavaScript dan die van het bron domein wordt uitgevoerd, ook niet als dat in de DOM wordt geïnjecteerd.

[Reactie gewijzigd door djwice op 22 juli 2024 19:40]

[joco]

er is eigenlijk geen verschil

Electron gebruikt een chromium browser die hij mee shipped ja.

Maar ik kan ook WebView2 gebruiken (dat de Edge chromium engine maakt)
ik weet zeker als ik daar een applicatie om heen schrijf dat ik alles kan doen er mee wat ik maar wil.

Want dat is gewoon een include van een DLL die toevallig op het systeem staat ipv dat ik die ook mee ship
(tot een tijdje terug, geen idee hoe het nu is moest ik die zelfs mee installeren, want WebView2 was er niet standaard)

Ik heb naar WebView2 gekeken om bv dat als browser integratie te krijgen voor ons Eclipse based product (dat is uit eindelijk een 3rd party chromium geworden wat voor meerdere os'en werkt)

en ik weet bijna wel zeker dat WebView2 allemaal hooks heeft om alles daar binnen te doen wat je maar wilt.

[djwice]

Oei, ik zie het hier https://github.com/MicrosoftEdge/WebView2Feedback/issues/4

Er zijn mensen in die discussie die niet begrepen hoe het moet zijn.
Niet de app bouwer moet de waarde van set-cookie kopiëren naar de request, dat moet de netwerk laag doen.
Ik makkelijker voor de app ontwikkelaars: geen code nodig die cookies, auth tokens etc verwerkt, en een stuk veiliger : de kans dat de app ontwikkelaar beveiliging in detail snapt en onder tijdsdruk goed implementeert en later tijd krijgt om de 'onzichtbare' beveiliging te verbeteren is klein.
Door dat 1x goed te doen in de netwerk laag is het direct goed geregeld voor alle apps.

Zelfde met andere tokens, denkt men ook vaak van dat hun app dat moet regelen, nope, niet nodig. Je kunt gebruik maken van standaarden in de andere lagen : heb je minder code en is ook nog sneller. (win-win)

Veel IT architecten vinden dit ook nog lastig.

[Reactie gewijzigd door djwice op 22 juli 2024 19:40]

[joco]

ik snap die vraag wel, dat heb ik ook met onze electron app
je zit in de main process en de webview zeg maar is in de renderer process (wat echt je browser is)
die handled die cookies echt wel af. Maar ook in de main process wil je dingen doen (request naar dezelfde server) en dan moet die main process ook die zelfde cookies op sturen anders ben je niet authenticated.
Daarom heb je ook in electron van die api's om die cookies en dat soort dingen van de renderer process op te vragen.

ik vind dit niet meer dan logisch, je bent een desktop app aan het bouwen, die allerlei intergratie al heeft, de gebruiker heeft hier voor gekozen en het geinstallerd, dus ja dan kun je gewoon ook alles.

ik zou bv ook een eigen browser op chromium gebaseerd kunnen uit brengen dan kan ik ook alles...

[djwice]

Als je main proces vanaf dezelfde scope een request doet als waar je de cookie op ontvangt, moet het cookie automatisch door je browser op het request worden geplaatst.

Desnoods gebruik je een service worker als proxy.
Het scheelt een hoop security en sessie logica in je main app, en potentiële attack vectoren, als je het op die manier weet op te lossen.

[blorf]

Ik kan het mis hebben maar volgens mij is de dreiging een webapp die blijkbaar privilege kan krijgen om browser-cookies uit de betreffende directory te vissen.

[XIU]

dit is altijd zo geweest, bij elke browser die je kan hosten, dit is een "feature"

[blorf]

Geen idee, ikheb jaren geen Windows gehad. Is het normaal dat een online applicatie deze permissies van de browser erft?
Als je op die manier bij meer informatie kan dan webpagina's zonder dat er om extra toestemming wordt gevraagd klopt er iets niet.

[joco]

het gaat hier niet om een online app

Dit is de executable self, dit is een browser die men download en dan installeert en met die "browser" gaan ze dus naar een website toe waar ze de gegevens invullen wat dus door de "browser" wordt uit gelezen en opgestuurd naar de maker van die "browser"

Volgens mij is dit echt niet zo speciaal voor WebView2 of zo, Dit kan ik ook makkelijk voor elkaar krijgen met elke Electron app die ik zou bouwen, wat ook gewoon een gewrapped Chromium is, waar ik ook bijna alles kan doen wat ik maar wil.

[XIU]

Het gaat er inderdaad over dat deze lokale app de gegevens die je via die app opvraagt gewoon kan zien/gebruiken.
Elke mobiele app die gewoon een browser host, elke Electron app op elk OS, dat is net de hele functionaliteit.

[blorf]

Het wordt gebruikt als deurtje naar binnen voor hogere permissies.. Best dom om stanaard een dev-gerelateerd programma op je systeem te draaien dat een override op de permissies van je browser mogelijk maakt voor iemand "buiten". Een beetje vergelijkbaar met je hele systeem-directory achter anonymous ftp hangen. Sja, dan kun je alles lezen...

[Reactie gewijzigd door blorf op 22 juli 2024 19:40]

[HKLM_]

Volgens gehackt.net

The demo app, which is available on the researcher's GitHub project site, was not blocked by Microsoft Defender. It includes a keylogger that protocols any key input by the user. A SmartScreen warning was displayed, but it was not prevented from being launched.

Het hangt dus gewoon van je SmartScreen instellingen af of het een Block of Warning is. In de zakelijke markt waar je ook Defender kan gebruiken is deze optie gewoon als attack surface reduction regel beschikbaar en stel je SmartScreen wat strakker af met een default blok met bypass mogelijk als gewenst. Op Windows 10 / 11 zonder business is dit ook gewoon mogelijk uiteraard.

Die onderzoeker moet eerst zijn systeem eens fatsoenlijk afstellen voordat die dingen gaat zoeken zo is het natuurlijk half spel als je je systeem open zet…

[Reactie gewijzigd door HKLM_ op 22 juli 2024 19:40]

[xFeverr]

SmartScreen zal hier dan ook alleen op reageren omdat dit een applicatie is die van het internet afkomstig is en niet vaak (of zelfs nooit in het geval van de ‘onderzoeker’) gedowloaded is.

[HKLM_]

SmartScreen ging gewoon af bij de onderzoeker maar zijn opmerking dat het alleen een warning was en geen block komt toch echt door zijn eigen foute configuratie.

[i-chat]

Ik vind de opmerking dat je je systeem dan beter moet afstellen bel echt veel te ver gaat: je opmerking zou kloppen wanneer hij bewust zijn smart screen instellingen heeft aangepast naar een lager beveiligingsnivo.
Als dat echt waar niet zo is dan zou Windows als standaardinstelling iets moeten hebben dat dit soort praktijken tegenhoudt en hooguit na het invullen van een beheerders wachtwoord een uitzondering moeten toestaan anders is het zoals wij ze onderzoeken zegt veel te makkelijk om Jan met de pet om de tuin te leiden

[joco]

maar waarom zou die dit moeten blocken??

ik vind dat ie dat helemaal niet moet doen, dit is gewoon een applicatie die ik download, daar zijn er wel meer van.
Je zou kunnen zeggen het moet echt signed zijn om hem te trusten..

Bijna elke electron app die een browser embed kan dit soort dingen denk ik wel doen (bv Zoom of Telegram desktop, noem maar op, dat zijn allemaal wrappers om een browser heen)

[.oisyn]

@xFeverr's punt is dat de énige reden dat SmartScreen afgaat, is omdat het een gedownloadde applicatie is die Microsoft nog nooit eerder heeft gezien. Het heeft weinig te maken met de operaties die de applicatie daadwerkelijk doet, zoals keys loggen.

[Z80]

Elke gebruiker gaat op zijn eigen Windows machine de SmartScreen instellingen aanpassen?

Deze Microsoft webapp is juist bedoelt om te telewerken op elke willekeurige Windows machine.
Dus ook bij mensen zonder kennis van het systeem. Laptop kopen, vragen op het scherm invullen en gaan.

[wica]

Uhmmm, wat is hier nieuw aan? Als de gebruiker de applicatie start, is het toch vrij logisch dat die toegang heeft tot onder andere je cookies?

[xFeverr]

Precies, dit zou ook in iOS met een WKWebView en op Android met diens webview. Beetje gek onderzoek zo.

[GertMenkel]

Ik geloof dat het hier gaat om het feit dat de desktopbrowser en webview-clients data delen. Dit leest een beetje als "programma dat toegang heeft tot gegevens van gebruikers kan iets makkelijker bij gegevens van gebruikers". Het wordt zo wel veel eenvoudiger om de secrets van FIDO2/WebAuthn/U2F te stelen, maar ik denk niet dat dit iets nieuws toevoegt.

Wel is zoiets lastiger te detecteren door antivirusproducenten.

Een programma zonder adresbalk dat niet eens lijkt op een browser die gegevens kan onderscheppen maakt weinig indruk op mij. Je kunt kinderlijk eenvoudig een phishingpagina maken en die in je browser stoppen, daar heb je geen cookies voor nodig.

[XiniX88]

Dat is niet zoals ik het lees. Het zou gaan om de aangepaste versie die wordt gedraaid, waar je op inlogt en die je cookies en keystrokes kunnen doorzenden.

Ook ik zie niet wat hier nieuw aan is, ik kan ook makkelijk een aangepaste chromium, Firefox, WebKit etc maken en daar extra JavaScript in embedded. Sterker nog electron of cordova zijn hele pakketten die van alles kunnen inladen in de browser.

[joco]

precies, ik snap hier ook niks van dit is niks nieuws, elke electron app kan dit

[.oisyn]

Dit is gewoon een browsercontrol in een applicatie. Wat is daar nou bijzonder aan

[JustFogMaxi]

Mja precies dat kon met webview1 IE ook al.

[Ronosho]

Dit was dan toch ook al mogelijk met het oudere WebBrowser control?

[ShadLink]

Het is redelijk algemeen bekend dat je met toegang tot een webview control (of soortgelijk) je vrij eenvoudig javascript injectie kan doen. Immers dat is het hele doel van deze controls, om onderdelen van je applicatie via een web renderer te doen (en veelal gebruik te maken van js injectie)

Het belangrijkste is nog steeds dat je geen software moet draaien die je niet vertrouwd. Helemaal als die software ineens bv je MS login of bank login vraagt.

[lenwar]

Je zou verwachten dat Microsoft wel meer beveiliging heeft dan een opgeslagen cookie? In elk geval als het om een Windows cliënt gaat. (ik denk hier aan zaken als webauthn enzo)

Ik hoop ook dat dit duidelijk maakt aan iedereen dat 2FA niet zaligmakend is. Veel mensen (ook op dit platform) hebben het idee dat 2FA/MFA je account echt 'afschermt', maar het is puur en alleen een extra laagje voor de authenticatie die de serverkant verzoekt. Het voegt niks anders toe dan dat. Althans. Voor TOTP-achtige (aka Google Authenticator) MFA-oplossingen is dat zo. Er zijn uiteraard ook MFA-oplossingen die weldelijke wat meer toevoegen dan alleen dit.

Als je ervoor kan zorgen dat de webapplicatie er niet om vraagt via welke route dan ook, passeer je het dus simpel.
Het enige waar TOTP in de praktijk goed voor is, is dat als iemand per ongeluk je wachtwoord heeft gezien dat hij of zij niet klakkeloos, zonder extra moeite, als jou kan inloggen. Dat is al heel wat natuurlijk, maar zeker niet zo fantastisch als menige doen suggereren.

[XIU]

als website kan je jezelf nooit beschermen tegen een malafide client

[telefoontoestel]

Ik heb hier met jwt tokens in het verleden een oplossing voor toegepast door het toevoegen van een device fingerprint in de claims. Dit is niet de standaard, maar verlaagde wel het risico dat iemand anders dit token kon onderscheppen en gebruiken. Is tot noch toe erg effectief gebleken.

[mrooie]

De standaard vraag die je aan jezelf moet stellen:

Waarom moet ik een actie ondernemen/in beweging komen?

Als iemand vraagt op jouw eigen device in te loggen -> altijd nee, inlog processen zijn privé net als je wachtwoorden.
En als ik geen gehoor geef aan de vraag, en de tegenpartij dan door blijft pushen dan horen alle alarm bellen te gaan rinkelen


Daarnaast vroeg ik mij het volgende af:

Wat als in de browser alle cookies blokkeren aan staat?
En in de Audit/logs staat daar dan het IP + Locatie van de hacker of de gegevens van het slachtoffer?

[Reactie gewijzigd door mrooie op 22 juli 2024 19:40]