Missing signers in 2a84e6d95753c01725ce5e472aaec03b3001d81760aa88f8f393047fc7e55958

[gdesmar]

Describe the bug
Analyzing sample 2a84e6d95753c01725ce5e472aaec03b3001d81760aa88f8f393047fc7e55958 gives us a single signature with a single signer. Looking at the details of the file in Windows gives us 3 signers (I believe in a single signature).
The serial number of the signer found by LIEF is 013c6684e0f39030c05fa36b42af33ca, and windows gives us those three : 013c6684e0f39030c05fa36b42af33ca, 0a91f3b6841e24786ba268d145dca144 and 92712d7bf7f5bb8e44621813f38a2596.

To Reproduce
Download the attached 2a84e6d95753c01725ce5e472aaec03b3001d81760aa88f8f393047fc7e55958.zip file (password: lieftest) containing the sample or download it from https://www.virustotal.com/gui/file/2a84e6d95753c01725ce5e472aaec03b3001d81760aa88f8f393047fc7e55958.

Make sure the resulting file has the right hash :

$ sha256sum 2a84e6d95753c01725ce5e472aaec03b3001d81760aa88f8f393047fc7e55958*
2a84e6d95753c01725ce5e472aaec03b3001d81760aa88f8f393047fc7e55958  2a84e6d95753c01725ce5e472aaec03b3001d81760aa88f8f393047fc7e55958
9beb38b8f8f234378c740bc87003b9375894e7952c8af4764277dc104728fdc9  2a84e6d95753c01725ce5e472aaec03b3001d81760aa88f8f393047fc7e55958.zip

Check the number of signers and associated serial numbers for easy comparison :

>>> import lief
>>> lief.__version__
'0.12.0-cb9e43c7'
>>> b = lief.parse("2a84e6d95753c01725ce5e472aaec03b3001d81760aa88f8f393047fc7e55958")
>>> len(b.signatures)
1
>>> len(b.signatures[0].signers)
1
>>> b.signatures[0].signers[0].serial_number.hex()
'013c6684e0f39030c05fa36b42af33ca'

The result is the same with LIEF version 0.11.5-37bc2c9.

Expected behavior
I would expect to see 3 signers, or 3 signatures. I don't know exactly how it is built, but I expect to be able to find the two missing serial numbers (and all other associated information) somewhere in the signatures structure.

Environment :

• System and Version : Ubuntu 18.04
• Target format : PE
• LIEF commit version : 0.12.0-cb9e43c7

[romainthomas]

Hi!

Thanks for the sample. I had a quick look and it seems not trivial to fix.
I don't know if the issue comes from the un-supported Ms-CounterSign (1.3.6.1.4.1.311.3.3.1) or if issues is located in the parser of the signers. Nevertheless, the x509 certificates are parsed independently of the Authenticode's signers so you should be able to access the serial_number by iterating over the certificates

[gdesmar]

Thanks for the update and a bit of explanation on what may be happening!

If you are referring to the certificates located in the signature, here are the results :

>>> [x.serial_number.hex() for x in b.signatures[0].certificates]
['0d424ae0be3a88ff604021ce1400f0dd', '013c6684e0f39030c05fa36b42af33ca', '0aa125d6d6321b7e41e405da3697c215', '02c4d1e58a4a680c568da3047e7e4d5f']

Sadly, those are not the certificates of the other signers/countersigners.

I was talking about the serial number at first, but I am interested all other associated information too. It was just an easier way to check what was present and what wasn't without bloating the ticket too much.

Based on the Windows certificate information, the first signer (JSC SHA1) is a chain of 3 :

02ac5c266a0b409b8f0b79f2ae462577
-> 02c4d1e58a4a680c568da3047e7e4d5f
->-> 013c6684e0f39030c05fa36b42af33ca

Then JSC SHA256

02ac5c266a0b409b8f0b79f2ae462577
-> 03f1b4e15f3a82f1149678b3d7d8475c
->-> 0a91f3b6841e24786ba268d145dca144

And the simple SHA256 is by itself

92712d7bf7f5bb8e44621813f38a2596

The other two certificates found in the first signature, first signer (0d424ae0be3a88ff604021ce1400f0dd and 0aa125d6d6321b7e41e405da3697c215) are probably providing a code signing timestamp.

C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Assured ID Root CA
    C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 Assured ID Timestamping CA (0aa125d6d6321b7e41e405da3697c215)
        C=US, O=DigiCert, Inc., CN=DigiCert Timestamp 2021 (0d424ae0be3a88ff604021ce1400f0dd)

Thank you very much for looking into it.