Microsoft: Stuck between a rock and a hard patch?
The problem, of course, began with phishing emails - emails that purport to come from a reputable company and ask you to confirm your account details, but which actually have no affiliation with that company and are in fact distributed by criminals looking for gullible victims.
Since email headers are relatively easy to spoof, it's often difficult to tell that the email is a fake. But click on the link and things are different. Take this URL, for instance.
If you direct your unpatched Internet Explorer browser to this link, then you go to a page which, at the time of writing at least, looks like it is owned by eBay.com; indeed, even the top of the browser says you are at eBay.com. But even though there are plenty of 'ebay.com's littered throughout the URL bar, it's pretty obvious that this URL does not really point to eBay.
Now go to this page hosted at zapthedingbat.com and click on the button that says "Test Exploit" (don't worry, it won't do anything to your system). This time, you are taken to a page that, although it is a (deliberately) rather poor imitation of Microsoft.com, would, if its creator so desired, make it much more difficult to tell apart from the genuine Microsoft.com - or any other targeted site.
The trick (and this is no longer a secret since Danish security company Secunia posted details of the flaw just recently) is to use a URL that takes the form: http://username:password@mysite.com.
Usually, the browser uses whatever is to the right of the @ symbol to locate the Web page. Everything to the left of the @ is used to authenticate the user. But attackers can use the area to the left of the @ symbol to display a decoy Web address while actually transferring victims to a different page or site. Matters are made worse in Internet Explorer because by adding a couple of non-printing characters before the @ sign, an attacker can prevent the browser from displaying the true destination address of the URL. So, in the working example at zapthedingbat.com, the following URL is used: http://www.microsoft.com%01@zapthedingbat.com/security/ex01/vun2.htm
Add a little extra trickery, which zapthedingbat implements in that button, and the URL looks to all the world (including most people who would describe themselves as tech-savvy) as if it is microsoft.com.
This a big problem, for individuals and for any companies -- including eBay, ISPs and banks - that do business online. If you run an e-commerce site, your reputation is at stake; if you are an individual who takes the phishing bait, your cash and possibly even your identity are at stake. So it's hardly surprising that Microsoft decided to issue a patch to close the hole.
But just to complicate matters, there is a further problem, which lies in the fact that that many Web sites use the http://username:password@server/resource.com convention to authenticate users, and many of these have suffered as users duly updated IE with the new patch.
Angus Systems Group, for instance, found that its commercial real estate Web-enabled service suffered badly from the patch. Senior architect Brad Aisa said the company's reporting tool depended on the http://username:password@www.somesite.com URL convention, but users who have downloaded the patch can no longer use it. And a work-around is no simple matter (Aisa characterised it as "onerous and complex"), since the security was embedded in Angus Systems Group's application. The credentials, said Aisa, were not those of individuals, but groups of users who share credentials.
So whether not the patch was successful depends on several things, not least of which is your definition of the word "success".
For while the patch did what it was supposed to do for some users, it also meant they were locked out of legitimate e-commerce Web sites. For other users, the patch failed to do what it was supposed to do, but their access was unaffected. Whether or not the patch worked seems to be contingent on other third party applications on the client PC, but the real question is: should Microsoft have issued this patch in the first place?
The company was under pressure to plug what many consumers perceived as a bug. In fact, the username:password convention is mentioned in a document of the Internet Engineering Task Force called RFC 2396. However, the IETF's opinion appears to be that this practice is not recommended. The IETF's reticence appears to be not so much about phishing as the issue of passing usernames and passwords as clear text (as they are when embedded in URLs like this). So Microsoft can now say that, in this respect at least, its browser is more secure than those of the competition.
Indeed, no other browser has blocked this functionality. But then no other browser allowed that nasty %01 bit in the URL that is God's gift to phishing. Mozilla ignores it, and Opera even provides a security warning explicitly telling you the name of the server you are about to visit.
Whoever at Microsoft was responsible for the decision probably felt they were stuck between a rock and a hard place: they either left the functionality in IE and faced accusations of aiding phishers, or released the patch and broke countless e-commerce sites. But perhaps if the company simply paid more attention to the standards in the first place they would not have had to make that choice.