À Caça de Persistência no macOS: LaunchAgents, Itens de Início de Sessão e Tarefas em Segundo Plano

"Persistência" é o termo de segurança para um problema específico: como é que código que correu uma vez se organiza para voltar a correr, automaticamente, depois de um reinício ou de um início de sessão, sem que ninguém o volte a abrir à mão? O macOS dá ao software legítimo muitas formas sancionadas de fazer exatamente isso — um verificador de atualizações, um cliente de sincronização na barra de menus, o auxiliar de um controlador de impressora — e cada um desses mecanismos está igualmente disponível para algo que preferiria que não estivesse a correr de todo. Esta é uma visita guiada aos sítios reais a verificar, com os comandos reais, e um relato honesto de onde uma ferramenta focada na rede como o FireAI encaixa, e não encaixa, neste quadro.

LaunchAgents e LaunchDaemons: os dois grandes

O macOS arranca quase tudo através do launchd, orientado por ficheiros de lista de propriedades (.plist) num pequeno número de diretórios conhecidos. A técnica T1543.001 do MITRE ATT&CK descreve o mecanismo com clareza: no início de sessão, um processo launchd por utilizador carrega os plists dos diretórios de LaunchAgents de utilizador e de sistema, e um plist com RunAtLoad definido como verdadeiro executa automaticamente assim que é carregado — sem mais nenhuma ação necessária de quem o colocou lá. A técnica lista os três locais que importam: /System/Library/LaunchAgents, /Library/LaunchAgents, e ~/Library/LaunchAgents. O MITRE nota algo que vale a pena lembrar enquanto se percorre uma lista destes ficheiros: os agentes instalados para persistência são muitas vezes "disfarçados... usando nomes que se assemelham a componentes legítimos do sistema operativo ou de software" — o ficheiro que parece com.apple.something.plist merece um segundo olhar precisamente por tentar não o merecer.

Os LaunchDaemons, cobertos pela técnica relacionada T1543.004, são a versão de todo o sistema, sem necessidade de início de sessão: correm como raiz, a partir do arranque, de /System/Library/LaunchDaemons/ ou /Library/LaunchDaemons/. Como instalar um ali exige, à partida, privilégios administrativos, o MITRE enquadra a via do daemon como uma forma de converter um ponto de apoio privilegiado inicial em algo que sobrevive a um reinício, correndo a partir daí com acesso ao nível de raiz — o que também explica por que razão um novo ficheiro desconhecido a aparecer em /Library/LaunchDaemons é um sinal mais pesado do que um a aparecer na pasta LaunchAgents de um utilizador.

Terminal — a listar o que está de facto registado

$ 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.plist

Um ficheiro existir em disco e uma tarefa estar de facto carregada são duas perguntas diferentes, e o launchctl print responde à segunda. A sua página de manual descreve-o como algo que imprime "informação sobre o serviço ou domínio especificado" — apontado a um domínio como system/ ou gui/501/ (501 sendo o UID de um utilizador), lista todos os serviços e pontos finais atualmente carregados nesse contexto, mais o estado de cada um:

Terminal — o que está de facto carregado neste momento

$ 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
	}

Itens de início de sessão e a Gestão de Tarefas em Segundo Plano

A superfície voltada para o utilizador de muito disto é o painel Itens de Início de Sessão das Definições do Sistema, e vale a pena verificá-lo com os seus próprios olhos, não só a partir da linha de comandos. O guia de apoio da Apple descreve-o diretamente: pode "escolher itens de início de sessão que se abrem automaticamente quando inicia sessão," adicioná-los ou removê-los ali, e separadamente permitir ou negar aplicações que "realizam tarefas quando a aplicação não está aberta, como verificar atualizações de software ou sincronizar dados" — essa segunda categoria cobre auxiliares em segundo plano que não são itens de início de sessão completos, mas continuam a correr sem supervisão.

