Zoom til Mac-patches få root-fejl – opdater nu!

På det velkendte DEF CON sikkerheds-shindig i Las Vegas, Nevada, i sidste uge, Mac cybersikkerhedsforsker Patrick Wardle afslørede en "get-root" forhøjelse af privilegium (EoP) fejl i Zoom til Mac:

Mahalo til alle der kom til mig @defcon snak "Du er M̶u̶t̶e̶d̶ rodfæstet" 🙏🏽

Blev begejstret for at tale om (& live-demo 😅) en lokal priv-esc sårbarhed i Zoom (til macOS).

I øjeblikket er der ingen patch 👀😱

Slides med alle detaljer og PoC-udnyttelse: https://t.co/viee0Yd5o2 #0 dag pic.twitter.com/9dW7DdUm7P

— patrick wardle (@patrickwardle) August 12, 2022

I tweetet, som fulgte hans tale [2022-08-12], bemærkede Wardle:

I øjeblikket er der ingen plaster [:FRIED-EGG EYES DEPICTING ALARM EMOJI:] [:EDVARD MUNCH SCREAM EMOJI:]

Zoom arbejdede straks på en patch til fejlen, som blev annonceret dagen efter Zoom sikkerhedsbulletin ZSB-22018, fortjener et tillykke svar fra Wardle i processen:

Mahalos til @Zoom for den (utroligt) hurtige løsning! [:BEGGE HÆNDER RÆVEDE I FEJL OG VIKLEDE OM EMOJI:] [:PALMER PRESSET SAMMEN TIL TEGN PÅ ÅNDELIG GODVILJE EMOJI:]

Nul-dages afsløring

I betragtning af den tilsyneladende hastighed og lethed, hvormed Zoom var i stand til at udsende en patch til fejlen, døbt CVE-2022-28756, undrer du dig sikkert over, hvorfor Wardle ikke fortalte Zoom om fejlen på forhånd og satte dagen for sin tale som deadline for at afsløre detaljerne.

Det ville have givet Zoom tid til at skubbe opdateringen ud til sine mange Mac-brugere (eller i det mindste gøre den tilgængelig for dem, der tror på lappe tidligt/lappe ofte), og eliminerer dermed kløften mellem Wardle, der forklarer verden, hvordan man misbruger fejlen, og patchen af ​​fejlen.

Faktisk ser det ud til, at Wardle gjorde sit bedste for at advare Zoom om denne fejl, plus en masse indbyrdes forbundne fejl i Zooms autoopdateringsproces for nogle måneder siden.

Wardle forklarer tidslinjen for afsløring af fejl i dias fra hans DEF CON talk, og viser en strøm af Zoom-opdateringer relateret til de fejl, han opdagede.

Et dobbeltkantet sværd

De fejl, som Wardle diskuterede, var generelt relateret til Zooms automatiske opdateringsmekanisme, en del af ethvert softwareøkosystem, der er lidt af et tveægget sværd – et kraftigere våben end et almindeligt sværd, men tilsvarende sværere at håndtere sikkert.

Automatisk opdatering er en must-have-komponent i enhver moderne klientapplikation, da den gør kritiske patches nemmere og hurtigere at distribuere og dermed hjælper brugerne med at lukke huller i cybersikkerheden pålideligt.

Men automatisk opdatering bringer et hav af risici med sig, ikke mindst fordi selve opdateringsværktøjet typisk har behov for systemadgang på rodniveau.

Det er fordi opdateringsprogrammets opgave er at overskrive applikationssoftwaren (noget som en almindelig bruger ikke skal gøre), og måske at starte privilegerede operativsystemkommandoer for at foretage konfiguration eller andre ændringer på systemniveau.

Med andre ord, hvis udviklerne ikke er forsigtige, kan selve det værktøj, der hjælper dem med at holde deres underliggende app opdateret og mere sikker, blive et strandhoved, hvorfra angribere kan undergrave sikkerheden ved at narre opdateringsprogrammet til at køre uautoriserede kommandoer med systemprivilegier .

