Step by Step on: Hack The Box – OpenAdmin

By Franklin Nunez

As the title says, here we are going to walkthrough step by step on how to compromise the OpenAdmin vulnerable box being offered in Hackthebox. At the moment of this article, the box is active and has not yet been retired.

OpenAdmin is considered to be a slightly easy box according to its score in Hackthebox. However, like everything else in security, this will depend on your familiarity on common security tools, network, and web. Without further ado, let’s dive in.

WARNING: Everything beyond this point is spoiler. Discretion is advised.

1. Initial Recon

First, I started to do the basic reconnaissance that we are all supposed to do by running some nmap scan against the host static IP(10.10.10.171) with the command nmap -sV -A 10.10.10.171.

Note: alternately, just the -A could have been pass since -A includes version scan(-sV)

Here, I saw that there were some services being served, being the interesting ones HTTP in port 80, and ssh in port 22. Now that we know HTTP is being served, I went and took a look at the page to have an idea.

It is just a default apache page. Here, without trying to manually brute force for the possible directories, I went ahead and used a dirb tool instead which automates that for me. Since it’s almost certain that there is more than just a default page in this web server, dirb will allow us to see that else exist in it.

Several minutes after (about 15min), as you see in the image above, dirb has found 2 directories. I went ahead check them one by one. First, I went to the artwork directory.

Looking around for a moment, I could tell there was not much promising here since it was just a page with a lot of static content. Since the goal is to get a foothold on the host, I’m looking for something that can give me some kind of access, such as a login portal, or a vulnerable application.

Next, I went to the music directory since it was the only other option, despite having a name that could be easily underestimated.

However, this time it looked a little more promising since it had some login functionality. I clicked on it and I got a good surprised.

Bam! it took me to a directory named “ona” serving some web application at the moment I didn’t know anything about. I seemed that I was logged in with a default user account. Next, clicked on the “guest” button and tried another combination of username/password, to see if I could log in as an admin. So, I tried admin/admin since it is my goto when trying dummy passwords

And it worked! Here, I played around with the application, trying to make something happen that could give me some access to the underlying host, but the application seemed to be very limited. There was no luck.

After playing with the application for a while, I decided to look what “ona” meant or stands for since I had no idea. On the way, I wanted to see if this application was vulnerable and if there was some exploit out there that could help me.

I discovered ona stands for OpenNetAdmin server and It took one google search and one click to find an exploit in exploit-db.com.

• Initial foothold

After I discovered the exploit, it was time to copy it and use it. The script seemed to take an URL to the application, so once I copied the script into a file I called “exploit”, I made it executable by running chmod +x exploit, and executed it in the following way.

And It worked! I got an initially foothold on the host machine under the www-data user context.

Because this is a web shell, this is not an interactive shell, and www-data is restricted inside the application root directory, which it was /opt/ona/www. We can check what directories we are in the file system by running pwd Linux command.

It was time for me to search for anything useful like configurations or plaintext passwords, or both. So, I started to look around.

After searching for interesting files, I came across local/config/database_settings.inc.php. I use cat to see what was in the file.

It looks like the password for the backend database. This way, I got my first password. However, it was useless unless I find a user to use it against. I check /etc/passwd to see if I could find any users.

And Here I found two of them, jimmy, and Joanna.

• Lateral Movement

With these two users, I was ready to try to ssh into them, since it was open as we saw before in the nmap scan results. I tried to ssh into both using the mysql password I found earlier.

As you can see, ssh into Joanna with the password didn’t work, but I got access to jimmy instead. However, the “user” flag was not in Jimmie’s account. Also, I realized that Jimmy didn’t have any high privileges, nor it was in the sudoers file.

I knew needed to find a way to escalate my privileges or find a way to access joanna’s account. The user flag was most likely in her account. I checked for some GTFO binaries, But I couldn’t see anything that could help me.

After checking for GTFOs, I kept looking around until I could find something that can increase my privileges.

While looking around, I found this internal directory in /var/www that dirb never discovered. So, I decided to take a look at the files, more specifically main.php.

Bingo! I realized that part of the code was storing the result of the cat command to Joanna’s private ssh key into the output variable, and then that variable was being echoed to the user. If I could reach to that main.php file I could access the private key and use it to try to ssh into Joanna’s account. However, I decided to change the code a little bit to make it easier for me to log in.

I made a pair of keys with ssh-keygen and echoed my public key into /home/Joanna/.ssh/authorized_keys. This way, I skipped the possibility of having to deal with cracking Joanna’s private key passphrase.

Now, I had to find a way to access main.php.

I tried to forcefully browser to it, but the server did not allow me to leave the Document Root. So I decided to check the Apache config files and see if I could modify that.

For my surprise, I found out that the internal directory seemed to have it’s own config file.

I found what I needed. The config file revealed that the /var/www/internal was being served on 127.0.0.1 over the port 52846 and that the assigned user was Joanna. Note, that because is listening on localhost, it can just be served to a user making a request from the host machine.

Once I successfully curl to localhost, main.php got executed, and authorized_keys got printed back to me. Then, I was able to ssh into Joanna.

And obtain the “user” flag 😉

• Last Notes

Unfortunately, at the moment of this article, I haven’t been able to obtain root access yet. It is assumed that GTFO Binaries are the way to get root access. However, recent test has not lead any success.