More intranet hacks with applets
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.
Frii Wii
Later on this month (29th-31st) the first European NFJS eXchange will be held in London. The NFJS speaker list is usually impressive and the London conference is no different; there's a dazzling array of industry experts featured. And me.
Should be fun.
But the real news is that if you book with the promotional code NFJS-WAS669 you can bag yourself a free Wii.
How about that, eh?
Intranet port forwarding
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.