Zoom för Mac-korrigeringar får root-bugg – uppdatera nu!

På den välkända DEF CON-säkerhetsshindigen i Las Vegas, Nevada, förra veckan, kom Mac cybersäkerhetsforskaren Patrick Wardle avslöjade en "get-root" höjning av privilegiet (EoP) bugg i Zoom för Mac:

Mahalo till alla som kom till mig @defcon prata "Du är M̶u̶t̶e̶d̶ Rooted" 🙏🏽

Blev sugen på att prata om (& live-demo 😅) en lokal priv-esc sårbarhet i Zoom (för macOS).

För närvarande finns det ingen patch 👀😱

Presentationer med fullständiga detaljer och PoC-utnyttjande: https://t.co/viee0Yd5o2 # 0day pic.twitter.com/9dW7DdUm7P

— patrick wardle (@patrickwardle) Augusti 12, 2022

I tweeten, som följde på hans föredrag [2022-08-12], noterade Wardle:

För närvarande finns det inget plåster [:FRIED-EGG EYES PICTING ALARM EMOJI:] [:EDVARD MUNCH SCREAM EMOJI:]

Zoom arbetade omedelbart på en patch för felet, som tillkännagavs dagen efter Zoom säkerhetsbulletin ZSB-22018, tjänar ett grattis svar från Wardle i processen:

Mahalos till @Zoom för den (otroligt) snabba lösningen! [:BÅDA HÄNDERNA RÄCKTES I FIRANDE OCH VICKLADE OM EMOJI:] [:PALMER TRYCKTAS TILL TECKN PÅ ANDLIG VILJA EMOJI:]

Nolldagars avslöjande

Med tanke på den uppenbara hastigheten och lättheten med vilken Zoom kunde avge en patch för buggen, dubbad CVE-2022-28756, du undrar förmodligen varför Wardle inte berättade för Zoom om buggen i förväg och satte dagen för sitt tal som deadline för att avslöja detaljerna.

Det skulle ha gett Zoom tid att skicka ut uppdateringen till sina många Mac-användare (eller åtminstone göra den tillgänglig för dem som tror på lappa tidigt/lappa ofta), vilket eliminerar klyftan mellan att Wardle förklarar för världen hur man missbrukar felet, och korrigeringen av felet.

Det verkar faktiskt som att Wardle gjorde sitt bästa för att varna Zoom om denna bugg, plus ett gäng sammanlänkade brister i Zooms autouppdateringsprocess för några månader sedan.

Wardle förklarar tidslinjen för avslöjande av buggar i bilder från hans DEF CON talk, och listar en ström av Zoom-uppdateringar relaterade till de brister han upptäckt.

Ett dubbelkantigt svärd

De buggar som Wardle diskuterade relaterade generellt till Zooms automatiska uppdateringsmekanism, en del av alla mjukvaruekosystem som är lite av ett tveeggat svärd – ett kraftfullare vapen än ett vanligt svärd, men på motsvarande sätt svårare att hantera säkert.

Automatisk uppdatering är en måste-komponent i alla moderna klientapplikationer, med tanke på att det gör viktiga patchar enklare och snabbare att distribuera, vilket hjälper användare att på ett tillförlitligt sätt stänga av cybersäkerhetshål.

Men automatisk uppdatering för med sig ett hav av risker, inte minst för att själva uppdateringsverktyget vanligtvis behöver systemåtkomst på rotnivå.

Det beror på att uppdateringsprogrammets uppgift är att skriva över applikationsmjukvaran (något som en vanlig användare inte ska göra), och kanske att starta privilegierade operativsystemkommandon för att göra konfiguration eller andra systemnivåändringar.

Med andra ord, om utvecklarna inte är försiktiga, kan själva verktyget som hjälper dem att hålla sin underliggande app uppdaterad och säkrare bli ett strandhuvud från vilket angripare kan undergräva säkerheten genom att lura uppdateraren att köra obehöriga kommandon med systembehörighet .

Speciellt måste autouppdateringsprogram vara noga med att verifiera äktheten av uppdateringspaketen de laddar ner, för att förhindra att angripare helt enkelt matar ett falskt uppdateringspaket, komplett med tillagd skadlig kod.

De måste också underhålla integritet av uppdateringsfilerna som de i slutändan konsumerar, så att en lokal angripare inte smygt kan modifiera det "verifierade säkra" uppdateringspaketet som just har laddats ner under den korta perioden mellan det att det hämtas och aktiveras.

Undviker äkthetskontrollen

Som Wardle förklarar i sin papper, en av de buggar som han upptäckte och avslöjade var ett fel i det första steget ovan, när Zooms automatiska uppdateringsprogram försökte verifiera äktheten av uppdateringspaketet som det just hade laddat ner.

Istället för att använda de officiella macOS API:erna för att validera den digitala signaturen för nedladdningen direkt, beslutade Zoom-utvecklare att göra autentiseringen indirekt genom att köra macOS-verktyget pkgutil --check-signature i bakgrunden och undersöker resultatet.

Här är ett exempel på pkgutil output, med en gammal version av Zoom.pkg mjukvarupaket:

$ pkgutil --check-signature Zoom.pkg Paket "Zoom.pkg": Status: undertecknat av ett utvecklarcertifikat utfärdat av Apple för distribution Undertecknat med en betrodd tidsstämpel på: 2022-06-27 01:26:22 +0000 Certificate Chain : 1. Utvecklar-ID Installatör: Zoom Video Communications, Inc. (BJ4HAAB9B3) Upphör att gälla: 2027-02-01 22:12:15 +0000 SHA256 Fingeravtryck: 6D 70 1A 84 F0 5A D4 C1 C1 C3 AE AE 01F FB 2F 1C A2 9 5 A6 80 48 FF B4 F76 60 BB 5C ------------------------------------------ -------------------------------------- 0. Certifieringsmyndighet för utvecklar-ID upphör att gälla: 57-8-2 2027:02:01 +22 SHA12 Fingeravtryck: 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 88 -------------------------------------------------- -------------- 0. Apple Root CA Upphör: 1-63-58 7:3:2035 +02 SHA09 Fingeravtryck: 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

