Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 14:40:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/linux-hardening/freeipa-pentesting.md

21 KiB
Raw Blame History

FreeIPA Pentesting

Apprenez le hacking AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :

Cette information a été prise des articles :

Informations de base

C'est une alternative open source à Microsoft Windows Active Directory, principalement utilisée comme solution de gestion intégrée pour les environnements Unix. Semblable à Active Directory, FreeIPA implémente une infrastructure complète d'annuaire LDAP soutenue par un MIT Kerberos Key Distribution Center. Il utilise le Certificate System Dogtag pour la gestion des certificats CA & RA, lui donnant la capacité de gérer l'authentification multi-facteurs, y compris les cartes à puce. SSSD est utilisé pour intégrer FreeIPA dans le processus d'authentification Unix standard.

Empreintes

Fichiers & Variables d'Environnement

  • /etc/krb5.conf : Le fichier krb5.conf contient les informations du client Kerberos nécessaires pour être inscrit dans le domaine. Cela inclut les emplacements des KDCs et des serveurs admin pour les royaumes Kerberos d'intérêt, les valeurs par défaut pour le royaume actuel et pour les applications Kerberos, et les mappages des noms d'hôtes sur les royaumes Kerberos.
  • /etc/ipa/default.conf : C'est le fichier de configuration par défaut pour les serveurs IPA, il est utilisé pour définir les valeurs par défaut à appliquer lors de l'exécution des clients et serveurs IPA.
  • /etc/krb5.keytab : Le fichier krb5.keytab est requis sur tous les hôtes à l'intérieur du domaine. Il est nécessaire dans le cadre du processus d'authentification au KDC.
  • KRB5CCNAME : Si défini, cette variable indique l'emplacement du Ticket CCACHE à utiliser pour l'authentification.
  • KRB5_KTNAME : Si défini, cette variable indique l'emplacement du fichier Keytab à utiliser pour l'authentification.
  • KRB5_CONFIG : Si défini, cette variable indique l'emplacement du fichier de configuration Kerberos.
  • KRB5_KDC_PROFILE : Si défini, cette variable indique l'emplacement du fichier de configuration KDC, qui contient des directives de configuration supplémentaires pour le démon Key Distribution Center.
  • KRB5RCACHETYPE : Cette variable spécifie le type par défaut de cache de rejeu à utiliser pour les serveurs.
  • KRB5RCACHEDIR : Cette variable spécifie le répertoire par défaut pour les caches de rejeu utilisés par les serveurs.
  • KRB5_TRACE : Cette variable spécifie un nom de fichier pour écrire la sortie du journal de trace. Les journaux de trace peuvent aider à éclairer les décisions prises en interne par les bibliothèques Kerberos.
  • KRB5_CLIENT_KTNAME : Cette variable définit le nom de fichier keytab client par défaut.
  • KPROP_PORT : Cette variable définit le port par défaut pour kprop à utiliser.

Binaires

  • ipa : Ce binaire est la norme pour gérer un domaine FreeIPA. Il peut être utilisé pour gérer des hôtes, des utilisateurs, des règles sudo, et bien plus encore.
  • kdestroy : Le binaire kdestroy est utilisé pour détruire tout ticket Kerberos actuel dans la session de l'utilisateur.
  • kinit : Le binaire kinit est utilisé pour établir, ou renouveler des tickets Kerberos.
  • klist : Le binaire klist liste tout ticket Kerberos en cours d'utilisation, et quels principaux les tickets donnent accès.
  • kpasswd : La commande kpasswd est utilisée pour changer le mot de passe d'un principal Kerberos. kpasswd demande d'abord le mot de passe Kerberos actuel, puis demande deux fois à l'utilisateur le nouveau mot de passe, et le mot de passe est changé.
  • ksu : Ksu peut être utilisé comme une alternative au binaire su, pour changer le contexte utilisateur actuel.
  • kswitch : La commande kswitch va changer le cache d'identification en cours d'utilisation.
  • kvno : Le binaire kvno acquiert un ticket de service pour les principaux Kerberos spécifiés et imprime les numéros de version des clés de chacun.

Réseau

Voici à quoi pourrait ressembler un serveur FreeIPA :

Authentification

Puisque FreeIPA utilise Kerberos pour l'authentification, ce processus est très similaire à l'authentification dans Active Directory. Pour accéder aux ressources sur le domaine, un utilisateur doit avoir un ticket Kerberos valide pour cette ressource. Ces tickets peuvent être stockés dans différents emplacements en fonction de la configuration du domaine FreeIPA.

Fichiers Ticket CCACHE

Lorsque les tickets sont configurés pour être stockés sous forme de fichier sur disque, le format et le type standard est un fichier CCACHE. Il s'agit d'un format de fichier binaire simple pour stocker les informations d'identification Kerberos. Ces fichiers sont généralement stockés dans /tmp et ont des permissions 600. Du point de vue d'un attaquant, cela est important pour les raisons suivantes :

  1. Les tickets valides peuvent être utilisés pour s'authentifier, sans avoir besoin du mot de passe en clair de l'utilisateur respectif.
  2. Les tickets CCACHE sont très portables. Ils peuvent être téléchargés et chargés sur un autre hôte sans avoir besoin de renouveler ou de valider le ticket.

