<summary><strong>Aprenda hacking AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você quiser ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
**TCC (Transparência, Consentimento e Controle)** é um protocolo de segurança que se concentra em regular as permissões de aplicativos. Seu papel principal é proteger recursos sensíveis como **serviços de localização, contatos, fotos, microfone, câmera, acessibilidade e acesso total ao disco**. Ao exigir o consentimento explícito do usuário antes de conceder acesso do aplicativo a esses elementos, o TCC aprimora a privacidade e o controle do usuário sobre seus dados.
Os usuários encontram o TCC quando os aplicativos solicitam acesso a recursos protegidos. Isso é visível por meio de um prompt que permite aos usuários **aprovar ou negar o acesso**. Além disso, o TCC acomoda ações diretas do usuário, como **arrastar e soltar arquivos em um aplicativo**, para conceder acesso a arquivos específicos, garantindo que os aplicativos tenham acesso apenas ao que é explicitamente permitido.
O **TCC** é gerenciado pelo **daemon** localizado em `/System/Library/PrivateFrameworks/TCC.framework/Support/tccd` e configurado em `/System/Library/LaunchDaemons/com.apple.tccd.system.plist` (registrando o serviço mach `com.apple.tccd.system`).
Existe um **tccd em modo de usuário** em execução por usuário conectado definido em `/System/Library/LaunchAgents/com.apple.tccd.plist` registrando os serviços mach `com.apple.tccd` e `com.apple.usernotifications.delegate.com.apple.tccd`.
* O banco de dados de sistema em **`/Library/Application Support/com.apple.TCC/TCC.db`**.
* Este banco de dados é **protegido pelo SIP**, então somente uma bypass do SIP pode escrever nele.
* O banco de dados de TCC do usuário **`$HOME/Library/Application Support/com.apple.TCC/TCC.db`** para preferências por usuário.
* Este banco de dados é protegido, então somente processos com altos privilégios de TCC como Acesso Total ao Disco podem escrever nele (mas não é protegido pelo SIP).
Os bancos de dados anteriores também são **protegidos pelo TCC para acesso de leitura**. Portanto, você **não poderá ler** seu banco de dados TCC regular a menos que seja de um processo com privilégios de TCC.
No entanto, lembre-se de que um processo com esses altos privilégios (como **FDA** ou **`kTCCServiceEndpointSecurityClient`**) poderá escrever no banco de dados de TCC dos usuários.
* Existe um **terceiro** banco de dados TCC em **`/var/db/locationd/clients.plist`** para indicar clientes autorizados a **acessar serviços de localização**.
* O arquivo protegido pelo SIP **`/Users/carlospolop/Downloads/REG.db`** (também protegido do acesso de leitura com TCC), contém a **localização** de todos os **bancos de dados TCC válidos**.
* O arquivo protegido pelo SIP **`/Users/carlospolop/Downloads/MDMOverrides.plist`** (também protegido do acesso de leitura com TCC), contém mais permissões concedidas pelo TCC.
* O arquivo protegido pelo SIP **`/Library/Apple/Library/Bundles/TCC_Compatibility.bundle/Contents/Resources/AllowApplicationsList.plist`** (mas legível por qualquer pessoa) é uma lista de permissões de aplicativos que requerem uma exceção de TCC.
* O **`auth_value`** pode ter valores diferentes: denied(0), unknown(1), allowed(2) ou limited(3).
* O **`auth_reason`** pode assumir os seguintes valores: Error(1), User Consent(2), User Set(3), System Set(4), Service Policy(5), MDM Policy(6), Override Policy(7), Missing usage string(8), Prompt Timeout(9), Preflight Unknown(10), Entitled(11), App Type Policy(12)
* O campo **csreq** está lá para indicar como verificar o binário a ser executado e conceder as permissões do TCC:
* Para mais informações sobre os **outros campos** da tabela [**verifique esta postagem no blog**](https://www.rainforestqa.com/blog/macos-tcc-db-deep-dive).
Você também pode verificar as **permissões já concedidas** para aplicativos em `Preferências do Sistema --> Segurança e Privacidade --> Privacidade --> Arquivos e Pastas`.
O **banco de dados** do TCC armazena o **ID do Pacote** do aplicativo, mas também **armazena****informações** sobre a **assinatura** para **garantir** que o aplicativo que solicita permissão seja o correto.
(anchor apple generic and certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "6N38VWS5BX") and identifier "ru.keepcoder.Telegram"
As aplicações **não apenas precisam****solicitar** e ter sido **concedido acesso** a alguns recursos, elas também precisam **ter as permissões relevantes**.\
Por exemplo, o **Telegram** possui a permissão `com.apple.security.device.camera` para solicitar **acesso à câmera**. Uma **aplicação** que **não** possui essa **permissão não poderá** acessar a câmera (e o usuário nem mesmo será solicitado para as permissões).
No entanto, para as aplicações **acessarem** determinadas pastas do usuário, como `~/Desktop`, `~/Downloads` e `~/Documents`, elas **não precisam** ter nenhuma **permissão específica**. O sistema lidará com o acesso de forma transparente e **solicitará permissão ao usuário** conforme necessário.
As aplicações da Apple **não gerarão solicitações**. Elas contêm **direitos pré-concedidos** em sua lista de **permissões**, o que significa que **nunca gerarão um pop-up**, **nem** aparecerão em qualquer um dos **bancos de dados do TCC**. Por exemplo:
Além de algumas documentações oficiais sobre as permissões, também é possível encontrar **informações interessantes não oficiais sobre as permissões em** [**https://newosxbook.com/ent.jl**](https://newosxbook.com/ent.jl)
Algumas permissões do TCC são: kTCCServiceAppleEvents, kTCCServiceCalendar, kTCCServicePhotos... Não há uma lista pública que defina todas elas, mas você pode verificar esta [**lista de permissões conhecidas**](https://www.rainforestqa.com/blog/macos-tcc-db-deep-dive#service).
Como mencionado anteriormente, é possível **conceder acesso a um aplicativo a um arquivo arrastando-o e soltando-o nele**. Esse acesso não será especificado em nenhum banco de dados do TCC, mas como um **atributo estendido do arquivo**. Esse atributo irá **armazenar o UUID** do aplicativo permitido:
## Script from https://gist.githubusercontent.com/brunerd/8bbf9ba66b2a7787e1a6658816f3ad3b/raw/34cabe2751fb487dc7c3de544d1eb4be04701ac5/maclTrack.command
Também observe que se você mover um arquivo que permite o UUID de um aplicativo em seu computador para um computador diferente, porque o mesmo aplicativo terá UIDs diferentes, não concederá acesso a esse aplicativo.
O atributo estendido `com.apple.macl`**não pode ser apagado** como outros atributos estendidos porque é **protegido pelo SIP**. No entanto, como [**explicado neste post**](https://www.brunerd.com/blog/2020/01/07/track-and-tackle-com-apple-macl/), é possível desativá-lo **compactando** o arquivo, **apagando** e **descompactando**.
Se em algum momento você conseguir obter acesso de escrita sobre um banco de dados TCC, você pode usar algo como o seguinte para adicionar uma entrada (remova os comentários):
Esta permissão TCC específica também indica a **aplicação que pode ser gerenciada** dentro do banco de dados TCC (então as permissões não permitem apenas gerenciar tudo).
O **Finder** é um aplicativo que **sempre tem FDA** (mesmo que não apareça na interface do usuário), então se você tiver privilégios de **Automação** sobre ele, você pode abusar de seus privilégios para **fazê-lo executar algumas ações**.\
Com essa permissão, você poderá **solicitar ao Finder acesso a pastas restritas pelo TCC** e obter os arquivos, mas até onde sei você **não poderá fazer com que o Finder execute código arbitrário** para abusar totalmente do acesso ao FDA dele.
Observe que, como o aplicativo **Automator** possui a permissão TCC **`kTCCServiceAppleEvents`**, ele pode **controlar qualquer aplicativo**, como o Finder. Portanto, tendo a permissão para controlar o Automator, você também poderia controlar o **Finder** com um código como o abaixo:
tell application "Automator" set actionID to Automator action id "com.apple.RunShellScript" tell (make new workflow) add actionID to it tell last Automator action set value of setting "inputMethod" to 1 set value of setting "COMMAND\_STRING" to theScript end tell execute it end tell activate end tell EOD
## Once inside the shell you can use the previous code to make Finder copy the TCC databases for example and not TCC prompt will appear
O mesmo acontece com o aplicativo **Script Editor,** ele pode controlar o Finder, mas usando um AppleScript você não pode forçá-lo a executar um script.
**O System Events pode criar Ações de Pasta, e as Ações de Pasta podem acessar algumas pastas TCC** (Desktop, Documents & Downloads), então um script como o seguinte pode ser usado para abusar desse comportamento:
A automação no **`System Events`** + Acessibilidade (**`kTCCServicePostEvent`**) permite enviar **teclas de atalho para processos**. Dessa forma, você poderia abusar do Finder para alterar o TCC.db dos usuários ou conceder FDA a um aplicativo arbitrário (embora a senha possa ser solicitada para isso).
-- Check if the file exists in the destination and delete if it does (need to send keystorke code: https://macbiblioblog.blogspot.com/2014/12/key-codes-for-function-and-special-keys.html)
Verifique esta página para alguns [**payloads para abusar das permissões de Acessibilidade**](macos-tcc-payloads.md#accessibility) para escalonar privilégios para FDA\* ou executar um keylogger, por exemplo.
**`kTCCServiceSystemPolicySysAdminFiles`** permite **alterar** o atributo **`NFSHomeDirectory`** de um usuário que altera sua pasta pessoal e, portanto, permite **burlar o TCC**.
Obtendo **permissões de escrita** sobre o **banco de dados TCC** do usuário, você não pode conceder a si mesmo permissões de **`FDA`**, somente aquele que reside no banco de dados do sistema pode conceder isso.
Não acho que isso seja um real escalonamento de privilégios, mas caso você ache útil: Se você controla um programa com FDA, você pode **modificar o banco de dados TCC dos usuários e conceder a si mesmo qualquer acesso**. Isso pode ser útil como técnica de persistência caso você perca suas permissões de FDA.
O banco de dados do sistema TCC é protegido pelo **SIP**, por isso somente processos com as **autorizações indicadas poderão modificá-lo**. Portanto, se um atacante encontrar uma **burla do SIP** sobre um **arquivo** (ser capaz de modificar um arquivo restrito pelo SIP), ele será capaz de:
* **Remover a proteção** de um banco de dados TCC e conceder a si mesmo todas as permissões do TCC. Ele poderia abusar de qualquer um desses arquivos, por exemplo:
No entanto, há outra opção para abusar dessa **burla do SIP para burlar o TCC**, o arquivo `/Library/Apple/Library/Bundles/TCC_Compatibility.bundle/Contents/Resources/AllowApplicationsList.plist` é uma lista de permissões de aplicativos que requerem uma exceção do TCC. Portanto, se um atacante puder **remover a proteção do SIP** deste arquivo e adicionar seu **próprio aplicativo**, o aplicativo poderá burlar o TCC.\