Især skal automatiske opdateringsprogrammer sørge for at verificere ægthed af de opdateringspakker, de downloader, for at forhindre, at angribere blot fodrer dem med en falsk opdateringspakke, komplet med tilføjet malware.

De skal også vedligeholde integritet af de opdateringsfiler, som de i sidste ende bruger, så en lokal angriber ikke snigende kan ændre den "verificerede sikre" opdateringspakke, der netop er blevet downloadet i den korte periode mellem den blev hentet og aktiveret.

Omgåelse af ægthedskontrollen

Som Wardle forklarer i sin papir, en af ​​de fejl, han opdagede og afslørede, var en fejl i det første trin angivet ovenfor, da Zooms automatiske opdatering forsøgte at bekræfte ægtheden af ​​den opdateringspakke, den lige havde downloadet.

I stedet for at bruge de officielle macOS API'er til at validere den digitale signatur af download direkte, besluttede Zoom-udviklere at udføre godkendelsen indirekte ved at køre macOS-værktøjet pkgutil --check-signature i baggrunden og undersøge outputtet.

Her er et eksempel på pkgutil output, ved hjælp af en gammel version af Zoom.pkg softwarepakke:

$ pkgutil --check-signature Zoom.pkg Pakke "Zoom.pkg": Status: underskrevet af et udviklercertifikat udstedt af Apple til distribution Underskrevet med et betroet tidsstempel på: 2022-06-27 01:26:22 +0000 Certificate Chain : 1. Udvikler-id Installatør: Zoom Video Communications, Inc. (BJ4HAAB9B3) Udløber: 2027-02-01 22:12:15 +0000 SHA256 Fingeraftryk: 6D 70 1A 84 F0 5A D4 C1 C1 C3 AE AE 01 FB 2F 1C A2 9 5 A6 80 48 FF B4 F76 60 BB 5C ------------------------------------------ -------------------------------------- 0. Udvikler-id-certificeringsmyndighed udløber: 57-8-2 2027:02:01 +22 SHA12 Fingeraftryk: 15A FC 0000D 256 A7 9F 01 A6 DE 2 03 2 96D 37A FE 93 6 4D 68D E09 0D 2 F1 8C 03 CF B2 -------- B9 BA 88F -------------------------------------------------- -------------- 0. Apple Root CA Udløber: 1-63-58 7:3:2035 +02 SHA09 Fingeraftryk: B21 B40 36 0000E CB C256 FF 0 1 73 0C 7 F45 05 14E 2E DA 49B CA ED 1E 29C 5 C6 BE 6 B7 A2 68 5 F91 5

Desværre, som Wardle opdagede, da han dekompilerede Zooms signaturbekræftelseskode, behandlede Zoom-opdateringsprogrammet ikke pkgutil data på samme måde, som menneskelige observatører ville.

Vi ville kontrollere outputtet ved at følge den nyttige visuelle sekvens i outputtet.

Først ville vi først kigge efter den ønskede status, f.eks signed by a developer certificate issued by Apple for distribution.

Så ville vi finde underoverskriften Certificate Chain:.

Til sidst ville vi krydstjekke, at kæden bestod af disse tre underskrivere, i den rigtige rækkefølge:

  1. Zoom Video Communications, Inc. 2. Developer ID Certification Authority 3. Apple Root CA

Utroligt nok bekræftede Zooms kode simpelthen, at hver af de tre ovennævnte strenge (ikke engang tjekkede for Zooms eget unikke ID BJ4HAAB9B3) dukkede op et eller andet sted i outputtet fra pkgutil.

Så opret en pakke med et absurd-men-gyldigt navn som f.eks Zoom Video Communications, Inc. Developer ID Certification Authority Apple Root CA.pkg ville narre pakkebekræfteren til at finde de "identitetsstrenge", den ledte efter.

Det fulde pakkenavn gentages i pkgutil output header på den første linje, hvor Zooms ulykkelige "verifier" ville matche alle tre tekststrenge i den forkerte del af outputtet.

Således kunne "sikkerheds"-kontrollen trivielt omgås.

En delvis rettelse

