Information Escapology, part five – Careful with That Proxy, Eugene

Back here, I claimed that when presented with a login box web users would blindly enter whichever set of credentials came to mind whether they were relevant or not. It turns out that I had failed to dig deeply enough into the evidence, and was displaying a little bit of defensive avoidance – had I dug deeper and looked at the timings of the authentication exchange and the authentication scheme in use, I’d have seen that nothing of the sort was going on. I’ll put on the dunce’s cap and spend the rest of the lesson facing the wall in the corner of the classroom.

However, the truth is perhaps more interesting. It’s not the user leaking information, their proxy server does it for them without their knowledge.

Part four of this series was written after we noticed failed type 3 logons appearing in the Security event log of an IIS webserver. These log entries were a byproduct of the webserver serving up “401 Unauthorized” messages to visitors, which ties up nicely with what’s written here:

Windows logs logon type 3 in most cases when you access a computer from elsewhere on the network. One of the most common sources of logon events with logon type 3 is connections to shared folders or printers. But other over-the-network logons are classed as logon type 3 as well as most logons to IIS.

The webserver shouldn’t really have been serving up the 401s at all – there was a slight glitch in the site related to a script responsible for producing the CSS for the page being viewed. Its URL looks a bit like this:

http://www.example.com/scripts/mycss.aspx?param1=value1&param2=value2

Under certain circumstances, some clients (later determined to be proxies) would try to access the page like this:

http://www.example.com/scripts/?param1=value1&param2=value2

“mycss.aspx” is missing, so this URL is effectively a request for a directory listing (albeit embellished with parameters) and would normally result in a “403 Forbidden” message. So why the 401s? The scripts virtual directory has the default settings under Directory Security:

…but the “read” permission has been removed; it only allows “Scripts and Executables”:

So when the proxy asks for the URL with mycss.aspx missing, it’s really asking for a directory listing of a directory with no read permissions. This check apparently takes precedence over the check for the “directory browsing” permission, and it causes IIS to want the user to authenticate despite the fact that anonymous access is allowed. Only Integrated Windows authentication (IWA) is configured (since this is specified by default) so this is what IIS will ask the client to do.

What we have here is a situation where Integrated Windows authentication will be invoked, albeit unintentionally. However, this oughtn’t cause any problems for two reasons:

1. Integrated Windows authentication does not work through proxies
2. Integrated Windows authentication will, by default, only be attempted for sites that are in IE’s “Local Intranet” zone

However, certain proxies do Clever Tricks to make IWA work. BlueCoat, for example, uses a redirect to a “Virtual URL” in the Local Intranet zone to trick IE into performing an IWA exchange (see here under “For TRANSPARENT proxies”, and here). A BlueCoat configured like this (when visiting the site described above) will show the user a login box, but not before it has completed an IWA exchange and left the user’s username, machine name, and domain name in the Security event log on the webserver. There is nothing the user can do to prevent this information being leaked.

Surely nobody configures their proxy like this though? The whole reasoning for IWA only working for sites in the Intranet Zone is to prevent exactly this kind of leak from happening. Well, we’ve seen proxies behaving like this from all sorts of places:

• A city council
• A school
• A multinational corporation
• A telecoms giant favoured by Jedi Masters (Yodaphone, or something…)

Not all the proxies concerned are BlueCoats, and not all BlueCoats exhibit the same issue (so it looks like it’s down to the configuration of each individual proxy). If you want to see if your own proxy is leaking, I’ve set up a testbed <nolongeravailable>. If you’re happy to potentially leak your Windows login name, your machine name and your domain name, click the link, dismiss the login box without entering anything, and drop me a line with your proxy’s public IP address. I’ll let you know if you’re leaking.

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)dataline.co.uk