Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/linux-hardening/freeipa-pentesting.md
Translator workflow af42105553 Translated to French
2023-06-03 13:10:46 +00:00

22 KiB
Raw Blame History

FreeIPA Pentesting

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

Ces informations ont été prises à partir des publications suivantes :

Informations de base

Il s'agit d'une alternative open source à Microsoft Windows Active Directory, principalement utilisée comme solution de gestion intégrée pour les environnements Unix. Tout comme Active Directory, FreeIPA implémente une infrastructure de répertoire LDAP complète soutenue par un centre de distribution de clés MIT Kerberos. Il utilise le système de certificats Dogtag pour la gestion des certificats CA & RA, ce qui lui permet 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 digitales

Fichiers et variables d'environnement

  • /etc/krb5.conf : Le fichier krb5.conf contient les informations du client Kerberos requises pour être inscrit dans le domaine. Cela inclut les emplacements des KDC et des serveurs d'administration 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 : Il s'agit du 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 des serveurs IPA.
  • /etc/krb5.keytab : Le fichier krb5.keytab est obligatoire sur tous les hôtes à l'intérieur du domaine. Il est requis dans le cadre du processus d'authentification au KDC.
  • KRB5CCNAME : S'il est défini, cette variable pointe vers l'emplacement du fichier CCACHE Ticket à utiliser pour l'authentification.
  • KRB5_KTNAME : S'il est défini, cette variable pointe vers l'emplacement du fichier Keytab à utiliser pour l'authentification.
  • KRB5_CONFIG : S'il est défini, cette variable pointe vers l'emplacement du fichier de configuration Kerberos.
  • KRB5_KDC_PROFILE : S'il est défini, cette variable pointe vers l'emplacement de la 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 de 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 par défaut du client keytab.
  • 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 tous les tickets Kerberos actuels dans la session de l'utilisateur.
  • kinit : Le binaire kinit est utilisé pour établir ou renouveler les tickets Kerberos.
  • klist : Le binaire klist liste tous les tickets Kerberos actuels en cours d'utilisation, et les principaux auxquels 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 alternative au binaire su, pour basculer le contexte utilisateur actuel.
  • kswitch : La commande kswitch basculera le cache de crédential actuel en cours d'utilisation.
  • kvno : Le binaire kvno acquiert un ticket de service pour les principaux Kerberos spécifiés et affiche les numéros de version de clé de chacun.

Réseau

Voici à quoi pourrait ressembler un serveur FreeIPA :

Authentification

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

Fichiers de tickets CCACHE

Lorsque les tickets sont définis 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 sont limités par 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 l'authentification, sans avoir besoin du mot de passe en texte clair des utilisateurs respectifs.
  2. Les tickets CCACHE sont hautement portables. Ils peuvent être télécharg
klist /tmp/krb5cc_0

Pour un attaquant, il est très facile de réutiliser un ticket CCACHE valide. 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

Unix Keyring

Les tickets CCACHE peuvent également être stockés dans le keyring Linux. Le keyring vit à l'intérieur du noyau et donne 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 keyring 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 keyring Unix, son analyse peut être difficile. Cependant, la portée par défaut pour les tickets CCACHE dans le keyring Unix est KEYRING:persistent:uidnumber. Heureusement, si vous êtes dans le contexte de l'utilisateur, klist peut analyser ces informations pour nous.

En tant qu'attaquant, réutiliser un ticket CCACHE stocké dans le keyring Unix est assez difficile selon la manière dont le ticket est délimité. Heureusement, @Zer1t0 de @Tarlogic a créé un outil qui peut extraire les tickets Kerberos du keyring Unix. L'outil s'appelle Tickey et peut être trouvé ici.

Keytab

{% hint style="warning" %} Généralement, chaque hôte est déployé avec une clé d'identification keytab pour cet hôte qui peut être utilisée pour obtenir un ticket de validation de ticket (TGT) de cache de crédential 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, la keytab sera invalidée.

Les fichiers Keytab peuvent être utilisés pour obtenir un ticket de validation de ticket (TGT) 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.

L'analyse d'un fichier Keytab est très facile et peut être accomplie de quelques manières. La manière la plus facile de décoder 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 crédentials 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

Fiche de triche

Vous pouvez trouver plus d'informations sur la façon d'utiliser les tickets dans Linux en suivant 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 se 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, des utilisateurs et des groupes. Les hôtes et les utilisateurs sont triés dans des conteneurs appelés «Groupes d'hôtes» et «Groupes d'utilisateurs» respectivement. Ceux-ci sont similaires aux Unités organisationnelles (OU).

Par défaut dans FreeIPA, le serveur LDAP permet les liens anonymes, et une grande quantité de données est énumérable non authentifiée. Cela 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 Authentification pour apprendre comment 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 à un 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 administrateurs de domaine d'AD. {% endhint %}

Hashes

L'utilisateur root du serveur IPA a accès aux hashes de mots 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 est intégré à AD.

Pour casser ces hashes :

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

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

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

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

Règles HBAC

Ce sont les règles qui accordent des autorisations spécifiques aux utilisateurs ou aux hôtes sur les 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 permet 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é à exécuter des commandes en tant que sudo sur les hôtes inscrits dans le domaine. En tant qu'attaquant, nous pouvons énumérer les hôtes et les utilisateurs auxquels ces ensembles de règles sont appliqués, ainsi que les commandes autorisées par 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'utilisateurs" dans FreeIPA.

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

  • Administrateurs d'utilisateurs
  • Administrateurs de groupes
  • Administrateurs d'utilisateurs de la scène

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'utilisateurs" contient un grand nombre de permissions à l'intérieur de l'environnement. Comprendre le concept général et la structure des rôles, des privilèges et des permissions peut être crucial pour identifier les chemins d'attaque dans tout l'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 la façon d'abuser de certaines autorisations pour compromettre le domaine.

Linikatz

https://github.com/CiscoCXSecurity/linikatz

Privesc

Création d'un 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 pourrez SSH dans n'importe quelle machine en tant que root.

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

Le privilège "Administrateurs d'utilisateurs" est très puissant (comme son nom l'indique) :

Avec ce privilège, on peut avoir beaucoup de pouvoir différent 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 que l'utilisateur est créé dans le domaine, nous pouvons obtenir un ticket pour le compte avec _kinit_.

Maintenant, nous pouvons essayer de SSH en utilisant notre nouveau compte de domaine root.

Comme le montre la figure, cela fait passer l'utilisateur en compte root local ! Ainsi, 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\

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