Wardle siger, at Zoom til sidst rettede denne fejl, mere end syv måneder efter, at han rapporterede det, i tide til DEF CON...

…men efter at have påført plastret bemærkede han, at der stadig var et hul i opdateringsprocessen.

Opdateringsprogrammet forsøgte at gøre det rigtige:

• 1. Flyt den downloadede pakke til mappe, der ejes af root, og dermed teoretisk set forbudt for enhver almindelig bruger.
• 2. Bekræft den kryptografiske signatur for den downloadede pakke, ved hjælp af officielle API'er, ikke via en tekst-matchende bodge imod pkgutil udgang.
• 3. Fjern arkivering af den downloadede pakkefil, for at verificere dets versionsnummer for at forhindre nedgraderingsangreb.
• 4. Installer den downloadede pakkefil, ved at bruge root-rettighederne til den automatiske opdateringsprocessen.

Desværre, selvom den mappe, der blev brugt til at gemme opdateringspakken, var ejet af root, i et forsøg på at holde den sikker fra nysgerrige brugere, der forsøgte at undergrave opdateringsfilen, mens den blev brugt...

…den nyligt downloadede pakkefil blev efterladt "verden-skrivbar" på dens nye placering (en bivirkning af at være blevet downloadet af en almindelig konto, ikke af root).

Dette gav lokale angribere et smuthul til at ændre opdateringspakken efter dens digitale signatur var blevet valideret (trin 2), uden at påvirke versionstjekdetaljerne (trin 3), men lige før installationsprogrammet tog kontrol over pakkefilen for at behandle den med root-rettigheder (trin 4).

Denne slags fejl er kendt som en løbets tilstand, fordi angriberne skal time deres afslutning, så de kommer hjem lige før installationsprogrammet starter, og skal derfor snige deres ondsindede ændringer ind lige foran det.

Du vil også høre denne type sårbarhed refereret til med det eksotisk klingende akronym TOCTOU, forkortelse for tidspunkt for check-til-tidspunkt-for-brug, et navn, der er en klar påmindelse om, at hvis du tjekker dine fakta for langt i forvejen, så kan de være forældede, når du stoler på dem.

TOCTOU-problemet er, hvorfor biludlejningsfirmaer i Storbritannien ikke længere blot beder om at se dit kørekort, som kunne være blevet udstedt for op til 10 år siden, og som kunne være blevet suspenderet eller annulleret af forskellige årsager siden da, højst sandsynligt pga. af usikker eller ulovlig kørsel fra din side. Sammen med din fysiske licens skal du også fremvise en alfanumerisk engangskode for "bevis for nylig gyldighed", udstedt inden for de sidste 21 dage, for at reducere det potentielle TOCTOU-gab fra 10 år til kun tre uger.

Rettelsen er nu på plads

Ifølge Wardle har Zoom nu forhindret denne fejl ved at ændre adgangsrettighederne til opdateringspakkefilen, der er kopieret i trin 1 ovenfor.

Filen, der bruges til signaturkontrol, versionsvalidering og den endelige installation på rodniveau, er nu begrænset til kun at få adgang til rodkontoen til enhver tid.

Dette fjerner racebetingelsen, fordi en uprivilegeret angriber ikke kan ændre filen mellem slutningen af ​​trin 2 (verifikation lykkedes) og starten af ​​trin 4 (installationen begynder).

For at ændre pakkefilen for at narre systemet til at give dig root-adgang, skal du allerede have root-adgang, så du behøver ikke en EoP-fejl af denne slags i første omgang.

TOCTOU-problemet gælder ikke, fordi checken i trin 2 forbliver gyldig, indtil brugen af ​​filen begynder, hvilket ikke giver mulighed for, at checken bliver ugyldig.

Hvad skal jeg gøre?

Hvis du bruger Zoom på en Mac, skal du åbne appen og derefter gå til i menulinjen zoom.us > Check for Updates...

Hvis en opdatering er tilgængelig, vil den nye version blive vist, og du kan klikke [Install] for at påføre plastrene:

Den version du ønsker er 5.11.5 (9788) eller senere.

---