From Default Credentials to Operating System Access: Exploiting PostgreSQL in Metasploitable 2

When people think about penetration testing, they often imagine sophisticated exploits and advanced malware. In reality, many compromises begin with something much simpler: weak credentials and excessive privileges.

While practicing in my home lab using Metasploitable 2, I came across an exposed PostgreSQL database service. What started as a routine service enumeration exercise eventually led to operating system access and privilege escalation opportunities.

This article walks through the methodology, findings, and lessons learned from that assessment.

Disclaimer: All activities described in this article were performed in a controlled lab environment using Metasploitable 2, an intentionally vulnerable machine designed for cybersecurity training.

Understanding PostgreSQL

PostgreSQL is one of the most widely used open-source relational database management systems.

Organizations use it to store:

• Customer records
• User accounts
• Financial information
• Application data
• Logs and analytics

Because databases often contain critical business information, they are high-value targets during penetration tests.

Step 1: Service Discovery

The assessment began with a targeted Nmap scan.

nmap -sV -p 5432 192.168.56.102

The scan identified PostgreSQL running on the default port:

5432/tcp open postgresql PostgreSQL DB 8.3.0 - 8.3.7

At this stage, I had confirmed the presence of the service but knew nothing about authentication or permissions.

Step 2: Authentication Testing

The next question was straightforward:

Can I log in?

Instead of jumping directly into exploitation, I used a PostgreSQL authentication testing module using metasploit to evaluate common credentials.

The result was immediate:

postgres : postgres

A default administrative account was exposed.

This transformed the assessment from simple service discovery into authenticated database access.

Step 3: Verifying the Database Environment

After gaining access, I verified the exact PostgreSQL version.

SELECT version();

The server reported:

PostgreSQL 8.3.1

Version verification is important because many vulnerabilities and exploitation techniques depend on exact software versions.

Step 4: Enumerating Databases

The next objective was understanding what data existed on the server.

Using a simple query, I enumerated available databases.

SELECT datname FROM pg_database;

Screenshot 4

Insert database enumeration screenshot here

The results showed:

template0
template1
postgres

No custom application databases were present.

Although there was no sensitive business data to examine, the exercise remained valuable because it demonstrated authenticated database enumeration.

Step 5: Enumerating Users and Privileges

I then investigated which users existed within PostgreSQL.

SELECT usename FROM pg_user;

Only one account was present:

postgres

The next logical question was:

How powerful is this account?

so answer that, I queried PostgreSQL privilege information.

SELECT usename, usesuper FROM pg_user;

The result:

postgres | true

The account possessed PostgreSQL Superuser privileges.

In database terms, this is essentially administrator-level access.

Step 6: Reading Operating System Files

Database superuser privileges can sometimes extend beyond database management.

I tested whether PostgreSQL could access files on the underlying operating system.

The target file was:

/etc/passwd

The file was successfully retrieved.

This was a significant finding because it demonstrated that database access could be leveraged to access operating system resources.

At this stage, the attack chain looked like this:

Default Credentials
↓
Database Superuser
↓
Arbitrary File Read

Step 7: Achieving Operating System Access

The next objective was determining whether PostgreSQL could be leveraged for command execution.

A known PostgreSQL technique involving User Defined Functions (UDFs) was used.

Conceptually, the process involved:

Database Login
↓
Malicious Shared Library Upload
↓
UDF Creation
↓
Library Loading
↓
Payload Execution

The exploitation was successful.

An operating system shell was obtained.

Step 8: Verifying the Execution Context

After obtaining shell access, I verified the execution context.

whoami

Output:

postgres

Additional verification confirmed:

uid=108(postgres)
gid=117(postgres)

This is an important lesson:

Compromising a service does not automatically grant root access.

Instead, the attacker inherits the privileges of the compromised service account.

Step 9: Privilege Escalation Enumeration

With operating system access established, the next phase involved local privilege escalation assessment.

I first checked sudo permissions.

sudo -l

No sudo privileges were available.

I then enumerated SUID binaries across the system.

One entry immediately stood out:

/usr/bin/nmap

Version verification revealed:

Nmap 4.53

Historically, certain older Nmap versions included interactive functionality that could be abused for privilege escalation.

At this point, a viable local privilege escalation path had been identified.

Key Lessons Learned

This assessment reinforced several important penetration testing concepts.

1. Enumeration Drives Everything

Every major finding resulted from systematic enumeration rather than blind exploitation.

2. Default Credentials Are Dangerous

The entire attack chain originated from:

postgres : postgres

3. Database Access Can Lead to System Access

Databases are not isolated islands.

Administrative database privileges often interact closely with the operating system.

4. Initial Access Is Not the End Goal

Obtaining a shell is only one phase of the attack lifecycle.

Privilege escalation and post-exploitation remain equally important.

Attack Chain Summary

PostgreSQL Discovery
↓
Default Credentials
↓
Database Superuser
↓
File Read Capability
↓
Operating System Access
↓
Privilege Escalation Enumeration

Final Thoughts

This exercise demonstrated how multiple small weaknesses can combine into a serious security issue.

There was no single “magic exploit.”

Instead, the compromise resulted from:

• Weak authentication
• Excessive privileges
• File access capabilities
• Vulnerable host configuration

The most valuable lesson was not learning a specific exploit.

It was learning the mindset:

Discover
↓
Enumerate
↓
Verify
↓
Exploit
↓
Escalate

That workflow is what turns tools into real penetration testing skills.

*If you’re learning cybersecurity through labs like Metasploitable 2, I’d love to connect and discuss different approaches to enumeration, exploitation, and privilege escalation.*/usr/bin/nmap — interactive