Mark Goodwin's Blog - applet tag

More intranet hacks with applets

Thu, 16 Aug 2007 22:02:00 GMT

We've already looked at one of the two big problems posed by anti DNS pinning on Java applets; because there's rebinding on the applet and not the browser you can open a channel from an Internet host to an internal system (this is also true of Flash, of course).

The other problem is that, over the past decade, people have been developing a massive body of Java code to do just about anything. For example, there's:

JCIFS for CIFS/SMB if you want to talk to windows file servers - can attackers use null sessions to gather information on your systems?
JDBC if you want to talk to a database (just pick your driver) - all of your developers change the passwords on their local MySQL installation, right?
DNSJava if you want to do zone transfers, etc. from a DNS server - no-one bothers preventing zone transfers on internal DNS; should we?
JavaMail if you want to talk to a mail server - do you prevent relay from internal hosts?
libraries to support CVS, Subversion, and
thousands of other things there's not time to mention.

These things are all really useful in the right context, but combine them with the proxy bypass or LiveConnect anti DNS pinning attacks and you can see how easy things have just got for attackers.

Intranet port forwarding

Thu, 09 Aug 2007 23:29:00 GMT

It has been known for a month or so now that proxy bypass is an effective way of breaking DNS pinning on Java applets.

It's been known since forever that Java applets can interact with scripts on the parent page (same origin restrictions apply, IIRC).

It's been known for a few years now that it's really easy to do nice async data transfer to a remote server with fancy AJAXy stuff; there's even Comet to keep latencies down on the upstream.

So here's what you can do:

Write an ajax service on 'attacker' that allows you to forward the data from a connection on a local port to JS on a page on the victim's browser.
Load an applet in victim's browser from 'attacker', change 'attacker' DNS entry as soon as connection to download the applet jar is established. Don't break pinning on the browser.
Have the applet attempt a connection to 'attacker'; this will resolve to 'target'.
On connection, the applet phones home via the browser; pinning's not broken so the ajax call goes to the original server which results in the port being opened.
Voila! Browser based intranet port forwarding. This could work for TCP or UDP; the possibilities are endless...

There's nothing new here but it's interesting to see the combination. Let me know what you think.