8

For this file it shows SHA1:

.exe properties

But going into details the certificate looks like this:

details

I know SHA1 is an outdated algorithm but I'm not sure about this nested construction. Is this insecure? Which of the two parts matter, does it matter that one is SHA-384 and the other SHA-1 does it compromise it in any form?

0

3 Answers 3

12

The other answers correctly point out that SHA1 is not a watertight hashing algorithm: SHA1 is vulnerable to collision attacks. However, there are no known vulnerabilities to SHA1's preimage resistance nor second preimage resistance, which are properties regarding finding a hash collision for a specific hash/input (as opposed to finding a collision in two arbitrary hashes/inputs). So whether you can in practice trust this signature is down to whether its security relies on SHA1's resistance to collision attacks.

However, due to the certificate signing a specific SHA1 signature of an executable, collision attacks are not relevant. Collision attacks occur from the two hashes you're finding a collision in being free to change. This instead would require one to find a file which gives a SHA1 hash of the signed file's SHA1 hash—a much harder problem and one which SHA1 has no practical public attack for. Authenticode does not rely on collision resistance—only the preimage resistances.

So therefore, providing a malicious executable which has the same SHA1 hash as the SHA1 hash of the legitimate, signed executable is considered completely infeasible, and in practice you can consider this signature valid and the file safe.

As an additional note, SHA1 should still be phased out in software and libraries as it can be easy to unwittingly rely on a property of a hash function which you otherwise think you're not relying on. We should be ensuring that only hash functions with both preimage resistance(s) and collision resistance are supported going forwards in new software and updates. But this doesn't mean that, in this case, it's not providing the securiy guarantees desired.

5
  • 2
    Thanks for this addition, feel like that adds some important pragmatic context Jun 8, 2023 at 15:44
  • @StrahBehry No worries, glad it helps! I know I've added the answer a little late, but I personally didn't think the other answers were correct. They won't lead you astray, per se, but it's a bit more nuanced—as an end user it is certainly okay to use SHA1 authenticode signatures in 2023 (unless something changes in the next six months). And that will hold until a practical attack is found—as this is for an integrity check, a break found in 2030 wouldn't cause retrospective issues as one would have with e.g. an attack against symmetric encryption would do, with undermining confidentiality.
    – Alex W
    Jun 8, 2023 at 16:10
  • Excellent answer [+1] - especially for explaining that for code signing, it's the hash function's resistance to second preimage attacks that matters, not the function's resistance to collision attacks. But, the same is true for certificate signing, and SHA1 has been deprecated for use with certificate signing for almost a decade. Even though SHA1 is vulnerable to collision attacks (and not second preimage attacks) - the moment there are cracks in the foundation in any crypto algorithm, security people run.
    – mti2935
    Jun 8, 2023 at 20:14
  • 1
    @mti2935 Certificate signing is not supposed to be the same. Attacker can control about half the content of a certificate, so with a suitable collision between a legitimate cert body and a fraudulent one they can get the CA to issue the legitimate cert and then use that signature on the fraudulent cert. This was actually done in in 2009 for MD5 (which was broken for collision before SHA1 was) leading to rapid distrust and replacement of MD5-signed certs. When you sign code, supposedly it is code you wrote -- although nowadays almost nobody writes all their code and many don't write any, ... Jun 9, 2023 at 2:28
  • ... rather just copying things from repositories, websites (like SO), SDKs and other 'examples', and now AIs. An attacker could 'poisin' these -- this is called supply-chain attack and is now a major thing -- and get some devs to sign a program the attacker could then replace -- but why bother when they can just put malware directly in an update of a widely used component and build systems will automatically include it and sign it? Jun 9, 2023 at 2:33
11

It is not ok to use SHA1 authenticode signatures in 2023, they are not considered secure. Because of quite realistic SHA1 collision, the code might be tampered in the way that it will produce same SHA1 hash and it will look like the data was not tampered.

If you are the owner of this signature, you have to update your signing tools to use more secure algorithms, such as SHA256 or SHA384. If it was created by someone else, it may be reasonable to contact the owner and point to outdated signing practices.

Even if signed file is supposed to run on a systems where SHA2 is not supported, it is possible to attach multiple signatures, where first signature is SHA1 and another that uses SHA2 family: enter image description here

Speaking about different hashing algorithms, the signature hash algorithm has no connections to hash algorithm in certificate, they are completely independent things.

1
  • 3
    To expand on the last sentence there: The SHA2-384 hash in the certificate is used for the certificate's own signature (every certificate has a signature). It is unrelated to the certificate on anything else, whether or not the public key from that certificate validates the unrelated signature. The signatures on the certificate and on the external file can be completely unrelated algorithms, even (like, one might be SHA2-384-RSA, and the other might be Ed25519, if for example the certificate contained an Ed25519 public key but was issued by a CA that still uses RSA signatures).
    – CBHacking
    Jun 8, 2023 at 6:52
5

As for understanding the 'nested construction', it might help to understand the sequence of operations in this process:

  1. Phase to Phase created a key pair consisting of a private key and a public key.

  2. Phase to Phase created a certificate signing request (CSR) consisting of their name, the public key created in step 1, and other information pertaining to their organization, and sent this CSR to Sectigo for Sectigo to sign.

  3. Sectigo verified that the public key in the CSR that they received from Phase to Phase above in step 2 actually belongs to Phase to Phase. Then, Sectigo created a certificate containing this public key and other information from the CSR, then took a SHA384 hash of this certificate, then used their private key to sign the SHA384 hash. The result of this is the signed certificate whose image you posted.

  4. Phase to Phase took a SHA1 hash of their program Vision951.exe, then used the private key that they created in step 1 to sign the SHA1 hash.

  5. You downloaded Vision951.exe. To verify the integrity of this program, your OS used Phase to Phase's certificate (created in step 3 above). First, your OS verified that the certificate was signed by a certificate authority (CA) that it trusts (such as Sectigo). To do this, it verified the signature using Sectigo's public key. Your OS trusts Sectigo, therefore it trusts this certificate, therefore it trusts that the public key in this certificate actually belongs to Phase to Phase. Your OS then proceeded to extract Phase to Phase's public key from the certificate, then it used this public key to verify Phase to Phase's signature (created in step 4 above) on Vision951.exe.

So, there really is no 'nesting' here. Rather, a chain of trust is built, from the executable program; through the developer of the program (Phase to Phase); to the root of trust, which is the certificate authority (Sectigo).

All of the above is fairly typical, except for step 4. The SHA1 hash function is known to be vulnerable to collision attacks. Even though SHA1 has not been found to be vulnerable to second preimage attacks (which are really what matter when it comes to hashing for the purpose of signing, as pointed out in the answer by Alex W) - once a crypto algorithm shows any sign of weakness whatsoever, security people tend to run from it. See What are the implications of a SHA-1 collision being found? for more interesting reading on this subject.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .