hacktricks/linux-hardening/linux-post-exploitation/pam-pluggable-authentication-modules.md

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

• Travaillez-vous dans une entreprise de cybersécurité ? Voulez-vous voir votre entreprise annoncée dans HackTricks ? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les PLANS D'ABONNEMENT !

• Découvrez The PEASS Family, notre collection exclusive de NFTs

• Obtenez le swag officiel PEASS & HackTricks

• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez moi sur Twitter 🐦@carlospolopm.

• Partagez vos astuces de piratage en soumettant des PR au repo hacktricks et au repo hacktricks-cloud.

PAM est une collection de modules qui forment essentiellement une barrière entre un service sur votre système et l'utilisateur du service. Les modules peuvent avoir des objectifs très différents, allant de l'interdiction de connexion aux utilisateurs d'un groupe UNIX particulier ou d'un groupe de réseau, ou d'un sous-réseau..., à la mise en place de limites de ressources afin que votre groupe de "recherche" ne puisse pas monopoliser les ressources système.

Fichiers de configuration

Solaris et d'autres systèmes UNIX commerciaux ont un modèle de configuration légèrement différent, centré autour d'un seul fichier, /etc/pam.conf. Sur la plupart des systèmes Linux, ces fichiers de configuration se trouvent dans /etc/pam.d, et sont nommés d'après le service - par exemple, le fichier de configuration "login" s'appelle /etc/pam.d/login. Jetons un coup d'œil rapide à une version de ce fichier :

auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_nologin.so
auth sufficient /lib/security/pam_ldap.so
auth required /lib/security/pam_unix_auth.so try_first_pass
account sufficient /lib/security/pam_ldap.so
account required /lib/security/pam_unix_acct.so
password required /lib/security/pam_cracklib.so
password required /lib/security/pam_ldap.so
password required /lib/security/pam_pwdb.so use_first_pass
session required /lib/security/pam_unix_session.so

Royaumes de gestion PAM

La colonne de gauche peut contenir quatre mots uniques, qui représentent quatre royaumes de gestion PAM: auth, account, password et session. Bien qu'il existe de nombreux modules qui prennent en charge plus d'un de ces royaumes en effet, pam\_unix prend en charge tous les royaumes, d'autres, comme pam_cracklib par exemple, ne conviennent qu'à un seul la fonctionnalité «password» dans le cas de pam\_cracklib.

• auth: Le royaume «auth» que j'appelle un royaume - les docs le désignent comme un «groupe de gestion» ou une «facilité» est responsable de la vérification que l'utilisateur est bien celui qu'il prétend être. Les modules qui peuvent être répertoriés dans cette zone prennent généralement en charge la demande d'un mot de passe.
• account: Cette zone est responsable d'une large gamme de fonctionnalités de vérification de compte possibles. Il existe de nombreux modules disponibles pour cette facilité. Les contraintes à l'utilisation d'un service basées sur la vérification de l'appartenance à un groupe, l'heure de la journée, que le compte utilisateur est local ou distant, etc., sont généralement appliquées par des modules qui prennent en charge cette facilité.
• password: Les modules de cette zone sont responsables de toute fonctionnalité nécessaire dans le cadre de la mise à jour des mots de passe pour un service donné. La plupart du temps, cette section est assez «banale», appelant simplement un module qui demandera un mot de passe actuel, et, en supposant que cela réussisse, vous demandera un nouveau mot de passe. D'autres modules pourraient être ajoutés pour effectuer une complexité de mot de passe ou une vérification de dictionnaire également, comme celle effectuée par les modules pam_cracklib et pam_pwcheck.
• session: Les modules de cette zone effectuent un certain nombre de choses qui se produisent soit pendant la configuration ou le nettoyage d'un service pour un utilisateur donné. Cela peut inclure un certain nombre de choses; lancement d'un script d'initialisation à l'échelle du système, réalisation d'une journalisation spéciale, montage du répertoire personnel de l'utilisateur ou définition de limites de ressources.

Contrôles de module PAM

