Microsoft.com error reveals IDs, passwords
The problems I've had were a little scary and a lot annoying, but mostly I viewed them as signs of the immaturity in the programming code of many sites. But there was a common theme to each of my episodes. The programming language was always VBScript, the language used to code Active Server Pages on Microsoft's Internet Information Server. When I had the time, I'd take a screen shot and send it to the operators of the problematic site.
Until a few days ago, I didn't give it much thought. But then a Tech Update reader, who shall remain anonymous, showed me the "error message" that he was issued after attempting to sign on to the Certified Partners area of Microsoft.com. For resellers of Microsoft products, the Certified Partners area is one of those Web sites that Microsoft has "gated" with Passport. By requiring a Passport before resellers can enter, Microsoft turned all of its resellers into Passport holders. Conspiracy theorists will argue that this is yet another play that Microsoft has used to inflate the number of Passport holders (the current claim is 165 million and rising).
The error message received by the reader (shown here) is reminiscent of the VBScript dumps I used to see on those malfunctioning Web sites. At first, the error message seemed harmless enough. It indicates that there was a compilation error because of an undeclared variable and shows the offending line of code plus the two lines before and after. But there's also a link labeled "Show Complete Compilation Source." Being naturally curious, I clicked the link -- and the details of the error message were far more revealing. As you can see from the source code that was revealed, the VBScript provides detailed information about the names and addresses of Microsoft's Web and database servers, as well as complete user id and password information; all of it in clear text; in particular, see lines 444, 454, 464, 474, 483, 492, 502, 512, 521, and 574.
Now, I don't consider myself a VBScript programmer. But I do know enough to know that any time a Web site spits out a bunch of resource names, user ids, and passwords at the user, that it's a bad thing.
To confirm, I contacted a friend who dreams in VBScript to get his opinion of the code. My expert friend said, "The site that generated the error is being built using the beta version of Visual Studio 7.0. The programmers have also enabled detailed error dumps. The only code that I see that relates to Passport is for the purpose of checking whether the user currently has a valid session. The database information is for the local site's databases. The information includes the database server name, database names, username, and password for accessing the data."
My friend went on to say, "Although I wouldn't want somebody outside my organization to have this information, chances are that the database server is on a private network or behind a firewall so an outside user could not even have the chance to log on. However if someone were to use a Trojan horse program they could then place an ASPX page [on that server] to access the protected data since the Web server already has access to the database server. Again, I would hope that all the security patches would be up to date on any server that faces the outside world."
My immediate reaction to that is to ask: Sort of like the way that Microsoft patched it's Hotmail servers? As we all know by now, Microsoft failed to patch some of its Hotmail servers and the Code Red worm forced Microsoft to take them offline. And the second question that popped into my mind was, Is Microsoft really building production Web sites with beta versions of its development tools? I understand the need to stress test its own products, but building production systems with beta tools isn't exactly the sort of practice that breeds confidence. (Although some Microsoft detractors would argue that all Microsoft software, shipping or not, is beta.)
Saying "If I can load hostile code onto a system, then I own that system," Microsoft security spokesperson Christopher Budd doesn't dispute that damage than can be done once hostile code (ASPX-based or otherwise) is loaded onto a server. That much, I'll give him. If hostile code successfully penetrates any software or operating system (Windows, Linux, Unix, or otherwise), that code owns the system. The problem is not unique to Microsoft, although it's worth noting that its products are more frequently targeted than others. But what about when user ids and passwords are revealed in the same way they were revealed here? Doesn't that make the bad guy's job easier? Budd says no, claiming that when hostile code is loaded on the system, it's no easier to target a particular server or database when this information is revealed, than when it's not. I'm not convinced. Perhaps it's only a matter of time before someone who controls hostile code can find the same information that was revealed by this error message. But, as far as I'm concerned the less the bad guy knows, the better.
Fortunately, the Passport databases were not compromised. In terms of this incident, Budd emphasized that "This was not a Passport-related issue. What was exposed was ASP Plus code for a specific application and no database content or user profile information was exposed." While the databases in question may be protected by firewalls and may not contain any sensitive information, the issue of Microsoft eating its own dog food, and doing so with beta product still remains. According to Budd, the beta version of Visual Studio was indeed used. "But," says Budd, "[the usage of beta development tools for production systems] really depends on system being developed. Microsoft has been very forthcoming about using its own stuff, including beta product for production systems but not all systems. Only where it makes sense."
According to my friendly VBScript guru, "Basically, this is a major goof up on the programmers' part. I know Microsoft encourages the individual groups to work with beta products but a programmer shouldn't enable programming debug information to show up on a production site." Responding to questions regarding Microsoft's best practices, Microsoft spokesperson Jim Desler said "We're still investigating the incident, but the early indication is that someone left the page in a debugging mode. This is counter to the processes and procedures that Microsoft has in place. It was an operational error. Obviously we will review how this happened, why this happened, and based on what we learn, we will develop procedures from preventing this from happening again."
Desler and Budd realize that Microsoft is the poster child for its own technologies and that incidents such as these can undermine confidence in the company and its products. According to Desler, "We can't just be as good as others. The standard is higher for us. We have to be better than others." To that extent, Budd identified many of the broader initiatives that Microsoft is taking to buttress its products and customer installations that depend on them. Budd cites Microsoft's Secure Windows Initiative, announced in April at one of RSA's conferences, and more recently the announcement of a toolset to help server administrators be more proactive about the security of their servers.
The security issue appears to be a top priority for Microsoft. But, now the company is battling against the clock. Microsoft is staking a large part of its future on .NET, and in particular, the authentication aspect of it that is based on its own Passport technology. Meanwhile, Sun is pushing a competing authentication solution that will be delivered by the Liberty Alliance.
As I point out in another column, if an authentication standard doesn't emerge, the battle between Microsoft and the Liberty Alliance to be the premier provider of authentication services will be won on trust. If Microsoft continues to call its best practices into question with one goof after another (unpatched servers, using beta product to develop production servers, spitting out error messages with user ids and passwords), it will need to do some Herculean fence mending before it should earn your or your customers' trust.
What do you think? Share your thoughts with your fellow readers at ZDNet TechUpdate's Talkback, or write directly to david.berlind@cnet.com.
Got a great tip? An industry rumor? Or do you want to submit your own column to ZDNet TechUpdate? Send David your submission, and if we use it, you'll be compensated with some of the cool vendor schwag that arrives in our mailboxes on a daily basis.