"Persistens" er sikkerhetsbegrepet for ett spesifikt problem: hvordan kjører koden som kjørte en gang, å kjøre igjen, automatisk, etter en omstart eller en pålogging, uten at noen restarter den for hånd? macOS gir legitim programvare mange godkjente måter å gjøre akkurat det på - en oppdateringskontroll, en menylinjesynkroniseringsklient, en skriverdriverhjelper - og hver og en av disse mekanismene er like tilgjengelige for noe du helst ikke skulle kjøre i det hele tatt. Dette er en omvisning av de faktiske stedene å se, med de virkelige kommandoene, og en ærlig beretning om hvor et nettverksfokusert verktøy som FireAI hører hjemme og ikke hører hjemme i det bildet.
LaunchAgents og LaunchDaemons: de to store
macOS starter nesten alt gjennom launchd, drevet av egenskapsliste (.plist) filer i et lite antall kjente kataloger. MITER ATT&CKs teknikk T1543.001 beskriver mekanismen enkelt: ved pålogging, en per-bruker launchd-prosess laster plister fra bruker- og system LaunchAgents-kataloger, og en plist med RunAtLoad satt til true kjøres automatisk i det øyeblikket den lastes - ingen ytterligere handling er nødvendig fra hvem som helst. Teknikken viser de tre plasseringene som betyr noe: /System/Library/LaunchAgents, /Library/LaunchAgents og ~/Library/LaunchAgents. MITER bemerker noe som er verdt å huske mens du blar gjennom en liste over disse filene: agenter som er installert for utholdenhet er ofte "forkledning[d]... ved å bruke navn som ligner legitime OS- eller programvarekomponenter" - filen som ser ut som com.apple.something.plist er verdt en ny titt nettopp fordi den prøver å ikke få en.
LaunchDaemons, dekket av den relaterte teknikken T1543.004, er den systemomfattende versjonen uten pålogging: de kjører som root, starter ved oppstart, fra /System/Library/LaunchDaemons/ eller /Library/LaunchDaemons/. Fordi installering av en der krever administrative rettigheter til å begynne med, rammer MITER daemon-ruten som en måte å konvertere et innledende privilegert fotfeste til noe som overlever en omstart, som kjører med rotnivåtilgang fra da av - og det er også grunnen til at en ny, ukjent fil som vises i /Library/LaunchDaemons er et tyngre signal enn en som vises i en brukers egen LaunchAgent-mappe.
ls -la ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons
# compare this list against what you remember installing; anything you don't
# recognise is worth reading with: plutil -p /path/to/the.plistEn fil som finnes på disken og en jobb som faktisk lastes inn er to forskjellige spørsmål, og launchctl print svarer på det andre. Dens man-side beskriver det som å skrive ut "informasjon om den angitte tjenesten eller domenet" - pekt på et domene som system/ eller gui/501/ (501 er en brukers UID), den viser hver tjeneste og endepunkt som for øyeblikket er lastet inn i den konteksten, pluss hver enkelts tilstand:
launchctl print gui/$(id -u)
# example output, trimmed — a real run lists every loaded agent for your session
"com.apple.someAgent" => {
active count = 1
path = /Library/LaunchAgents/com.apple.someAgent.plist
state = running
}Påloggingselementer og bakgrunnsoppgavebehandling
Den brukervendte overflaten for mye av dette er System Settings' Login Items-panel, og det er verdt å sjekke med egne øyne, ikke bare kommandolinjen. Apples støtteguide beskriver det direkte: du kan "velge påloggingselementer som åpnes automatisk når du logger på", legge til eller fjerne dem der, og separat tillate eller nekte apper som "utfører oppgaver når appen ikke er åpen, for eksempel å se etter programvareoppdateringer eller synkronisere data" - den andre kategorien dekker bakgrunnshjelpere som ikke er fullstendige påloggingselementer, men som fortsatt kjører uten tilsyn.
Siden macOS Ventura, er systemet under denne innstillingsruten ofte kalt Background Task Management (BTM) i sikkerhetsfellesskapet: en tjeneste som sporer hver lanseringsagent, lanseringsdemon og påloggingselement når den registrerer seg selv, som er det som lar systeminnstillingene vise deg en levende, sentralisert liste i stedet for at du må lete gjennom tre plist-kataloger for hånd. Det er et udokumentert kommandolinjeverktøy, sfltool, som noen forskere bruker for å spørre den databasen mer direkte med sfltool dumpbtm — Apple sender ingen man-side for den, og utdataformatet er ikke garantert stabilt, så behandle det som en forskningsnysgjerrighet å prøve på din egen maskin i stedet for noe å bygge en arbeidsflyt rundt. Den støttede, stabile måten å se den samme informasjonen på er fortsatt påloggingselementer-ruten i Systeminnstillinger, eller launchctl print for live-statusen til en bestemt jobb.
cron: eldre, roligere, fortsatt der
launchd har vært Apples foretrukne planlegger i lang tid, men den eldre Unix cron-demonen sendes fortsatt og kjører fortsatt alt som er planlagt i den. Crontab-man-siden beskriver filformatet direkte: hver linje har fem tid/dato-felt - minutt, time, dag i måneden, måned, ukedag - etterfulgt av kommandoen for å kjøre, med @reboot og lignende stenografistrenger tilgjengelig i stedet for de fem feltene på noen systemer. crontab -l, per man-siden for crontab(1), vil "Vise gjeldende crontab på standardutgang" for gjeldende bruker:
crontab -l
sudo crontab -l -u rootEt tomt resultat for begge er normalt på de fleste Mac-er i dag - det er nettopp derfor alt der inne fortjener oppmerksomhet. cron er uglamorøst og sjelden sjekket, og det er nettopp derfor det fortsatt dukker opp som et fallback-utholdenhetssted i hendelsesskrivinger.
Konfigurasjonsprofiler: utholdenhet med papirspor
En konfigurasjonsprofil kan installere en LaunchDaemon, gi personverntillatelser eller pushe innstillinger på tvers av en flåte av Mac-er – det er legitimt slik MDM (mobilenhetsadministrasjon) fungerer. Ulovlig er en profil en dokumentert måte å få endringer til å feste seg uten å berøre en plist-fil direkte. Kommandolinjeverktøyet profiles viser hva som er installert: profiles list viser installerte profiler, og som man-siden bemerker, vil kjøring av det som root med -all "liste alle konfigurasjonsprofiler på systemet" i stedet for bare gjeldende brukers.
sudo profiles list -all
sudo profiles show -allEn personlig Mac uten MDM-registrering bør vanligvis ikke ha noen, eller bare de du har installert med vilje (en VPN-konfigurasjon, en jobbprofil). En profil du ikke husker å ha installert er verdt å undersøke før du fjerner, siden profiles også støtter fjerning med passordbeskyttelse for akkurat det trinnet.
Autorisasjonsplugins og den lange halen
Utover de fire store ovenfor, er det en lang hale av mindre, eldre mekanismer: Directory Service og autorisasjonsplugins, Spotlight-importører, QuickLook-generatorer, Dock-tile-plugins og shell-oppstartsfiler som kjører hver gang en ny terminaløkt åpnes. Det er her et spesialbygd verktøy fortjener sin manuelle kontroll. Objective-See's KnockKnock, for eksempel, teller opp mer enn tjue kategorier av utholdenhetsplasseringer i ett pass - inkludert lanseringsagenter og demoner, påloggingselementer, nettleserutvidelser, cron-jobber, kjerne- og systemutvidelser, og autorisasjons- og katalogtjenesteplugins - og viser kodesigneringsstatusen til det den finner i hver enkelt. Dens følgesvenn, BlockBlock, tar den samme listen over steder og ser på dem kontinuerlig, og varsler øyeblikket noe nytt registrerer seg selv; i henhold til sin egen beskrivelse, "overvåker den vanlige utholdenhetsplasseringer og varsler hver gang en ny vedvarende komponent legges til," viser den ansvarlige prosessen, dens signeringsstatus og lar deg tillate eller blokkere på stedet.
Shell-oppstartsfiler: det stille oppsamlingsstedet
En plassering til som er verdt en direkte titt, siden den ikke trenger noen plist og ingen privilegert installasjon i det hele tatt: skallkonfigurasjonsfiler. ~/.zshrc, ~/.zprofile og ~/.bash_profile kjører hver gang en matchende ny terminaløkt åpnes, og en enkelt vedlagt linje – pipe til et skript, eksportere en kapret PATH, starte en bakgrunnsprosess – er nok til å reetablere fotfeste hver gang du åpner Terminal, uten at det er noe å laste inn i @@CODE@CODE og @@CODE. Objective-See's KnockKnock inkluderer akkurat denne kategorien i skanningen, oppført sammen med lanseringsagenter og påloggingselementer som skallkonfigurasjonsfiler, av samme grunn som den hører hjemme i denne artikkelen: den er vanlig nok, og uglamorøs nok, til å være verdt å sjekke i stedet for å anta.
cat -A ~/.zshrc ~/.zprofile ~/.bash_profile 2>/dev/null | less
# -A shows non-printing characters, which surfaces anything hidden with
# trailing whitespace or a carriage return trying to push it off-screenHvor FireAI passer, og hvor det bevisst ikke gjør det
For å være direkte om det: FireAI skanner ikke /Library/LaunchDaemons, leser ikke plist-filer og gjør ingen forsøk på å oppdage et nytt påloggingselement eller konfigurasjonsprofil. Det er en distinkt disiplin fra hva FireAI gjør, og verktøy bygget spesielt for det – KnockKnock og BlockBlock blant dem – gjør allerede den jobben godt. Det FireAI ser på er trinnet som kommer etter utholdenhet, og som hver og en av disse mekanismene til slutt trenger hvis den skal være nyttig for den som installerte den: en nettverkstilkobling. En LaunchAgent som kjører stille ved hver pålogging, men som aldri snakker med nettverket, er, fra en nettverksbrannmurs synspunkt, usynlig – og også i praksis langt mindre nyttig for en angriper. I det øyeblikket den åpner en socket, gjelder FireAIs per-app-regler for den som alle andre prosesser: en ukjent, signert eller usignert binær som gjør sin første tilkobling, utløser en melding, med resonnementet til modellen på enheten vist på et klart språk, og hver beslutning er synlig, kan angres og eksporteres som en tekstregel etterpå.
Den ærlige måten å sette de to disiplinene sammen på: sjekk plasseringene i denne artikkelen på en tidsplan som samsvarer med risikotoleransen din - månedlig er rimelig for de fleste, ukentlig hvis du installerer mye tredjepartsprogramvare - og la et nettverksverktøy bære belastningen i mellom, under forutsetning av at alt som vedvarte stille til slutt vil måtte snakke for å nå hvem det svarer til.
Hvor FireAI og HisnLabs kommer inn
FireAI does not scan for persistence — that is a different job, and tools like KnockKnock and BlockBlock already do it well; what FireAI watches is what that persisted code does the moment it opens a socket, which is the step every one of these mechanisms eventually has to take to be useful to whoever installed it.
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.