La colonne du milieu contient un mot-clé qui détermine essentiellement ce que PAM doit faire si le module réussit ou échoue. Ces mots-clés sont appelés «contrôles» en langage PAM. Dans 90% des cas, vous pouvez utiliser l'un des mots-clés courants «requis», «obligatoire», «suffisant» ou «facultatif». Cependant, ce n'est que la pointe de l'iceberg en termes de libération de la flexibilité et de la puissance de PAM.

• required: Si un module «requis» renvoie un statut qui n'est pas «succès», l'opération échouera toujours, mais seulement après que les modules ci-dessous ont été invoqués. Cela semble absurde à première vue, je suppose, mais cela sert à toujours agir de la même manière du point de vue de l'utilisateur essayant d'utiliser le service. L'effet net est qu'il devient impossible pour un pirate potentiel de déterminer quel module a causé l'échec.
• requisite: Si un module «requis» échoue, l'opération échoue non seulement, mais l'opération est immédiatement interrompue avec une erreur sans invoquer d'autres modules.
• sufficient: Si un module «suffisant» réussit, il suffit de satisfaire les exigences des modules suffisants dans ce royaume pour l'utilisation du service, et les modules ci-dessous qui sont également répertoriés comme «suffisants» ne sont pas invoqués. S'il échoue, l'opération échoue à moins qu'un module invoqué après lui ne réussisse.
• optional: Un module «facultatif», selon la page de manuel pam(8), ne fera échouer une opération que s'il est le seul module dans la pile pour cette facilité.

Exemple

Dans notre fichier d'exemple, nous avons quatre modules empilés pour le royaume auth:

auth       required     /lib/security/pam_securetty.so
auth       required     /lib/security/pam_env.so
auth       sufficient   /lib/security/pam_ldap.so
auth       required     /lib/security/pam_unix.so try_first_pass

Comme les modules sont invoqués dans l'ordre, voici ce qui se passera :

1. Le module 'pam_securetty' vérifiera son fichier de configuration, /etc/securetty, et vérifiera si le terminal utilisé pour cette connexion est répertorié dans le fichier. Si ce n'est pas le cas, les connexions root ne seront pas autorisées. Si vous essayez de vous connecter en tant que root sur un terminal "mauvais", ce module échouera. Étant donné qu'il est "requis", il invoquera toujours tous les modules de la pile. Cependant, même si chacun d'entre eux réussit, la connexion échouera. Il est intéressant de noter que si le module était répertorié comme "requis", l'opération se terminerait immédiatement par un échec, sans invoquer aucun des autres modules, quel que soit leur statut.
2. Le module 'pam_env' définira des variables d'environnement en fonction de ce que l'administrateur a configuré dans /etc/security/pam_env.conf. Sur une configuration par défaut de Redhat 9, Fedora Core 1 et Mandrake 9.2, le fichier de configuration pour ce module ne définit en fait aucune variable. Une bonne utilisation de cela pourrait être de définir automatiquement une variable d'environnement DISPLAY pour un utilisateur se connectant via SSH afin qu'il n'ait pas à le définir lui-même s'il veut envoyer un 'xterm' vers son bureau à distance (bien que cela puisse être pris en charge automatiquement par OpenSSH).
3. Le module 'pam_ldap' demandera à l'utilisateur un mot de passe, puis vérifiera le répertoire ldap indiqué dans /etc/ldap.conf pour authentifier l'utilisateur. Si cela échoue, l'opération peut toujours réussir si 'pam_unix' réussit à authentifier l'utilisateur. Si pam_ldap réussit, 'pam_unix' ne sera pas invoqué.
4. Le module 'pam_unix', dans ce cas, ne demandera pas à l'utilisateur de saisir un mot de passe. L'argument 'try_first_pass' indiquera au module d'utiliser le mot de passe qui lui a été donné par le module précédent (dans ce cas, pam_ldap). Il essaiera d'authentifier l'utilisateur en utilisant les appels système standard getpw*. Si pam_unix échoue et que pam_ldap a échoué, l'opération échouera. Si pam_ldap échoue mais que pam_unix réussit, l'opération réussira (ce qui est extrêmement utile dans les cas où root n'est pas dans le répertoire ldap, mais est toujours dans le fichier local /etc/passwd !).