Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 21:53:54 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/linux-hardening/freeipa-pentesting.md
Translator workflow c928d8e52e Translated to Portuguese
2023-06-06 18:56:34 +00:00

21 KiB
Raw Blame History

FreeIPA Pentesting

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Esta informação foi retirada dos posts:

Informações básicas

É uma alternativa de código aberto ao Active Directory da Microsoft Windows, usada principalmente como solução de gerenciamento integrado para ambientes Unix. Semelhante ao Active Directory, o FreeIPA implementa uma infraestrutura completa de diretório LDAP suportada por um Centro de Distribuição de Chaves Kerberos do MIT. Ele usa o sistema de certificados Dogtag para gerenciamento de certificados CA e RA, dando-lhe a capacidade de lidar com autenticação de múltiplos fatores, incluindo smartcards. O SSSD é usado para integrar o FreeIPA ao processo padrão de autenticação Unix.

Impressões digitais

Arquivos e variáveis de ambiente

  • /etc/krb5.conf: O arquivo krb5.conf contém as informações do cliente Kerberos necessárias para ser matriculado no domínio. Isso inclui as localizações dos KDCs e servidores de administração para os reinos Kerberos de interesse, padrões para o reino atual e para aplicativos Kerberos, e mapeamentos de nomes de host em reinos Kerberos.
  • /etc/ipa/default.conf: Este é o arquivo de configuração padrão para servidores IPA, é usado para definir padrões em todo o sistema a serem aplicados ao executar clientes e servidores IPA.
  • /etc/krb5.keytab: O arquivo krb5.keytab é obrigatório em todos os hosts dentro do domínio. É necessário como parte do processo de autenticação para o KDC.
  • KRB5CCNAME: Se definido, essa variável aponta para a localização do arquivo CCACHE Ticket a ser usado para autenticação.
  • KRB5_KTNAME: Se definido, essa variável aponta para a localização do arquivo Keytab a ser usado para autenticação.
  • KRB5_CONFIG: Se definido, essa variável aponta para a localização do arquivo de configuração Kerberos.
  • KRB5_KDC_PROFILE: Se definido, essa variável aponta para a localização do arquivo de configuração KDC, que contém diretivas de configuração adicionais para o daemon do Centro de Distribuição de Chaves.
  • KRB5RCACHETYPE: Essa variável especifica o tipo padrão de cache de replay a ser usado para servidores.
  • KRB5RCACHEDIR: Essa variável especifica o diretório padrão para caches de replay usados por servidores.
  • KRB5_TRACE: Essa variável especifica um nome de arquivo para gravar a saída do log de rastreamento. Os logs de rastreamento podem ajudar a iluminar as decisões tomadas internamente pelas bibliotecas Kerberos.
  • KRB5_CLIENT_KTNAME: Essa variável define o nome do arquivo de chave do cliente padrão.
  • KPROP_PORT: Essa variável define a porta padrão para kprop a ser usada.

Binários

  • ipa: Este binário é o padrão para gerenciar um domínio FreeIPA. Ele 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 atuais em uso e quais princípios os tickets fornecem acesso.
  • kpasswd: O comando kpasswd é usado para alterar a senha do principal Kerberos. O kpasswd primeiro solicita a senha Kerberos atual, depois solicita ao usuário duas vezes a nova senha e a senha é alterada.
  • ksu: Ksu pode ser usado como uma alternativa ao binário su, para alternar o contexto do usuário atual.
  • kswitch: O comando kswitch irá alternar o cache de credenciais atual em uso.
  • kvno: O binário kvno adquire um ticket de serviço para os princípios Kerberos especificados e imprime os números de versão da chave de cada um.

Rede

Assim é como um servidor FreeIPA pode parecer:

Autenticação

Como o FreeIPA usa o 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 definidos 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 com permissões 600. Do ponto de vista de um atacante, isso é importante pelos seguintes motivos:

  1. Tickets válidos podem ser utilizados para autenticação, sem a necessidade da senha em texto plano do respectivo usuário.
  2. Os 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 é 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 válido é 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

Os Tickets CCACHE também podem ser armazenados no keyring do Linux. O keyring fica dentro do kernel e dá aos administradores maior controle sobre a recuperação e uso dos tickets armazenados. Os tickets podem ser escopados das seguintes maneiras:

  • KEYRING:nome: Tickets são escopados para um keyring nomeado específico.
  • KEYRING:processo:nome: Tickets são escopados para um ID de processo específico.
  • KEYRING:thread:nome: Tickets são escopados para uma thread específica.
  • KEYRING:sessão:nome: Tickets são escopados para uma sessão de usuário específica.
  • KEYRING:persistente:númerodeuid: Tickets são escopados para um usuário específico, independentemente da sessão (padrão).

Dependendo de como o administrador escopou o ticket armazenado no Unix keyring, analisá-lo pode ser difícil. No entanto, o escopo padrão para os Tickets CCACHE no Unix keyring é KEYRING:persistente:númerodeuid. Felizmente, se você estiver no contexto do usuário, o klist pode analisar essas informações para nós.

