Is IT AI VXXXXine .... Binary Medicine?

NOT!

"...that could allow attackers to take control of vast numbers of machines, particularly those located off US shores..."

What, like in China?

</rimshot>

You'd need to register a domain like "wpad.net.nz" which would make you very traceable to start with. I notice the above domain has been registered by Beau Butler, I guess so he can demo his exploit.

Moreover, I'd think that the browser has to go directly to the WPAD server to get its settings, so unless your site has both proxy and direct access, this probably wouldn't hit you.

Transparent proxies are a much better idea, anyway.

in my business (technology systems and software support), we call that job security.

i'd like to thank Gates, Ballmer & Co., and also millions of Windows-focused ISVs all over the world, for NOT changing their business priorities or development processes to focus on software quality and security, first and foremost. every year that these companies continue to be driven primarily by marketing considerations, my customers will need my services for another 5 to 10 years after that.

if there were no fires, there would be no money in addressing and preventing fires.

that reminds me, i need to get more marshmallows....

actually uses WPAD? If you are running a proper windows domain structure you should be using group policies to set your proxies at a push. Transparent proxies would be better. Or pac files. Or login scripts. Or batch files/reg hacks. If you are running windows machines on a large scale network without domain controllers you are doing something wrong. If you have a primarily windows network and need to apply proxies to *nix, macs firefox users etc then most of your users are quite likely to know how to set that up anyway!

I would have thought the biggest flaw with Windows was that it comes in a box with "Microsoft" on the front...............

@ Rich

you're having a laugh.

in real life, it is almost a no-brainer. i have a recent example.

last weekend, i was at the home office of my wife's colleague (name withheld to protect the clueless and the ignorant) whose "friend" (software developer) was kind enough to set up a Linksys wireless router for her cable connection some years ago. her company (sole proprietorship) represents suppliers who want to do business with a particular cable TV shopping channel (QVC), and she is a conduit for tens of millions of dollars worth of product every year.

so this was like watching a veterinarian practice neurosurgery on human infants. seriously, programmers should either [a] learn more about systems work, or [b] stick to what they know. this guy didn't change ANY settings in the router. default SSID, no encryption, default admin password (looked it up on the Linksys website, i did), web administration accessible, so the biggest security hole i've seen in a longish time. they did their banking on this connection, as well.

many of these routers include DNS proxy functionality enabled by default (this one did), so registering a domain is not necessary. one can set up whatever DNS information is required, within the router itself; or one just points the router to a rogue DNS server, and sets up whatever domain information one wants. this IE "feature" would then allow capture of all Windows clients through a web proxy one can configure, for the perfect man-in-the-middle attack.

in real-life situations like the one i was presented with, it is TRIVIAL to exploit this problem. since most users and many IT wannabes have no clue, scenarios like this are rather common.

Nothing about mating ferrits then?

WPAD is convenient. It allows machines to work once taken offsite. True, this can be achieved through serving a PAC file on the open internet (a security weakness), or a locally stored PAC file (PITA because you need to add scripts as well as policy objects).

That having been said, WPAD is just a director to the PAC file anyway. It first tries as a DHCP option (which is a well thought out solution), then runs the heirarchy of wpad.mydomain.sld.cc then wpad.sld.cc, then (in an incorrect implementation) wpad.cc. This was stupid right from the beginning. It is a plainly apparent flaw in the (expired) draft ietf specification. The operating system just follows the spec. Of course the spec was filed by microsoft too...

WPAD is useful, but the standard should be redrafted to use DHCP only. While there is still potential for abuse under DHCP, it is limited to the local broadcast domain, rather than an entire SLD.

While the DNS search can be sanitized to avoid likely malicious wpad entries, it's tricky, as some ccTLDs have SLDs, others don't. Others even go half-and-half. Banning the registration of WPAD would work on some registries, not others. Therefore, the DNS search method of WPAD should die, or at least have a switch.

And for the record, intercepting proxies (aka transparent proxies) aren't the panacea. Those who understand a little bit about routing can tell you why.

Yes, Microsoft were a bunch of dicks about this one, but let's face it, everybody in software engineering are prone to their own moments of idiocy.

Ray

This is the first paragraph of the article - it contains a clue for you...

"Microsoft bug squashers are investigating reports of a serious security vulnerability in Windows operating systems that could allow attackers to take control of vast numbers of machines, particularly those located off US shores."

</rimshot>??

Ignoring the fact that that brings something of a pornographic nature to my mind's eye, I can't believe that a poster to El Reg would make such a shocking XML error. You have typed a closing delimiter to the element <rimshot> there. But there was no opening delimiter! How do you expect us to parse this!!?? I can only hope that you meant to type <rimshot />, making it an empty element and allowing this tag to stand alone.

Semantic web my arse.

That kind of workload... has been known to break whole civilizations

Ah yes that 'other' operating system. How is it doing these days? ;-)

I helped a total IT illeterate sent up his router.

In 4 years:

How many viruses has he had....none,

spyware.......none

