If a file is signed does that mean it is clean?

A. something utterly idiotic: I cannot read your mind, please write what you think.

or
B. something that makes sense: I cannot read your mind, please write what you think.

or
C. All of the above: I cannot read your mind, please write what you think.

P.S: I do not know mind reading, even though I'm fluent in three languages; none of them has given me the ability to read minds, yours included.

Thanks.

 

Can I ask you something? If you do not know of any other solutions, fine. Therefore, let this be your last post on the subject, please.

Thanks.

 

Hi Guys

Here a similar example of a malware that steal certificate to deliver their payloads. Yesterday I was testing CIS v5 the latest beta and I have encountered a trojan that bypassed CIS and install itself without any warning from D+. Thus CIS mistakenly place the trojan in the category of trusted vendors. In other words the trojan had carte blanche to do whatever it pleases.

At first I thought it was a bug from CIS since the new version is still in beta. But today upon careful investigation after I went through the TrendMicro blog I realized that it was actually a trojan that disguised itself as having a certificate from Kaspersky Labs. I think that someone else from the Comodo forums was confronting the same issue. Here is the ~ Virus Total Results Removed per Policy ~

Furthermore:

Here is Prevx input of the file:

Vendor, Product and Version Information

A file with the name TIYTL.EXE have been seen to have the following Vendor, Product and Version Information in the file header:

* Kaspersky Lab; Njp; 9.3.4.2
* Kaspersky Lab; VeriSign Class 3 Code Signing 2004 CA; {c}

Reference:

info.prevx.com:

http://info.prevx.com/aboutprogramtext.asp?PX5=E1E05A99E8D48207E7EC01869335B100B19B46F7

As of yesterday only 5 anti-virii detected the threat: AVG, DrWeb, NOD32, Panda, and Prevx.
Thanks.

 

Does the latest stable release of Comodo catch this?

 

No, unfortunately. It was the latest stable beta version that I used.

Thanks.

 

Not if they are checked they can't. No one has found a way to break the hashes (at least SHA-1 and greater). If you have info to the contrary, please provide it as some of the finest crypto minds in the world would love to hear about it.

It's true someone could create their own cert and claim it is from Microsoft Corporation, but it wont match the cryptographic fingerprint of the real MS cert. All that has to be done is to check it.

 

Uh, that certificate is invalid as it clearly says right on the screen. It has been revoked. Plain as day. Again, as long as the user checks the cert, there is nothing to worry about.

 

Exactly right. Thank you.

What's happening here is these AV companies are trying to scare users into believing that somehow digital signatures are flawed. They're not. They are only flawed if the user doesn't take 30 seconds to verify it.

 

Well then can someone explain this to me; how could a trojan go through CIS layered defenses, install itself, and got verified by CIS as a trusted vendor if the certificate that the trojan used was not valid? Maybe my first assuption was correct, but I doubt it.

I could assume that CIS may not be the only security vendor that may have fallen prey to the trojan's tricks. Moreover, like it or not, hate it or love it, Comodo Group is Certification Authority (CA) and to me that's make the matter even worst.

Thanks.

 

Yes au contraire, there are plenty to worry about. My questions are the following: 1) When was the theft discovered? 2) Was the certificate revoked before the theft? If the certificate was not revoked before the theft, therefore the trojan could have used the certificate to fulfill its nefarious deeds before the certificate got revoked. By then it would have been to late for the unfortunate computer users.

Malware writers would never use the stolen certificate for an unlimited amount time. To me, I think they would use it for the shortest amount of time and inflict as much damages as possible. Crying stop thief after the theft already occurred is counter productive. Also as soon as the theft is discovered they would turn around and steal another legitimate one; then the stop thief shouting match starts over again. In that context, preventing the theft is the best way to go. Now what would prevent such a theft not to occur in the future? Well let us all fuse our brains together and find out.

Thanks.

 

Because people at CIS are dumb and didn't properly vet the certificate. Anyone can generate their own certificates. Give me 5 minutes and I will go generate my own. CIS merely didn't check to see who the cert really belonged to. User error here.

Now, in the case of the Realtek and JMicron certs, what happened is someone on the inside stole the cert key or an outsider hacked the machine the cert key was being housed on and brute forced its passphrase. Either way, both are an example of carelessness by these companies. It's called key management and they did a horrible job of it.

For example, I have a public/private key-pair I use for digitally signing e-mail. If I was careless and failed to secure my private key with a strong passphrase and if my wife decided to divorce me and steal my private key, then e-mails not from me could be spoofed and signed with my legitimate key. There is no way for my contacts to defend against this sort of thing other than to watch out for key revocation. If, in my hypothetical scenario, my wife also stole my revocation certificate before I was able to send it to the key servers, I would be totally screwed. I would have to contact all of my contacts individually and tell them what's up and hope they believe me (likely this would involve face to face meetings). This is why it's so important to secure the private key and keep a revocation certificate handy (in a safe physical location away from any machine) in case you need to issue it. A better idea is to not allow the key to be compromised in the first place (the best way to do this is to use a strong passphrase so even if they key is physically stolen it does an attacker no good).

What I was talking about in my previous posts were nefarious people creating their own certs under false names and hoping end-users would not check to see if the cert's hashes matched the hashes from the real cert. This is a trick that some malware authors use in hopes that their cert "looks official" when it really isn't. Typically this issue is solved by the CA's signing the certs. If they sign them, this means they have vetted them (that's their job after all). How good of a job they do in vetting them is another issue. That's why I think the Web of Trust model is much better than the CA model.

The trojan has nothing to do with this. What has happened is someone at the CA failed to check to see if the cert really belonged to who was claiming it. It's also possible that someone stole the real certificate's key and then used it for nefarious purposes. Either way, user error is to blame, not the crypto itself.

All failures that have been discussed here can be summed up by one of three possibilities:

1) Realtek and JMicron are careless with securing the private keys.
2) The CA's are doing a lousy job of vetting who owns the certs
2) End users are careless and don't check sigs.

Either way, this is not a weakness in the technology itself, but a case of individuals being stupid and careless and not properly using the technology.

What would prevent the theft is using a strong passphrase on the private key. So even if someone on the inside were able to physically steal the key, he would have to know the passphrase to decrypt it. Otherwise it does him no good. Also, a revocation cert should be generated immediately after the keys are created and then it should be stored on removable media (CD, USB drive) and stored in a safe or something similar.

 

@Chromatic

You did not answer my questions. Here they are again:

1) When was the theft discovered? 2) Was the certificate revoked before the theft?

Thanks.

 

How am I supposed to know that? I would hope soon after it happened, but we can't know for sure. This is why its imperative not to let the damn keys get stolen in the first place. It isn't hard to do.

That's like asking was chemotherapy done on a man before he got cancer. I mean why would it be?

Hopefully these people aren't toally incompetent and did as I suggested in my previous post -- generate a revocation certificate upon the creation of the key-pair. Keep in mind that generating a revocation cert is different from issuing it. I have a revocation cert already generated for my key-pairs but I haven't issued them since my keys have not been compromised. Should they be compromised, I would issue it to my contacts and to the keyservers. My revocation cert is stored on a USB drive and the cert itself is encrypted with a very strong password I have committed to memory. It's the same with my keys -- they are protected by a strong passphrase, so even if they are physically stolen, the attacker wont be able to use them. The only way to compromise my keys is through rubber-hose cryptanalysis.

The key here (pun intended) is to not let the keys get compromised in the first place. This is not rocket science, folks. I am shocked how few people in this thread understand PKI. I recommend picking up one of Bruce Schneier's books. Applied Cryptography is excellent. You can also read about how PGP works here. Even though digital certs use the CA model and not PGP's WoT model, the underlying technology is exactly the same. That link explains the differences in WoT and CA's.

EDIT:

I just read through the first page of this thread and see that Windchild has already covered a lot of this. He is 100% correct in everything he said. Frankly, he, like me, is wasting his time trying to explain this stuff to people who have no idea whatsoever how PKI works. I'm not trying to be rude, just stating a fact. Go read the links I provided and get back to me.

 

I would like to extend my sincere appreciation for being frank and I couldn't agree more with you. As a matter of fact, I do not even think that the computer security companies know themselves, probably not even the CAs. That's the problem that we are facing, no one knows; and by the time the theft is discovered, then it is already too late.Maybe, just maybe thousands of computers have already been taken an unwilling tour at the bank of Nikolai.

http://www.everyclickmatters.com/dangers/bank-of-nikolai.html

The point that I was making in all of my posts on this thread was not about cryptography. Cryptography may not prevent a malware writer to steal a legitimate certificate and use it. It may prevent tampering for some time, since no code is forever unbreakable. Kaspersky would never say when the theft occured since such an admission would trigger an immediate follow-up question: Was the certificate revoked before the theft? The answer that Eugene Kaspersky would eventually provide is "no" and you said yourself: Why would it be?". No, in that context, implies that the prospective trojan can do what ever it wants since it has a legitimate certificate (not yet revoked) that will give it security clearance. Trojans you are free to come, for now at least or until your stolen legitimate certificate is revoked. That's where the problem resides.

Once again, at least to me, that's the bottom line of the F-Secure presentation that I referred to at the very beginning of the thread.

Thanks.

 

In addition, it is possible to split the key among two or more individuals, so that all must come together with their parts of the key for it to be rejoined and used (i.e., Blakely-Shamir key splitting). In this way, the theft of one individual’s key does not compromise the key in its entirety.

 

This conclusion is justified only if the adversary has stolen the private key from a trustworthy source (e.g., Microsoft or Symantec) and the digital certificate has not been revoked. I am not aware of any real-world cases in which these two conditions have occurred, resulting in a meaningful threat to users. Theoretically, it is possible; but there seems to be little merit in worrying about problems that do not really exist.

Note also that the word “valid” in the context of this thread has two possible meanings: (1) the digital certificate is not revoked, or (2) the digital signature (i.e., the decrypted SH1 hash of the executable file using the signer’s public key) matches the independently computed hash of the same file by the user (or by the user's anti-malware application). Even if the malicious executable file has a non-revoked legitimate certificate grafted onto it, the file will fail validation in the second sense of the term: i.e., the two hash values will not match, indicating that the file has been altered.

 

Correct, but I think we may differ in our perspectives on the likelihood of (1) a private key being stolen from (2) a trustworthy source that (3a) fails to detect the theft and (3b) fails to revoke the certificate. Again, it is theoretically possible; but in practice, to the best of my knowledge, it has never occurred.

Thus, the practicality of the problem is fundamentally a “tempest in a tea pot” -- but, a good and interesting intellectual discussion nonetheless.

 

Wow. I'm quite impressed. I wish I could discussed cryptography with you guys, but unfortunately I can't. Figuratively speaking any code can be broken if you apply the proper force based upon its design, shape and data flow.

Thanks.

 

All in all I'm quite happy we are having this exchange of information about that subject.

Thanks.

 

You have a sample of this trojan, correct? Then the question to ask is this: does the Kaspersky signature on the trojan check out as valid? If you have a sample of the trojan on your system, you can easily test this yourself. I'm sure readers would appreciate it if you would report back in this thread on whether the signature is valid or not. It's The question in situations like this.

If the signature checks out as invalid, then CIS is seriously flawed as it doesn't even bother to check signature validity. In such a case, users ought to demand CIS developers to fix their broken software. If the signature does check out as valid, you might have a case where someone actually stole Kaspersky's certification key (instead of just copying signature data from a legit file). If that actually happened, then that ought to seriously damage anyone's trust in Kaspersky as a security company. If they couldn't even protect their own confidential data, how could they ever protect their clients? Do note, though, that I'm not saying Kaspersky's keys got compromised. More likely it's just another copied signature, which is exactly what's described in that Trend Micro blog.

If we're concerned about legit developers like Kaspersky or Realtek being compromised and having their certification keys stolen, then there really aren't that many possible solutions. Obviously step one is for developers to take serious, responsible measures to secure their certification keys so they don't get stolen in the first place. Chronomatic already wrote about that subject. End-users can do nothing to protect developers who can't protect their own keys, but, end-users can at least refuse to trust such developers.

Problem is, if the code is any good, it may take more than the current age of the universe to break it.

 

Enjoying this thread

Why ? apart from the good info/ideas, it's nice to see that people can disagree, make errors, etc etc, and still continue to debate. Keep it up

 

I already said that I cannot talk of cryptography. However, you answer goes further to prove that you have no clue of what you talking about.

Thanks.

 

Well most threads are like that. Don't you agree?

Thanks.

 

Can you perhaps help me find some clue?

Also, what about the trojan with a Kaspersky signature on it, the one that got past CIS? Signature invalid? Valid? Don´t care?

Thanks.