Desde o macOS Ventura, o sistema por trás desse painel de definições é normalmente chamado, na comunidade de segurança, de Gestão de Tarefas em Segundo Plano (Background Task Management, BTM): um serviço que acompanha cada agente de lançamento, daemon de lançamento e item de início de sessão à medida que se regista, o que é o que permite às Definições do Sistema mostrar-lhe uma lista ao vivo e centralizada, em vez de ter de ir procurar à mão em três diretórios de plists. Existe uma ferramenta de linha de comandos não documentada, sfltool, que alguns investigadores usam para consultar essa base de dados de forma mais direta com sfltool dumpbtm — a Apple não disponibiliza nenhuma página de manual para ela e o seu formato de saída não tem garantia de se manter estável, por isso trate-a como uma curiosidade de investigação para experimentar na sua própria máquina, e não como algo sobre o qual construir um fluxo de trabalho. A forma suportada e estável de ver a mesma informação continua a ser o painel Itens de Início de Sessão nas Definições do Sistema, ou o launchctl print para o estado ao vivo de uma tarefa específica.

cron: mais antigo, mais silencioso, continua lá

O launchd tem sido, há muito tempo, o agendador preferido da Apple, mas o mais antigo daemon Unix cron continua a vir incluído e continua a correr o que quer que esteja nele agendado. A página de manual do crontab descreve o formato do ficheiro diretamente: cada linha tem cinco campos de tempo/data — minuto, hora, dia do mês, mês, dia da semana — seguidos do comando a correr, com @reboot e atalhos semelhantes disponíveis em vez dos cinco campos em alguns sistemas. crontab -l, segundo a página de manual crontab(1), vai "Mostrar o crontab atual na saída padrão" para o utilizador atual:

Terminal — a verificar o seu próprio crontab e o da raiz

$ crontab -l
$ sudo crontab -l -u root

Um resultado vazio para ambos é normal na maioria dos Macs hoje em dia — é exatamente por isso que qualquer coisa lá dentro merece atenção. O cron é pouco vistoso e raramente verificado, o que é precisamente a razão pela qual continua a aparecer como local de persistência de reserva em relatórios de incidentes.

Perfis de configuração: persistência com um rasto documentado

Um perfil de configuração pode instalar um LaunchDaemon, conceder permissões de privacidade, ou aplicar definições a uma frota de Macs — legitimamente, é assim que funciona a MDM (gestão de dispositivos móveis). Ilegitimamente, um perfil é uma forma documentada de fazer com que alterações persistam sem tocar diretamente num ficheiro plist. A ferramenta de linha de comandos profiles lista o que está instalado: profiles list mostra os perfis instalados e, como nota a sua página de manual, correndo-a como raiz com -all vai "listar todos os perfis de configuração no sistema", em vez de apenas os do utilizador atual.

Terminal — todos os perfis de configuração no Mac

$ sudo profiles list -all
$ sudo profiles show -all

Um Mac pessoal sem nenhuma inscrição em MDM deve geralmente não ter nenhum, ou apenas os que instalou deliberadamente (uma configuração de VPN, um perfil de trabalho). Um perfil de que não se lembra de ter instalado vale a pena investigar antes de remover, já que o profiles também suporta a remoção com proteção por palavra-passe exatamente para esse passo.

Plugins de autorização e a longa cauda

Para além dos quatro grandes acima, há uma longa cauda de mecanismos mais pequenos e mais antigos: plugins de Directory Service e de autorização, importadores do Spotlight, geradores do QuickLook, plugins de ícones do Dock, e ficheiros de arranque da shell que correm cada vez que se abre uma nova sessão de terminal. É aqui que uma ferramenta feita para este propósito ganha valor face à verificação manual. O KnockKnock, da Objective-See, por exemplo, enumera mais de vinte categorias de locais de persistência numa única passagem — incluindo agentes e daemons de lançamento, itens de início de sessão, extensões de navegador, tarefas cron, extensões de kernel e de sistema, e plugins de autorização e de directory service — e mostra o estado de assinatura de código do que encontra em cada um. O seu companheiro, o BlockBlock, pega na mesma lista de locais e vigia-os continuamente, alertando no momento em que algo novo se regista; segundo a sua própria descrição, "monitoriza locais comuns de persistência e alerta sempre que um novo componente persistente é adicionado", mostrando o processo responsável, o seu estado de assinatura, e deixando-o permitir ou bloquear na hora.

