Zoom til Mac retter luskede "spion-på-mig"-fejl – opdater nu!

Populært og allestedsnærværende (software er ikke altid begge disse ting!) cloud-mødefirmaet Zoom annoncerede for nylig en ups-det-ikke-skulle-ske-fejl i Mac-versionen af ​​sin software.

Sikkerhedsbulletinen er, tilgiveligt, skrevet i den typiske staccato og jargon-gennemblødte stil af bug-jægere, men meningen er ret klar.

Fejlen er angivet CVE-2022-28762, og er detaljeret i Zoom Bulletin ZB-22023:

Når gengivelseskontekst for kameratilstand er aktiveret som en del af Zoom App Layers API ved at køre visse Zoom-apps, åbnes en lokal fejlretningsport af Zoom-klienten.

Hvor vil du gerne hen i dag?

En "debugging-port" refererer typisk til en lyttende netværksforbindelse, normalt en TCP-socket, der håndterer debugging-anmodninger.

På samme måde som en e-mail-server normalt lytter på TCP-port 25 og venter på, at eksterne e-mail-klienter "ringer ind" over netværket og anmoder om tilladelse til at levere indgående meddelelser, lytter fejlfindingsporte på en port efter eget valg (ofte kan konfigureres, dog nogle gange kun på en udokumenteret måde) for indgående forbindelser, der ønsker at udstede fejlretningskommandoer.

I modsætning til en e-mail-server, der dog accepterer anmodninger vedrørende levering af meddelelser (f MAIL FROM , RCPT TO), giver fejlretningsforbindelser normalt en meget mere intim form for interaktion med den app, du opretter forbindelse til.

Faktisk giver debugging-porte dig generelt ikke kun mulighed for at finde ud af konfigurationen og den interne tilstand af selve appen, men også at udstede kommandoer direkte til appen, inklusive den slags sikkerhedsnedbrydende kommandoer, der ikke er tilgængelige for almindelige brugere, der går via den almindelige brugergrænseflade.

En e-mail-server, for eksempel, vil typisk lade dig sende en besked til dens TCP-port for et brugernavn efter eget valg, men den vil ikke lade dig sende kommandoer, der rekonfigurerer selve serveren, og den vil ikke lade dig udtrække hemmelige oplysninger såsom serverstatistik eller andres beskeder.

I modsætning hertil er det præcis den slags "funktioner", som fejlretningsporte normalt tillader, så udviklere kan justere og overvåge adfærden af ​​deres app, mens de forsøger at løse problemer, uden at skulle gå gennem den almindelige brugergrænseflade.

(Du kan se, hvordan denne form for "side-kanal" ind i en applikations indvolde vil være særlig praktisk, når du forsøger at fejlsøge selve brugergrænsefladen, da det næsten helt sikkert ville interferere med at bruge brugergrænsefladen til at fejle brugergrænsefladen. med netop de målinger, du forsøgte at foretage.)

Navnlig giver fejlfindingsporte dig typisk mulighed for at få en slags "intern visning" af selve app'en, såsom: kig ind i områder af hukommelsen, der normalt aldrig ville blive eksponeret for brugere af appen; at få fat i snapshots af data, der kunne indeholde fortrolige data såsom adgangskoder og adgangstokens; og udløser lyd- eller videooptagelser uden at advare brugeren...

…alt uden at logge ind på appen eller tjenesten i første omgang.

Med andre ord er debugging-porte et nødvendigt onde til brug under udvikling og test, men de formodes ikke at blive aktiveret, eller ideelt set endda at være aktiverbare, under regelmæssig brug af appen, på grund af de åbenlyse sikkerhedshuller, de introducerer.

Ingen adgangskode nødvendig

Løst sagt, hvis du har adgang til den TCP-port, som debuggeren lytter til, og du kan oprette en TCP-forbindelse til den, er det al den godkendelse, du skal bruge for at overtage appen.

