We recently received two malicious utilities that appeared to be digitally signed using a valid Adobe code signing certificate. The discovery of these utilities was isolated to a single source. As soon as we verified the signatures, we immediately decommissioned the existing Adobe code signing infrastructure and initiated a forensics investigation to determine how these signatures were created. We have identified a compromised build server with access to the Adobe code signing infrastructure. We are proceeding with plans to revoke the certificate and publish updates for existing Adobe software signed using the impacted certificate. This only affects the Adobe software signed with the impacted certificate that runs on the Windows platform and three Adobe AIR applications* that run on both Windows and Macintosh. The revocation does not impact any other Adobe software for Macintosh or other platforms.
Sophisticated threat actors use malicious utilities like the signed samples during highly targeted attacks for privilege escalation and lateral movement within an environment following an initial machine compromise. As a result, we believe the vast majority of users are not at risk. We have shared the samples via the Microsoft Active Protection Program (MAPP) so that security vendors can detect and block the malicious utilities.
Customers should not notice anything out of the ordinary during the certificate revocation process. Details about what to expect and a utility to help determine what steps, if any, a user can take are available on the support page on Adobe.com.
The first malicious utility we received is pwdump7 v7.1. This utility extracts password hashes from the Windows OS and is sometimes used as a single file that statically links the OpenSSL library libeay32.dll. The sample we received included two separate and individually signed files. We believe the second malicious utility, myGeeksmail.dll, is a malicious ISAPI filter. Unlike the first utility, we are not aware of any publicly available versions of this ISAPI filter. More details describing the impacted certificate and the malicious utilities, including MD5 hash values for the files, are included in the Adobe security advisory.
In addition to working with your security vendors to ensure you have the latest updates containing protections against these utilities, system administrators for managed desktop Windows OS environments can create a Software Restriction Policy (SRP—via Group Policy) that disallows the execution of the malicious utilities and blocks them on the basis of the individual file hashes.
Our internal testing indicates that moving the impacted Adobe certificate to the Windows Untrusted Certificate Store does not block threat actors from executing the malicious utilities on a victim machine. However, this configuration does have a negative impact on the user experience and execution of valid Adobe software signed with the impacted certificate. Adobe does not recommend using the Untrusted Certificate Store in this situation.
Adobe Code Signing Infrastructure
The private keys associated with the Adobe code signing certificates were stored in Hardware Security Modules (HSMs) kept in physically secure facilities. All entities authorized to request digital signatures were provisioned according to an established procedure that verified the identity of the entity and verified that the release engineering environment met the relevant assurance criteria. All code signing requests were submitted via mutually authenticated Transport Layer Security (TLS) connections to the code signing service and were performed only if the requesting entity came from the originally provisioned IP address.
Within minutes of the initial triage of the first sample, we decommissioned our signing infrastructure and began a clean-room implementation of an interim signing service for re-signing components that were signed with the impacted key after July 10, 2012 and to continue code signing for regularly scheduled releases. The interim signing solution includes an offline human verification to ensure that all files scheduled for signature are valid Adobe software. We are in the process of designing and deploying a new, permanent signing solution.
Compromised Build Server
We have identified a compromised build server that required access to the code signing service as part of the build process. Although the details of the machine’s configuration were not to Adobe corporate standards for a build server, this was not caught during the normal provisioning process. We are investigating why our code signing access provisioning process in this case failed to identify these deficiencies. The compromised build server did not have rights to any public key infrastructure (PKI) functions other than the ability to make code signing requests to the code signing service.
Our forensic investigation is ongoing. To date we have identified malware on the build server and the likely mechanism used to first gain access to the build server. We also have forensic evidence linking the build server to the signing of the malicious utilities. We can confirm that the private key required for generating valid digital signatures was not extracted from the HSM. We believe the threat actors established a foothold on a different Adobe machine and then leveraged standard advanced persistent threat (APT) tactics to gain access to the build server and request signatures for the malicious utilities from the code signing service via the standard protocol used for valid Adobe software.
The build server used a dedicated account to access source code required for the build. This account had access to only one product. The build server had no access to Adobe source code for any other products and specifically did not have access to any of Adobe’s ubiquitous desktop runtimes such as Flash Player, Adobe Reader, Shockwave Player, or Adobe AIR. We have reviewed every commit made to the source repository the machine did have access to and confirmed that no source code changes or code insertions were made by the build server account. There is no evidence to date that any source code was stolen.
The revocation of the impacted certificate for all code signed after July 10, 2012 is planned for 1:15 pm PDT (GMT -7:00) on Thursday October 4, 2012. To determine what this means for current installations and what corrective steps (if any) are necessary, please refer to the support page on Adobe.com. The certificate revocation itself will be included in the certificate revocation list (CRL) published by VeriSign; no end user or administrator action is required to receive the updated CRL.
Through this process we learned a great deal about current issues with code signing and the impact of the inappropriate use of a code signing certificate. We plan to share our lessons learned as well as foster a conversation within the industry about the best way to protect users and minimize the impact on users in cases where the revocation of a certificate becomes necessary (as in this example). Please stay tuned for more details in the coming weeks.
* Adobe Muse and Adobe Story AIR applications as well as Acrobat.com desktop services