Ficheiros de arranque da shell: a rede silenciosa que apanha tudo

Mais um local que vale a pena observar diretamente, já que não precisa de nenhum plist nem de nenhuma instalação privilegiada: os ficheiros de configuração da shell. O ~/.zshrc, o ~/.zprofile e o ~/.bash_profile correm sempre que uma nova sessão de terminal correspondente se abre, e uma única linha acrescentada — a encaminhar para um script, a exportar um PATH sequestrado, a lançar um processo em segundo plano — basta para restabelecer um ponto de apoio de cada vez que abre o Terminal, sem nada para carregar no launchd e nada para o launchctl print mostrar. O KnockKnock, da Objective-See, inclui exatamente esta categoria na sua análise, listada ao lado dos agentes de lançamento e dos itens de início de sessão como ficheiros de configuração da shell, pela mesma razão que pertence a este artigo: é comum o suficiente, e pouco vistosa o suficiente, para merecer verificação em vez de ser dada como garantida.

Terminal — uma leitura rápida, não um substituto para a ler de facto

$ 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-screen

Onde o FireAI encaixa, e onde deliberadamente não encaixa

Para ser direto sobre isto: o FireAI não analisa /Library/LaunchDaemons, não lê ficheiros plist, e não faz nenhuma tentativa de detetar um novo item de início de sessão ou perfil de configuração. Essa é uma disciplina distinta daquilo que o FireAI faz, e ferramentas construídas especificamente para isso — o KnockKnock e o BlockBlock entre elas — já fazem bem esse trabalho. O que o FireAI vigia é o passo que vem depois da persistência, e de que cada um destes mecanismos acaba por precisar se quiser ser útil a quem o instalou: uma ligação de rede. Um LaunchAgent que corre silenciosamente em cada início de sessão mas nunca fala com a rede é, do ponto de vista de uma firewall de rede, invisível — e também, na prática, muito menos útil para um atacante. No momento em que abre um socket, as regras por aplicação do FireAI aplicam-se a ele como a qualquer outro processo: um binário assinado ou não assinado e desconhecido a fazer a sua primeira ligação desencadeia um pedido, com o raciocínio do modelo no dispositivo mostrado em linguagem simples, e cada decisão é visível, reversível e exportável como regra de texto depois.

A forma honesta de juntar as duas disciplinas: verifique os locais deste artigo com uma periodicidade que corresponda à sua tolerância ao risco — mensalmente é razoável para a maioria das pessoas, semanalmente se instalar muito software de terceiros — e deixe uma ferramenta de rede carregar o peso pelo meio, partindo do princípio de que qualquer coisa que persistiu silenciosamente vai eventualmente ter de falar para alcançar quem quer que responda por ela.

O papel do FireAI e da HisnLabs

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.

O FireAI é o produto da HisnLabs: uma firewall com IA que corre diretamente no seu Mac. Mostra, em linguagem clara, cada ligação que as suas aplicações fazem e deixa-o decidir o que sai do seu Mac — a IA funciona localmente, pelo que o seu tráfego nunca é enviado para nós nem para mais ninguém. A equipa de investigação em segurança da HisnLabs é quem mantém essas decisões fiáveis: cataloga que domínios são simples telemetria e quais são um serviço real, acompanha o país e a rede por detrás de uma ligação e treina o modelo local (a funcionalidade Autopilot) com padrões de tráfego reais, sem que nada disso saia do seu Mac.

Pode ler as decisões técnicas por detrás dele, ou experimentar o FireAI durante 17 dias, em FireAI, da HisnLabs.