Tyvärr, som Wardle upptäckte när han dekompilerade Zooms signaturverifieringskod, bearbetade inte Zoom-uppdateringsprogrammet pkgutil data på samma sätt som mänskliga observatörer skulle göra.

Vi skulle kontrollera utgången genom att följa den användbara visuella sekvensen i utgången.

Först skulle vi först leta efter önskad status, t.ex signed by a developer certificate issued by Apple for distribution.

Sedan skulle vi hitta underrubriken Certificate Chain:.

Slutligen skulle vi krysskontrollera att kedjan bestod av dessa tre undertecknare, i rätt ordning:

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

Otroligt nog verifierade Zooms kod helt enkelt att var och en av de tre ovanstående strängarna (inte ens letade efter Zooms eget unika ID BJ4HAAB9B3) dök upp någonstans i utgången från pkgutil.

Så, skapa ett paket med ett absurt-men-giltigt namn som t.ex Zoom Video Communications, Inc. Developer ID Certification Authority Apple Root CA.pkg skulle lura paketverifieraren att hitta de "identitetssträngar" den letade efter.

Det fullständiga paketnamnet återges i pkgutil output header på den första raden, där Zooms olyckliga "verifierare" skulle matcha alla tre textsträngarna i fel del av utdata.

Således kan "säkerhets"-kontrollen förbigås trivialt.

En delvis fix

Wardle säger att Zoom så småningom fixade det här felet, mer än sju månader efter att han rapporterade det, i tid för DEF CON...

...men efter att ha applicerat plåstret märkte han att det fortfarande fanns ett gapande hål i uppdateringsprocessen.

Uppdateraren försökte göra rätt:

• 1. Flytta det nedladdade paketet till katalogen som ägs av root, och därmed teoretiskt sett förbjudet för alla vanliga användare.
• 2. Verifiera den kryptografiska signaturen för det nedladdade paketet, använder officiella API:er, inte via en textmatchande bodge mot pkgutil utgång.
• 3. Avarkivera den nedladdade paketfilen, för att verifiera dess versionsnummer, för att förhindra nedgraderingsattacker.
• 4. Installera den nedladdade paketfilen, med hjälp av root-privilegierna för den automatiska uppdateringsprocessen.

Tyvärr, även om katalogen som användes för att lagra uppdateringspaketet ägdes av root, i ett försök att hålla den säker från nyfikna användare som försöker undergräva uppdateringsfilen medan den användes...

…den nyligen nedladdade paketfilen lämnades "världsskrivbar" på sin nya plats (en bieffekt av att ha laddats ner av ett vanligt konto, inte via root).

Detta gav lokala angripare ett kryphål för att ändra uppdateringspaketet efter dess digitala signatur hade validerats (steg 2), utan att påverka versionskontrolldetaljerna (steg 3), men strax före installationsprogrammet tog kontroll över paketfilen för att bearbeta den med root-privilegier (steg 4).

Denna typ av bugg är känd som en loppskick, eftersom angriparna måste tajma sin avslutning så att de kommer hem precis innan installationsprogrammet startar, och de ska därför smyga in sina skadliga ändringar precis före det.

Du kommer också att höra denna typ av sårbarhet som hänvisas till med den exotiskt klingande akronymen TOCTOU, Förkortning av tid för kontroll-till-tid-för-användning, ett namn som är en tydlig påminnelse om att om du kontrollerar dina fakta för långt i förväg, kan de vara inaktuella när du litar på dem.

TOCTOU-problemet är varför biluthyrningsföretag i Storbritannien inte längre bara ber om att få se ditt körkort, som kunde ha utfärdats för upp till 10 år sedan, och som kunde ha dragits in eller annullerats av en mängd olika anledningar sedan dess, troligen pga. av osäker eller olaglig körning från din sida. Tillsammans med din fysiska licens måste du också presentera en alfanumerisk engångskod för "bevis på nyligen giltighet", utfärdad inom de senaste 21 dagarna, för att minska det potentiella TOCTOU-gapet från 10 år till bara tre veckor.

Fixningen är nu inne

Enligt Wardle har Zoom nu förhindrat denna bugg genom att ändra åtkomsträttigheterna på uppdateringspaketfilen som kopierades i steg 1 ovan.

Filen som används för signaturkontroll, versionsvalidering och den slutliga installationen på rotnivå är nu begränsad till endast root-kontot, hela tiden.

Detta tar bort rasvillkoret, eftersom en oprivilegierad angripare inte kan ändra filen mellan slutet av steg 2 (verifieringen lyckades) och början av steg 4 (installationen börjar).

För att modifiera paketfilen för att lura systemet att ge dig root-åtkomst, skulle du behöva ha root-åtkomst redan, så du skulle inte behöva en EoP-bugg av detta slag i första hand.

TOCTOU-problemet gäller inte eftersom kontrollen i steg 2 förblir giltig tills användningen av filen börjar, vilket inte lämnar någon möjlighet för kontrollen att bli ogiltig.

Vad göra?

Om du använder Zoom på en Mac öppnar du appen och går sedan till i menyraden zoom.us > Check for Updates...

Om en uppdatering är tillgänglig kommer den nya versionen att visas och du kan klicka [Install] för att applicera plåstren:

Den version du vill ha är 5.11.5 (9788) eller senare.

---