Zoom voor Mac lost stiekeme "spy-on-me" bug op - update nu!

Populair en alomtegenwoordig (software is niet altijd beide!) cloud meeting bedrijf Zoom heeft onlangs een oeps-dat-niet-moest gebeuren-bug aangekondigd in de Mac-versie van zijn software.

Het beveiligingsbulletin is, vergeeflijk, geschreven in de typische staccato- en jargon-doordrenkte stijl van bugjagers, maar de betekenis is vrij duidelijk.

De bug wordt aangegeven CVE-2022-28762, en is gedetailleerd in Zoombulletin ZB-22023:

Wanneer de weergavecontext van de cameramodus is ingeschakeld als onderdeel van de Zoom App Layers API door bepaalde Zoom-apps uit te voeren, wordt een lokale foutopsporingspoort geopend door de Zoom-client.

Waar wil je vandaag heen?

Een "foutopsporingspoort" verwijst meestal naar een luisterende netwerkverbinding, meestal een TCP-socket, die foutopsporingsverzoeken afhandelt.

Op dezelfde manier waarop een e-mailserver gewoonlijk luistert op TCP-poort 25, wachtend op externe e-mailclients om via het netwerk "in te bellen" en toestemming te vragen om inkomende berichten te bezorgen, luisteren foutopsporingspoorten op een poort naar eigen keuze (vaak configureerbaar, hoewel soms alleen op een ongedocumenteerde manier) voor inkomende verbindingen die debug-opdrachten willen geven.

In tegenstelling tot een e-mailserver die verzoeken accepteert met betrekking tot de bezorging van berichten (bijv MAIL FROM en RCPT TO), biedt het debuggen van verbindingen meestal een veel intiemer soort interactie met de app waarmee u verbinding maakt.

Door poorten te debuggen, kunt u over het algemeen niet alleen meer te weten komen over de configuratie en interne status van de app zelf, maar ook om opdrachten rechtstreeks aan de app te geven, inclusief het soort beveiligingsondermijnende opdrachten die niet beschikbaar zijn voor gewone gebruikers die gaan via de reguliere gebruikersinterface.

Een e-mailserver laat je bijvoorbeeld meestal een bericht naar zijn TCP-poort sturen voor een gebruikersnaam naar keuze, maar je kunt er geen commando's mee sturen die de server zelf opnieuw configureren, en je kunt er geen geheime informatie uit halen. zoals serverstatistieken of berichten van anderen.

Daarentegen zijn dit precies het soort "functies" die het debuggen van poorten gewoonlijk toestaan, zodat ontwikkelaars het gedrag van hun app kunnen aanpassen en volgen terwijl ze problemen proberen op te lossen, zonder dat ze door de reguliere gebruikersinterface hoeven te gaan.

(Je kunt zien hoe dit soort "zijkanaal" in het lef van een applicatie vooral handig zou zijn als je probeert de gebruikersinterface zelf te debuggen, aangezien het gebruik van de gebruikersinterface om de gebruikersinterface te debuggen vrijwel zeker zou interfereren met de metingen die u probeerde te maken.)

Met name laat het debuggen van poorten je meestal een soort "intern beeld" van de app zelf krijgen, zoals: gluren in geheugengebieden die normaal nooit zouden worden blootgesteld aan gebruikers van de app; het grijpen van momentopnamen van gegevens die vertrouwelijke gegevens kunnen bevatten, zoals wachtwoorden en toegangstokens; en het activeren van audio- of video-opnames zonder de gebruiker te waarschuwen...

...allemaal zonder in te loggen op de app of service.

Met andere woorden, het debuggen van poorten is een noodzakelijk kwaad voor gebruik tijdens ontwikkeling en testen, maar het is niet de bedoeling dat ze worden geactiveerd, of idealiter zelfs niet geactiveerd kunnen worden, tijdens regelmatig gebruik van de app, vanwege de duidelijke beveiligingslekken die ze introduceren.

Geen wachtwoord nodig

Losjes gesproken, als je toegang hebt tot de TCP-poort waarop de debugger luistert, en je kunt er een TCP-verbinding mee maken, dan is dat alle authenticatie die je nodig hebt om de app over te nemen.

