Summary: This post goes over how attackers could use search engines to find and abuse legitimate code-signing certificates. With this technique, I was able to find a valid code-signing certificate belonging to a leading tech company and disclosed it to them.

This isn’t particularly novel but I’m writing this to raise defensive awareness that abusing code-signing certificates is not limited to well-resourced attackers.

Background

Stuxnet was known for signing its malware with legitimate certificates stolen from two Taiwanese semiconductor companies (both of which happened to be headquartered in the same industrial park). Signing the malware certainly didn’t make it any safer, but it helped systems establish trust. Some security products may overlook signed binaries as part of their heuristics, and Office products can be configured to allow signed macros.

This causes a substantial breach of trust because certificates are supposed to assure users and systems that the software was developed by the organization named in the certificate and that it hasn’t been modified by anyone else.

There a few ways to obtain certificates while concealing one’s identity:

• Falsify Requirements, which involves mimicking legitimate companies. This can get more difficult depending on the certificate authority.
• Cryptographic Attacks, as was done with Flame which forged Microsoft signatures or the “CurveBall” vulnerability (CVE-2020-0601) in the Windows CryptoAPI system. This type of attack is usually expensive to develop and prohibitive to most attackers.
• Compromised Certificate Authorities, which appears to have become more prevalent according to researchers from Masaryk University and Maryland Cybersecurity Center.
• Stealing from Legitimate Organizations, which could involve operations to infiltrate enterprises, pivot to where they are being safeguarded and perform extraction.

Code Search Technique

Certificate extraction missions from internal corporate networks have been popularized, but are not necessary if an attacker is looking to just get any valid certificate they can use for a period of time. To that end, attackers can take advantage of the fact that valid certificates tend to be inadvertently committed to public repositories from time to time.

Using GitHub as an example, one way to find Authenticode certificates could involve:

1. Searching across all repositories for “signtool”, sorting by recently indexed.
2. Filtering for repositories that contain PFX or P12 files.
3. Filtering further for signtool command lines using a hardcoded password (/p option).

Further optimizations and variations could be made. Using the API could automate this process to a degree, or at least make it easier to sift through a shortlist of candidate repos. That said, even with the growing scale of content to sift through, finding a valid certificate is still rare.

Using the technique above, I was able to find a certificate issued to a leading OEM company which was still valid at the time. It appeared to be on a user’s personal account. I reported the issue to their security team and the offending repository was quickly removed.

Disclosure Timeline

• 2020-04-23: Reported issue and received acknowledgement.
• 2020-04-24: Offending repository was removed and received confirmation.

Conclusion

Although an attacker using this technique won’t get their pick of the litter, finding at least one valid certificate should be enough for many use cases. The process is repeatable and the cost is low.

There isn’t a perfect search query to find all certificates, which also means there isn’t a perfect defence against this problem. As some certificates get removed or revoked, others will inevitably surface over time. Responsible organizations should continue to be proactive in safeguarding their certificates, and should also consider options for monitoring abuse.

Thank you to @MastemaSec, @JT_InfoSec, Geoff H., and Lincoln for their reviews and feedback.

References

• What Is Code-Signed Malware and How Do You Avoid It?