Meta brengt opensourcebrowserextensie uit om WhatsApp Web te verifiëren

Meta heeft in samenwerking met Cloudflare Code Verify uitgebracht. Dat is een browserextensie die automatisch de authenticiteit van de code op de WhatsApp Web-website verifieert als gebruikers daarop inloggen. De extensie komt naar Chrome, Edge en Firefox.

Het gebruik van Code Verify zorgt er volgens Meta voor dat gebruikers er zeker van kunnen zijn dat als zij WhatsApp Web gebruiken, er niet geknoeid is met de code. Het moederbedrijf van Facebook en WhatsApp wil het daarmee moeilijker maken voor aanvallers om berichten te onderscheppen van gebruikers die WhatsApp in de browser gebruiken.

Volgens Meta is Code Verify gebaseerd op het concept van subresource integrity. Dat is een beveiligingsfunctie waarmee browsers verifiëren dat de inhoud die ze binnenhalen niet gemanipuleerd is. Dat werkt alleen met losse bestanden, terwijl Code Verify alle bronnen op de volledige pagina controleert, aldus Meta. Om dat op grote schaal te kunnen doen, werkt Meta samen met Cloudflare.

Meta heeft Cloudflare een cryptografische hash gegeven van de JavaScript-code van WhatsApp Web. De Code Verify-extensie vergelijkt vervolgens de code in de browser van de gebruiker met de geverifieerde code in het bezit van Cloudflare. Het vergelijken van hashes om te kijken of er met code is geknoeid, is niet nieuw, zegt ook Meta. Het bedrijf stelt echter dat de manier waarop dat automatisch gaat met Code Verify en de schaal waarop dat nu kan plaatsvinden, vernieuwend is.

Als de extensie is geïnstalleerd, wordt die automatisch geactiveerd als WhatsApp Web bezocht wordt. Met stoplichtkleuren laat de extensie zien of alles in orde is, of dat er problemen zijn. Bij een netwerktime-out of detectie van een mogelijk risico is een oranje cirkel zichtbaar. Als de extensie merkt dat de code niet overeenkomt, wordt het icoontje rood met een uitroepteken. Een klik op het icoontje moet meer informatie opleveren.

De Code Verify-extensie is beschikbaar voor Chrome en Edge. Een Firefox-versie volgt later. Volgens Meta logt de browserextensie geen data, metadata of gebruikersdata en wordt er geen informatie met WhatsApp gedeeld. Ook heeft de extensie geen toegang tot berichten, benadrukt het bedrijf. Het gaat om een opensource-extensie en de broncode staat op GitHub.

Reacties (46)

[TechSupreme]

Dit is dus ook de reden waarom er voor Signal geen webinterface bestaat. In 2017 is er het volgende gezegd:

The fundamental problem with web interfaces is: there's no way to version, sign and securely distribute a web page. Instead, you're re-requesting the code you'll run every single time you visit the site (making audits practically impossible).

This effectively reduces the security of your end-to-end encrypted communication to that of your SSL connection to the server, i.e. you're only as secure as the CA system. Anyone able to intercept the client-server SSL connection (and the server itself) can silently change the code you receive and execute, with a very low risk of getting caught. This is why products which offer end-to-end encrypted communication through in-browser crypto are often considered snake oil, unless they use some form of a packaged & signed browser extension.

Wat toen is gezegd is Meta nu gaan doen. Zo'n browser extension brengt natuurlijk ook weer praktische problemen met zich mee waardoor het ook weer niet ideaal is. Dat Meta ervoor kiest om het verificatie proces via Cloudfare te laten lopen is weer een pluspunt, maar is ook weer een single point of failure en maakt het weer traceerbaar.

[Skit3000]

In theorie zouden "Web3" oplossingen zoals IPFS deze browserextensie direct overbodig maken. Je haalt dan namelijk een pagina als Whatsapp Web op aan de hand van haar cryptografische en unieke hash.

[TechSupreme]

Ik had eigenlijk ook liever gezien dat ze met een andere oplossing kwamen. Het is nu wel heel makkelijk om de query om te leiden naar je eigen server en de plugin zo alsnog foute informatie te voeren.

Web3 is op dit moment nog maar een idee en het zal wel een tijdje duren voor het vorm krijgt, maar er bestaan nu al meerdere decentrale oplossingen welke een stuk veiliger kunnen zijn.

[Skit3000]

Het concept van Web3 is dat data decentraal wordt opgeslagen, waardoor het inherent dus onveranderbaar is. De oplossing van Meta richt zich vooral op "wat als een van onze eigen medewerkers een aanpassing aan Whatsapp Web maakt" (of een aanvaller met toegang tot de server). SSL zorgt al dat niemand tussen de server en de gebruiker aanpassingen kan maken.