Analyser un Ticket CCACHE est facilement réalisable de différentes manières. La méthode la plus simple est de l'analyser avec le binaire klist.

klist /tmp/krb5cc_0

<figure><img src="../.gitbook/assets/image (70).png" alt=""><figcaption></figcaption></figure>

Pour un attaquant, réutiliser un ticket CCACHE est très facile. Pour **réutiliser** un ticket CCACHE valide, **exportez** **KRB5CCNAME** vers le **chemin** du fichier de ticket valide. Le système devrait reconnaître la variable d'environnement et tentera d'utiliser ce matériel d'identification lors de l'interaction avec le domaine.

export KRB5CCNAME=/tmp/krb5cc_0
klist

Porte-clés Unix

Les tickets CCACHE peuvent également être stockés dans le porte-clés Linux. Le porte-clés réside à l'intérieur du noyau, et offre aux administrateurs plus de contrôle sur la récupération et l'utilisation des tickets stockés. Les tickets peuvent être délimités de différentes manières :

  • KEYRING:name : Les tickets sont délimités à un porte-clés nommé spécifique.
  • KEYRING:process:name : Les tickets sont délimités à un identifiant de processus spécifique.
  • KEYRING:thread:name : Les tickets sont délimités à un thread spécifique.
  • KEYRING:session:name : Les tickets sont délimités à une session utilisateur spécifique.
  • KEYRING:persistent:uidnumber : Les tickets sont délimités à un utilisateur spécifique indépendamment de la session (par défaut).

Selon la manière dont l'administrateur a délimité le ticket stocké dans le porte-clés Unix, l'extraire peut être difficile. Cependant, la portée par défaut pour les tickets CCACHE dans le porte-clés Unix est KEYRING:persistent:uidnumber. Heureusement, si vous êtes dans le contexte de l'utilisateur, klist peut analyser cette information pour nous.

En tant qu'attaquant, réutiliser un ticket CCACHE stocké dans le porte-clés Unix est assez difficile selon la portée du ticket. Heureusement, @Zer1t0 de @Tarlogic a développé un outil qui peut extraire les tickets Kerberos du porte-clés Unix. L'outil s'appelle Tickey et peut être trouvé ici.

Keytab

{% hint style="warning" %} habituellement, chaque hôte est déployé avec des informations d'identification keytab pour cet hôte qui peuvent être utilisées pour obtenir un Ticket Granting Ticket (TGT) CCACHE valide pour l'hôte lui-même. {% endhint %}

Il se compose de paires de principaux Kerberos et de clés chiffrées qui sont dérivées du mot de passe Kerberos associé au principal. Étant donné que ces clés sont dérivées du mot de passe du principal, si ce mot de passe change, le fichier keytab sera invalidé.

Les fichiers keytab peuvent être utilisés pour obtenir un ticket granting ticket (TGT) valide pour le principal auquel il est délimité. Ce processus d'authentification ne nécessite pas le mot de passe, car il contient des clés dérivées du mot de passe.

Analyser un fichier keytab est très facile et peut être accompli de plusieurs manières. La manière la plus simple d'analyser un fichier keytab est avec klist. La deuxième méthode utilise un excellent utilitaire python que Cody Thomas a créé. Son projet KeytabParser analysera le principal et ses clés chiffrées pertinentes.

Les attaquants peuvent réutiliser les informations d'identification stockées dans les fichiers keytab en générant un ticket CCACHE via le binaire kinit.

# Parse keytab
klist -k /rtc/krb5.keytab

# Get TGT
kinit -kt /etc/krb5.keytab host/bastion.westeros.local@WESTEROS.LOCAL

Cheatsheet

Vous pouvez trouver plus d'informations sur comment utiliser les tickets dans linux dans le lien suivant :

{% content-ref url="privilege-escalation/linux-active-directory.md" %} linux-active-directory.md {% endcontent-ref %}

Énumération

{% hint style="warning" %} Vous pouvez effectuer l'énumération via ldap et d'autres outils binaires, ou en vous connectant à la page web sur le port 443 du serveur FreeIPA. {% endhint %}

Hôtes, Utilisateurs et Groupes

Il est possible de créer des hôtes, utilisateurs et groupes. Les hôtes et les utilisateurs sont triés dans des conteneurs appelés respectivement “Groupes d'Hôtes” et “Groupes d'Utilisateurs”. Ceux-ci sont similaires aux Unités Organisationnelles (OU).

Par défaut dans FreeIPA, le serveur LDAP permet des liaisons anonymes, et une grande quantité de données est énumérable de manière non authentifiée. Ceci peut énumérer toutes les données disponibles non authentifiées :

ldapsearch -x

Pour obtenir plus d'informations, vous devez utiliser une session authentifiée (consultez la section Authentication pour apprendre à préparer une session authentifiée).

# 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"

À partir d'une machine jointe au domaine, vous pourrez utiliser les binaires installés pour énumérer le domaine :

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" %} L'utilisateur admin de FreeIPA est l'équivalent des domain admins de AD. {% endhint %}

