Säkerhetsforskarna Talal Haj Bakry och Tommy Mysk har demonstrerat att en app hämtad utanför Mac App Store kan få sitt huvudprogram utbytt efter första öppningen och därefter starta utan en ny Gatekeeper-varning. Det är allvarligt, eftersom den ändrade appen kan framstå under ett känt namn och ikon. Men det är inte ett angrepp från ingenting: skadeprogrammet måste redan kunna köras som den aktuella användaren, och åtkomst till Nyckelring, Skrivbord och Dokument kräver fortfarande användarens godkännande.
Så fungerar det demonstrerade angreppet
En macOS-app är i praktiken en mapp med bland annat programfil, ikoner, bibliotek och metadata. Enligt Mysks tekniska genomgång skyddar macOS normalt innehållet när en app har installerats och öppnats. Forskarna fann emellertid att de kunde arkivera app-paketet, ta bort originalet och återställa paketet på samma plats. Därefter kunde de byta ut appens huvudprogram mot sin egen ad hoc-signerade kod.
Den ändrade appen startade utan en ny Gatekeeper-varning. Om programfilen däremot byttes ut före appens första öppning, avvisade macOS den som skadad. Fyndet handlar därför om tillit som redan har etablerats vid den första kontrollen.
Forskarna använde Signal som exempel, men understryker att det inte är ett fel i Signal. De reproducerade samma grundläggande beteende med flera användarinstallerade appar från nätet. Deras test omfattade macOS Tahoe 26.0 till 26.5.2 och de första fyra betorna av macOS 27; tidigare versioner kan enligt dem vara berörda, men testades inte.
Vad angriparen redan måste kunna
Det viktigaste för riskbedömningen är förutsättningen: En angripare måste redan ha fått en skadlig app eller ett skript att köras med den aktuella användarens rättigheter. Det är varken ett zero-click-angrepp eller en metod som ensam kan infektera en Mac via ett besök på en webbplats.
Det gör inte fyndet betydelselöst. Kodkörning som en vanlig användare är ett realistiskt första steg i många angrepp, och metoden kan därefter användas för att dölja den skadliga koden bakom en app som användaren redan litar på. Men fyndet bör inte beskrivas som fri åtkomst till vilken Mac som helst eller som ett fullständigt brott mot alla macOS-skydd.
Den falska appen ärver inte alla rättigheter
Mysks ersättningsprogram ärvde inte den ursprungliga appens utvecklarsignatur, entitlements eller redan godkända TCC-rättigheter. Det kunde därför inte ljudlöst läsa skyddade mappar eller Nyckelring. macOS visade nya, äkta systemdialoger innan sådan åtkomst kunde ges.
Problemet är att dialogerna visade den kända appens namn och ikon. I demonstrationen kunde en ändrad Signal-app därför begära åtkomst på ett sätt som såg ut att komma från Signal. Angreppet kringgår alltså inte själva tillståndsdialogen; det försöker utnyttja användarens tillit till avsändaren. Det är en viktig skillnad, men också skälet till att forskarna menar att beteendet är säkerhetsrelevant.
Apple och forskarna är oeniga om gränsen
Apple beskriver Gatekeeper som tekniken som kontrollerar att programvara från nätet kommer från en identifierad utvecklare, är notariserad och inte har ändrats. Apples vägledning för Mac-användare säger samtidigt att den centrala kontrollen sker innan nedladdad programvara öppnas första gången.
Enligt Mysks offentliggjorda tidslinje skickades rapporten till Apple den 4 juni med proof-of-concept-kod den 11 juni och stängdes den 14 juli. Apple bedömde att Gatekeeper och TCC inte hade kringgåtts: Angriparen hade redan kodkörning, den användarägda app-paketet ersattes, och nya känsliga rättigheter krävde fortfarande godkännande. Apple ansåg därför det sista steget som social engineering och inte som ett säkerhetshål som krävde en rättelse.
Forskarna accepterar att TCC och kodsignering inte kringgås direkt, men menar att macOS borde validera appen på nytt när programfilen har ändrats, eller visa den faktiska kodsignaturen i tillståndsdialogen. Det skulle göra det tydligt att begäran inte kommer från den ursprungliga utvecklaren.
Perspektiven spänner från allvarligt hål till begränsad risk
Privacy Guides framhåller att utbytet inte kräver administratörsrättigheter, och att de äkta systemdialogerna kan göra den falska appen övertygande. The Register lägger på motsvarande sätt vikt vid konflikten mellan den fortsatta app-identiteten och den ändrade programfilen.
Macworld gör den motsatta bedömningen och kallar ett praktiskt angrepp svårt, eftersom angriparen först måste ha tillgång till att köra kod eller övertyga användaren om flera handlingar. Den bedömningen är viktig som motvikt, men den får inte förväxlas med att fysisk åtkomst är ett tekniskt krav: Mysks proof of concept kräver kodkörning som användaren, inte nödvändigtvis fysisk åtkomst till maskinen.
Det har heller inte offentliggjorts något CVE-nummer eller dokumentation för aktiv exploatering i verkliga angrepp. Vi kan därför med säkerhet säga att beteendet har demonstrerats under de beskrivna förutsättningarna – inte att Mac-användare redan drabbas i stor skala.
Det bör du göra som Mac-användare
- Installera helst appar från Mac App Store eller direkt från en utvecklare du känner till.
- Håll macOS och appar uppdaterade, men var medveten om att Apple ännu inte har lovat en specifik rättelse för detta fynd.
- Godkänn inte plötsliga begäranden om Nyckelring, Skrivbord, Dokument, kamera eller mikrofon bara för att dialogen visar ett känt appnamn.
- Om en känd app oväntat begär nya känsliga rättigheter, avvisa, avsluta appen och hämta en färsk kopia från den officiella utvecklaren.
- Undvik skript, piratkopierad programvara och nedladdningar från slumpmässiga spegelsidor. De kan leverera den första kodkörning som detta angrepp kräver.
Apples notarization och Gatekeeper är fortfarande värdefulla säkerhetslager, men de är ingen garanti för att en app förblir oförändrad för alltid. Den exakta och försvarbara slutsatsen är därför: Fyndet visar en verklig tillits- och identitetsbrist efter första öppningen, medan de övriga macOS-lagren fortfarande begränsar vad en angripare kan göra utan nya tillstånd.