Como atacante, reutilizar um Ticket CCACHE armazenado no keyring do Unix é bastante difícil, dependendo de como o ticket é escopado. Felizmente, @Zer1t0 da @Tarlogic criou uma ferramenta que pode extrair tickets Kerberos do keyring do Unix. A ferramenta é chamada de Tickey e pode ser encontrada aqui.

Keytab

{% hint style="warning" %} geralmente, cada host é implantado com uma credencial keytab para esse host que pode ser usada para obter um Ticket Granting Ticket(TGT) válido do Cache de Credenciais(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.

Os arquivos Keytab podem ser usados para obter um TGT válido para o principal ao qual está escopado. 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 o klist. A segunda maneira utiliza uma ótima ferramenta em Python que Cody Thomas criou. Seu projeto **** KeytabParser **** irá analisar o principal e suas chaves criptografadas relevantes.

Os atacantes podem reutilizar credenciais armazenadas em arquivos keytab gerando um Ticket CCACHE 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

Folha de dicas

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 da 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 classificados em contêineres chamados "Grupos de Hosts" e "Grupos de Usuários", respectivamente. Estes são semelhantes às Unidades Organizacionais (OU).

Por padrão, no FreeIPA, o servidor LDAP permite ligações anônimas, e uma grande quantidade de dados é enumerável não autenticada. Isso pode enumerar todos os dados disponíveis não autenticados:

ldapsearch -x

Para obter mais informações, você precisa usar uma sessão autenticada (verifique 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 integrada 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 administradores de domínio do AD. {% endhint %}

Hashes

O usuário root do servidor IPA tem acesso às hashes de senha.

  • A hash de senha de um usuário é armazenada como base64 no atributo "userPassword". Essa hash pode ser SSHA512 (versões antigas do FreeIPA) ou PBKDF2_SHA256.
  • O Nthash da senha é armazenado como base64 em "ipaNTHash" se o sistema tiver integração com o AD.

Para quebrar essas hashes:

• Se o FreeIPA estiver integrado com o AD, o ipaNTHash é fácil de quebrar: você deve decodificar o base64 -> re-codificá-lo como hexadecimal ASCII -> John The Ripper ou hashcat podem ajudá-lo a quebrá-lo rapidamente.

• Se uma versão antiga do FreeIPA for usada, então SSHA512 é usado: você deve decodificar o base64 -> encontrar a hash SSHA512 -> John The Ripper ou hashcat podem ajudá-lo a quebrá-lo.

• Se uma nova versão do FreeIPA for usada, então PBKDF2_SHA256 é usado: você deve decodificar o base64 -> encontrar o PBKDF2_SHA256 -> seu tamanho é de 256 bytes. John pode trabalhar com 256 bits (32 bytes) -> SHA-265 usado como a função pseudo-aleatória, o tamanho do bloco é de 32 bytes -> você pode usar apenas os primeiros 256 bits da hash PBKDF2_SHA256 -> John The Ripper ou hashcat podem ajudá-lo a quebrá-lo.

Para extrair as hashes, você precisa ser root no servidor FreeIPA, lá você pode usar a ferramenta dbscan para extraí-las:

Regras HBAC

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 do Sudo

O FreeIPA fornece a capacidade de gerenciar permissões do sudo a partir de uma fonte centralizada por meio de regras do 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 em quais hosts e usuários esses conjuntos de regras são aplicados e quais comandos são permitidos por meio 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ção

Cada função contém um conjunto de privilégios, e esses respectivos privilégios contêm um conjunto de permissões. As 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 "Administrador de Usuário" no FreeIPA.

Como a captura de tela acima mostra, a função "Administrador de Usuário" contém os seguintes privilégios:

  • Administradores de Usuários
  • Administradores de Grupos
  • Administradores de Usuários de Estágio

Podemos aprofundar ainda mais e enumerar as permissões delegadas a cada privilégio:

Como podemos ver, a função "Administrador de Usuário" contém muitas permissões dentro do ambiente. Compreender o conceito geral e a estrutura de funções, privilégios e permissões pode ser fundamental 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

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 SSH em qualquer máquina como root.

ISSO FOI CORRIGIDO. {% endhint %}

O privilégio "Administradores de Usuários", é muito poderoso (como o nome indica):

Com esse privilégio vem muitos poderes diferentes para afetar usuários dentro do ambiente. Usando esse privilégio, podemos criar um novo usuário dentro do domínio FreeIPA com o nome _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 nova 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, fomos capazes de autenticar usando a conta root@WESTEROS.LOCAL e obter o contexto do usuário da conta root local.

Para mais detalhes sobre essa vulnerabilidade, verifique https://posts.specterops.io/attacking-freeipa-part-iv-cve-2020-10747-7c373a1bf66b\

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