Hackthebox - RouterSpace writeup
I have to admit, this one had me stumped with it’s name, I mean, it clearly has something to do with routers? Right? well, I was wrong, along with a lot of other people, serves us right for judging a book by its cover.
Machine Summary
RouterSpace is an easy Linux machine that has us analyse traffic flowing from an Android application in order for us to leverage a command injection vulnerability to gain a foothold. The machine also presents us with a common vulnerability in sudo in order for us to escalate our privileges. This rather easy pathway is shrouded by a complicated setup which is why this box leans more toward the medium side of difficulty in my opinion.
Enumeration
Let’s start with the basics! we go ahead and run an Nmap on the target.
nmap -sV -A -O 10.129.144.113NOTE: It is good practice to run a full port scan along with a UDP scan as well.
nmap -p- 10.129.144.113 #All ports instead of top 1000
nmap -sU 10.129.144.113 #UDP ScanLooking at the results, all that interests me is port 80 for now. In most cases SSH is secure and will be used later for persistence.
We go ahead and add routerspace.htb to our /etc/hosts file.
vi /etc/hostsLet’s take a look at this webpage.
The webpage appears static, as most of the links are anchored besides one interesting button. i.e., the Download button. This allows us to download an APK(Android Package) file.
The first thing that crossed my mind when I saw this, was to use apktool to extract the APK and then proceed to statically analyse it for any juicy strings, however this lead me down hours of digging through code to no avail.
I decided to switch to dynamic analysis which involves me actually running the application, in hindsight it would make more sense to try this first. I was reminded of an article that I read on certificate pinning a while back, in which the writer intercepts traffic from the application.
Introduction to APK Reverse Engineering — bypassing Root Detection and Certificate Pinning (isec.pl)
To see what kind of traffic was being created by this app, I decided to follow this same principle.
Setting up the environment
This by far was the most frustrating portion of the box, however, it all could have been avoided if I just had made a fresh VM to work with from the beginning.
We require a few things here:
1. A fresh VM (preferably Ubuntu).
2. An emulator of some sort to run the application.
3. Burp suite to intercept traffic.
4. Install ADB for command line control of your emulator.
My two cents is that you install a fresh copy of Ubuntu desktop to set up your environment, simply because you can always nuke the box if something goes wrong and of course start over.
Once you have installed Ubuntu on either VMware or VirtualBox, you can proceed to install an emulator.
Installing Anbox
For reasons I don't know, Android studio’s emulator did not want to work, so I decided to use Anbox instead.
Anbox puts the Android operating system into a container, abstracts hardware access and integrates core system services into a GNU/Linux system. Every Android application will be integrated with your operating system like any other native application.
You can follow the documentation on the Anbox website or this article to run the installation.
Install Anbox — Anbox documentation
As per the documentation, the first step is to install the kernel modules, which can be done with the below commands:
sudo add-apt-repository ppa:morphis/anbox-support
sudo apt update
sudo apt install linux-headers-generic anbox-modules-dkmsWe now need to load the kernel modules:
sudo modprobe ashmem_linux
sudo modprobe binder_linuxYou can confirm this by listing the below and seeing the same output:
ls -1 /dev/{ashmem,binder}
/dev/ashmem
/dev/binderNext, we can use snap to install Anbox, you would need to install snap if you haven't already and make sure that the snapd service is running.
apt-get install snap
systemctl start snapd.serviceLastly:
snap install --devmode --beta anboxIf you end up having issues with your emulator later on, you can use systemctl to stop and start the Anbox service.
systemctl stop anbox
systemctl start anboxAt this point, you should be able to search your application launcher for Anbox and start the emulator.
Install Burpsuite
Installing Burpsuite is pretty straightforward, just download the bash script from Burpsuite’s official page and run it.
Professional / Community 2022.1.1 | Releases (portswigger.net)
chmod +x burpsuite_community_linux_v2022_1_1
./burpsuite_community_linux_v2022_1_1Once you have installed Burp, make sure to configure it to listen on all interfaces and not just your loopback address.
You can do this by going to the proxy tab, options and pressing edit on the interface that is present.
Installing ADB(Android debug bridge)
Installing ADB is also trivial and can be accomplished with a simple apt-get.
apt-get install adbPhew, okay that's it for the setup, we can finally stop making and start breaking!
Exploitation
Alright, lets start by actually installing this APK onto our emulator. If you haven't already, now is the time for you to start your emulator, after which you can confirm that its on by running the below command:
adb devicesIf you see an attached emulator, then its working as expected, and we can proceed to installing the APK, which can be done with the following command:
adb install RouterSpace.apkMake sure you specify or are in the directory containing the APK that you downloaded earlier. After you do this, you should see the RouterSpace application icon pop up in your emulator.
Now, lets start up Burpsuite, and make the changes that we spoke about earlier to your listeners if you haven't already, making sure to bind them to all interfaces.
Now we need to configure our emulator to send traffic through our proxy, i.e., Burpsuite so that we can see the requests being made by the application, to do this we run the below command:
adb shell settings put global http_proxy 192.168.36.131:8080Make sure to change the IP and port accordingly, if all went well we should be able to start the application and see the requests come through on Burp, if not you should restart your emulator by using systemctl.
systemctl restart anboxAfter running the application, we notice a single POST request being made.
It seemed to be checking if an access point was alive…
After tampering for some time with this, we discovered that the IP value was vulnerable to command injection by amending an ; to the value and adding a command after.
Nice, we now have some control. I first try the obvious and attempt to get a reverse shell, however, it becomes apparent that the box blocked connections to some degree as I also attempted to download files from a python server of mine but to no avail.
Instead we opt to paste our SSH Public key into Paul’s authorized_keys file. If you would like to generate a new key pair, you can do so by running:
ssh-keygenAfter which you can cat out your id_rsa.pub file and paste it into Burpsuite in the format below.
echo ‘YOUR ID_RSA.PUB KEY’ > /home/paul/.ssh/authorized_keys
Awesome! it didn't stall this time, which means in all likelihood, it worked! Lets cross our fingers and try to SSH into Paul.
Bam! we’ve finally got a foothold. user.txt can be found in Paul’s home directory. That was a handful, pun unintended.
Privilege Escalation
Okay, I have to admit, this was quite easy, but in the same breath, it was annoying to find simply because of the connectivity restrictions on the box, this prevented a lot of people from properly enumerating because we could not get our scripts on like we usually would, however like I said, root was quite straight forward so lets get cracking.
For all of our scripts, instead of using a python server, we have to instead use scp to copy files over to Paul.
Run the following command in the directory from which you would like to copy from.
scp linpeas.sh paul@routerspace.htb:/home/paul/
scp -r folder paul@routerspace.htb:/home/paul/ #For a folderWhile running linpeas, we come across a rather popular vulnerability:
Sudo version 1.8.31 is known for a serious privilege escalation vulnerability, we quickly find an article explaining the vulnerability to us.
This vulnerability is achieved because sudo doesn’t process escaped characters correctly, causing a malloc error and a program kill. Sudo takes arguments and saves them into an array. When we input “space” we use “\”. However, if after “\” is not followed by another character, sudo will misinterpret and assume it is an escape character and continue processing until it becomes an overflow.
The article contains a link to an exploit on GitHub.
We download the repository and send the folder over to Paul:
git clone https://github.com/blasty/CVE-2021-3156.git
scp -r CVE-2021–3156 paul@routerspace.htb:/home/paulAll that's left to do now is to compile and run, on Paul’s machine do:
cd CVE-2021–3156
makeHere goes nothing!
./sudo-hax-me-a-sandwich 0
To my surprise it actually works! root.txt can be found in /root/root.txt
PWNED!!!
Conclusion
This one seriously pushed me out of my comfort zone, but at the same time taught me a whole lot, Big thanks to the box creator h4rithd
If you have made it this far, thanks again for reading!
Remember to always keep learning and never stop hacking.
