Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

WhatsApp en Telegram dichten webclient-lek dat hackers toegang gaf tot berichten

Door , 44 reacties

WhatsApp en Telegram hebben een lek in hun webversies gedicht, waarmee aanvallers gebruikersaccounts konden overnemen. Het bedrijf Check Point ontdekte het lek en stelde de makers van de chatdiensten vorige week op de hoogte.

Check Point beschrijft dat het gebruik van de kwetsbaarheid mogelijk was door een kwaadaardig html-bestand met een preview van een afbeelding naar een slachtoffer te sturen. Daarmee was toegang mogelijk tot onder meer persoonlijke en groepsgesprekken, gedeelde bestanden en contacten.

In het geval van WhatsApp waren de onderzoekers in staat om de restricties op het gebied van bestandstypen in de webversie te omzeilen door gebruik te maken van het feit dat bestanden versleuteld naar de WhatsApp-servers verstuurd worden. Op die manier konden zij een kwaadaardig html-bestand uploaden, dat voorzien was van een aantrekkelijke preview waar een gebruiker op zou klikken. Als een gebruiker inderdaad op het bestand klikte, werd zijn lokale opslag naar de aanvallers gestuurd. Daardoor kan de aanvaller het account van het slachtoffer overnemen, aldus Check Point.

Het slachtoffer zou in dat geval een mededeling te zien krijgen dat er op een andere locatie is ingelogd, maar deze is te omzeilen door gebruik van een aantal regels code om het browservenster van het slachtoffer te laten vastlopen.

In het geval van Telegram waren de onderzoekers eveneens in staat om de bestandsrestricties voor het uploaden van bestanden te omzeilen. Zo konden zij ook hier een kwaadaardig html-bestand uploaden dat de indruk wekt een video te bevatten. Het verschil met de WhatsApp-methode is dat een slachtoffer de video in een nieuw tabblad moet openen, waardoor een aanvullende stap is vereist voor een succesvolle aanval. Ook toont Telegram geen waarschuwing, omdat het meerdere sessies toelaat. Het verdere verloop van de methode komt overeen met die van WhatsApp.

Forbes schrijft dat de lekken sinds de release van de WhatsApp-software in januari 2015 bestonden. Het bedrijf claimt dat er sindsdien geen gebruik is gemaakt van de kwetsbaarheid. De onderzoekers zeggen dat zij niet onderzocht hebben of de webversie van Signal eveneens kwetsbaar is voor deze methode. De bedrijven hebben de kwetsbaarheid opgelost door bestandstypes voor upload te valideren. het is niet de eerste keer dat de webversie van WhatsApp kwetsbaar blijkt. In 2015 bleek dat het mogelijk was om malware via vcards te verspreiden.

Reacties (44)

Wijzig sortering
Dit soort dingen krijg je er van met een web-app. Waar blijven de native apps die niet leunen op een in-app browser of iets dergelijks.
Een native desktop app kan niet voor WhatsApp zonder de end-to-end encryptie te breken. Telegram heeft volgens mij wel een desktop client.
Het kán wel, alleen slaat WhatsApp geen berichten op de server op waardoor het niet onafhankelijk naar alle apparaten gestuurd kan worden. Als jij een bericht stuurt, wordt dit direct doorgestuurd naar de WhatsApp client van de ontvanger en de buffer op server niveau geleegd.

Hierdoor kan een losse app hier niet op in springen. Daarom werken ze ook met een web-app die wordt 'gestreamed' vanaf de telefoon.

(Je telefoon is hier dan een relay die de berichten doorstuurt naar de web-app.)

[Reactie gewijzigd door xoniq op 15 maart 2017 15:23]

