Adobe confirms targeted attack on digital certificate code signing infrastructure
Adobe releases patches for critical vulnerabilities in Flash, Shockwave and Photoshop
Adobe has announced that it was the victim of a targeted attack that accessed an internal server and confirmed its digital certificate code signing infrastructure was hacked, but Flash, Reader, Shockwave and Air were not impacted.
According to a statement by Adobe senior engineering director Brad Arkin, Adobe became aware of the attack after it received two malicious utilities that appeared to be digitally signed using a valid Adobe code signing certificate.
Arkin confirmed that the impacted certificate runs on the Windows platform and three Adobe Air applications that run on both Windows and Macintosh, and that its revocation will not impact any other Adobe software for Macintosh or other platforms.
It has now decommissioned the existing Adobe code signing infrastructure and as of yesterday, has issued an advisory revoking all software code signed after 10th July 2012.
He said: “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.”
Arkin confirmed on Twitter that Adobe received the pwdump7 sample on 12th September leading to the investigation. He also said that the three known bad files that were signed with the impacted certificate occurred on 25th and 26th July.
He said that a forensic investigation is underway, but its 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 and this could have a negative impact on the user experience and the execution of valid Adobe software signed with the impacted certificate. Therefore it does not recommend using the Untrusted Certificate Store in this situation.
Arkin said that the private keys associated with the Adobe code signing certificates were stored in hardware security modules (HSMs) kept in physically secure facilities, and all entities authorised 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,” he said.
“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 10th 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.”
A build server was identified as being compromised. This required access to the code signing service as part of the build process and this was not caught during the normal provisioning process. Arkin said that 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.
In its ongoing forensic investigation, Arkin said that Adobe has identified malware on the build server and suspected that this was the likely mechanism used to first gain access to the build server. He also said that Adobe has forensic evidence linking the build server to the signing of the malicious utilities but could 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,” he said.
“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. There is no evidence to date that any source code was stolen.”
The next stage is a complete revocation of the impacted certificate for all code signed after 10th July 2012, this is planned for Thursday 4th October.
Mikko Hypponen, chief research officer at F-Secure, said that it had "thousands of clean, official Adobe files signed with the compromised certificate", but only three were deemed to be ‘bad files'.
Andrew Storms, director of security operations for nCircle, said: “Adobe acknowledges they have found two different pieces of malware using one of their code-signing certificates. One steals passwords and the second will modify ISS servers. The implications of a breach this serious are staggering. Adobe will be cleaning up this mess for a long time.”