Hashes

L'utilisateur root du serveur IPA a accès aux hashes de mot de passe.

  • Le hash de mot de passe d'un utilisateur est stocké en base64 dans l'attribut "userPassword". Ce hash peut être SSHA512 (anciennes versions de FreeIPA) ou PBKDF2_SHA256.
  • Le Nthash du mot de passe est stocké en base64 dans "ipaNTHash" si le système a une intégration avec AD.

Pour craquer ces hashes :

• Si FreeIPA est intégré avec AD, ipaNTHash est facile à craquer : Vous devez décoder le base64 -> le réencoder en hex ASCII -> John The Ripper ou hashcat peuvent vous aider à le craquer rapidement

• Si une ancienne version de FreeIPA est utilisée, donc SSHA512 est utilisé : Vous devez décoder le base64 -> trouver le hash SSHA512 -> John The Ripper ou hashcat peuvent vous aider à le craquer

• Si une nouvelle version de FreeIPA est utilisée, donc PBKDF2_SHA256 est utilisé : Vous devez décoder le base64 -> trouver PBKDF2_SHA256 -> sa longueur est de 256 octets. John peut travailler avec 256 bits (32 octets) -> SHA-256 utilisé comme fonction pseudo-aléatoire, la taille du bloc est de 32 octets -> vous pouvez utiliser seulement les premiers 256 bits de notre hash PBKDF2_SHA256 -> John The Ripper ou hashcat peuvent vous aider à le craquer

Pour extraire les hashes, vous devez être root sur le serveur FreeIPA, là vous pouvez utiliser l'outil dbscan pour les extraire :

Règles HBAC

Ce sont les règles qui accordent des permissions spécifiques aux utilisateurs ou aux hôtes sur des ressources (hôtes, services, groupes de services...).

# 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

Règles Sudo

FreeIPA offre la possibilité de gérer les permissions sudo à partir d'une source centralisée grâce aux règles sudo. Ces ensembles de règles peuvent être utilisés pour restreindre ou déléguer la capacité d'exécuter des commandes en tant que sudo sur les hôtes inscrits dans le domaine. En tant qu'attaquant, nous pouvons énumérer quels hôtes et utilisateurs ces ensembles de règles sont appliqués, et quelles commandes sont autorisées à travers l'ensemble de règles.

# 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

Contrôle d'Accès Basé sur les Rôles

Chaque rôle contient un ensemble de privilèges, et ces privilèges respectifs contiennent un ensemble de permissions. Les rôles peuvent être appliqués aux Utilisateurs, aux Groupes d'Utilisateurs, aux Hôtes, aux Groupes d'Hôtes et aux Services. Pour illustrer ce concept, discutons du rôle par défaut "Administrateur d'Utilisateur" dans FreeIPA.

Comme le montre la capture d'écran ci-dessus, le rôle "Administrateur d'Utilisateur" contient les privilèges suivants :

  • Administrateurs d'Utilisateurs
  • Administrateurs de Groupes
  • Administrateurs d'Utilisateurs en Attente

Nous pouvons aller plus loin et énumérer les permissions déléguées à chaque privilège :

Comme nous pouvons le voir, le rôle "Administrateur d'Utilisateur" contient beaucoup de permissions au sein de l'environnement. Comprendre le concept général et la structure des rôles, privilèges et permissions peut être crucial pour identifier les chemins d'attaque à travers un environnement.

# 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

Exemple de scénario d'attaque

Dans https://posts.specterops.io/attacking-freeipa-part-iii-finding-a-path-677405b5b95e, vous pouvez trouver un exemple simple de comment abuser de certaines permissions pour compromettre le domaine.

Linikatz/LinikatzV2

Élévation de privilèges

création d'utilisateur root

{% hint style="warning" %} Si vous pouvez créer un nouvel utilisateur avec le nom root, vous pouvez vous faire passer pour lui et vous serez capable de vous connecter en SSH sur n'importe quelle machine en tant que root.

CELA A ÉTÉ CORRIGÉ. {% endhint %}

Le privilège "User Administrators" est très puissant (comme son nom l'indique) :

Avec ce privilège vient beaucoup de différents pouvoirs pour affecter les utilisateurs à l'intérieur de l'environnement. En utilisant ce privilège, nous pouvons créer un nouvel utilisateur dans le domaine FreeIPA nommé _root_.

Une fois l'utilisateur créé dans le domaine, nous pouvons obtenir un ticket pour le compte avec _kinit_.

Maintenant, nous pouvons tenter de nous connecter en SSH en utilisant notre nouveau compte root du domaine.

Comme montré, cela connecte l'utilisateur au compte root local ! Donc, simplement en créant un utilisateur de domaine pour un utilisateur local, nous avons pu nous authentifier en utilisant le compte root@WESTEROS.LOCAL et obtenir le contexte utilisateur du compte root local.

Pour plus de détails sur cette vulnérabilité, consultez https://posts.specterops.io/attacking-freeipa-part-iv-cve-2020-10747-7c373a1bf66b\

Apprenez le hacking AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :