Integrated Windows Authentication
Convenience at a price
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.