Dus als je met WA een berichtje stuurt en de ontvanger kan het berichtje niet ontvangen wegens bijv. geen bereik, kan deze het alleen ontvangen op een moment dat beiden toestellen bereik hebben? Alle andere situaties vergt immers opslag op een WA-server.
Hij bedoelt dat de berichten niet in plain-text op de server beschikbaar zijn. Slechts één apparaat heeft de sleutels om te decrypten. WhatsApp heeft dus wel een que om berichten in te zetten, maar kan ze zelf niet uitlezen en daardoor is het ook niet op andere apparaten te lezen zonder tussenkomst toestel met sleutels.
Klopt, echter was er vóór het encryptie verhaal ook een queue systeem, dat is hoe WhatsApp gebouwd is, gericht op één uniek apparaat/telefoonnummer. Als het bericht succesvol afgeleverd is wordt het uit de queue verwijderd, daarom hebben al langer tijd en intern backup systeem binnen de applicatie. Als je twee apparaten zou gebruiken, los van elkaar, en de ene haalt het bericht binnen, zou de andere dit niet meer mogen ontvangen.
Onzin, ttl van berichten kan gewoon ingesteld worden in MQs. WhatsApp heeft echter niet voor die implementatie gekozen.
Dus dat is hoe WhatsApp nu gebouwd is toch? Ten tijde van de implantatie.
Vergelijkbaar met het ouderwetse POP-protocol.

Hiervoor hebben ze denk ik gekozen omdat ze telefoonnummers als account aanmaken. Een apparaat == een account. Ik vind Apple's iMessage implementie een stuk beter uitgedacht.
Dat klopt, dat is (vrijwel) vanaf dag één al zo. Dat was ook een puntje toen ik de boel daar kraakte, maar dat authenticatie probleem is gelukkig al heel lang gepatched naar aanleiding daarvan. :P

Wat je zegt klopt, al heeft Signal een methode om dat wel op meerdere devices mogelijk te maken. Ik zelf ben daar niet zo'n voorstander van.
Ok. Maar met die queue, wat de WA-server is, is het dan nog steeds end-to-end?
Berichten in de queue zijn gewoon versleuteld. En waarschijnlijk is dat niet de enige security maatregel.
Juist een native app kan beter omgaan met e2ee. Je hebt namelijk een stabiele client, die gelijk is bij alle gebruikers. Je weet dus dat een beveilingsonderzoeker dezelfde versie heeft als die je zelf hebt. Open source is hier een hele grote bonus, maar niet strikt noodzakelijk.

Webversies daarentegen zijn niet compatibel met e2ee. De server kan willekeurig besluiten om een kwaadaardige javascript naar specifieke gebruikers die de encryptie keys uploaden naar de server. En er is niemand die absoluut ieder http request gaat controleren op zulk soort code.

Voorbeeld waarin iets soortgelijks (in 2007 al) is gebeurd:
https://www.wired.com/2007/11/encrypted-e-mai/
In dit specifieke geval ging het om een java client die iedere keer opnieuw wordt gedownload en dus per gebruiker anders kan zijn.

[Reactie gewijzigd door Youri219 op 15 maart 2017 16:03]

Juist een native app kan beter omgaan met e2ee. Je hebt namelijk een stabiele client, die gelijk is bij alle gebruikers. Je weet dus dat een beveilingsonderzoeker dezelfde versie heeft als die je zelf hebt. Open source is hier een hele grote bonus, maar niet strikt noodzakelijk.
Het punt is dat e2e niet gaat werken tenzij je op de desktop niet de berichtjes kan lezen die je op je telefoon had, en andersom.
Op zich kan het wel. Kijk maar naar iMessage, alleen heb je daar geen authenticatie; dat is een zwaktepunt omdat er dan ongezien meer apparaten toegevoegd zouden kunnen worden. (Of Apple dat doet is een tweede, maar als je Apple als adversary ziet moet je eigenlijk heel iMessage niet gebruiken...)
Signal heeft er ook een ingenieuze methode voor waarbij authenticatie nog wel kan werken, maar toch: hoe meer devices je private key hebben, hoe meer risico dat ze gejat worden.
iMessage heeft wel authenticatie hoor, tegenwoordig zelfs twee staps, toegangscode krijg je op een 'bekend' apparaat (Mac, iPhone, iPad) die al gebruik maakt van het account.
Ik bedoelde authenticatie op de encryptie, ik doelde niet op login functies. ;) Authenticatie bij encryptie; daarmee kan je controleren of je verbinding daadwerkelijk versleuteld is. Dus zoals WhatsApp heeft dat je de twee sleutels met elkaar kan vergelijken om te controleren of je encryptie wel werkt.
Dat snap ik, maar iMessage heeft ook gewoon end-to-end encryptie. Met de login functies doelde ik op dat er ongezien meerdere apparaten zouden kunnen worden toegevoegd, dat is dus niet zo. Elk apparaat waarop je iMessage activeert genereert een eigen private key.
Ahhhh dan snappen we elkaar verkeerd! :)
Ja waar ik op doelde, is dat Apple dus nog een extra apparaat zou kunnen toevoegen zonder dat jij daar iets van merkt. Vandaar ook mijn opmerking "als je Apple als adversary ziet, dan moet je iMessage niet gebruiken". Als je Apple vertrouwt, dan is dit natuurlijk geen probleem - alleen het feit dát het mogelijk is, dat vind ik zelf niet bijster prettig. Ik zie Apple niet als adversary, maar bepaalde machten in hun land wel. Nu zijn die vast niet in mij geïnteresseerd, maar ik heb toch liever niet dat ze m'n communicatie kunnen meelezen. Derhalve vermijd ik iMessage dan ook, omdat ik niet zeker kan weten of de encryptie actief is. (Al blijft het een Apple telefoon, dus Apple zou ook op andere wijze kunnen proberen toegang te verkrijgen - maar dan sla ik door, en zulke backdoors zijn niet bekend :))

