The cryptography and algorithms used to protect computing systems are strong in theory, but even the strongest cryptography is still vulnerable to implementation issues and rubber hoses. Even after investing a significant amount of time securing a public key infrastructure (PKI), a vulnerability can bring the complete infrastructure into question. This principle was highlighted when an attacker disguised malicious code as a legitimate Adobe software update by signing the malware with Adobe's certificates. In this tip, we'll provide an analysis of the attack on Adobe to understand the security issues posed by Adobe certificates and some steps enterprises can take to protect themselves.
Adobe revoked the certificate in question, but this response will not solve all of the security vulnerabilities exploited in this attack.
Adobe attack analysis
The attack on Adobe is one of several attacks involving the use of maliciously signed software. Both Stuxnet and Flame utilized stolen or valid certificates to sign malware in an attempt to evade potential Windows defenses. Due to Adobe's security certificate issues, the attackers were able to sign malicious software with Adobe's digital code-signing signature, making the malware appear to be legitimate Adobe software. According to Adobe security chief Brad Arkin, Adobe revoked the certificate in question, but this response does not address all of the security vulnerabilities exploited in this attack.
Adobe used a hardware security module (HSM) to better protect the certificates in use for signing their software. HSMs can provide high levels of security to protect private keys and higher performance for certain types of cryptography, but HSM implementations do pose security challenges, particularly concerning how the private key is accessed. They typically offer several different options for controlling access to the private key, including password protection, two-factor authentication (biometric, smartcard, etc.) and split-key authentication. However, each option involves a different tradeoff for implementation and security. For example, in order to automate certain cryptographic operations, such as signatures, some HSMs allow these functions to execute without the use of a password. This set up requires other compensating controls to prevent access to the HSM. Adobe most likely used this password-free option in its software build process to sign files, enabling the attacker to sign malware with Adobe certificates.
Enterprise mitigations for malicious Adobe-signed software
The same protections I recommended implementing in the wake of the Flame malware attack can also be used to defend against malicious Adobe-signed software: Antimalware software can be used to block the malicious update, Windows can be configured to only execute signed software, or whitelisting can be used to help avoid compromise. Also, maintaining the basic protections of running as a limited user and keeping software updated will help minimize the chances of a complete compromise. Enterprises with network devices that can scan downloaded files for malware can also have them check for software signed with revoked certificates. A revocation check can also be performed on downloaded signed software, but this may not be the default configuration for all patch management software. Enterprises could also check hashes received from official sources on the signed software, but a knowledgeable attacker could potentially forge these, too.
From the editors: More on PKI security
Assess the security of the PKI components in an AMI network.
Is PKI still a trusted method of protection?
Adobe's compromised security certificates could have been more serious for users that automatically install updates, since the update looked legitimate and therefore would automatically be installed on unsuspecting systems. This could potentially evade any whitelisting protections that allow Adobe updates. An old version of Adobe Reader still poses a greater risk than a malicious Adobe-signed update because Reader's security is compromised routinely, and deploying malware through the Adobe update process is unlikely. Other software makers might not take the expensive steps Adobe did to use an HSM, but they are all vulnerable to attacks on their infrastructure.
Simply put, while PKI is complex and difficult to do correctly, it must be simple for end users, and it is critical to the security of the computing ecosystem. Given these competing requirements, enterprises should expect PKIs to be compromised, and in turn they must have a response plan at the ready to minimize the risk to the enterprise, its customers and users. Adobe has made significant advancements with its software security development lifecycle and took reasonable security precautions by using an HSM but, as this incident demonstrates, if an attacker gains privileged access to the infrastructure, this access can be leveraged to compromise the system.
About the author
Nick Lewis, CISSP, is an information security architect at Saint Louis University. Nick received his Master of Science in information assurance from Norwich University in 2005 and telecommunications from Michigan State University in 2002. Prior to joining Saint Louis University in 2011, Nick worked at the University of Michigan and previously at Children's Hospital Boston, the primary pediatric teaching hospital of Harvard Medical School, as well as for Internet2 and Michigan State University.