Uiteindelijk is het allemaal maar lapwerk. Iemand met toegang tot de Whatsapp Web-server heeft waarschijnlijk ook wel toegang tot de extensie en kan dan ook gewoon daarvan een nieuwe versie installeren, of de extensie verwijderen van de lokale machine van de gebruiker die ze willen volgen en vervangen door een andere met hetzelfde icoontje, etc. En in dat geval hebben ze die extensie niet nodig want heeft de aanvaller toch al toegang tot een machine. Cirkeltje rond.

[Reactie gewijzigd door Skit3000 op 22 juli 2024 18:40]

[mr_seeker]

SSL zorgt al dat niemand tussen de server en de gebruiker aanpassingen kan maken.

Als ik als proxy fungeer, en jou een valide website voorschotel met mij als root CA, dan is de enigste manier om te controleren of je de correcte website krijgt een controle op certificaatniveau. En dan moet je hopen dat de applicatie die ik je stuur ook niet besmet is. Oftewel: de cliënt moet je altijd als "onveilig" beschouwen.
En ik heb het hier over de root CA van verschillende landen die misbruik kunnen maken van dit doel...

[Sissors]

Huh? Dat komt toch gewoon exact op hetzelfde neer en heeft niks met iets overbodig maken te doen? Wat deze extentie doet is controleren of de hash van je Whatsapp web degene is die het moet zijn. Wat je met IPFS zou doen, is op basis van de hash het binnen halen. In beide gevallen zit je met exact hetzelfde ding wat je moet oplossen: Je moet de hash weten. Als je die kent kan het allemaal verder triviaal gecontroleerd worden. Zou ook heel makkelijk in browsers kunnen worden geimplementeerd, daar heb je geen web3 voor nodig. Maar wat je wel nodig hebt is de juiste hash. En daar gebruiken ze nu deze extentie voor.

[TheVivaldi]

Dit is dus ook de reden waarom er voor Signal geen webinterface bestaat.

Maar voor Matrix zijn er dan wel weer tig webinterfaces, en Matrix is toch minstens net zo veilig als Signal, zo niet veiliger.

[TechSupreme]

Wie zegt dat de webbased clients voor Matrix niet te maken hebben met hetzelfde probleem en wie zegt dat die clients veilig zijn?

https://community.signalu...rty-security-audits/13243

[MartenBE]

De Signal app voor desktop is toch ook maar een electron app? Heeft dit dan niet hetzelfde risico als een webinterface?

Ik zou gewoon vermoeden dat alle controles bij de server liggen? Public key crypto en certificates zijn toch net gemaakt om deze problemen op te lossen op een publieke ruimte zoals het internet?

[TechSupreme]

Het gaat om: "no way to version, sign and securely distribute". Ook al is het een electron app (zou zomaar kunnen heb me daar nooit in verdiept) dan heb je nog steeds een statische binaire distributie welke je totaal kan verifiëren, als ermee geknoeid is dan valt dat op.

Het probleem met een webpagina (zoals het daar ook staat) is dat je die mogelijkheden niet hebt, de client browser haalt de pagina van jou server op en daarna ligt alles buiten jou bereik.

[MartenBE]

Ja ok, maar de server wordt hier toch tegen gehardened? De server beslist toch de flow en hoe die het vertrouwen met een client opbouwt? Of dat nu een webpage is of een binary, de server is toch altijd open en klaar om requests te ontvangen. Dus die zou toch beveiligd moeten zijn omdat wie dan ook (frauduleuze) requests kan sturen. Never trust client-side enzo.

Of je nu de juiste pagina ophaalt of een distributable afhaalt van een bepaalde pagina, het probleem blijft daar hetzelfde toch? Als je je op de frauduleuze pagina vind, heb je het toch vlaggen en een corrupte versie mee (op die pagina zal de versie en hash ook wel overeenkomen met die corrupte versie). Of heb ik dit echt zo verkeerd op?

[TechSupreme]

Bij een binaire installatie heb je 1 install en die blijft hetzelfde. Bij een webpagina heb je 1 bestand welke elke keer weer opnieuw op wordt gehaald, Je hebt ook te maken met dingen als caching en er zitten meerdere partijen tussen de client en de server. Omdat het ophalen van de pagina meerdere keren gebeurt heb je ook meer kansen om ertussen te komen. Je kan dus tussen de client en de server gaan zitten en dan heb je een hele grote kans dat de communicatie wordt onderschept. Het is voor de server niet te verifiëren of het bestand wat verzonden is ook daadwerkelijk aankomt zoals bedoelt. Dus je zou elke keer als je de pagina opent aan de clientside moeten checken of de hash wel klopt en dat is juist wat de plugin doet.

