# Pentesting FreeIPA
Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)! Outras formas de apoiar o HackTricks: * Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com) * Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos * **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.** * **Compartilhe suas técnicas de hacking enviando PRs para os repositórios do GitHub** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
Esta informação foi retirada dos posts: * [https://posts.specterops.io/attacking-freeipa-part-i-authentication-77e73d837d6a](https://posts.specterops.io/attacking-freeipa-part-i-authentication-77e73d837d6a) * [https://posts.specterops.io/attacking-freeipa-part-ii-enumeration-ad27224371e1](https://posts.specterops.io/attacking-freeipa-part-ii-enumeration-ad27224371e1) * [https://www.youtube.com/watch?v=9dOu-7BTwPQ\&feature=youtu.be](https://www.youtube.com/watch?v=9dOu-7BTwPQ\&feature=youtu.be) ## Informações Básicas É uma **alternativa** open source ao Microsoft Windows **Active Directory**, usada principalmente como uma solução integrada de gestão para ambientes **Unix**. Semelhante ao Active Directory, o FreeIPA implementa uma infraestrutura completa de **diretório LDAP** suportada por um MIT **Kerberos** Key Distribution Center. Utiliza o Dogtag **Certificate System** para gestão de certificados CA & RA, dando-lhe a capacidade de lidar com autenticação **multi-fator**, incluindo smartcards. O SSSD é usado para integrar o FreeIPA no processo padrão de autenticação Unix. ## Impressões Digitais ### Arquivos & Variáveis de Ambiente * **`/etc/krb5.conf`:** O arquivo `krb5.conf` contém as informações do cliente Kerberos necessárias para ser **inscrito no domínio**. Isso inclui as **localizações dos KDCs e servidores admin** para os reinos Kerberos de interesse, padrões para o reino atual e para aplicações Kerberos, e mapeamentos de hostnames para reinos Kerberos. * **`/etc/ipa/default.conf`:** Este é o **arquivo de configuração padrão para servidores IPA**, é usado para definir padrões de sistema a serem aplicados ao executar clientes e servidores IPA. * **`/etc/krb5.keytab`:** O arquivo `krb5.keytab` é **necessário** em todos os hosts dentro do **domínio**. É necessário como parte do processo de **autenticação** para o KDC. * **`KRB5CCNAME`:** Se definido, esta variável aponta para a **localização do CCACHE Ticket** a ser usado para autenticação. * **`KRB5_KTNAME`:** Se definido, esta variável aponta para a **localização** do arquivo **Keytab** a ser usado para autenticação. * **`KRB5_CONFIG`:** Se definido, esta variável aponta para a **localização** do arquivo de **configuração Kerberos**. * **`KRB5_KDC_PROFILE`:** Se definido, esta variável aponta para a **localização do arquivo de configuração do KDC**, que contém diretivas adicionais de configuração para o daemon do Key Distribution Center. * **`KRB5RCACHETYPE`:** Esta variável especifica o **tipo padrão de cache de replay** a ser usado pelos servidores. * **`KRB5RCACHEDIR`:** Esta variável especifica o **diretório padrão para caches de replay** usados pelos servidores. * **`KRB5_TRACE`:** Esta variável especifica um **nome de arquivo para escrever a saída do log de rastreamento**. Logs de rastreamento podem ajudar a esclarecer decisões feitas internamente pelas bibliotecas Kerberos. * **`KRB5_CLIENT_KTNAME`:** Esta variável define o nome do arquivo **keytab do cliente padrão**. * **`KPROP_PORT`:** Esta variável define a **porta padrão para o kprop** usar. ### Binários * **ipa:** Este binário é o padrão para **gerenciar um domínio FreeIPA**. Pode ser usado para gerenciar hosts, usuários, regras sudo e muito mais. * **kdestroy:** O binário kdestroy é usado para **destruir** quaisquer **tickets Kerberos** atuais na sessão do usuário. * **kinit:** O binário kinit é usado para **estabelecer**, ou **renovar tickets Kerberos**. * **klist:** O binário klist **lista** quaisquer **tickets Kerberos em uso** atualmente, e quais principais os tickets fornecem acesso. * **kpasswd:** O comando kpasswd é usado para **mudar a senha de um principal Kerberos**. kpasswd primeiro solicita a senha Kerberos atual, depois pede ao usuário duas vezes pela nova senha, e a senha é alterada. * **ksu:** Ksu pode ser usado como uma **alternativa ao binário su**, para mudar o **contexto do usuário atual**. * **kswitch:** O comando kswitch irá **trocar** o **cache de credenciais em uso** atualmente. * **kvno:** O binário kvno adquire um **ticket de serviço** para os **principais Kerberos especificados** e imprime os números de versão das chaves de cada um. ### Rede É assim que um servidor FreeIPA pode parecer:
## Autenticação Como o FreeIPA usa **Kerberos para autenticação**, esse processo é muito semelhante à **autenticação** no **Active Directory**. Para **acessar** recursos no domínio, um usuário deve ter um **ticket Kerberos válido** para esse recurso. Esses tickets podem ser armazenados em vários locais diferentes com base na configuração do domínio FreeIPA. ### **Arquivos de Ticket CCACHE** Quando os tickets são configurados para serem **armazenados** como um **arquivo** em **disco**, o formato e tipo padrão é um arquivo **CCACHE**. Este é um formato de arquivo binário simples para armazenar credenciais Kerberos. Esses arquivos são normalmente armazenados em **`/tmp`** e configurados com permissões **600**. Do ponto de vista de um atacante, isso é importante pelas seguintes razões: 1. Tickets válidos podem ser **utilizados para autenticar**, **sem** a necessidade da **senha** em texto simples do respectivo usuário. 2. Tickets **CCACHE** são altamente **portáteis**. Eles podem ser baixados e carregados em outro host sem a necessidade de renovar ou validar o ticket. **Analisar** um Ticket CCACHE pode ser facilmente realizado de várias maneiras diferentes. O método mais simples é analisá-lo com o binário klist. ``` klist /tmp/krb5cc_0 ``` ```markdown Para um atacante, reutilizar um Ticket CCACHE é muito fácil. Para **reutilizar** um Ticket CCACHE válido, **exporte** **KRB5CCNAME** para o **caminho** do arquivo de ticket válido. O sistema deve reconhecer a variável de ambiente e tentará usar esse material de credencial ao interagir com o domínio. ``` ```bash export KRB5CCNAME=/tmp/krb5cc_0 klist ``` ### **Unix Keyring** CCACHE Tickets podem também ser **armazenados** no **keyring** do Linux. O keyring vive dentro do **kernel** e oferece aos administradores **mais controle sobre a recuperação e uso de tickets armazenados**. Os tickets podem ser delimitados das seguintes maneiras: * **`KEYRING:name`:** Tickets são delimitados a um Keyring nomeado específico. * **`KEYRING:process:name`:** Tickets são delimitados a um id de processo específico. * **`KEYRING:thread:name`:** Tickets são delimitados a uma thread específica. * **`KEYRING:session:name`:** Tickets são delimitados a uma sessão de usuário específica. * **`KEYRING:persistent:uidnumber`:** Tickets são delimitados a um usuário específico independentemente da sessão (padrão). Dependendo de como o administrador delimitou o ticket armazenado dentro do Unix keyring, analisá-lo pode ser difícil. No entanto, o **escopo** **padrão** para CCACHE Tickets no Unix keyring é **`KEYRING:persistent:uidnumber`**. Felizmente, se você está no **contexto** do **usuário**, `klist` pode **analisar** essa informação para nós. Como atacante, **reutilizar um CCACHE** Ticket armazenado no Unix **keyring** é bastante **difícil** dependendo de como o ticket é delimitado. Felizmente [@Zer1t0](https://github.com/Zer1t0) da [@Tarlogic](https://twitter.com/Tarlogic) desenvolveu uma ferramenta que pode extrair tickets Kerberos do Unix keyring. A ferramenta chama-se **Tickey** e pode ser encontrada [**aqui**](https://github.com/TarlogicSecurity/tickey). ### Keytab {% hint style="warning" %} geralmente, cada host é implantado com uma credencial keytab para aquele host que pode ser usada para obter um Ticket Granting Ticket (TGT) válido do Credential Cache (CCACHE) para o próprio host. {% endhint %} Consiste em pares de **principais Kerberos e chaves criptografadas** que são derivadas da senha Kerberos associada ao principal. Como essas chaves são derivadas da senha do principal, se essa **senha mudar o keytab será invalidado**. Arquivos keytab podem ser usados para **obter um ticket granting ticket** (TGT) válido para o principal ao qual está delimitado. Esse processo de autenticação **não requer a senha**, pois contém chaves derivadas da senha. Analisar um arquivo keytab é muito fácil e pode ser feito de algumas maneiras. A maneira mais fácil de **analisar** um arquivo **keytab** é com **klist**. A segunda maneira utiliza uma ótima utilidade python que [Cody Thomas](https://medium.com/u/645ffcef8682?source=post\_page-----77e73d837d6a--------------------------------) criou. Seu projeto [**KeytabParser**](https://github.com/its-a-feature/KeytabParser) **analisará** o principal e suas chaves criptografadas relevantes. Atacantes podem **reutilizar credenciais armazenadas em arquivos keytab gerando um CCACHE Ticket** através do binário kinit. ```powershell # Parse keytab klist -k /rtc/krb5.keytab # Get TGT kinit -kt /etc/krb5.keytab host/bastion.westeros.local@WESTEROS.LOCAL ``` ### Cheatsheet Você pode encontrar mais informações sobre como usar tickets no linux no seguinte link: {% content-ref url="privilege-escalation/linux-active-directory.md" %} [linux-active-directory.md](privilege-escalation/linux-active-directory.md) {% endcontent-ref %} ## Enumeração {% hint style="warning" %} Você pode realizar a **enumeração** via **ldap** e outras ferramentas **binárias**, ou **conectando-se à página web na porta 443 do servidor FreeIPA**. {% endhint %} ### Hosts, Usuários e Grupos É possível criar **hosts**, **usuários** e **grupos**. Hosts e usuários são organizados em contêineres chamados “**Host Groups**” e “**User Groups**”, respectivamente. Estes são semelhantes a **Unidades Organizacionais** (OU). Por padrão no FreeIPA, o servidor LDAP permite **binds anônimos**, e uma grande quantidade de dados é enumerável **sem autenticação**. Isso pode enumerar todos os dados disponíveis sem autenticação: ``` ldapsearch -x ``` Para obter **mais informações**, você precisa usar uma sessão **autenticada** (consulte a seção de Autenticação para aprender como preparar uma sessão autenticada). ```bash # Get all users of domain ldapsearch -Y gssapi -b "cn=users,cn=compat,dc=domain_name,dc=local" # Get users groups ldapsearch -Y gssapi -b "cn=groups,cn=accounts,dc=domain_name,dc=local" # Get all the hosts ldapsearch -Y gssapi -b "cn=computers,cn=accounts,dc=domain_name,dc=local" # Get hosts groups ldapsearch -Y gssapi -b "cn=hostgroups,cn=accounts,dc=domain_name,dc=local" ``` De uma máquina associada ao domínio, você poderá usar **binários instalados** para enumerar o domínio: ```bash ipa user-find ipa usergroup-find ipa host-find ipa host-group-find ------------------- ipa user-show --all ipa usergroup-show --all ipa host-find --all ipa hostgroup-show --all ``` {% hint style="info" %} O usuário **admin** do **FreeIPA** é equivalente aos **domain admins** do **AD**. {% endhint %} ### Hashes O usuário **root** do **servidor IPA** tem acesso aos **hashes** de senha. * O hash de senha de um usuário é armazenado como **base64** no **atributo** “**userPassword**”. Esse hash pode ser **SSHA512** (versões antigas do FreeIPA) ou **PBKDF2\_SHA256**. * O **Nthash** da senha armazenado como **base64** em “**ipaNTHash**” se o sistema tem **integração** com **AD**. Para quebrar esses hashes: • Se o freeIPA estiver integrado com AD, **ipaNTHash** é fácil de quebrar: Você deve **decodificar** **base64** -> recodificá-lo como hex **ASCII** -> John The Ripper ou **hashcat** podem ajudá-lo a quebrá-lo rapidamente • Se uma versão antiga do FreeIPA estiver sendo usada, então **SSHA512** é usado: Você deve decodificar **base64** -> encontrar o **hash** SSHA512 -> John The Ripper ou **hashcat** podem ajudá-lo a quebrá-lo • Se uma versão nova do FreeIPA estiver sendo usada, então **PBKDF2\_SHA256** é usado: Você deve decodificar **base64** -> encontrar PBKDF2\_SHA256 -> seu **comprimento** é de 256 bytes. John pode trabalhar com 256 bits (32 bytes) -> SHA-256 usado como a função pseudo-aleatória, tamanho do bloco é de 32 bytes -> você pode usar apenas os primeiros 256 bits do nosso hash PBKDF2\_SHA256 -> John The Ripper ou hashcat podem ajudá-lo a quebrá-lo
Para extrair os hashes você precisa ser **root no servidor FreeIPA**, lá você pode usar a ferramenta **`dbscan`** para extraí-los:
### Regras HBAC Estas são as regras que concedem permissões específicas a usuários ou hosts sobre recursos (hosts, serviços, grupos de serviços...). ```bash # Enumerate using ldap ldapsearch -Y gssapi -b "cn=hbac,dc=domain_name,dc=local" # Using ipa ipa hbacrule-find # Show info of rule ipa hbacrule-show --all ``` #### Regras de Sudo FreeIPA oferece a capacidade de **gerenciar permissões sudo** de uma fonte **centralizada** através de regras de sudo. Esses conjuntos de regras podem ser usados para restringir ou delegar a capacidade de **executar comandos como sudo** em hosts inscritos no domínio. Como atacante, podemos enumerar quais hosts e usuários esses conjuntos de regras são aplicados, e quais comandos são permitidos através do conjunto de regras. ```bash # Enumerate using ldap ldapsearch -Y gssapi -b "cn=sudorules,cn=sudo,dc=domain_name,dc=local" # Using ipa ipa sudorule-find # Show info of rule ipa sudorule-show --all ``` ### Controle de Acesso Baseado em Funções Cada **função** contém um conjunto de **privilégios**, e esses respectivos privilégios contêm um **conjunto** de **permissões**. Funções podem ser **aplicadas a Usuários**, **Grupos** de Usuários, **Hosts**, Grupos de Hosts e Serviços. Para ilustrar esse conceito, vamos discutir a função padrão de "Administrador de Usuário" no FreeIPA.
Como a captura de tela acima mostra, a função de “Administrador de Usuário” contém os seguintes privilégios: * **Administradores de Usuários** * **Administradores de Grupos** * **Administradores de Usuário em Estágio** Podemos detalhar ainda mais e enumerar as **permissões** delegadas a cada **privilégio**:
Como podemos ver, a função de “**Administrador de Usuário**” contém **muitas permissões** dentro do ambiente. Entender o conceito geral e a estrutura de **funções**, **privilégios** e **permissões** pode ser crítico para identificar caminhos de ataque em todo o ambiente. ```bash # Using ldap ldapsearch -Y gssapi -b "cn=roles,cn=accounts,dc=westeros,dc=local" # Using ipa binary ipa role-find ipa role-show --all ipa privilege-find ipa privilege-show --all ipa permission-find ipa permission-show --all ``` ### Exemplo de Cenário de Ataque Em [https://posts.specterops.io/attacking-freeipa-part-iii-finding-a-path-677405b5b95e](https://posts.specterops.io/attacking-freeipa-part-iii-finding-a-path-677405b5b95e) você pode encontrar um exemplo simples de como abusar de algumas permissões para comprometer o domínio. ### Linikatz/LinikatzV2 * [https://github.com/Orange-Cyberdefense/LinikatzV2](https://github.com/Orange-Cyberdefense/LinikatzV2) * [https://github.com/CiscoCXSecurity/linikatz](https://github.com/CiscoCXSecurity/linikatz) ## Privesc ### ~~criação de usuário root~~ {% hint style="warning" %} Se você pode **criar um novo usuário com o nome `root`**, você pode se passar por ele e será capaz de **acessar qualquer máquina via SSH como root.** **ISSO FOI CORRIGIDO.** {% endhint %} O privilégio "**User Administrators**" é muito poderoso (como o próprio nome indica):
Com esse privilégio vem uma série de diferentes poderes para afetar usuários dentro do ambiente. Usando esse privilégio, podemos **criar um novo usuário dentro do domínio FreeIPA chamado \_root**\_.
Uma vez que o usuário é criado no domínio, podemos **obter um ticket para a conta com \_kinit**\_.
Agora podemos tentar **SSH** usando nossa recém-criada conta de domínio root.
Como mostrado, isso **coloca o usuário na conta root local**! Então, simplesmente criando um usuário de domínio para um usuário local, conseguimos autenticar usando a conta _root@WESTEROS.LOCAL_ e obter o **contexto de usuário da conta root local**_._ _Para mais detalhes sobre essa vulnerabilidade, confira_ [_https://posts.specterops.io/attacking-freeipa-part-iv-cve-2020-10747-7c373a1bf66b_](https://posts.specterops.io/attacking-freeipa-part-iv-cve-2020-10747-7c373a1bf66b)\\
Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)! Outras formas de apoiar o HackTricks: * Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com) * Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos * **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao grupo [**telegram**](https://t.me/peass) ou **siga**-me no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.** * **Compartilhe suas técnicas de hacking enviando PRs para os repositórios github** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).