Slashdot Mirror
Security Vulnerability in Microsoft .NET Passport
Stuart Moore writes "A vulnerability was reported in Microsoft .NET Passport, also affecting Hotmail user accounts. The simple flaw allows an attacker to change any person's password to an arbitrary value. The attacker can then gain access to the victim's accounts, as well as to the victim's personal information (if any is stored w/ Passport). Muhammad Faisal Rauf Danka posted a note to the Full-Disclosure security e-mail list after multiple unsuccessful attempts to contact Microsoft." There's a news report as well.
Too bad this was caused by a blatant underestimation of the power of curious users. If I had ever used the feature, I would have picked it up instantly.
Job? I don't have time to get a job! Who will sit around and bitch about being broke and unemployed then?
Sooner or later they'll start blaming users for providing personal information, and excusing websites and companies from security flaws.
My neighbor's
You expect security from a company with one of the worst track records in the industry? Ha!
The problem with Microsoft (and the majority of other IT firms) is that there is no PROACTIVE auditing. I think that every company should conduct OpenBSD-style code audits before they release software. This would cut down dramatically on the number of incidents like this.
Microsoft make an interesting interpretation of RFCs by accepting all mail to postmaster@ but only insofar as to send an automatic response saying your message will not be read.
This guy also says he tried to email them ten times and never got further than automagic autoreplies. Do they actually have a procedure to inform them when things are broken?
There is an outlined procedure for this sorta thing...
In the event a user discovers an exploit, inform user to reboot machine and it will go away.
But seriously, there seems to be no OFFICIAL way for end users to actually contact microsoft, nor any sorta automated system to rank e-mails based on importance, nor any human within the phone network who actually knows who to talk to. People who i've known that worked there also have no clue as far as who to talk to, and admit this if you're lucky. If you are unlucky, just say it's a vender issue without thinking the vender is Microsoft.
There is no sanctuary. There is no sanctuary. SHUT UP! There is no shut up. There is no shut up.
But seriously, there seems to be no OFFICIAL way for end users to actually contact microsoft, nor any sorta automated system to rank e-mails based on importance, nor any human within the phone network who actually knows who to talk to.
Tell me about it. When IE5 first came out (with the modular installer) the installer had a nasty bug: If the FTP site it tried to connect to to download a CAB was full, it would create the CAB file which would contain no data, only the error message!
As one might expect, this would cause the installation to bomb, and no explanation would be given to the user. Attempting to resume the installation would also fail. The solution was, of course, to go into the installer's temp directory and delete the bad CAB files and re-download them, but most users wouldn't know where to find them, and would be forced to start from scratch.
When I attempted to contact Microsoft about the problem, they asked me for a credit card number. When I explained I didn't want support and was trying to report a bug, I was transferred to someone else who... asked me for a credit card number. Wash, rinse, repeat.
What part of "shall not be infringed" is so hard to understand?
And eventually, we will see a similar exploit on Sun's Liberty system as well.
While we will undoubtably see exploits on any system large enough to atract interest, I don't think Sun would code something this brain-dead stupid.
The industry standard is to ask for a passphrase when you forget your password. MS didn't even do this. I'm still wondering what junior level coder came up with this one though... I can't even express how stupid this is.
The whole single sign on concept is flawed at present. Far too many potential holes, no matter what the tool, or who the builder.
So we work to make it better... abandoning the concept entirely isn't going to happen. It's a worthwhile concept IMO, and while there's a lot of issues to be worked out that's not to say that they can't be. Most people would be willing to use a "strong" password if they only had to remember one. When you have to remember a dozen then forget it - the vast majority of people are going to use something like "password" or an easily guessable word from their personal life. Remembering "df783N:pa04uYG" and another dozen variants just isn't going to happen.
I usually stand up for the Redmond boys if there's some bashing going on and not alot of balance to the issue. But this is just an incredibly stupid hole to have open. Why would you ever, ever, ever pass details in the URL string that the user himself need not (and should not be allowed to) supply? If it is because you are passing it among servers in some fancy-schmancy web service scheme, then at least have the decency to hide the exploitable name/value pair in an http header or something (but even this should not be necessary for what they are doing , even if my guess as to how their backend works is wayyy offbase). Somebody said it earlier in the discussion that it is because developers (using the term lightly) add features without thinking of how to do it right and how to do it securely and just pass any old thing in the URL string, and they were right on the mark.
Some coders (again using the term loosely) at my organization used to do this absolutely all the time and I would bitch about how piss poor it was from a security angle (and regularly demonstrate how easy it was to circumvent the intended "security" mechanisms). Everybody laughed at me when I did... that is until one of our largest customers hired an outside firm to audit the "security" of the apps they were getting. It took the firm very little time to discover these nuggets, of course. It is interesting to note that they reported that the application security was among the poorest they had seen, but that the server configurations (my department) were among the tightest. The sad thing is the stupid customer basically thought the two canceled each other out, threw some extra money at redesigning the application to meet the standards it should have to begin with, rewarded our systems team which had done it right the first time with absolutely squat, and renewed the contract for another five years. Shows you how much the corporate world understands what's really going on.
Can I bum a sig? I left mine at the office.
After months of trying to understand Microsoft's situation (Windows XP Shows the Direction Microsoft is Going), I came to the conclusion that the Microsoft management style leads to mountains of sloppy code that is difficult to maintain. That's the only theory that seems to fit. For example, in Internet Explorer browser alone, there have been for years more serious security bugs than Microsoft fixed. There are, at present 14 security vulnerabilities.
Here is the recent record. The list of defects has been similar for years. Also, this is a record only of security defects, not all defects:
- June 18, 2002: 18 vulnerabilities
- August 8, 2002: 22 vulnerabilities
- September 9, 2002: 19 vulnerabilities
- November 19, 2002: 32 vulnerabilities
- December 9, 2002: 19 vulnerabilities. (Microsoft fixed 15 on Nov. 20, but
two new ones were found.)
- May 8, 2003: 14 vulnerabilities
This is a terrible record for a company that has $52.9 billion in the bank. (See "Total Current Assets" in the upper left hand corner, which is the money available within the next few months. It takes time to spend a billion dollars, so the next few months is equivalent to cash.)Obviously, Microsoft could fix the bugs if the company wanted to fix them. But the company apparently lacks the will to devote the resources necessary (IE still does not have tabbed browsing), and apparently also, it is not easy.
But where's the public outrage?
/. regularly vent our spleens (including me, and I'm a Microsoft user myself) about this blatantly bad situation, but Microsoft continues to prevail, and except for the occasional story, there really seems to be no negative impact on their business (much of which seems to be spinning their abysmal record in "trustworthiness").
We on
Hackers are only an endangered species because it hardly takes a hacker to break MS code these days.
You are in a maze of twisty little passages, all alike.
If you've made any study of it at all you know that effective security results from a process that starts before the software is even written. There is no protocol that will save you from logic errors (like the latest Passport hole). To do this reqires a good understanding by the devs of security and their adherence to design principles and coding practices. To do that you need a software development methodology that enforces the consistent application of those priciples and practices. Therein lies the problem.
In my little corner of MS (though by all accounts it was typical of the company as a whole) what was prized above all was meeting requirements and deadlines. Virtually no energy was put into the development environment (hence the hour I spent every morning just downloading the nightly build, the insane .bat scripts, constantly fixing my own NT install as a $55/hr contractor). Nobody got "c-hours" for making life easier. More importantly, there was little value placed on design, good technique. Lip service was paid in meetings and reviews, of course, and superficial style details received obsessive scrutiny. Code reviews often bogged down on correct hungarian notation but a unit test consisting of "return true" was perfectly ok. The "heros" were people with big brain muscles who spent nights and weekends hammering out code to meet the latest deadline.
The result of all this was a coding culture that I called the kingdom of cut-and-paste. I was actually encouraged to write routines by starting with someone else's routine to do something unrelated and edit it to do my task. A colleague would stand over my shoulder browsing the codebase looking for something convenient to steal. It was a shock to realize how little code people actually wrote. This is one of the things that I hated about working there, that I spent so much of my time fscking with the various APIs, incomprehensible include file heirarchies and so little time writing C++.
Well, in my Intro to Fortran class in '77 the prof explained why massive code duplication is a bad idea, and the results are visible in every MS product. You can't fix a bug in one place, you have to fix it every place it got copied to, and you don't know where those are. The codebase is now on the order of 100'sM lines or better? Probably not even MS has a good handle on this, because they can't know for sure how much duplication (with tiny variations) there is (clue: lots).
Once a company grows to a considerable size it's really hard to change the culture. I've seen this at several startups. MS is like a battleship or an aircraft carrier. High-tech and deadly but turning that boat around is really hard and simply may not happen in a short distance. Expecting them to change their performance WRT security in a few months (or year) is kind of like expecting the old Soviet apparatchiks to start respecting civil liberties and human dignity because the Central Comittee sends out a memo. Good luck. It's a city unto itself in Redmond, its own little world. And even if you did, what the hell are you going to do about the millions of lines of (largely incomprehensible) code in the installed base? The millions of systems in the wild that are unpatched and unmaintained?
I see many of the same disasters being recapitulated in .NET. They may talk security and I'm sure they're trying hard but I expect that their long term strategies are going to rely more on legislation than the (probably impossible)
task of bringing their products t