Don't Trust Code Signed by 'Microsoft Corporation'

omarius writes "From the Microsoft Security Bulletin: 'VeriSign, Inc., recently advised Microsoft that on January 30 and 31, 2001, it issued two VeriSign Class 3 code-signing digital certificates to an individual who fraudulently claimed to be a Microsoft employee. The common name assigned to both certificates is "Microsoft Corporation".' See the bulletin for more information. Brings a whole new meaning to the concept of 'Windows Update.' ;)" Most users probably ignore the name on a certificate presented to them anyway, but even that minimal protection is worthless if certificate authorities don't perform their job.

hm...

maybe the next "service update" will magically "install debian" on some "lusers' PCs"?

In a perfect world, anyway...

- A.P.

--
* CmdrTaco is an idiot.

Re:Barf.

Better yet, how in hell is Microsoft goint to implement this "patch"? They can't do it securely. How can I trust that this "patch" is really the real one now, and not one that will permantently etch a back door into my system?

Ladies and Gentlemen, the barn door is open, and the genie is molesting the horses.

Microsoft screwed up by not using the Verisign CRL

In their advisory, Microsoft writes:

Vulnerability identifier: None. This issue is not the result of a flaw in a Microsoft product; it results because of an error made by a third party.

Which is an out-and-out lie. This wouldn't have been an issue for more than two months if Microsoft had made their browsers properly deal with VeriSign CRLs (Certificate Revocation Lists). Instead, it will continue to be an issue for a long time: even after MS releases patches, it takes years before the majority of users apply them. Earlier in the very same advisory, they wrote:

VeriSign has revoked the certificates, and they are listed in VeriSign?s current Certificate Revocation List (CRL). However, because VeriSign?s code-signing certificates do not specify a CRL Distribution Point (CDP), it is not possible for any browser?s CRL-checking mechanism to download the VeriSign CRL and use it. Microsoft is developing an update that rectifies this problem.

However, Microsoft has known for years about the CDP problem. They knew that VeriSign would be issuing the vast majority of code-signing certificates, so they could have (and obviously should have) included a mechanism in the browser to explicitly use VeriSign's CDP.

Instead, they chose to ignore the possibility that the security might be flawed and allow revoked certificates to be used. They didn't give a damn whether someone got a fraudulent code-signing certificate for J. Random Software Company, and the browser couldn't tell that it had been revoked. They've only been prompted to take action when this unexpectedly happened using their own name.

VeriSign made an error and corrected it within two months. Microsoft made a bigger error and has taken five years (and counting) to fix it, then has the gall to blame it all on VeriSign.

This Shows that

We can not only have one company to handle Digital Signatures. The internet community should create a non profit company to help with this problem. I am assuming that Microsoft is not the only company that this has happened to.

That's what CRL's are for

Ok...I hope this finally get's Microsoft and Verisign out of their complacent moods, and prompts them both to implement Certificate Revocation Lists capability that WORKS in all of thier offerings -

It is because they haven't bothered to do this yet that this is possible - think about it - if CRLs were implemented, and every application that used Certs checked the Revocation list of the issuing CA, this problem would have a trivial solution - Revoke the Cert, and this "fraudulent" issued cert becomes useless.

But since Microsoft, Netscape/AOL, and most other vendors of Certificate aware software haven't bothered until VERY recently to even think of the CRL, then this is now a rather large problem...
ame)

Anyways... I hope this causes them to go and actually implement RFC compliant CRL capabilities in all of their products - would make those of us who work with them VERY happy....

McAlister

Re:Wondering...

Actually its only accepts code also signed by the identical certificate as this is a different certificate but the same name it would not automatically accept it based on a previous acceptance of "Microsoft"

Re:?Microsoft Corporation?

No, it's due to the effects of the nonstandard "smart quotes [rainmaker.iki.fi]" plague.

CA's in general

This goes great with this [slashdot.org] article from a couple of days ago.

I used to think that the whole idea of paying a shitload of money to goons like Verisign was that you could trust the certificates issued by them. If they make mistakes like this, how can I trust them anymore? Furthermore, how can I trust the certificate any ecommerce site that uses their certificates?

This is a huge problem for all CA's if this is a precedent. I'm really curious to see what, if anything, Verisign will do about this.

All PKI suffers from this

The problem with any encryption system, neigh any protection system at all, is the point at which they break.

They super heavy deadbolts on my front door are useless if I pass out they key. The electronic security system is just a bunch of lights and buzzers if I give out the passcode or everyone ignores it. The extra heavy combination lock is just dead weight if the hinges of the safe are on the outside of the door.

