Fixing PostgreSQL on the Pwn Plug R3

May 28, 2017

I’m not a big fan of throwing shade, but I’m also not a big fan of companies that ship broken product. After coming to the conclusion that I didn’t have the time to build my own, I bought a Pwn Plug R3 for work. Three days later, one of the guys at my local security meetup spent 40 minutes presenting on the homebrew solution he whipped up after being burned hard by Pwnie Express.

I feel his pain.

That said, what if you, like me, have already purchased the ticket and are now on the figurative ride? How do you get this thing functional? Oh, you thought it would arrive fully functional? You silly idiot.

Fixing PostgreSQL

I’m not sure how you ship a penetration testing device with a broken Metasploit install, but it’s probably best that we skip denial and move straight to acceptance.

Not ready yet? OK. Here’s what the official documentation has to say about getting Metasploit up and running:

Accessing Metasploit The Metasploit binaries (msfconsole, msfcli, etc.) can be run from any directory. Simply type ‘msfconsole’ to launch the local Metasploit Console. Note: For information on how to use Metasploit, go to


The Manual Hates This One Weird Trick!

After installing a few extra tools and taking a quick look to verify that Metasploit was installed, I shipped the device onsite for its first engagement. After attempting to use the search functionality I got the same error I get every time I fire up a new Metasploit instance: Database not connected or cache not built, using slow search.

This is because I cannot for the life of me remember to start the postgresql service.

I drop out of Metasploit, hammer in service start postgresql and jump back in.

[email protected]:~$ msfconsole
[-] Failed to connect to the database: could not connect to server: Connection refused
    Is the server running on host "localhost" (::1) and accepting
    TCP/IP connections on port 5432?
could not connect to server: Connection refused
    Is the server running on host "localhost" ( and accepting
    TCP/IP connections on port 5432?

Weird. I run a netstat -antp | grep 5432. Nothing. Weirder is that the service shows enabled but exited. Next I check the dependencies:

[email protected]:~$ sudo systemctl list-dependencies postgresql
● ├─[email protected]
● ├─[email protected]
● ├─system.slice
● ├─
● │ └─networking.service
● └─
●   ├─dev-hugepages.mount
●     └─linux_swapfile.swap

Both the [email protected] services show red, which may explain why my postgresql service is having trouble starting.

[email protected]:~$ sudo systemctl status [email protected][email protected] - PostgreSQL Cluster 9.6-main
   Loaded: loaded (/lib/systemd/system/[email protected]; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Tue 2017-05-23 15:49:05 MDT; 1min 41s ago
  Process: 14965 ExecStart=[email protected]%i --skip-systemctl-redirect %i start (code=exited, status=1/FAILURE)

May 23 15:49:04 gppr3 systemd[1]: Starting PostgreSQL Cluster 9.6-main...
May 23 15:49:05 gppr3 [email protected][14965]: The PostgreSQL server failed to start. Please check the log output:
May 23 15:49:05 gppr3 [email protected][14965]: 2017-05-23 21:49:05 UTC [14970-1] FATAL:  could not access private key file "/etc/ssl/private/ssl-cert-snakeoil.key": N
May 23 15:49:05 gppr3 [email protected][14965]: 2017-05-23 21:49:05 UTC [14970-2] LOG:  database system is shut down
May 23 15:49:05 gppr3 systemd[1]: [email protected]: Control process exited, code=exited status=1
May 23 15:49:05 gppr3 systemd[1]: Failed to start PostgreSQL Cluster 9.6-main.
May 23 15:49:05 gppr3 systemd[1]: [email protected]: Unit entered failed state.
May 23 15:49:05 gppr3 systemd[1]: [email protected]: Failed with result 'exit-code'.

I’m not sure what the rest of line 9 says, but I’m pretty sure it says something “Not found. Are you sure this silly box shipped with everything it needs to just work?” because /etc/ssl/privlate/ssl-cert-snakeoil.key is definitely missing.

A quick bit of Googling leads me to the solution:

sudo make-ssl-cert generate-default-snakeoil --force-overwrite

With key material present, [email protected] can start, providing just the sort of support that postgresql needs to, you know, function. A quick msfdb reinit gets Metasploit operational and I can get back to hacking.