iMessage is zeker end-to-end encrypt, en over het algemeen een zeer veilige messenger. Maar dat het mogelijk is voor hen om een device toe te voegen, waarop dan meegelezen kan worden, en ik dat op geen enkele wijze betrouwbaar kan verifiëren: dat maakt het voor mij toch een beetje eng platform. Al is het nog altijd tienduizend keer beter dan SMS natuurlijk. :)

Ik geef dan ook geen waardeoordeel over hun beveiliging hoor, iMessage is in principe een prima beveiligde dienst die je als normaal mens met een zeer gerust hart kunt gebruiken.
als signal het kan, moet whatsapp het ook kunnen
Dit klopt Telegram heeft een Desktop client, deze wordt niet aangetast door de hack.
Volgens mij maakt dit helemaal geen gebruik van een in-app browser. Je opent het html bestand in een externe browser, waarna je cookies worden geupload.
WhatsApp als 'native' app is een in-app browser. Er bestaat geen echte desktop client. Wat ze nu gebruiken is gewoon een mini-browser die niks anders kent dan web.whatsapp.com.
Dit klopt, het is daarom ook nutteloos om web whatsapp te installeren.
Dit soort dingen krijg je er van met een web-app. Waar blijven de native apps die niet leunen op een in-app browser of iets dergelijks.
De web app van Whatsapp kwam in reactie op het weglopen van gebruikers oa. richting Telegram, omdat je daar wel op meerdere apparaten kan inloggen, een feature waar veel vraag naar was.

Whatsapp heeft volgens mij daarom helemaal geen plannen voor native apps, ze houden je liever zo lang mogelijk op je mobiel tussen de Whatsapp, Facebook en Instagram apps binnen hun eigen reclame platform.
WhatsApp is hier ook technisch in beperkt door hun huidige infrastructuur. Het is sinds dag één bij WhatsApp ingericht als peer-to-peer met hun servers als tijdelijke buffer. Ze zullen dan vrij grote aanpassingen moeten doen om het om te gooien.
Native apps leunen op een OS. Dus tja.
Dus? Native apps kunnen ook met 'React' werken voor multi-platform etc. Het probleem met WhatsApp is dat het de-centralized werkt, waar Telegram de boel centraliseert op server-niveau. Telegram heeft dan ook daadwerkelijk native apps.
Ik dacht dat je insunineerde dat apps een groter ksn op veiligheidsproblemen hebben omdat ze leunen op een onderliggend platform, maar dat heb ik denk ik verkeerd begrepen ofzo. Mijn excuses.
Nee in dit geval gaat het dus niet om een native app, maar om een web-app. Je kan WhatsApp gebruiken via hun website (web.whatsapp.com) of via hun desktop app, wat slechts een mini-browser is die eveneens web.whatsapp.com gebruikt. En daardoor is het vrij vatbaar voor client-side injecties.