Public Key cryptography is only as strong as the security on the key. The article says that this doesn't fit the strict definition of a security vulnerability, presumably because it doesn't break the software. Well, I'd like to disagree. Part of the product, part of what M$ sells with the promotion of signed inActiveX controls, is that the pieces of code are trusted. This is not a piece of software they are selling, it's an entire system. The software is only part of it. The system has been broken. This makes it a security vulnerability in the same way that giving out keys to my front door and the combination to my safe are security vulnerabilities.

The gist of my rant, and the point I'm trying to convey, is that systems are more than just the software. To concentrate only on one part of the system when defining terms to describe the safety of the whole system is foolish.

Bigger problem

Don't trust certificates issued by VeriSign

I dunno, but it seems to me that they have the bigger problem. We put our trust in VeriSign to properly identify people requesting certificates. That trust has been broken now.
---

Re:Always trust content from Microsoft Corporation

It's not a problem. The "always trust content from ...." is not on a name basis but on a certificate basis. These phoney (or any other) certificates won't automatically be accepted.

Trust relationships with cryptography

Guess the problem here is that it should have always been up to the end user as to which certificate signing authorities to trust, rather than for software manufacturers to decide for us. At least browsers are getting better, before if they saw a certificate that the browser didn't trust it would reject it outright.

But nowadays if a company becomes untrustworthy through malicious intent or just plain incompetence it's not possible for users to 'un-trust' a certificate authority trusted by the browser/software manufacturers.

There should be a higher degree of control at the end-user as to which CA's are trusted.

-- Greg

Re:Bigger problem

The only truly effective answer to the question "who watches the watchers" must be "the public themselves".

pardon my ignorance but is there an "open / free" (im using the terms loosely and not interchangebly) CA out there? I know that there was an Ask Slashdot about why SSL Certs are so expensive (here [slashdot.org] for the curious). I agree with the position that certs are issued typically for piece of mind, but would it be practical to implement an open standard of secure communication specifically for browser / server communications or is SSH adequate for this? Obviously Im not a security expert, but I am a concerned person who would rather place their trust in an open standard than in a hidden company that requires "blind faith"
--------
"Counting in octal is just likst counting in decimal--if you don't use your thumbs."

The system needs reform

Don't trust certificates issued by VeriSign?

Then who will you trust?

With the amount of money verisign requires you to pay for their various types of certificates, you would think that they could take the proper steps to ensure that the application is valid? A phonecall to the posted number for the company perhaps?

Running a script to generate a key does not cost hundreds of dollars, we are paying for the extra for the cost of validation. I expect Verisign to DO that validating!

Re:Uh..

Actually, MS has a good share of the blame here. Two things which make this an effective hack:

• The lack of CRL support. This is largely MS's fault (no in there) and Verisign's fault (no CDP)
• The all or nothing trust model. This is seriously flawed; you do not get the option of letting a control have a 'little' access.

Both share a good bit of the blame. OTOH, it is more fun to just bash MS.

Hey, I know how to solve this!

Guess we need another layer of certificates to verify VeriSign, Inc.

Yes, I'm joking.

This is serious, but not as serious as it could be

(From the NTBUGTRAQ) Despite the fact that its a Microsoft Certificate (for all intents and purposes it appears as such), it WILL NOT automatically be trusted by anyone's system. Even if you have previously stated that you want to trust all signed software from Microsoft, the fact that this one is a *different* Microsoft Certificate means you will still be prompted to trust it.
So it's still a big deal, but if you keep that little bit of knowledge in hand, you wont have to worry (to much)

----------------------------------

Re:Had to happen eventually.

That may sound like a bold statement, but if you think about it for a moment, can you ever trust an automated software update again, even a "secure" one?

Yeah, maybe. Research is currently being done on how to do this without the idea of a trusted party. The general idea is that the code comes with a proof of its safety (or a proof that it meets some other specification), which is "easily" verified by a small piece of software on your computer. It's not a panacea (there is a world of difficulty in specifying the right policies), but it could certainly stop updates of application-level (or especially applet-level) software from containing naughtiness.

Check out http://www.cs.cmu.edu/~petel/papers/pcc/pcc.html [cmu.edu] for more info on Proof Carrying Code.

What about a slightly different name?

