Archive for December, 2009

‘Twas the night before D-DoS

Posted in Silly on 16 December, 2009 by Alec Waters

The festive season is upon us again, so I hereby present a yuletide tale of the age old battle between Good and Evil…


‘Twas the night before D-DoS, when all through the net
Not a rootkit was stirring, no activity yet.
The victims were chosen, the criminals dared
To hope cash from extortion soon would be theirs.

The targets were nestled all snug in their nets,
Protected from dangerous POSTs HEADs and GETs.
Their NSM sensors, all fed from a Tap,
Kept watch for traffic they knew should be zapped.

When into my inbox there arrived a stern warning,
“Give us your cash, or we’ll DoS you by morning.”
Away to the helpdesk I flew like a flash,
Afraid that my website soon would be trashed.

My lack of response to the blackhat’s demands
Caused him to issue the fatal commands.
Sitting alone in his t-shirt and jeans,
With his tower PC, and eight LCD screens.

Then his dusty old keyboard went clickety-click,
His army of trojans heeded his nick.
More rapid than torrents his botnets they came,
And he whistled, and shouted, and called them by name!

“Now Gumblar! now Koobface! now Storm Worm and Ozdok!
On, Clampi! On, Pushdo! On, Cutwail and Rustock!
Use all your ports! Fear no firewall!
Now DoS away! DoS away! DoS away all!”

As dry leaves before the wild hurricane fly,
Packets were inbound, my bandwidth sucked dry.
So back to the helpdesk in panic I flew,
Only to find that they were DoS’d too!

And then, in a twinkling, I heard through the panic
A cry from the desk of a worker less manic.
As he drew on his pad, his colleagues turned round,
Listened intently to what he had found.

“I know this sounds crazy,” he said through the din,
“I can disrupt the botnet, attack from within”.
“I’ve seen it before, in a film with a spy“,
‘send spike’ is the answer; the trojans will die!”

His eyes-how they twinkled! his dimples how merry!
As he hammered away on a keyboard from Cherry.
He pictured the blackhat – alone, unaware –
“Attacking my botnet? Surely no-one would dare!”

The end of a pen he held tight in his teeth,
It leaked ink that encircled his mouth like a wreath.
He sent spike on its way, and sat back from his desk,
Hoping to neutralise botnets grotesque.

He was chubby and plump, was our evil blackhat,
But his face turned to horror, he froze where he sat.
His botnets revolted and cackled with glee,
Changing his wallpaper to pictures of goatse!

He spoke not a word as the bots went to work,
They emptied the bank accounts held by this jerk.
Their final accomplishment was rather extreme –
They framed him for felonies and called in the SWAT team.

The blackhat defeated by our Hero so gallant,
Away to the pub they went – drink to his talent!
But I heard him exclaim, ‘ere he drove out of sight,
“Happy Christmas to all, and to all a good-night!”

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

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

Posted in General Security, Information Leaks on 7 December, 2009 by Alec Waters

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:

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

“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)

Information Escapology, part four – Ask, and ye shall receive

Posted in General Security, Information Leaks on 1 December, 2009 by Alec Waters

One of the websites we monitor has a teeny problem, in that there is something somewhere on it that that causes the users to see a spurious “401 Unauthorized” message. Tracking down and removing the problem is straightforward, so I don’t want to write about that. I want to write about what the users do when this happens.

The site in question isn’t anything particularly elaborate – it’s public access, and there are no user accounts or login boxes at all. The users are merrily browsing away, when all of a sudden they hit the part of the site that raises the spurious 401s. The net result in this specific case is that the browser starts the HTTP authentication process, and a login box is presented to the user.

Now, what do users do when they see a login box? Despite the fact that this site has no user logins whatsoever, they do what they are conditioned to do…

…which is to type in their username and password.

There is no reason for them to do this. They just seem to see the login box that is a byproduct of the unintentional HTTP authentication process, and type away. They don’t have any credentials for this particular site (because there aren’t any), so they just go ahead and try whichever set comes to mind (Windows login credentials, mostly).

User psychology aside, from an NSM perspective we can harvest quite a bit of information. If the website is using IIS and is set up to use Integrated Authentication, we’ll be able to see (from a full-content capture) the user’s username, their machine name and their Windows domain name. If it’s set up to use Basic authentication, we’ll be able to see their username and password. If we can somehow make different parts of the site use both of these authentication schemes we’ll have the whole lot, plus of course their IP address from the web server logfiles.

It’s an interesting way to take a phishing trip!

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