Zoom för Mac korrigerar lömsk "spion-on-me"-bugg – uppdatera nu!

Populärt och allestädes närvarande (mjukvara är inte alltid båda dessa saker!) molnmötesföretaget Zoom tillkännagav nyligen en oj-som-inte-behövde-hända-bugg i Mac-versionen av sin programvara.

Säkerhetsbulletinen är, förlåtligt, skriven i den typiskt staccato och jargongdränkta stilen av buggjägare, men innebörden är ganska tydlig.

Felet betecknas CVE-2022-28762, och är detaljerad i Zoombulletin ZB-22023:

När kontext för rendering av kameraläge är aktiverat som en del av Zoom App Layers API genom att köra vissa Zoom-appar, öppnas en lokal felsökningsport av Zoom-klienten.

Vart vill du åka idag?

En "debugging-port" hänvisar vanligtvis till en lyssnande nätverksanslutning, vanligtvis en TCP-socket, som hanterar felsökningsförfrågningar.

På samma sätt som en e-postserver vanligtvis lyssnar på TCP-port 25 och väntar på att fjärranslutna e-postklienter ska "ringa in" över nätverket och begära tillstånd att leverera inkommande meddelanden, lyssnar felsökningsportar på en port som de själva väljer (ofta konfigurerbara, men ibland bara på ett odokumenterat sätt) för inkommande anslutningar som vill utfärda felsökningskommandon.

Till skillnad från en e-postserver, som dock accepterar förfrågningar som rör meddelandeleverans (t.ex MAIL FROM och RCPT TO), ger felsökningsanslutningar vanligtvis en mycket mer intim typ av interaktion med appen du ansluter till.

Faktum är att felsökningsportar i allmänhet tillåter dig inte bara att ta reda på konfigurationen och det interna tillståndet för själva appen, utan också att utfärda kommandon direkt till appen, inklusive den typ av säkerhetsnedbrytande kommandon som inte är tillgängliga för vanliga användare som går via det vanliga användargränssnittet.

En e-postserver, till exempel, låter dig vanligtvis skicka ett meddelande till dess TCP-port för ett valfritt användarnamn, men den låter dig inte skicka kommandon som omkonfigurerar själva servern, och den låter dig inte extrahera hemlig information som serverstatistik eller andras meddelanden.

Däremot är det exakt den sortens "funktioner" som felsökningsportar vanligtvis tillåter, så att utvecklare kan justera och övervaka beteendet hos sin app medan de försöker fixa problem, utan att behöva gå igenom det vanliga användargränssnittet.

(Du kan se hur den här typen av "sidokanal" in i en applikation skulle vara särskilt praktisk när du försöker felsöka själva användargränssnittet, med tanke på att handlingen att använda gränssnittet för att felsöka gränssnittet nästan säkert skulle störa med just de mätningar du försökte göra.)

Noterbart är att felsökningsportar vanligtvis låter dig få en slags "intern vy" av själva appen, till exempel: kika in i minnesområden som vanligtvis aldrig skulle exponeras för användare av appen; ta tag i ögonblicksbilder av data som kan innehålla konfidentiell data som lösenord och åtkomsttokens; och utlöser ljud- eller videoinspelningar utan att varna användaren...

…allt utan att logga in i appen eller tjänsten i första hand.

Med andra ord är felsökningsportar ett nödvändigt ont för användning under utveckling och testning, men de är inte tänkta att aktiveras, eller helst ens vara aktiverbara, under regelbunden användning av appen, på grund av de uppenbara säkerhetshålen de introducerar.

Inget lösenord behövs

Löst sagt, om du har tillgång till TCP-porten som felsökaren lyssnar på, och du kan skapa en TCP-anslutning till den, är det all autentisering du behöver för att ta över appen.

Och det är därför felsökningsportar vanligtvis bara aktiveras under noggrant kontrollerade omständigheter, när du vet att du faktiskt vill tillåta en utvecklare att kunna vandra runt i applikationen och njuta av vad som är effektivt oreglerad och potentiellt farlig supermaktsåtkomst.

Faktum är att många mjukvaruprodukter är avsiktligt byggda i två olika varianter: en debug-build, där felsökning kan aktiveras om så önskas, och en release-build där felsökningsfunktionerna helt utelämnas så att de inte kan aktiveras alls, vare sig av olycka eller genom design.

Googles Android-telefoner inkluderar ett felsökningsläge, där du kan koppla in en USB-kabel och gräva in telefonen (om än inte med full rotkraft) från din bärbara dator via det som kallas ADB, förkortning för Android Debug Bridge. För att aktivera felsökning överhuvudtaget måste du först klicka på Inställningar > Om telefonen > Bygga nummer sju gånger (på riktigt!) i rad. Först då dyker alternativet att aktivera felsökning ens i menyerna, där du kan aktivera det på Inställningar > Systemkrav > Advanced Open water > utvecklare Alternativ > USB felsökning. Sedan, när du kopplar in och försöker ansluta från din bärbara dator, måste du auktorisera anslutningen via en varningspopup på själva telefonen. Du kan säkert göra detta med flit, om du har fysisk tillgång till en olåst telefon, men det är osannolikt att det händer av misstag.

För ytterligare säkerhet ställs ofta felsökningsportar in så att de inte accepterar anslutningar som kommer in från andra datorer (i tekniska termer lyssnar de bara på "localhost"-gränssnittet).

Detta innebär att en angripare som försöker missbruka ett felaktigt aktiverat felsökningsgränssnitt skulle behöva fotfäste på din dator först, till exempel någon sorts proxy-skadlig programvara som själv accepterar anslutningar via internet och sedan vidarebefordrar sina nätverkspaket till "localhost" nätverksgränssnittet.

Trots behovet av någon form av lokal åtkomst i fallet med CVE-2022-28762, gav Zoom dock denna bugg ett CVSS "allvarlighetspoäng" på 7.3/10 (73 %) och ett brådskande betyg på Hög.

Lokala TCP-nätverksanslutningar är vanligtvis utformade för att fungera över användar- och processgränser, så en angripare skulle inte behöva vara inloggad som du (eller som administratör) för att missbruka denna bugg – vilken process som helst, även ett program som körs under en mycket begränsad gästkonto, kanske kan spionera på dig efter behag.

Dessutom, eftersom programvarukommandon som utfärdas via en felsökningsport vanligtvis fungerar oberoende av en apps vanliga användargränssnitt, skulle du förmodligen inte se några giveaway-tecken på att din Zoom-session hade kapats på detta sätt.

Om en angripare aktiverade appen via mer konventionella Mac-fjärrkontrollkanaler som skärmdelning (VNC), skulle du åtminstone ha en chans att se angriparen flytta runt din muspekare, klicka på menyknappar eller skriva in text...

…men via ett felsökningsgränssnitt, som i grunden är en avsiktlig bakdörr, kan du vara lyckligt omedveten (och kanske till och med inte kunna upptäcka) att en angripare snokade på dig väldigt personligt med hjälp av din webbkamera och din mikrofon.

Vad göra?

Lyckligtvis upptäckte Zooms eget säkerhetsteam vad vi antar var en blunder under byggtiden (en funktion kvar aktiverad som borde ha undertryckts) och uppdaterade omedelbart den buggiga Mac-mjukvaran.

Uppdatera till din macOS Zoom Client till version 5.12.0 eller senare och felsökningsporten förblir stängd när du använder Zoom.

På en Mac, gå till huvudmenyn zoom.us menyn och välj Check for Updates... för att se om du har den senaste versionen.

---