En dat is de reden waarom foutopsporingspoorten meestal alleen worden ingeschakeld onder zorgvuldig gecontroleerde omstandigheden, wanneer je weet dat je een ontwikkelaar echt wilt laten ronddwalen in de applicatie, genietend van wat in feite ongereguleerde en potentieel gevaarlijke superkrachttoegang is.

Veel softwareproducten zijn namelijk bewust gebouwd in twee verschillende smaken: een debug-build, waarbij debugging desgewenst kan worden ingeschakeld, en een release-build waarin de debugging-functies helemaal worden weggelaten, zodat ze helemaal niet kunnen worden geactiveerd, hetzij door ongeluk of door opzet.

De Android-telefoons van Google bevatten een debug-modus, waarbij je een USB-kabel kunt aansluiten en vanaf je laptop in de telefoon kunt graven (zij het niet met volledige root-powers) via wat bekend staat als de ADB, een afkorting van Android-foutopsporingsbrug. Om foutopsporing überhaupt in te schakelen, moet u eerst op . klikken Instellingen > Over Phone > Nummer bouwen zeven keer (echt waar!) achter elkaar. Alleen dan verschijnt de optie om foutopsporing in te schakelen zelfs in de menu's, waar u deze kunt activeren op Instellingen > Systeem > Geavanceerd > Developer Options > USB debugging. Wanneer u vervolgens de stekker in het stopcontact steekt en verbinding probeert te maken vanaf uw laptop, moet u de verbinding autoriseren via een waarschuwingspop-up op de telefoon zelf. Je kunt dit zeker expres doen als je fysieke toegang hebt tot een ontgrendelde telefoon, maar het is onwaarschijnlijk dat dit per ongeluk gebeurt.

Voor extra veiligheid worden foutopsporingspoorten vaak zo ingesteld dat ze geen verbindingen accepteren die binnenkomen vanaf andere computers (in technische termen luisteren ze alleen op de "localhost"-interface).

Dit betekent dat een aanvaller die misbruik wil maken van een onjuist ingeschakelde foutopsporingsinterface, eerst voet aan de grond moet hebben op uw computer, zoals een soort proxy-malware die zelf verbindingen via internet accepteert en vervolgens zijn netwerkpakketten doorstuurt naar de "localhost" -netwerkinterface.

Ondanks de noodzaak van een soort van lokale toegang in het geval van CVE-2022-28762, gaf Zoom deze bug echter een CVSS-"ernstscore" van 7.3/10 (73%) en een urgentiebeoordeling van Hoge.

Lokale TCP-netwerkverbindingen zijn meestal ontworpen om over gebruikers- en procesgrenzen heen te werken, dus een aanvaller hoeft niet ingelogd te zijn als u (of als beheerder) om deze bug te misbruiken - elk proces, zelfs een programma dat draait onder een zeer beperkte gastaccount, kan u naar believen bespioneren.

Bovendien, omdat softwarecommando's die via een foutopsporingspoort worden uitgegeven, meestal onafhankelijk van de normale gebruikersinterface van een app werken, zou je waarschijnlijk geen weggeeftekens zien dat je Zoom-sessie op deze manier is gekaapt.

Als een aanvaller de app zou activeren via meer conventionele Mac-afstandsbedieningskanalen zoals Screen Sharing (VNC), zou je op zijn minst een kans hebben om de aanvaller te zien die je muisaanwijzer beweegt, op menuknoppen klikt of tekst intypt...

... maar via een foutopsporingsinterface, die in wezen een opzettelijke achterdeur is, zou je je er niet van bewust kunnen zijn (en misschien zelfs niet in staat zijn om te detecteren) dat een aanvaller je heel persoonlijk bespiedde, met behulp van je webcam en je microfoon.

Wat te doen?

Gelukkig ontdekte Zoom's eigen beveiligingsteam wat volgens ons een blunder tijdens de bouw was (een functie die nog was ingeschakeld en die onderdrukt had moeten worden), en heeft de Mac-software met fouten onmiddellijk bijgewerkt.

Update naar uw macOS Zoom Client naar versie 5.12.0 of hoger en de foutopsporingspoort blijft gesloten wanneer u Zoom gebruikt.

Ga op een Mac naar het hoofdmenu zoom.us menu en kies Check for Updates... om te zien of je de laatste versie hebt.

---