What if i would own (I don't by the way ;-) the domain www.microsoff.nl. I register my company 'Microsoff' here in the netherlands, and claim I do window-cleaning (as long as the type of commerce you do is different, you can register a name here).

It should be possible for me to get a Verisign certificate for 'the Microsoff corporation'. Most users won't notice this, so I can trick people into running my code.

Is there anything that can be done against this? Has Microsoft trademarked all 'Microsoft'-alike names? Can Verisign refuse to give out a certificate?

--

Uhh

Don't Trust Code Signed by 'Microsoft Corporation'

I've had that one covered for the last 18-24 months or so...

--

True story: Why you shouldn't trust Verisign

The company that I used to work for bought a certificate from them for their https site. (yep the one that costs some $500 a year). Unfortunately, the engineer who had done all the certificate generation and signing had left the company, and when it came time to deploy the server, we couldn't find the certificate, and the engineer was vacationing in the Amazon forests or something: unreachable except by snail mail. So I called Verisign customer service, told them that I was calling on behalf of this company, the engineer had left so could they send me a copy of the certificate? The customer service representative goes: "Oh sure, what's your email address?". I give her my email and she emailed it to me. That was it! No id checking. No passphrases. Nothing. And they sent it to me in plaintext email.

And the bastards charge money for this service.

Microsoft is innocent here

Everyone can setup a certificate server and give out certificates. Do you check the contents of the certificates? most people don't. They just see "ah! A certificate! so it's ok!", while there is a possibility it's not ok.

Verisign gave out the wrong certificates. If browsers now already have stored these certificates as 'safe', users should remove them, but it's VERISIGN's fault. They should have been more careful when they gave out the certificates. the person who now got the certificates could also have used 'Sun' or 'Red Hat' or any other company. Would that company then be 'the faulty'? NO.
--

This Isn't Really A Microsoft Story.

This is a security story. The lock logo would have been more appropriate. Oh, wait... every time MS is mentioned on /. you get a spike in ad revenue. Carry on.

Some comments here...

Who should read this bulletin: All customers using Microsoft® products.

Impact of vulnerability: Attacker could digitally sign code using the name "Microsoft Corporation".

Recommendation: All customers should follow the administrative procedures detailed in the FAQ. A software update will be issued shortly to provide permanent remediation.

I find it very fascinating that MS doesn't mention anything about the hazards of running code from an unknown author.

I would also hope that Verisign is taking a very serious look at their procedures - if CAs don't verify identities before issuing certificates, what good are they?

For that matter, how were individuals - MS employees or not - given keys in the company's name? There's no need for an individual employee to have those - especially before calling to check with executives within the company.

Re:Uh..

The real question is, why is this story posted under Microsoft at all? Clearly Verisign made the mistake. And the title "Don't Trust Code Signed by 'Microsoft Corporation" doesn't exactly help the situation.

Guys, Microsoft is not nearly as evil as you think it is. Yes, they had a track history, and yes clearly Bill Gates is a dick, but there are a lot of cool OS and game programmers, and hardware specialists that put out some wicked shit. You have to separate the company from the nerds like you and me.

Hahaha!

Hmmm... Verisign and Microsoft... now there's a team that just reaks of reliability!

Surprised? - Not really
Worried? - No more than yesterday
Still accepting certs without EVER reading them? - You Bet Your Sweet Ass!!!

It's not just an OS, It's an adventure!

WTF?

They make me send them multiple faxes and wait two weeks when I forgot my domain password, but some guy says he's from MS and that's good enough for them?

Re:WTF?

This has happened with domain names too - someone claimed to be the Excite webmaster and pointed the Excite.com domain to nowhere a couple of years ago... Maybe they are in fact less secure when the customer is a Big Important Corporation with No Time to Waste!

Barf.

From the MS announcement, why PKI sucks:

VeriSign has revoked the certificates, and they are listed in VeriSign's current Certificate Revocation List (CRL). However, because VeriSign's code-signing certificates do not specify a CRL Distribution Point (CDP), it is not possible for any browser's CRL-checking mechanism to download the VeriSign CRL and use it. Microsoft is developing an update that rectifies this problem. The update package includes a CRL containing the two certificates, and an installable revocation handler that consults the CRL on the local machine, rather than attempting to use the CDP mechanism.

Translation: This cert is bad, but the authority issuing it can't tell you this, even though the authority claims to be responsible for doing so. Microsoft and said authority didn't think of this, and so they now have to come up with a totally kludgey patch which they promise won't break anything else.

This is so fucking confusing even to someone who is fairly technical - can you imagine Joe User's reaction to this? Makes code signing pretty much useless.

Uh..

We trusted MS Before?! Did i blink and miss something?

Getting you money's worth

This certainly adds a new dimension to recent /. discussions about what, exactly, you get when you pay for an expensive certificate!!


-------------------------

Here's a thought.

A software update is under development and will be released shortly. When it is available, we will update this bulletin to provide information on how to obtain and use it.

What if the hacker(s) releases a patch before MS releases one?

Had to happen eventually.

If this doesn't wake people up to the problems with the very idea of certification authorities, I don't know what will. Any public key infrastructure hinging on trust of a central authority like this is doomed to fail, and in exactly this spectacular manner.

That may sound like a bold statement, but if you think about it for a moment, can you ever trust an automated software update again, even a "secure" one?

OK,
- B
--

And this makes Hailstorm all better!

I know it's Verisign's fault, but it really doesn't make the consumer side of .NET sound very trustworthy. I understand they're going to be using Kerebos for the Hailstorm identity back-end, but clearly there's plenty of room for Microsoft to botch. They're well positioned (and well funded) to actually go head with it, but the question is how much will people trust Microsoft? Even paired up with AmEx?

Re:True story: Why you shouldn't trust Verisign

So I called Verisign customer service, told them that I was calling on behalf of this company, the engineer had left so could they send me a copy of the certificate? The customer service representative goes: "Oh sure, what's your email address?". I give her my email and she emailed it to me. That was it! No id checking. No passphrases. Nothing. And they sent it to me in plaintext email.

The certificate would also be in the VeriSign LDAP directory and would in any case be handed out to everyone who accesses your Web site using SSL

With certificate based PKI the security does not lie in keeping the certificate secret. The purpose of the certificate is to authenticate your public key.

The security depends on you maintaining the secrecy of your private key. That was generated by your engineer on the server itself and VeriSign would never see it.

So calling up VeriSign and asking for a copy of the certificate does not constitute a security problem. It is like telling someone your PGP fingerprint, or someone downloading a keysigning from BAL's MIT key server or whatever it does not compromise your key.

Re:Wondering...

when one of those VeriSign things pop-up, you have an options to check "Always Trust Xyz Corp"

That dialog refers to the organization that signed the certificate. Most browsers (at least, IE and Netscape) come equipped to trust any certificate signed by Verisign. When you go to a page with a Verisign cert, the browser will trust the certificate, regardless of what company actually owns it.

Since in this case the certs were purchased from Verisign, your browser won't have any problem at all with them (it'll just assume that Verisign is trustworthy.) You won't get that dialog at all. If you look at the security info for that page, it'll show the page as registered to Microsoft corporation. Generally MS signs their own certificates, so it would be a little odd to see a cert owned by MS and signed by Verisign (although they may actually do this.)

