Adobe certification revocation for October 4th

Published: 2012-09-28. Last Updated: 2012-09-28 19:20:08 UTC
by Joel Esler (Version: 1)
10 comment(s)

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 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.

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

 

10 comment(s)

Comments

It's not always APT, as if calling it that provides an excuse for getting compromised. Somebody goofed along the way and the bad guys got in. Stuff happens, but don't make it worse by making excuses.
The "interesting" part to me is how they say you don't have to do anything for Flash and Reader. Unless you're an administrator and you manage software.

Reading between the lines it sounds like Adobe is saying if you allow automatic updating you'll be fine. Otherwise you won't.

So what happens when the certificate is revoked? Do you just get a warning when you try to install an old version? Or do all of your users get a warning when they try to run Adobe Reader or use Flash? The latter would really suck.

I guess we will be finding out next week?
"Never ruin an apology with an excuse."
- Ben Franklin
(... unless you're in marketing.)
.
I tried to update a client's flash player this week and kept getting an invalid cert error. Had never seen that before. Did a bit of Googling and found a site that had a screenshot just like the dialog box I was seeing. (too bad I can't find it now). Was really confused until started seeing posts like this describing what was going on.
- http://nakedsecurity.sophos.com/2012/09/28/adobe-revokes-certificate-after-hackers-compromise-server-sign-malware/
Sep 28, 2012 - "... the issue appears to have been the result of hackers compromising a vulnerable build server. -Malware- seen using the digital signature includes pwdump7 v 7.1 (a utility that scoops up password hashes, and is sometimes used as a single file that statically links the OpenSSL library libeay32.dll). According to Adobe, the second malicious utility is myGeeksmail.dll, a malicious ISAPI filter..."
.
Q: Why would someone break in to Adobe to use their certificate to sign a legitimate file like pwdump? (Yes, it has legitimate uses.)

A: Because the one that was signed had been modified somehow. Or perhaps anti-malware products will ignore digitally signed files.

Anyway, that is my take. No one has said what those two files are doing malware-wise. Adobe has the samples. They need to tell us what they were doing.

If a security company was using them in pen tests, this could be seriously bad.
@JJ: you can export the affected certificate from an older file and import it in the "Untrusted Certificates" store, and conduct tests right now. Make sure you import it in the _system_ section of the cert store (not in your personal section).

Such a "older file" can be obtained from, for example, http://helpx.adobe.com/flash-player/kb/archived-flash-player-versions.html
I just downloaded the Flas player archive "(Released 6/21/2012) Flash Player 11.3.300.262 (35.1 MB)" (file: fp_11.3.300.262_archive.zip). All three executables in zip/fp_11.3.300.262_archive/11_3r300_262/ are signed with the certificate that will be revoked (Serial Nr. 15 e5 ac 0a 48 70 63 71 8e 39 da 52 30 1a 04 88).

@Bob Stangarone: what you describe has nothing to do with the issue at hand. No certificate has been revoked yet.

The interesting section (to me at least) of http://blogs.adobe.com/asset/2012/09/inappropriate-use-of-adobe-code-signing-certificate.html is:

"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."

Unfortunately this is correct. By default Windows (at least XP) does not check digitally signed binaries when you expect them to do that. Even an exe file just downloaded, and hence tagged as "blocked" (using an Alternate Data Stream), does not have it's signature checked when you first run it.
@JJ you ask why they wanted a signed pwdump. I believe the answer is: to attack a server that is protected by whitelisting which blocks execution of untrusted programs but accepts code signed by Adobe et.al.as trusted.
If you are interested in finding executables on your machines signed with this certificate, I've released a new digital signature tool that can help you with this:

http://blog.didierstevens.com/2012/10/01/searching-for-that-adobe-cert/

Diary Archives