Zoom for Mac retter sleipe "spion-på-meg"-feil – oppdater nå!

Populært og allestedsnærværende (programvare er ikke alltid begge disse tingene!) skymøteselskapet Zoom annonserte nylig en ups-som-ikke-skulle skje-feil i Mac-versjonen av programvaren.

Sikkerhetsbulletinen er, tilgivelig, skrevet i den typiske staccato og sjargong-gjennomvåte stilen til insektjegere, men meningen er ganske klar.

Feilen er merket CVE-2022-28762, og er detaljert i Zoom Bulletin ZB-22023:

Når gjengivelseskontekst for kameramodus er aktivert som en del av Zoom App Layers API ved å kjøre visse Zoom-apper, åpnes en lokal feilsøkingsport av Zoom-klienten.

Hvor vil du reise i dag?

En "feilsøkingsport" refererer vanligvis til en lyttende nettverkstilkobling, vanligvis en TCP-kontakt, som håndterer feilsøkingsforespørsler.

På samme måte som en e-postserver vanligvis lytter på TCP-port 25 og venter på at eksterne e-postklienter skal "ringe inn" over nettverket og be om tillatelse til å levere innkommende meldinger, lytter feilsøkingsporter på en port som de selv velger (ofte konfigurerbar, men noen ganger bare på en udokumentert måte) for innkommende tilkoblinger som ønsker å utstede feilsøkingskommandoer.

I motsetning til en e-postserver, men som godtar forespørsler knyttet til meldingslevering (f MAIL FROM og RCPT TO), gir feilsøkingstilkoblinger vanligvis en mye mer intim form for interaksjon med appen du kobler til.

Faktisk lar feilsøkingsporter deg generelt ikke bare finne ut om konfigurasjonen og den interne tilstanden til selve appen, men også å utstede kommandoer direkte til appen, inkludert typen sikkerhetsdempende kommandoer som ikke er tilgjengelige for vanlige brukere som går via det vanlige brukergrensesnittet.

En e-postserver, for eksempel, vil vanligvis la deg sende en melding til TCP-porten for et brukernavn du ønsker, men den lar deg ikke sende kommandoer som rekonfigurerer selve serveren, og den lar deg ikke trekke ut hemmelig informasjon som serverstatistikk eller andres meldinger.

I motsetning til dette er det akkurat den typen "funksjoner" som feilsøkingsporter vanligvis tillater, slik at utviklere kan justere og overvåke oppførselen til appen deres mens de prøver å fikse problemer, uten å måtte gå gjennom det vanlige brukergrensesnittet.

(Du kan se hvordan denne typen "sidekanal" inn i tarmene til en applikasjon vil være spesielt nyttig når du prøver å feilsøke selve brukergrensesnittet, gitt at det å bruke brukergrensesnittet til å feilsøke brukergrensesnittet nesten helt sikkert vil forstyrre med selve målingene du prøvde å gjøre.)

Spesielt, feilsøkingsporter lar deg vanligvis få en slags "intern visning" av selve appen, for eksempel: kikke inn i områder av minnet som vanligvis aldri vil bli eksponert for brukere av appen; gripe øyeblikksbilder av data som kan inneholde konfidensielle data som passord og tilgangstokener; og utløser lyd- eller videoopptak uten å varsle brukeren...

...alt uten å logge på appen eller tjenesten i utgangspunktet.

Med andre ord er feilsøkingsporter et nødvendig onde for bruk under utvikling og testing, men de er ikke ment å være aktivert, eller ideelt sett til og med å være aktiverbare, under vanlig bruk av appen, på grunn av de åpenbare sikkerhetshullene de introduserer.

Ingen passord nødvendig

Løst sagt, hvis du har tilgang til TCP-porten som debuggeren lytter til, og du kan opprette en TCP-tilkobling til den, er det all autentiseringen du trenger for å ta over appen.

