Adobe, on Thursday 09-27-2012, delivered a public statement that an internal server with access to its digital certificate code-signing infrastructure was hacked by “sophisticated threat actors” engaged in “highly targeted attacks.”
Apparently the attack took place before July 11th, and it has led to the creation of at least two malicious files that were digitally signed using a valid Adobe certificate, according to Adobe security chief Brad Arkin.
Although it was reported that only two files were signed, the hack effectively gave the attackers the ability to create malware masquerading as legitimate Adobe software, and F-Secure’s Mikko Hypnonen stated today at 6:30pm that 5,127 files have already been submitted to F-Secure’s Malware Repository that were signed by the compromised Adobe certificate.
The initial report from Brad Arkin at Adobe mentions two digitally signed malware files: “PWdump7 v7.1” which is a well-known utility that extracts password hashes from the Windows operating system and is sometimes used as a file that statically links the OpenSSL library “libeay32.dll”. Arkin went on to say “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.”
Once Adobe realized what had happened, they halted their normal code signing infrastructure and implemented a “clean-room implementation of an interim signing service for re-signing components that were signed with the impacted key.” Apparently, this new interim signing solution is relying on offline human verification to ensure that “all files scheduled for signature are valid Adobe software.” Arkin went on to say that they are in the process of designing and developing a new permanent signing solution.
“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,” he added.
Arkin said a forensics investigation 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,” he added.
Adobe plans to revoke the impacted certificates on October 4, 2012.
The revocation will affect all code signed after July 10, 2012, which indicates the attackers had access to Adobe’s infrastructure for more than two months.
“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,” Arkin wrote. “The revocation does not impact any other Adobe software for Macintosh or other platforms.”
The three affected applications are Adobe Muse, Adobe Story AIR applications, and Acrobat.com desktop services.
The company said it had good reason to believe the signed malware wasn’t a threat to the general population, and that the two malicious programs signed with the certificate are generally used for targeted, rather than broad-based, attacks.
Digital certificates are a core part of the trust that exists between software makers and their users. Software vendors sign their code with digital certificates so that computers recognize a program as legitimate code from a trusted source. An attacker who can sign their malware with a valid certificate can slip past protective barriers that prevent unsigned software from installing automatically on a machine.
Revoking the certificate should prevent the signed rogue code from installing without a warning.
Stuxnet, a sophisticated piece of malware that was designed to sabotage Iran’s nuclear program, was the first malicious code discovered to be using a valid digital certificate. In that case the attackers – believed to have been working for the U.S. and Israel – stole digital certificates from two companies in Taiwan to sign part of their code.
Adobe said that it stored its private keys for signing certificates in a hardware security module and had strict procedures in place for signing code. The intruders breached a build server that had access to the signing system and were able to sign their malicious files in that way.
Questions about the security of Adobe’s source code came up earlier this month after Symantec released a report about a group of hackers who broke into servers belonging to Google and 33 other companies in 2010. The attackers were after source code for the companies. Adobe was hacked around the same time, but has never indicated if the same attackers that hit Google were responsible for hacking them.
Symantec found evidence that the attackers who struck Google had developed and used an unusually large number of zero-day exploits in subsequent attacks against other companies. The attackers used eight zero-day exploits, five of which were for Adobe’s Flash Player. Symantec said in its report that such a large number of zero-days suggested that the attackers might have gained access to Adobe’s source code. But Arkin insisted at the time that no Adobe software had been stolen.
We will most likely find out more in the future about this breach and only time will tell if Adobe is telling the truth about what happened.