Sjekk enhver Mac-apps signatur og notarisering fra terminalen

Gatekeeper kjører denne sjekken automatisk første gang du åpner en nedlastet app, og mesteparten av tiden ser du aldri detaljene - en dialogboks vises, du klikker deg gjennom den, ferdig. Denne laboratoriet handler om å se hva Gatekeeper så: hvilken utvikler som signerte appen, om signaturen er intakt, om Apples notartjeneste sjekket den, og hva den har lov til å gjøre når den kjører. Hver kommando her leveres med Xcodes kommandolinjeverktøy (xcode-select --install hvis du ikke har dem ennå), og hver og en av dem er skrivebeskyttet - du inspiserer, ikke endrer, appen.

Selve signaturen: codesign -dvvv

codesign er Apples verktøy for å lage og inspisere kodesignaturer. -d-flagget viser informasjon om den signerte koden ved en bane, og i henhold til sin man-side, "Økende nivåer av detaljerthet produserer mer utdata" - så -dvvv (skjerm, tre nivåer med ord) gir deg hele bildet i én kommando:

$ codesign -dvvv /Applications/Example.app
# example output, trimmed to the fields that matter
Executable=/Applications/Example.app/Contents/MacOS/Example
Identifier=com.example.app
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=... flags=0x10000(runtime) hashes=...
Signature size=4741
Authority=Developer ID Application: Example Software LLC (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Team Identifier=ABCDE12345
Runtime Version=14.0.0

Fire felt å lese hver gang. Authority er sertifikatkjeden: en normal, ekstern app skal ende på Apple Root CA ved hjelp av Developer ID Certification Authority, med den øverste linjen som navngir utvikleren. Team Identifier er Apples ti-tegns ID for utviklerkontoen – verdien for å sammenligne på tvers av apper du tror kommer fra samme selskap, siden den ikke endres mellom utgivelsene. flags=0x10000(runtime) betyr at den herdede kjøretiden er aktivert, et sett med ytterligere begrensninger (som å motstå kodeinjeksjon i prosessen) som Apple krever for notarisering. Og fraværet av noen Authority-linje i det hele tatt – bare Signature=adhoc – betyr at appen er usignert eller selvsignert uten noen kjede til Apple overhodet.

Stemmer signaturen fortsatt med filene: --verify --deep --strict

En signatur er et løfte om et spesifikt sett med byte på signeringstidspunktet. --verify sjekker om det løftet fortsatt holder - per man-siden bekrefter det "at koden på disse banen(e) er signert, at signaturen er gyldig og at alle forseglede komponenter er uendret." To ekstra flagg betyr noe for en app-pakke, som er en katalog full av nestede ressurser, rammer og kjørbare hjelpefiler, ikke en enkelt fil:

$ codesign --verify --deep --strict --verbose=2 /Applications/Example.app
/Applications/Example.app: valid on disk
/Applications/Example.app: satisfies its Designated Requirement

--deep betyr noe fordi, i henhold til man-siden, er verifisering av nestet innhold som standard "begrenset til en grunn undersøkelse som kanskje ikke oppdager endringer i den nestede koden" - dypmodus verifiserer rekursivt hvert innebygd rammeverk og hjelpeverktøy, ikke bare den ytre bunten. --strict legger til ekstra kontroller som Apple anser som viktige nok til å ikke være på som standard, inkludert at enhver symbolkobling inne i pakken "peker til forseglede filer inne i pakken," og avviser en som peker utenfor appen eller til noe uforseglet – et kjent triks for å smugle en usignert nyttelast inn i en ellers legitimt signert pakke. Hvis en av kontrollen mislykkes, vil du se code failed to satisfy specified code requirement eller et notat som navngir nøyaktig hvilket nestet element som ikke samsvarer med det som opprinnelig ble forseglet - les den linjen, den gir filen navn.

Leser rettighetene

Rettigheter er de spesifikke tillatelsene en app-signatur gir den – kameratilgang, muligheten til å nå nettverket uten sandkasse, deaktivering av bibliotekvalidering og så videre. codesign -d --entitlements - trekker ut dem; per man-siden, "Innebygde rettighetsdata vil bli ekstrahert på samme måte og skrevet til" den gitte banen, og - betyr standard utdata:

$ codesign -d --entitlements - /Applications/Example.app
# example output, trimmed
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
<key>com.apple.security.network.client</key>
<true/>
<key>com.apple.security.device.camera</key>
<true/>

De fleste rettighetene er umerkelige og samsvarer med det appen åpenbart trenger - en app for videosamtaler som ber om kameratilgang er ikke et funn. Den som er verdt å stoppe på er disable-library-validation: det betyr at appen vil laste inn kode fra utenfor sin egen signerte pakke, som er et normalt behov for noen plugin-basert programvare og en bredere dør enn de fleste apper krever. Det er en detalj å merke seg, ikke et automatisk rødt flagg, og det er akkurat den typen detalj du ikke kan se uten å spørre.

Har Apples notartjeneste faktisk sjekket det: spctl og stiftemaskin

En gyldig signatur beviser bare at en app ikke har blitt endret siden en utvikler signerte den - den sier ingenting om Apple har sett på den. Det er det notarisering legger til. Apples egen dokumentasjon beskriver den automatiserte notartjenesten som skanning av "programvaren din for ondsinnede komponenter, sjekker for kodesigneringsproblemer og returnerer resultatene raskt til deg." Når det går, "genererer notariustjenesten en billett som du kan stifte til programvaren din; notartjenesten publiserer også billetten på nettet der Gatekeeper kan finne den."

spctl --assess er den praktiske måten å be Gatekeepers egen policymotor om sin dom i stedet for å utlede det selv. I henhold til man-siden, --assess "utfør en vurdering av filene som er gitt," og -v / --verbose, gjentatt for mer detaljer, beskrives ganske enkelt som å be om "mer detaljert utgang":

$ spctl --assess -vv /Applications/Example.app
/Applications/Example.app: accepted
source=Notarized Developer ID

source=Notarized Developer ID er resultatet du vil se – det betyr at Gatekeeper fant en gyldig utvikler-ID-signatur og en notariseringsbillett, enten den billetten er stiftet til appen eller ble funnet på nettet. Et resultat av source=Unnotarized Developer ID betyr at appen er signert, men Apple har ikke (eller ennå) notarisert den, og en flat rejected betyr at Gatekeeper vil blokkere den fra å starte i standardkonfigurasjonen.

For å sjekke stiften spesifikt, ser xcrun stapler validate etter billetten som er fysisk festet til appen i stedet for å be Gatekeeper om å slå den opp på nettet – nyttig for å bekrefte at en app fortsatt vil vurdere riktig uten internettforbindelse i det hele tatt:

$ xcrun stapler validate /Applications/Example.app
Processing: /Applications/Example.app
The validate action worked!

Karanteneflagget: hvor førstegangssjekken kommer fra

Apples plattformsikkerhetsguide forklarer at "Gatekeeper sporer også opprinnelsen til filer skrevet av nedlastet programvare" og "ber om brukergodkjenning før du åpner nedlastet programvare for første gang." Mekanismen bak det er en utvidet attributt, com.apple.quarantine, som Safari, Mail og andre apper knytter til alt de lagrer fra nettverket. xattr -l viser det, og per man-siden, dette alternativet "fører at både attributtnavn og tilsvarende verdier vises":

$ xattr -l ~/Downloads/Example.dmg
com.apple.quarantine: 0081;65e1a2b3;Safari;

Ingen utdata i det hele tatt betyr at filen ikke har noe karanteneflagg – enten ble den opprettet lokalt, ankommet av en bane som ikke angir attributtet (noen arkivverktøy og pakkebehandlere hopper over det), eller så ble flagget manuelt fjernet med xattr -d com.apple.quarantine. Det siste tilfellet er verdt å vite om av en annen grunn: det er en dokumentert måte folk omgår Gatekeepers førstegangssjekk helt, på filer de stoler på eller tror de stoler på, og det er verdt å være bevisst på i stedet for å lime inn fra et ukjent sett med terminalinstruksjoner.

En fungert sammenligning: to apper som gjør krav på samme utvikler

En konkret måte å bruke alt dette sammen på: si at du har to kopier av en app som begge hevder å være fra samme selskap, en fra utviklerens egen side og en fra en lenke noen sendte deg. Kjør codesign -dvvv på begge og sammenlign Team Identifier-linjen – det er en streng på ti tegn knyttet til en spesifikk Apple Developer-konto, og i motsetning til et visningsnavn eller en pakkeidentifikator, er det ikke noe en annen part tilfeldig kan reprodusere uten tilgang til kontoens signeringssertifikat. Hvis de to kopiene viser forskjellige teamidentifikatorer, ser du ikke på to versjoner av samme app; du ser på to forskjellige underskrivere, hvorav den ene ikke er den nedlastingen gjorde krav på. Følg det med spctl --assess -vv på den mistenkelige kopien - en feilaktig eller fraværende notariseringskilde på kopien som hevder å være identisk med en notarisert original er bekreftelsen, ikke bare en ledetråd.

Leser hele bildet, og de faktiske røde flaggene

• Ingen Authority-kjede i det hele tatt, eller en kjede som ikke ender i Apple Root CA – appen har ingen ansvarlig utvikleridentitet bak seg.
• codesign --verify mislykkes, spesielt med en melding som navngir en bestemt nestet fil - noe inne i pakken endret seg etter at den ble signert.
• spctl --assess returnerer rejected, eller teamidentifikatoren i codesign -dvvv samsvarer ikke med utvikleren du forventer for det produktet.
• Et karanteneflagg som tydelig ble fjernet på en fil du ikke lastet ned selv, eller som kom via en uvanlig kanal (et skript, et e-postvedlegg som ble omdøpt til å se ut som noe annet).
• Rettigheter som er vidåpne – full disktilgang, deaktivert bibliotekvalidering, ubegrenset nettverkstilgang – på en app hvis oppgitte formål ikke åpenbart trenger dem.

Ingen av disse kontrollene ser på hva appen faktisk gjør når den kjører og er koblet til nettverket - det er en annen type spørsmål, besvart ved å se trafikken i stedet for signaturen. En ren signatur og en gyldig notariseringsbillett er et ekte, meningsfullt gulv: de sier at Apple har sett dette eksakte settet med byte og ikke funnet noen problemer med kodesignering på tidspunktet for sjekken. De er begynnelsen på å stole på en app, ikke slutten på den.

Hvor FireAI og HisnLabs kommer inn

A clean signature and a stapled ticket say an app hasn’t been tampered with since Apple checked it — they say nothing about what it connects to afterward, which is the question FireAI’s per-app rules and on-device review are built to keep answering, signature by signature, connection by connection.

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.