Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I've noticed that in order to 'illegally' crack certain applications, it is necessary to patch the host file to stop communication with the activation servers.

I've found that with several applications there are entries that don't match the rest. These entries seem to patch the certificate revocation lists (CRL) for Verisign which i find to be quite suspicious.

The entry in question is:

127.0.0.1 crl.versign.net

Obviously the CRLs don't have anything to do with the application cracking process (so far as i can tell). Is there a malicious reason to do this?

share|improve this question
    
As a side note, I just checked the application, and yes, it appears that the original DLL is signed by verisign while the cracked DLL is indeed flagged as invalid. I have tested patching the hosts file without the CRL line and I haven't encountered any issues however. –  NULLZ Apr 29 '13 at 0:00

1 Answer 1

up vote 2 down vote accepted

Some operating systems, including Windows, want to enforce verifications of signatures of DLL. The verification entails validating the signature against the signer's public key, which is found in the signer's certificate, which itself needs to be validated. Certificate validation includes revocation status check.

In practice, a Windows OS validating a certificate will download CRL to ascertain that the certificate is not revoked. However, if the same OS cannot download the CRL, then it will just assume that the certificate is probably unrevoked. According to the normal X.509 model, when revocation status cannot be obtained, the certificate should be rejected. However, this means here that the application does not start, and the consumer will be unhappy (that is, significantly unhappier than what is already entailed by using Windows); and it would mean that the machine cannot work without a working Internet connection, which would imply some interesting chicken-and-egg issues.

So adding an entry which prevents connections to Verisign's CRL download server can have a malicious reason: this allows the attacker to sign his nefarious code with a revoked certificate (e.g. a certificate whose private key has been stolen by the attacker some time ago), while still maintaining a working Internet connection for the said machine.

share|improve this answer
    
Does that mean any stolen/known malicious certificates that are revoked are revoked by the original CA only? –  NULLZ Apr 28 '13 at 13:33
    
Well, yes, mostly. Revocation in X.509 is done either by the CA itself, or by a CRL issuer which is designated by the CA (the CRL issuer name is specified in the target certificate) and which also has a validated certificate (this is called indirect CRL issuing and it is rather rare because deployed implementations have only poor support for it). –  Thomas Pornin Apr 28 '13 at 13:42
    
Alright, are there ever any instances where another CA would also provide the CRL of a different CA then? Once you machine downloads a CRL, does it care where it came from? –  NULLZ Apr 28 '13 at 14:27
    
A CRL is signed precisely so that the way it was obtained is irrelevant. Like certificates, they can be delivered with avian carriers if need be; it does not matter. CA 1 signing a CRL for CA 2 may occur only if CA 1 agrees with it; CA 1 "agrees" by including in the certificates issued by CA 1 a specific extension which designates CA 2 has an allowed issuer for CRL covering the certificate (but, in practice, CA rarely do that). –  Thomas Pornin Apr 28 '13 at 14:41
    
Awesome, thanks! One last question. Do things like 'windows update' update CRLs? I remember the stuxnet incident where verisign blacklisted the certs, but apparently Microsoft did as well? How does that work exactly? Are they just ensuring that the verisign blacklist gets pushed through via win-updates? –  NULLZ Apr 28 '13 at 23:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.