Og det er derfor feilsøkingsporter vanligvis bare er aktivert under nøye kontrollerte omstendigheter, når du vet at du faktisk vil la en utvikler kunne vandre rundt rett inne i applikasjonen og nyte det som er effektivt uregulert og potensielt farlig supermakttilgang.

Faktisk er mange programvareprodukter bevisst bygget i to forskjellige varianter: en debug build, der debugging kan slås på om ønskelig, og en release build der feilsøkingsfunksjonene er utelatt helt slik at de ikke kan aktiveres i det hele tatt, enten uhell eller ved design.

Googles Android-telefoner inkluderer en feilsøkingsmodus, der du kan koble til en USB-kabel og grave inn i telefonen (om enn ikke med full rotkraft) fra den bærbare datamaskinen din via det som kalles ADB, forkortelse for Android Debug Bridge. For å aktivere feilsøking i det hele tatt, må du først klikke på innstillinger > Om telefonen > Bygg nummer syv ganger (virkelig!) på rad. Først da vises til og med muligheten for å slå på feilsøking i menyene, hvor du kan aktivere den på innstillinger > System > Avansert > Developer Options > USB feilsøking. Deretter, når du kobler til og prøver å koble til fra den bærbare datamaskinen, må du autorisere tilkoblingen via en advarselspopup på selve telefonen. Du kan sikkert gjøre dette med vilje, hvis du har fysisk tilgang til en ulåst telefon, men det er usannsynlig at det skjer ved en feiltakelse.

For ekstra sikkerhet er feilsøkingsporter ofte satt opp slik at de ikke godtar tilkoblinger som kommer inn fra andre datamaskiner (i tekniske termer lytter de kun på "localhost"-grensesnittet).

Dette betyr at en angriper som prøver å misbruke et feil aktivert feilsøkingsgrensesnitt, vil trenge fotfeste på datamaskinen din først, for eksempel en slags proxy-malware som i seg selv aksepterer tilkoblinger via internett, og deretter videresender nettverkspakkene til nettverksgrensesnittet "localhost".

Til tross for behovet for en slags lokal tilgang i tilfellet med CVE-2022-28762, ga Zoom imidlertid denne feilen en CVSS "alvorlighetsscore" på 7.3/10 (73%), og en hastevurdering på Høy.

Lokale TCP-nettverkstilkoblinger er vanligvis utformet for å fungere på tvers av bruker- og prosessgrenser, så en angriper trenger ikke å være logget på som deg (eller som administrator) for å misbruke denne feilen – enhver prosess, selv et program som kjører under en svært begrenset gjestekonto, kan være i stand til å spionere på deg etter eget ønske.

Videre, fordi programvarekommandoer utstedt via en feilsøkingsport vanligvis fungerer uavhengig av appens vanlige brukergrensesnitt, vil du sannsynligvis ikke se noen giveaway-tegn på at Zoom-økten din har blitt kapret på denne måten.

Hvis en angriper aktiverer appen via mer konvensjonelle Mac-fjernkontrollkanaler som Screen Sharing (VNC), ville du i det minste ha en sjanse til å se angriperen bevege musepekeren rundt, klikke på menyknapper eller skrive inn tekst...

…men via et feilsøkingsgrensesnitt, som i hovedsak er en bevisst bakdør, kan du være lykkelig uvitende (og kanskje til og med ute av stand til å oppdage) at en angriper snoket etter deg veldig personlig ved å bruke webkameraet og mikrofonen din.

Hva gjør jeg?

Heldigvis oppdaget Zooms eget sikkerhetsteam det vi antar var en byggetidsfeil (en funksjon som ble aktivert som burde vært undertrykt), og oppdaterte den buggy Mac-programvaren umiddelbart.

Oppdater til macOS Zoom Client til versjon 5.12.0 eller nyere og feilsøkingsporten forblir stengt når du bruker Zoom.

Gå til hovedmenyen på en Mac zoom.us menyen og velg Check for Updates... for å se om du har den nyeste versjonen.

---