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'm not experienced in code signing but I was thinking about this: as you know, there are various tools for self-signing digital certificate generation (as makecert from Windows or OpenSSL). Now, It would be great if a malware developer could sign his malware's code from a trusted CA. He can only sign it in two ways:

  1. Pays a trusted CA to generate a certificate with wich he will sign his malware;
  2. Creates a self-signed certificate where, for obvious reasons, the authority that release the certificate is equal to the subject's name

Particularly, the second point regards my question: if the algorithm to generate a digital certificate is known, I could write my own certificate generator to sign my application, where the Issuer is a well known CA's name; then I add the newly generated cert in the Trusted Root Certificate Authority (in Windows OS). Now, when someone opens the application, the certificate is installed in the TRCA and then the malware starts. The malware is signed from the certificate that has just been added and it seems that it comes from a well known source due to the CA's name. I know that, if it could be possible, the CA and all the cryptography stuff wouldn't exist and it would be very simple to generate a certificate on my own where the releaser is a CA. So my question is: why there's no way to generate a self-signed certificate where the Issuer is different from the Subject?

share|improve this question

3 Answers 3

up vote 3 down vote accepted

Yes, you can make a self-signed certificate with any subject name you want. It's easily doable with free tools. Getting a signing certificate with a fake subject name signed by a truthworthy issuer is another story - they take verification of identity fairly seriously.

Another thing that isn't easy (in fact assumed to be impossible) is to figure out the private key of the legitimate CA. So if you are faking a CA, you'll most likely end up making up a new public/private key pair and signing that. Any entity that explicity trusts a specific public key will NOT trust your fake CA (true for the MS certificate store).

What you cannot do - easily - is modify the Trusted Certificate store on a computer that you don't already have access to. This isn't an operation that is available from most web browsers - it takes at least user-level access, although some operating systems can be restricted further to administrator level access. In essence, to extend the realm of trust, you yourself must be trusted.

Which begs the question - if you've gotten access at this level to a machine - why bother signing the malware? Just install it and save yourself the headache of doing code signatures.

There, are, however two really interesting attacks in this area:

  • Social Engineering - in many cases, when a user is browsing, the browser will prompt the user when an unknown CA is encountered - the user is asked to explicitly trust the signer, and if the user has the capability, the option is there to install the CA certificate as a trusted CA. So... there's all sorts of ways of setting up a site to helpfully advice the user to trust you.

  • If it's not validated properly, you have a problem - the big famous one was FLAME, which used a fake Microsoft signing certificate - it wasn't validated properly and many servers did, in fact, upload malware.

Not the easiest attack - you really have to know a product and how it's doing certificate validation to get something like this through - but bad design/implementation can lead to flaws, so it's mostly about how much time the attacker can spend to find the hole.

share|improve this answer
    
As you said, thanks to @AJ, I've found a way to become a private CA. If I declare myself as Verisign, for example, I generate a new pair of public/private keys to sign other certificates (and check CSR). Now I should create a new CSR and ask my "own" Verisign CA to sign it. Now I've got that Subject/Issuer differs, but the problem remains to add my own CA to the MS store. You're right about the headache of the signing stuff but even with admin access there are firewalls on the machine that could block your not signed malware. –  Angelo Jul 9 '13 at 16:54
    
I was rereading your answer and paid particular attention to this: "Any entity that explicity trusts a specific public key will NOT trust your fake CA (true for the MS certificate store)." Do you mean that, when something (a firewall?) checks for the certificate of some application, it looks for a public key match in its database and not in the MS Store? –  Angelo Jul 9 '13 at 22:12
1  
@Angelo - The MS store is a construct of any machine running a Windows operating system. It's used primarily by Microsoft made products - Outlook, IE, etc. - I'd have to check, but I believe servers like IIS may have their own store, or a special area within the store. Products like Firefox, or devices like firewalls use an equivalent system for root CA certs. From here, it's got a lot to do with the implementation - the standard process is to check the total certificate - like a hash - which includes the public key, but get a specialized and custom product and I wouldn't guarantee it. –  bethlakshmi Jul 10 '13 at 1:11
    
My thoughts was that any anti-malware product checks the Microsoft Store for the public key comparison. Think about that: if they've got their own certificate database, it means that they need to check it online (and you are "secure" only if online). Maybe it could be possible to download the "personal" database of certificates and compare on the offline db. I still don't understand how firewalls/antivirus manage digital sign checks. –  Angelo Jul 26 '13 at 11:53
    
This gets bigger than a comment stream will handle - "how firewalls/antivirus manage digital sign checks" - are easily at least two questions that worth posting or researching separately in this forum. I'll tell you based on experience, that how you store the certs, where you store the certs, and whether you depend on them online or off are serious parts of any PKI design and are a part of how you envision risks, vs. cost/challenges of configuration. Most security devices will fail closed, so rather than security risk, you have operational risk from a device who can't find it's trust store. –  bethlakshmi Jul 26 '13 at 19:04

This is by definition. A self-signed certificate is signed by the subject itself. This means a self-signed certificate is defined by having the same entry as issuer and subject.

As you ask for a certificate where the issuer is different to the subjet this is by definition not a self-signed certificate.

Also know that you cannot fake the issuer as the certificate is signed by the issuer and that means you need the private key of the issuer.

share|improve this answer
    
So, your answer brings to me another question: is it possible to become a CA (self-CA?) and then sign my own certificate by asking a Certificate Signing Request to the CA that I've just created? –  Angelo Jul 9 '13 at 13:30
    
@Angelo please create a new question out of this. –  Uwe Plonus Jul 9 '13 at 13:33
    
@Angelo or just look at this question, the short answer is yes, you make your own self signed root certificate and add it to the trusted root certificate repository of any computers that need to trust it. Any certs signed by that cert are then trusted as well. –  AJ Henderson Jul 9 '13 at 15:18

There is nothing that prevents you from saying you are anyone you want in a self-signed certificate. What keeps it secure is the signing itself. Verisign isn't identified by it saying in text that it is signed by Verisign. It is identified as being Verisign because users's computers come with a Trusted Root Certificate for Verisign which is used to verify the signature that Verisign places on the certificates they sign. The text is just there to aid looking up the certificate on the client so that the signature can be verified.

So in your case where you say "I'm verisign" and sign it yourself, a client that tries to validate the signature goes and looks up their Trusted copy of Verisign's cert (because that's what the signer is identified as) tries to validate the signature and the signature validation fails because you don't have Verisign's private key.

share|improve this answer

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.