Als het een native app was, heb je meer kans op sandboxing waar je veel minder onheil van buitenaf hoeft te verwachten.
Alsof de webapp van whatsapp zo veilig is. De berichten worden niet eens versleuteld. Dat kan niet. Het idee is dat alléén je telefoon dat kan, en ja, de webapp moet verbinden met telefoon. Maar daarna kan ik m'n telefoon UIT zetten, en het blijft werken. Veiligheid m'n aars.

Ze hadden er een normale desktop app van moeten maken, die gewoon hetzelfde doet als de mobiele app.
Als je het actief kan blijven gebruiken, dan staat je telefoon niet uit.
Als je bedoelt dat de pagina actief blijft en je berichtjes kan blijven tikken: dat klopt, maar die worden dan niet verstuurd tenzij de page openblijft staan tot je mobiel weer online komt. Komt je mobiel niet terug online of pas als de page gesloten is? Dan worden berichten niet verstuurd.
De berichten waren wel verstuurd, en mobiel stond echt uit.

Ergo, OF de server kan de berichten decrypten, OF de private key wordt naar de webapp gestuurd, OF er wordt helemaal niets encrypted. Geen van deze opties is wenselijk.
Het is geen van allen, je zal het verkeerd gezien hebben...
De server kan de berichten niet decrypten. Er worden geen private keys naar de webapp gestuurd, en er wordt wel degelijk encryptie toegepast.

Het is niet mogelijk om WhatsApp Web of de Desktop client te gebruiken als je telefoon uitgeschakeld is. Technisch onmogelijk...
En toch werkte het. Ik weet het niet hoor, ik zeg gewoon wat ik gezien heb.
Telegram geeft wel degelijk een melding als er ergens anders ingelogd is:
Je login-code: *****

Met deze code kun je inloggen op je Telegram-account. We vragen deze code nooit voor iets anders. Geef deze code niet aan anderen, ook niet als ze zeggen dat ze voor Telegram werken!

Als jij deze code niet hebt aangevraagd om in te loggen op een ander apparaat kun je dit bericht negeren.
Maar mooi dat het gedicht is :)
Dit gaat niet om inloggen. Hier wordt een sessie op twee apparaten tegelijk uitgevoerd. Zonder in te loggen. Met de kwaadaardige afbeelding sta jij je sessie af aan een ander apparaat (van de aanvaller).

Dat kan dan ook enkel in de web-app, niet in de native desktop app.
Ah oke :) Dat is ook wat ik 90% van de tijd gebruik. Sowieso zal ik niet snel op linkjes van onbekenden klikken. Beetje gezond verstand.
Ikzelf open ook nooit zomaar wat, maar daardoor presenteren ze het ook met die Emoji's erachteraan, genoeg mensen die er dan sneller op klikken omdat het heel grappig schijnt te zijn.
Het slachtoffer zou in dat geval een mededeling te zien krijgen dat er op een andere locatie is ingelogd, maar deze is te omzeilen door gebruik van een aantal regels code om het browservenster van het slachtoffer te laten vastlopen.
De webversie van Whatsapp loopt bij mij om de haverklap vast en creëert een eindeloze feedback loop van notificaties (even het hele groeps gesprek van die dag notificatie voor notificatie doorspelen).

Dus dat zal niet eens opvallen.

[Reactie gewijzigd door batjes op 15 maart 2017 15:40]

Hun oplossing is client side validation? Dan is het gewoon wat moeilijker gemaakt om uit te voeren.
AL die pseudo-sociale-schoftware - 't mag mijn deur passeren - ik blokkeer gewoon via dns al die sites - dus er komt niks binnen en er gaat niks buiten. Ik ben bewust asociaal - en ik slaap nog altijd heel goed... (en als 't kan gaan we met mate(n) een pint pakken - dat is veel socialer verantwoord).
Op Twitter claimt Telegram dat deze bug niet van toepassing was op hun webclient en linken ze naar dit artikel.

Op dit item kan niet meer gereageerd worden.


Nintendo Switch Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*