Og det er derfor, debugging-porte typisk kun er aktiveret under nøje kontrollerede omstændigheder, når du ved, at du faktisk vil tillade en udvikler at kunne vandre rundt lige inde i applikationen og nyde, hvad der er effektivt ureguleret og potentielt farlig supermagtsadgang.

Faktisk er mange softwareprodukter bevidst bygget i to forskellige varianter: en debug build, hvor debugging kan aktiveres, hvis det ønskes, og en release build, hvor fejlfindingsfunktionerne er udeladt helt, så de slet ikke kan aktiveres, uanset om uheld eller ved design.

Googles Android-telefoner inkluderer en debug-tilstand, hvor du kan tilslutte et USB-kabel og grave ind i telefonen (omend ikke med fuld rodkraft) fra din bærbare computer via det, der er kendt som ADB, en forkortelse for Android Debug Bridge. For overhovedet at aktivere debugging skal du først klikke på Indstillinger > Om telefon > Bygge nummer syv gange (virkelig!) i træk. Først derefter dukker muligheden for at slå fejlsøgning til endda op i menuerne, hvor du kan aktivere den kl Indstillinger > Systemkrav > Avanceret > Udvikler Options > USB debugging. Derefter, når du tilslutter og prøver at oprette forbindelse fra din bærbare computer, skal du godkende forbindelsen via en advarselspop-up på selve telefonen. Du kan helt sikkert gøre dette med vilje, hvis du har fysisk adgang til en ulåst telefon, men det er usandsynligt, at det sker ved en fejl.

For yderligere sikkerhed er debugging-porte ofte sat op, så de ikke accepterer forbindelser, der kommer ind fra andre computere (i tekniske termer lytter de kun på "localhost"-grænsefladen).

Dette betyder, at en angriber, der søger at misbruge en forkert aktiveret fejlfindingsgrænseflade, først skal have fodfæste på din computer, såsom en slags proxy-malware, der selv accepterer forbindelser via internettet og derefter videresender sine netværkspakker til "localhost"-netværksgrænsefladen.

På trods af behovet for en form for lokal adgang i tilfældet med CVE-2022-28762, gav Zoom imidlertid denne fejl en CVSS "alvorlighedsscore" på 7.3/10 (73%) og en hastevurdering på Høj.

Lokale TCP-netværksforbindelser er typisk designet til at fungere på tværs af bruger- og procesgrænser, så en angriber behøver ikke at være logget ind som dig (eller som administrator) for at misbruge denne fejl – enhver proces, selv et program, der kører under en meget begrænset gæstekonto, kan muligvis spionere på dig efter behag.

Fordi softwarekommandoer, der udsendes via en debugging-port, typisk fungerer uafhængigt af en apps almindelige brugergrænseflade, vil du sandsynligvis ikke se nogen giveaway-tegn på, at din Zoom-session var blevet kapret på denne måde.

Hvis en angriber aktiverede appen via mere konventionelle Mac-fjernbetjeningskanaler såsom Screen Sharing (VNC), ville du i det mindste have en chance for at se angriberen flytte din musemarkør rundt, klikke på menuknapper eller skrive tekst ...

…men via en fejlretningsgrænseflade, som i bund og grund er en bevidst bagdør, er du måske lykkeligt uvidende om (og måske endda ude af stand til at opdage), at en angriber snoede efter dig meget personligt ved hjælp af dit webcam og din mikrofon.

Hvad skal jeg gøre?

Heldigvis opdagede Zooms eget sikkerhedsteam, hvad vi antager, var en bommert i byggetiden (en funktion, der blev forladt aktiveret, som burde have været undertrykt), og opdaterede omgående den buggy Mac-software.

Opdater til din macOS Zoom Client til version 5.12.0 eller nyere og fejlretningsporten forbliver lukket, når du bruger Zoom.

På en Mac skal du gå til hovedmenuen zoom.us menuen og vælg Check for Updates... for at se, om du har den nyeste version.

---