Usually pretty obvious

It's usually not hard to figure out if you're getting a MS product online.
The files tend to come from domains like, oh, say, microsoft.com or mechwarrior4.com...
Now, of course, if you are trying to download 'http://ftp.goatse.cx/hotgaypr0n.exe' and it's signed by MS you a) have other problems and b) deserve whatever you get if you accept the file.

Of course, this is probably not too good for Verisign, as they now look like dumbasses, and have probably pissed off MS to boot.


Brant

So how did a class 3 get out?

Take a look at the requirements to get a Class 3 cert:

http://www.verisign.com/repository/CPS/CPSCH2.HTM# _toc361806948 [verisign.com]

http://www.verisign.com/products/asb/faq.html [verisign.com]

Especially interseting is the Assurance level that comes with this cert.

Even if these certiciates are never used, there will be some pretty heavy US govt. involvement as a result of this.

Anyone know if this has happened with any companies less visible than MS? A quick search did not turn anything up, but if Versign's procedures could let something like this slip through...

Re:This Isn't Really A Microsoft Story.

Exactly my point also. If someone posing as a Microsoft employee would write you a bad check, would you then post a story saying that 'Microsoft has a bad credit history' or something similar? I'm exaggerating here a little but you get the idea.

For some reason /. is assuming that Nerd=='someone who hates MS' and News for Nerds==Microsoft-bashing, using any means possible?

Get a life and realize that there are actually many many pro-microsoft (or at least neutral) geeks out there also, who would sometimes rather like to read something where the primary goal would be to tell people about some interesting/cool stuff done by MS, not just bashing. Right now you are just missing all these potential readers who are getting news from more balanced sources elsewhere. Don't get me wrong, I think /. is very cool but it's really harming itself more this way.