From NFS to Root: A Sloink HackTheBox Breakdown
When a misconfigured NFS share exposes sensitive system directories, even a restricted user account can become a gateway to deeper compromise. That’s exactly what happened on HackTheBox’s Sloink machine, where a combination of open NFS exports, exposed PostgreSQL backups, and a forgotten shell restriction allowed a tester to escalate from unauthenticated access to full root control.
The First Foot in the Door: NFS Misconfiguration
Initial reconnaissance revealed two NFS shares accessible to all users: /home and /var/backups. Both were exported with overly permissive settings, enabling attackers to mount and read sensitive files. Among the exposed data were PostgreSQL backup archives generated every minute and user shell histories. One file stood out: /home/service/.psql_history, which recorded a command connecting to the PostgreSQL superuser via a Unix socket.
Credentials and Tunnels: Breaking Through Barriers
The service user’s shell was restricted to /bin/false, blocking direct SSH access. However, the exposed .bash_history confirmed regular PostgreSQL connections. Using the NFS root escape vulnerability—a feature of some NFS servers that allows users to traverse outside their designated share—attackers extracted /etc/passwd and /etc/shadow. The hashes were yescrypt, slowing down brute-force attempts, so focus shifted back to the NFS data.
A clever workaround involved creating a local user with the same UID as the service account (1337), granting access to the restricted home directory. This revealed the PostgreSQL Unix socket path (/var/run/postgresql/.s.PGSQL.5432) and confirmed the user’s habit of connecting to the database as the superuser.
Database Abuse and Privilege Escalation
With the PostgreSQL superuser credentials unavailable, attackers pivoted to network-based access. They tunneled through the SSH account to reach the PostgreSQL Unix socket directly. Once connected, they exploited the COPY FROM PROGRAM feature—typically used for data import—to execute arbitrary commands as the postgres user, achieving remote code execution.
The final stage leveraged a cron job running as root that periodically copied the entire PostgreSQL data directory, owned by the postgres user. By placing a SUID-enabled bash binary within that directory, the attacker waited for the cron job to execute, instantly upgrading their access to root.
Sloink demonstrates how layered misconfigurations—especially in shared filesystems and database services—can create unexpected attack paths. Proper access controls on NFS exports and secure handling of PostgreSQL superuser connections could have prevented this chain of compromise.
Source: DEV Community. AI-assisted editorial synthesis — TechnoExpress.