malware.......none

All I did was instruct him to do a google for 'secure my router' and then he followed the instructions.

He did is within 10 minutes and did not need me to do anything but check.

He (Not me) set up:

His router has a unique password, it blocks ports (except ones used), its own firewall is enabled. Windows is fully up to date (with its own firewall running as well)

As he only has two PCs on his wireless network he has assigned 2 IP address (assigned to MAC addresses), so even if a hacker wanted in they would not get an IP Address by hacking into the Wireless

You do not have to be an IT boffin to secure your router, the ablity to do a simple search and follow very simple instructions is all you need.

/nuff said

Oh aye, you're expecting me to believe that your arse is always empty?

You needed to read the DTD

<!ELEMENT myarse EMPTY>

<!ATTLIST myarse contents (shit | wind | gerbil) #REQUIRED>

Phone the head domain registrar at his house and get all domain names with wpad.* suspended and all future wpad.* entries EXCEPT .com one (as they are already protected) banned.

Now THAT is the Microsoft way.

Ah, pisspoor DTD design is at the heart of so many problems. Content in an attribute? This is very short-sighted. And what happens just after a trip to the loo when <myarse /> actually IS empty? Is the user manual going to tell me I have to shove a gerbil up there just to be able to parse?

Okay, I'll stop now.

Microsoft on the hunt for 'serious' Windows flaw.

I'll give them a tip, It's Windows. Flawed from birth and just more flawed in its various incarnations.

Oops! Sorry forgot, Vista was been designed from the bottom up. Nothing to do with previous flavours.

Can't we be redirected to a malicious Paris Hilton site?

perfect design would see a lot of unemployed people

Nothing wrong with simple content in empty elements either

but maybe

<!ATTLIST myarse contents (shit | wind | gerbil | empty) "empty">

would be better to avoid the need for a gerbil dispenser next to the bog roll

Combine with dns cache poisoning which has been around for yonks this exploit could be very powerful.

Take the average ISP which assigns addresses of the form <somenumber>.pool.<isp domian>.

All you need to do is convince the ISPs DNS cache servers that pool.<isp domain> points at $evil_server, and you are suddenly in the position to proxy the majority of the ISP's users through your evil server.

There's one or two caveats but even if this worked for 1 in 10 ISPs it would be a pretty major exploit, you don't have to think too hard to see how much mileage can be gotten out of this.

Duncan, Colin... Guys, give it a rest! I'm splitting my sides and my cow-orkers are getting worried. I usually only laugh this hard when someone has screwed up in a collossal and totally preventable manner...

..Oh, wait...

security through obscurity

:o<

Aren't we missing the obvious here? in that the top level of the domain which is potentially out of control is the LAST place the script looks.

Therefore if you have a properly configured proxy within your domain it will find that first then stop looking. Therefore this exploit would require the autoconfig to be active and no valid proxy within the domain....

Point being this isn't a "hack my pc" button, 4 events need to occur

1) auto config on

2) "malice" setting up a hoax proxy on the tld

3) all proxies below the tld going down.

4) network must be configured to allow traffic out of the domain that doesn't go through the proxy, which defies the point of having a proxy.....

I'd say this bug was low risk but high hazard.

I was choosing the most obvious attack, you are right, that users behind a NAT firewall with a built in dhcp server which gives out a different domain would not be vulnerable to the approach I suggested, the approach I suggested would only work for ALL of the ISPs users who are directly connected and use internet explorer with the auto config option turned on (which is still a pretty large target audience, given that successful exploitation allows you to snoop all their browsing).

I still think that's a pretty big score.

Regards NAT, ISPs recently have taken to shipping their own NAT router to users, so in these cases you have a nice monoculture which means that guessing the domain the DHCP implementation gives out would be trivial, which would give a nice attack vector using DNS spoofing for these machines, also of interest, many of these 'NAT' boxes have a piss poor DNS proxy implementation which is trivial to poison. Although I suspect the majority of these types of boxes will pass on the domain their public facing interface receives anyway, which completely ruins your argument.

Regards DNS poisoning being quite difficult, in the case where you are trying to convince a DNS server that a domain which does not exists actually exists and points somewhere, you get one attempt to poison the cache every time the negative response is removed from the cache, if it is even cached. negative response caches are an optional part of the DNS specification, and even when they are implemented, the cache timeout is low.

The mitigating factors that come to mind:

- If the ISP uses a transparent http cache, the evil server through which you proxy connections would have to be located behind the transparent cache (I.E. on the ISPs network).

- If the ISPs servers are authoritative for the parent domains of the domain given out via DHCP then it would not be possible to poison it.

- DNS Poisoning is difficult to achieve given a sane caching DNS implementation.

- Users may not have the auto config option turned on.

- Users may not be using Internet Explorer.

Maybe this would be better directed at a security related mailing list than the comments section of a popular IT rag :)

I'm curious about a comment you made in a forum in late-October, concerning Marconi. I'd like to talk. Please email me at scylla.charybdis@gmail.com