En zero-day er en sikkerhetsfeil som utnyttes før leverandøren har en rettelse for den, oppkalt etter at forsvarerne har hatt null dager på å reagere. Det er den mest urovekkende truselkategorien fordi det vanlige rådet, «hold programvaren oppdatert», ennå ikke gjelder: det finnes ingenting å oppdatere til. Denne artikkelen ser på hvordan slike feil faktisk har sett ut på Apples plattformer, med utgangspunkt i Apples egne sikkerhetsutgivelser, Google Project Zero og Citizen Lab, og deretter på den ene tingen et ukjent angrep fortsatt må gjøre etter at det har lyktes.
Ett poeng må slås fast med en gang, fordi markedsføringen rundt dette temaet ofte er villedende: ingen brannmur stopper et exploit. Ikke FireAI, ikke noen annen. En brannmur kan ikke se et misdannet bilde som tolkes inne i iMessage eller en kjernefeil som utløses fra en nettside. Det en brannmur kan gjøre, er å følge med på hva som skjer etterpå, og det viser seg å bety mer enn det først ser ut til.
Hva historikken faktisk viser
Apple dokumenterer hver sikkerhetsrettelse på siden Apple security releases, og når en feil allerede ble brukt mot virkelige mennesker, sier de det med en standardformulering: «Apple er kjent med en rapport om at dette problemet kan ha blitt aktivt utnyttet.» Å lese den siden over noen år gir et mer jordnært bilde enn noen overskrift. Google Project Zero fører en utfyllende offentlig oversikt, sin 0-day «In the Wild»-tracker, som lister exploits oppdaget i reelle angrep før det fantes en patch. Project Zero er nøye med å påpeke at trackeren bare inneholder tilfeller som ble oppdaget, som per definisjon er angriperens fiaskoer, så den kan ikke brukes til å telle hvor mye utnyttelse som faktisk skjer eller til å sammenligne plattformer.
Tre dokumenterte tilfeller viser problemets form.
FORCEDENTRY, 2021
I mars 2021 analyserte Citizen Lab ved University of Toronto telefonen til en saudiarabisk aktivist og gjenopprettet et exploit de kalte FORCEDENTRY. Det var et zero-click-angrep: en spesiallaget fil, levert gjennom iMessage, som ikke krevde noe trykk fra offeret og installerte NSO Groups spionprogramvare Pegasus. Citizen Lab fant bevis for at det hadde vært i bruk siden minst februar 2021. Apple rettet feilen, CVE-2021-30860 i bildetolkeren CoreGraphics, 13. september 2021 i iOS 14.8, macOS Big Sur 11.6 og en sikkerhetsoppdatering for Catalina; Apples egne utgivelsesnotater for Big Sur 11.6 bekrefter at feilen «kan ha blitt aktivt utnyttet».
Google Project Zero publiserte senere en teknisk analyse som forklarer hvorfor denne typen ting er så vanskelig å fange opp. Feilen lå i JBIG2-bildekomprimeringskoden som brukes inne i PDF-er. NSOs exploit brukte formatets egne logiske operatorer til å bygge, ut av mer enn 70 000 bildesegment-kommandoer, en liten fungerende datamaskin inne i bildedekoderen, og kjørte resten av angrepet på den. Ingenting ved det ser ut som et program fra utsiden. Det er et bilde, åpnet av en legitim, signert systemprosess.
Vanningshullet i Hongkong, 2021
I slutten av august 2021 fant Googles Threat Analysis Group en vanningshull-kampanje rettet mot besøkende på nettstedene til et medieselskap og en prodemokratisk gruppe i Hongkong. Mot Macer lenket den en WebKit-feil som allerede var rettet i januar sammen med en rettighetseskaleringsfeil i kjernen, CVE-2021-30869, som fortsatt var upatchet på macOS Catalina; Apple rettet den 23. september 2021. Nyttelasten, en bakdør Google kalte MACMA, kunne ta fingeravtrykk av maskinen, ta skjermbilder, ta opp lyd, logge tastetrykk, laste opp og ned filer og kjøre terminalkommandoer.
Dette eksempelet er lærerikt fordi exploitet og nyttelasten er to forskjellige ting. Exploitet var usynlig: en nettside. Nyttelasten var et ordinært implantert program som, for å være til noen nytte for operatørene, måtte opprette en kommando-og-kontroll-kanal og flytte data ut av Macen. Googles gjennomgang beskriver nøyaktig den infrastrukturen.
BLASTPASS, 2023
I september 2023 rapporterte Citizen Lab BLASTPASS, nok en zero-click-kjede via iMessage som leverte Pegasus, denne gangen gjennom PassKit-vedlegg med ondsinnede bilder. Apple tildelte CVE-2023-41064 og CVE-2023-41061 og sendte ut rettelser for iPhone, iPad, Mac og Apple Watch. Verdt å merke seg: både Apples sikkerhetsingeniører og Citizen Lab sa at de trodde Lockdown-modus (Lockdown Mode) blokkerte akkurat denne kjeden, som er det sterkeste offentlige beviset for at det er reduksjon av angrepsflate, ikke deteksjon av angrepet, som virker mot denne trusselklassen.
Hvorfor det er så vanskelig å oppdage selve exploitet
Sett de tre tilfellene ved siden av hverandre, og mønsteret er tydelig. Exploitet kommer som data (et bilde, en PDF, en nettside) i stedet for som en app. Det behandles av legitim, Apple-signert kode. Det finnes ingen fil for XProtect å matche, ingen usignert binærfil for Gatekeeper å avvise, og ofte ingen ny prosess for et endepunktsikkerhetsverktøy å flagge, fordi den fiendtlige koden kjører inne i en prosess som allerede var klarert. Deteksjon, når den skjer, er vanligvis etterforskningsmessig: Citizen Lab fant FORCEDENTRY ved å undersøke spor på en enhet i etterkant, ikke ved at en skanner fanget det opp live.
Det er derfor Apples råd til folk som tror de kan være mål, ikke er «installer en detektor», men Lockdown-modus, som på macOS Ventura og nyere blokkerer de fleste typer meldingsvedlegg, deaktiverer komplekse webteknologier, avviser ukjente FaceTime-anrop og hindrer installasjon av konfigurasjonsprofiler. Den virker ved å fjerne kodestiene et exploit trenger, til en pris i bekvemmelighet som Apple er tydelig på.
Hvorfor nettverkssteget er annerledes
Et exploit er begynnelsen på et angrep, ikke formålet med det. Pegasus finnes for å sende meldinger, bilder og mikrofonlyd til operatøren sin. MACMAs skjermbilder og tastetrykk var verdiløse på offerets disk. I hvert dokumentert tilfelle ble verdien realisert av trafikk som forlot maskinen, og i MITRE ATT&CK-matrisen for macOS har den fasen to egne kolonner, kommando og kontroll og eksfiltrering, fordi den er et distinkt, observerbart steg som angripere ikke kan hoppe over.
Dette steget har egenskaper exploitet ikke hadde. Det kommer fra en identifiserbar prosess med en kodesignatur (eller, avslørende nok, uten en). Det går til en destinasjon med en IP, et vertsnavn og en historikk. Det bruker ofte en uvanlig port, en rå IP i stedet for et navn, eller en hostingleverandør som ikke har noen tilknytning til noen app på Macen. Ingenting av dette krever kjennskap til feilen som ble brukt. Det krever bare å se tilkoblingen og å ha lov til å si nei.
Dette er delen FireAI er bygget for. Reglene per app er knyttet til kodesignaturen til prosessen som kobler seg til, så en implantert binærfil som ikke er en app du har godkjent, får en tillatelsesforespørsel i stedet for fri passasje, med den lokale modellens begrunnelse vist i klart språk. Trusseletterretningsfeedene (abuse.ch, Spamhaus, FireHOL, OpenPhish, Phishing Army og den gjeldende listen over Tor-utgangsnoder) brukes lokalt, så en kjent kommando-og-kontroll-adresse avvises uansett om noe annet på Macen kjente igjen nyttelasten eller ikke. Modusene Under angrep og Paranoid strammer inn standarden til å blokkere usignerte apper og ukjente destinasjoner direkte, og nødbryteren kutter internett mens det lokale nettverket beholdes, som er det riktige første trekket når du mistenker et innbrudd og vil bevare bevis.
Hva dette ikke dekker
Ærlighet krever den andre halvdelen av listen. Hvis en nyttelast kjører helt og holdent inne i en tillatt app, for eksempel inne i en nettleser du allerede har godkjent, arver trafikken dens den appens tillatelser, og FireAI vil ikke skille den ut. Kryptert trafikk til en destinasjon med rent omdømme ser ut som enhver annen tilkobling. En feed inneholder bare adresser noen allerede har rapportert; en fersk kommando-og-kontroll-server står ikke der ennå. Og FireAI oppdager, fjerner eller analyserer ikke exploitet eller implantatet: den skanner ikke filer eller minne, og den er ikke et antivirus. På en Mac du tror er kompromittert av en statlig aktør, er riktig vei Apples veiledning for trusselvarsler og en etterforskningsspesialist, ikke en brannmurinnstilling.
Det praktiske forsvaret mot ukjente sårbarheter er derfor lagdelt og lite glamorøst: installer Apples oppdateringer den dagen de kommer, siden det meste av utnyttelse retter seg mot feil som allerede har en rettelse; slå på Lockdown-modus hvis arbeidet ditt gjør deg til et plausibelt mål; hold angrepsflaten liten; og kontroller hvilke apper på Macen din som i det hele tatt får lov til å snakke med internett, slik at når noe ukjent likevel kommer inn, er steget det ikke kan hoppe over det steget du følger med på.
Hvor FireAI og HisnLabs kommer inn
FireAI cannot stop an exploit and does not claim to; what it does is sit on the one step every documented case above could not skip, the connection out, and ask, for each unknown process, whether that connection should be allowed at all.
FireAI er HisnLabs’ eget produkt: en KI-brannmur som kjører direkte på Macen. Den viser hver tilkobling appene dine gjør, i klart språk, og lar deg bestemme hva som forlater Macen din — KI-en kjører lokalt, så trafikken din sendes aldri til oss eller noen andre. HisnLabs’ sikkerhetsforskningsteam er de som holder disse vurderingene pålitelige: de katalogiserer hvilke domener som er vanlig telemetri og hvilke som er en ekte tjeneste, sporer landet og nettverket bak en tilkobling, og trener den lokale modellen (Autopilot-funksjonen) på ekte trafikkmønstre — uten at noe av det forlater Macen din.
Du kan lese om de tekniske valgene bak, eller prøve FireAI i 17 dager, på FireAI, fra HisnLabs.