19 KiB
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!
- Adquira o material oficial PEASS & HackTricks
- Descubra A Família PEASS, nossa coleção de NFTs exclusivos
- Junte-se ao grupo 💬 Discord ou ao grupo do telegram ou siga-me no Twitter 🐦 @carlospolopm.
- Compartilhe suas técnicas de hacking enviando PRs para os repositórios do GitHub HackTricks e 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-ii-enumeration-ad27224371e1
- 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 arquivokrb5.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 arquivokrb5.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:
- Tickets válidos podem ser utilizados para autenticar, sem a necessidade da senha em texto simples do respectivo usuário.
- 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
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.
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 da @Tarlogic desenvolveu uma ferramenta que pode extrair tickets Kerberos do Unix keyring. A ferramenta chama-se Tickey e pode ser encontrada aqui.
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 criou. Seu projeto 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.
# 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 {% 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).
# 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:
ipa user-find
ipa usergroup-find
ipa host-find
ipa host-group-find
-------------------
ipa user-show <username> --all
ipa usergroup-show <user group> --all
ipa host-find <host> --all
ipa hostgroup-show <host group> --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...).
# 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 <hbacrule> --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.
# 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 <sudorule> --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.
# Using ldap
ldapsearch -Y gssapi -b "cn=roles,cn=accounts,dc=westeros,dc=local"
# Using ipa binary
ipa role-find
ipa role-show <role> --all
ipa privilege-find
ipa privilege-show <privilege> --all
ipa permission-find
ipa permission-show <permission> --all
Exemplo de Cenário de Ataque
Em 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
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\
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!
- Adquira o material oficial PEASS & HackTricks
- Descubra A Família PEASS, nossa coleção de NFTs exclusivos
- Junte-se ao grupo 💬 Discord ou ao grupo telegram ou siga-me no Twitter 🐦 @carlospolopm.
- Compartilhe suas técnicas de hacking enviando PRs para os repositórios github HackTricks e HackTricks Cloud.