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.

Add a comment

Posted by Mark Goodwin on 16 August 2007 23:02:00 BST #

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?

Add a comment

Posted by Mark Goodwin on 14 August 2007 20:41:00 BST #

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.

Add a comment

Posted by Mark Goodwin on 10 August 2007 00:29:00 BST #

I've been playing around with DNS pinning over the past few weeks; mainly on how the presence of proxies affects the story, which Rsnake and Portswigger beat me to (nice work guys), but also on various other bits.

Something that's caught my attention, especially following David Ross' comments on how IE does not actively implement DNS Pinning, is that the Firefox's DNS Pinning behaviour (if it does it at all) is rather interesting:

It seems that all you have to do to make Firefox rebind is wait a minute or two. The normal explanation of how the attack needs to work is as follows:

1. Client is fooled to request a page from attacker, client's resolver looks up attacker and is told that attacker is at yyy.yyy.yyy.yyy.
2. Client requests a page from attacker (at yyy.yyy.yyy.yyy) and is returned a page containing a script which tells client to come back later
3. Once this is served, attacker changes its DNS so the RR for attacker now points to zzz.zzz.zzz.zzz. Attacker also firewalls off its webserver.
4. When client comes back to refresh the page (or whatever the script told it to do) it discovers the server is down and rebinds DNS
5. Client then connects to what it thinks is attacker but which is actually the machine at zzz.zzz.zzz.zzz
6. The script served to client by attacker can now read content from zzz.zzz.zzz.zzz and pass it on however the attacker wishes

It seems that with the Firefox behaviour, attacker no longer needs to carry out the firewalling step; it simply needs to serve a script which is told to wait for something between 80 seconds and 2 minutes. The amount of time seems to change; I suspect the browser has a resolver cache which is cleared periodically but I've not really looked to find out whether this is the case.

This has some interesting implications:

• If you don't need to firewall off the webserver, it's much easier to make use of more than a single host; many targets of this type of attack will sit NATed behind a firewall, and even selective firewalling would block other potentially useful client machines
• The original 'Princeton' attack on applets (and presumably various browser plugins) can perhaps still be made to work without relying on a proxy just by timing things right.

I'm sure the rabbit hole goes much deeper than this. Let's see what happens.

Update: In my tests I'm sending responses to the original request to attacker with Connection: close; maybe this is affecting the behaviour?

Update 2: Having tested my theory on applet attacks; I think this is not possible.

Responses[2]

Posted by Mark Goodwin on 19 July 2007 19:27:00 BST #

Everybody is saying that JavaScript is the new malware. There's an interesting application of this idea that probably hasn't occurred to many people; we've all heard about standard CSRF and using this type of technique to perform sophisticated operations on an attacker's behalf but what about the simple stuff?

I've been working on a tool which allows you to stress test an application using scripted browser clients (like a stress test version of Selenium). One of the advantages of this approach over something like, say, the Grinder is that it allows you to get a view of what real traffic from real browsers might look like. You simply set up some virtual machine images with various different browsers, point your virtual machine images at the test tool (via the target site if you want detailed client reporting or the ability to script around CSRF protection), clone your image as many times as is necessary and run them. The test clients poll a management application to find out what they should be doing and how often and report back when they're done.

The scary thing about the possibility of using this against real users is that the user of the browser needn't necessarily know that their machine has just been conscripted as part of a vast stress-testing army. You could be browsing away minding your own business whilst in the background your browser is making forged requests to DOS a website on an attacker's behalf. Because it's JavaScript based your AV won't alert you and you can patch all you like but this is possible because of a feature of browser design not a vulnerability. Your machine will forget all about it when your browser session ends, but that's no problem to the attacker if they can attract enough browsers. Jikto was aimed at breaking in - this is similar, but rather more brutal.

So what's necessary from the attacker's perspective? The attacker needs to do the following:

• Find some expensive functionality on the target site (preferably available to non authenticated users).
• Find somewhere to host the scripts and the management application (a simple PHP script and a few lines of JavaScript would suffice for most purposes); sites vulnerable to various PHP remote file include issues are easy to come by for free hosting
• Once these are in place the attacker gets people infected either by driving traffic to their scripts from a popular site, or inviting people directly (spoof e-mail from a bulk mailer perhaps)

I've had a look around and this appears to be easier than I'd initially dared imagine; people are starting to understand the need to protect functionality that makes changes to their systems or data, but I'm not sure people are wise to the possibility of DDOS via CSRF. Given that this is all entirely plausible; do we need to start protecting expensive, publicly accessible functionality in our web applications with some kind of CSRF protection?

Just a thought.

Add a comment

Posted by Mark Goodwin on 17 May 2007 20:49:00 BST #

On the face of it Integrated Windows Authentication for your intranet applications (formerly known as NTLM) seems like a good deal; you can protect your users' credentials without needing to set up SSL (so your credentials are safer than with basic authentication) and if you're running IIS you can turn it on with the click of a mouse. There's the additional benefit of convenience; your users don't need to bother with interactive login as Windows makes use of user information from the current Windows session. It's like having single sign-on for all of your intranet applications.

Unfortunately there's a catch. The convenience that comes from the fact that users are not usually prompted to log in can extend to attackers as well as legitimate users.

How does this work? We're going to take a look at two different types of attack; cross site request forgery (often abbreviated to CSRF or, less commonly, XSRF) and anti dns pinning:

CSRF:
This is a type of attack where an attacker crafts web content that instructs a user's browser to forge requests to another web site on the user's behalf. Depending on how the site is crafted, the attacker may be able to perform any operation that the user would normally be able to perform, although the attacker can't read the results of the operations that have been performed. The user will often be completely unaware that the attack is taking place. You can read more about this type of attack here.

Anti DNS pinning:
This is a type of attack where an attacker fools a user's browser into making connections firstly to a server under the attackers control, then servers on your local network believing they are all one and the same host; this is achieved by some trickery with DNS and some selective firewalling. This attack is somewhat harder to understand than CSRF (you can read more about this technique here) but the key feature of this attack is that the attacker can read information from webservers on your internal network that they would not normally be able to see.

So how does Integrated Windows Authentication relate to these types of attack? Let's say you're an attacker and you want to make use of one of these techniques to hack a company intranet. To be able to make use of CSRF you need your user on the target network to already be authenticated to the application you're attacking; if the user is not authenticated then the forged requests will not carry the cookie or auth. header necessary for certain operations. If you've got Integrated Windows Authentication enabled on your server then all bets are off; the user's browser and the server will (in most cases) negotiate authentication with no interaction whatsoever from the user so, even if the user hasn't used the application at all in the current browser session, the attacker can directly hit the functionality they require.

And what about Anti-DNS pinning? The situation is even worse here; because the browser believes the target servers are actually in the same security domain as the attacker's server, any cookies the user may have set for the target server under it's normal name are unavailable to the attacker. This means that under normal circumstances Anti-DNS pinning attacks can't be used for any operations that require authentication. Again, with servers that have Integrated Windows Authentication enabled things get much easier for the attacker. The user's browser will negotiate authentication with the server without the user's knowledge and the attacker can read any data or make any request that the user would normally have permissions for.

Many problems in security are about finding a good balance between making life hard for attackers and making life easy for everyday users; we've just looked at how Integrated Windows Authentication makes life rather easier for attackers than you might at first think.

Add a comment

Posted by Mark Goodwin on 16 April 2007 20:54:00 BST #