3

Several dominant software vendors distribute updates over HTTP or over HTTPS with bad certificates. In general, it doesn't seem like I can expect to rely on a secure channel to ensure that an installer is not tampered with in transit.

It looks like all of the installers have valid signatures. This is a typical screen when I check the properties of an installer file:

enter image description here

The operative part of the dialog box is "This digital signature is OK." What is not clear is what portion of the file the signature is attesting to. You would expect this to be all of the file, but I haven't found a statement from Microsoft confirming that. I also vaguely recall a tweet rumoring that only parts of a file are attested to by a code signing signature.

  1. What parts of a file are checked by windows when checking whether a code signing signature is "OK"?

  2. Are there known third-party attacks that use correctly-signed installers from a trusted second party as a vector?

4

The signature is of a hash of the portion of the executable before the code signing block. Best practice is to have both the installer and the application signed.

You can study some details by looking at this:
https://msdn.microsoft.com/en-us/library/windows/hardware/gg463180.aspx

EDIT: OK, now that I'm off the mobile device and on a real keyboard, I can elaborate.

As noted in the document to which I referred you, the hash that gets signed is generated as to the entire executable file except for two excluded portions (a) the total file checksum; and (b) the certificate tables. These cannot be incorporated into the hashing because of the chicken or egg problem (e.g., these fields are dependent on the content of the attribute certificate table, and thus their values are not fixed until the certificates/signatures are prepared and appended).

As for the attack surface/scenarios, we see once again why it is so important to have good crypto primitives, and ALSO to use best practices. I suppose that in theory an attacker could create a malicious version of a software application, and then roll it into an installer and include some carefully calculated data to generate a hash collision with an existing real MD5 certificate from the application vendor, attaching that existing certificate/signature to the compromised executable. If you only checked the installer you might get fooled. This is why MD5 cannot be trusted for this sort of application anymore. It is also why, in addition to checking the installer, you should check the application program itself.

Windows 7 accepted MD5 hashes for code signing, whereas Windows 8 and up requires SHA1 or better. (For what it's worth, I dug around my program files and old installers just now and only found one from 2008 or so that used MD5 for the signature hash. 2nd edit: I take that back, I also found a relatively recent version of Winzip using MD5).

  • You also have a trust issue. Is "Adobe Systems, Incorporated" actually the Adobe Systems you expected to sign this file, or did someone get a CA you trust (or rather, Microsoft has decided you trust) to issue them a certificate with that name? Theoretically, an attacker could substitute in their own file signed with their own digital certificate, and provided their certificate is signed by a trusted CA, it will look legit (to most people). Would you notice (and realize) if the name was "Adobe Software LLC" that it was not the right name? "Trusted Software Updates"? – gregmac Feb 11 '15 at 18:07
  • Its a really good point. The role of CA crucial, because if they're authenticating impersonators' credentials the whole exercise is for naught. However, I suppose one could mitigate that scenario by collecting a series of files from the application provider and comparing the certificate serial numbers. If every Sony installer certificate you find says "Sony Corporation" and bears serial no. ‎17a772242e77a4970d746713723f6029, it would be suspicious to find one installer from the same era using "Sony Corp." with a different CA and some other serial no. – boggart Feb 11 '15 at 18:14
  • I'm using a script to automate download and validation, so I suppose I could fairly easily assert that the publisher and chain of trust remain the same. I wonder how consistent the certificates used to sign code actually are from update to update. – alx9r Feb 12 '15 at 1:28
0

There is a difference between the certificate signature and the signature made with the certificate.

The former, which is valid, means that the Certificate Authority says the certificate you have is a legit certificate they have controlled, and the CA signature integrity allows you to check the certificate has not been tampered with. Therefore if you trust the CA, then you can trust the certificate of the site.

The latter is used to start the TLS transactions and exchange a shared key for symmetric encryption of the current session. If the handshake is able to complete, it means that the site you are communicating with owns a copy of the private key related to the certificate. But, if there is a mismatch of the domain name on the certificate and the address you are connecting to, it could mean:

  • that the website is a subsidiary of the certificate owner, and he did not bothered to have a certificate for the new domain
  • that the website stole the private key of the legitimate owner

In conclusion, such a mismatch should lead to rejection of the communication as you have no means to ensure to with whom you are talking to.

  • 1
    This answer seems to speak to TLS communications. The question is about signed files. Can you explain how this applies to the question? – alx9r Feb 11 '15 at 16:19
  • TL;DR: the answer is applicable to <put whatever you want to sign here>. I did not noticed the mention to "files" in your question, my bad. But the explanation remains the same. In the case of files, the file will be signed by the private key linked to the certificate (instead of the TLS handshake). I talked about TLS specifically as your second link targets a file identified by a https. Certificates are still signed by a CA to authenticate them, and you use the certificate private key to sign whatever you want. – M'vy Feb 11 '15 at 16:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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