Yesterday Adobe came out in a bog post stating an inappropriate use of an Adobe code signing certificate for Windows.
Apparently they discovered a compromised build server with access to Adobe code signing infrastructure. (Which is corporate speak for one of our servers was hacked.) They immediately decommissioned the existing Adobe code signing infrastructure and initiated a forensics investigation to determine how these signatures were created.
This apparently only effects the Windows platform and three Adobe AIR applications for both Windows and Macintosh. I found a list of the applications involved, and how to update them on this page: http://helpx.adobe.com/x-productkb/global/certificate-updates.html. This update revocation will not occur until the 4th of October. (Next Thursday).
The interesting section (to me at least) of this post is the middle section:
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 machines 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 Adobes 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.
Naturally people are writing in to us asking what this impacts (see the first link above) and what happened, (the second link above). But there is one thing we are sure of, we don't know the extent of the damage, and hope there was nothing more compromised than what Adobe has found in their investigation. I know Brad Arkin and trust him, so I don't have any reason to doubt him and his team (who are very good, and work very hard by the way, I don't want anyone to get the wrong impression), but you never know, I guess, is my point.
Since I work for an IDS vendor, (Sourcefire, in the interest of full disclosure), our customers were very interested in the rules we released yesterday to cover this. So this is definitely on people's minds.
-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.