Nou kan je zeggen dat een binaire download dat probleem ook heeft, maar je downloadt en installeert het bestand 1x en dat blijft zo staan op je computer, dus je kan de hash checken en dan weet je zeker dat er niet mee gesjoemeld is. Na die ene keer downloaden en installeren wordt er niks meer opgehaald van de server en verandert er ook niks aan de bestanden.

[Reactie gewijzigd door TechSupreme op 22 juli 2024 18:40]

[djwice]

Als je HSTS preload, DNSsec en DNS CAA hebt, wordt het een stukje lastiger om die modificatie uit te voeren.

De verbinding moet dan een vertrouwd certificaat hebben van een provider die in DNS CAA staat.

Je moet dan dus niet alleen de key van het TLS-certificaat kennen (om te ontsleutelen), maar ook de DNS van de cliënt kunnen vervangen.


Alternatieve aanval is natuurlijk manipulatie na decryptie op de cliënt. Dus bijvoorbeeld via een extensie of een geïnjecteerde service worker.
Bij dat laatste type aanval is het voor de beveiliging van belang dat de extensie van meta/cloudflare uitgevoerd wordt na de manipulatie. Ik neem even aan dat de aanvaller nog geen sha256 hash collisions kan uitvoeren.

Note
Wat ik ook in de blog lees is: een vorm van beveiliging voor als de code al gecompenseerd is op de server. Opvallend. En ook opvallend dat de aanname is dat als de code bij de bron gecompromitteerd is, dat het uploaden van de nieuwe hash naar CloudFlare zal mislukken.

Issue:

But hold on a second: if the same website providing the download is also providing the hash, couldn’t a malicious actor replace both the download and the hash with their own values?

Mitigatie:

1. WhatsApp publishes the latest version of their JavaScript libraries to their servers, and the corresponding hash for that version to Cloudflare’s audit endpoint.

@Xtuv ik ben wel benieuwd, en jij vast ook als journalist, hoe het proces is ingericht om die hash van de gehackte versie op het Whatsapp bron systeem af te laten wijzen door het Cloudflare audit endpoint.

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

[TheVivaldi]

Ik ben wel nieuwsgierig, maar ik ben geen journalist.

[djwice]

Foutje :-)

[DevWouter]

Oké, what in the hell...
Het lijkt er meer op dat deze tool bedoeld is om te voorkomen dat andere extension niet je browser kunnen aanpassen. In andere woorden: Dit is een opstapje om te voorkomen dat men bepaalde AdBlockers kunnen gebruiken op FaceBook zelf.

Immers op https://github.com/facebo...lob/main/src/js/config.js staan vooral verwijzingen naar AdBlockers.

Tenzij ik er gigantisch naast zit is het probleem wat ze beschrijven al lang opgelost zoals "Cross-Origin Resource Sharing" en "Subresource Integrity" tenzij iemand je complete internet verbinding hackt (en ook daar zijn oplossing voor), en als men daar voor bij komt dan kan men net zo goed een update pushen voor de de complete browser. Een stuk intressanter en dan kunnen ze ook veel meer.

[Reactie gewijzigd door DevWouter op 22 juli 2024 18:40]

[mdgf]

Op basis van het prentje veronderstel ik dat de attack vector hier slaat op phishing websites die eruitzien als whatsapp web.

Dan zou zo'n oplossing dat inderdaad moeten kunnen detecteren, maar tbh een extensie die gewoon controleert of de url klopt en https enabled is zou dat ook al doen en heeft geen toegang tot de content van de pagina nodig. Als een malafide actor je https verkeer kan manipuleren heb je toch al verloren me dunkt.

Die lijst van extensies die warnings triggeren lijkt me op het eerste zicht een halfslachtige poging om extensies die permissie hebben om content op de pagina van whatsapp web te manipuleren te detecteren. Op zich ergens wel begrijpelijk, maar niet nuttig als je dit met hashes moet gaan matchen, want dan kun je toch nooit alles vangen.

[EraYaN]

Die hashes worden juist gebruikt om van INVALID_SOFT een WARNING_RISK te maken. Dus JUIST om die wat extra ruimte te geven.

Zie: https://github.com/facebo...contentUtils.js#L558-L569

[mdgf]

Correct, ik had miskeken, ik dacht dat die van valid naar warning ging.

[weazle]

Misschien moeten ze eerst een beginnen met een goede beveiliging van de website zelf, o.a. die gebruik van een strikte Content-Security-Policy. Whatsapp web scoort op beveiliging heel slecht:
Securityheaders.com < score D
SSLLabs < score B

Dit voelt voor mij dan ook als een lapmiddel. Door middel van een strikte CSP kunnen ze ook zorgen dat de site niet gemanipuleerd wordt en heb je geen plugin nodig.

[Verwijderd]

Wanneer de client geïnfecteerd is, dan kan de spyware die extensie uitschakelen of manipuleren altijd een groen licht te geven. Dus daarvoor is dit niet echt nuttig. Want een vals gevoel van veiligheid.

Verder voegt het volgens mij weinig toe aan voor alles https te gebruiken. Dan is de content ook d.m.v. encryptie gegarandeerd vrij van een MiTM aanval waarbij deze in transit zou gewijzigd worden.

[RienBijl]

Maar als upstream de server een verkeerde versie meestuurt, die E2EE breekt, heb je wel een probleem. En aangezien de server in een E2EE model niet vertrouwd is, is dat een risico. Dit maakt die aanvalsvector veel kleiner.

Destijds bij ProtonMail was dit ook een punt van kritiek
https://eprint.iacr.org/2018/1121.pdf

[Grannd]

Interessant, dit is voor het eerst dat ik me realiseer dat er risico's zijn bij het gebruik van Web WhatsApp.
Is het een gezonde pro-actieve stap dat Meta dit doet of speelt er stiekem iets anders wat ze onder de pet willen houden?

[Christoxz]

Wellicht een risico sinds het niet meer nodig is dat je telefoon online is. Nu kan/gaat web whatsapp verkeer niet meer altijd via je eigen toestel

[jerkitout]

https://www.bleepingcompu...rity-to-bypass-sanctions/

Misschien deze?

[kodak]

Aangezien de broncode van meer af hangt dan of je de verbinding kan vertrouwen kon al niet zomaar verwacht worden dat een betrouwbare ca of verbinding genoeg is.
Gekaapte browser, gekaapte website, xss injectie door aangepaste url etc zijn ook al ruim 25 jaar bekende risico's.

[kodak]

Het risico lijkt niets anders dan bij andere webservices. Zolang je als gebruiker niet op een veilige manier kan controleren of de code werkelijk is als bedoeld kun je er niet zomaar vanuit gaan dat die betrouwbaar is.

Daarbij geeft deze oplossing ook niet zomaar meer of genoeg zekerheid.

Het lijkt dus vooral een waardevol experiment om te zien wanneer dit in de praktijk nu helpt en wanneer niet. Als whatsapp en cloudflare tenminste niet te veel gegevens verzamelen en ze bij problemen niet opeens risico gaan afschuiven op gebruikers.

[Reactie gewijzigd door kodak op 22 juli 2024 18:40]

[Plainside]

Kan me vaak niet vinden in de stappen van Meta, maar dit vind ik wel een hele mooie. Zoals @Grannd zegt had ik hierbij nog geen eens stil gestaan. Wacht nog wel ff voordat ik hem installeer, je weet eigenlijk niet of wat Meta zegt waar is, doelend op dat er geen gegevens worden gelogt.

[nst6ldr]

Deze implementatie lijkt me een beetje low-effort, ik snap het doel (GrapheneOS komt ook met een audit tool), maar als de browser niet vertrouwd kan worden dan gaat een audit vanuit diezelfde browser natuurlijk niet helpen. Dan moet je dit bijvoorbeeld als app gaan aanbieden zodat je vanuit een andere bron van verifiëren of de browser vertrouwde code draait.

[EraYaN]

Het gaat in deze niet om de browser zelf (dat is ook een ondertekende binary) maar om de content IN de browser.

[YopY]

Wat @DevWouter ook al aangeeft, verificatie van bijv. de gebruikte Javascript is opgelost dmv Subresource Integrity; de beveiliging met de server gaat via HTTPS, en daar zijn technieken voor om het vervangen van de certificaten te voorkomen met bijv. HSTS en/of Perfect Forward Secrecy.

[RienBijl]

Dat is niet wat HSTS en Perfect Forward Secrecy doen naar mijn weten.

HSTS verzekert dat er een certificaat is, niet een specifieke. En PFS zorgt er alleen voor dat het uitlekken van de private key niet de eerdere communicatie ontsleutelbaar maakt.

Een CAA record zou wel kunnen wat jij beschrijft, tot zekere hoogte.

[CivLord]

Is dit de opmaat naar de situatie waarin voor elke webapp, extensie en webpagina een aparte extensie komt die aangeeft dat er niet mee geknoeid is?
Dat betekent dus een paar extra balken met extensies bovenaan mijn scherm en flink afgeknepen prestaties door alle recourses die al die extra extensies gebruiken.

[fre0n]

Waaro. Moet die verificatie via een tussenlersoon gebeuren? Kan er niet een hash gebruikt worden waarmee lokaal geverifieerd kan worden?