How to fail at code-signing, the Sony edition

Another massive corporate security breach? Readers well-versed in contemporary history of data-breaches may not be surprised to learn that the target this time was Sony, a repeat-customer for enterprising attackers since 2011. But they might still be surprised to learn both the extent of damage and surprisingly weak internal processes used by Sony in managing critical assets. Leaked internals documents and emails are making the rounds, despite best efforts by Sony to put the genie back in the bottle both using alleged denial-of-service attacks and enlisting their army of attorneys to mail out nastygrams to journalists as Christmas presents.

Here we will focus on just one aspect of the breach: theft of code-signing keys. These were the credentials used by Sony for digitally signing applications authored by the company, proving their origin. Granted “authored by Sony” does not automatically translate into “safe” or “not riddled with vulnerabilities.” Knowledge of authorship attested by the digital signature is at best intended to be a proxy for the reputation of the software publisher. A reputable company would not be in the business of publishing harmful malware, goes the theory. Ironically Sony itself has provided a spectacular counter-example to that assumption: in 2006 the company willfully and deliberately published a malicious rootkit designed to implement gratuitous DRM restrictions against copying CDs on personal computers. Granted at the time digital signatures were not commonly required for Windows kernel-mode drivers, which is the specific type of binary this rootkit assumed. In that sense, the question of code-signing was decoupled from the problem of honesty on behalf of the software vendor. In principle the terms of use required by CAs prior to issuing a code-signing certificate includes warm-and-fuzzy promises by the publisher that they will not use the certificate to sign malicious code.

Back to Sony, the organization which we learned, keeps passwords in cleartext files and stores encryptions keys alongside the content they are protecting. It would not be out of character for such an enterprise to also mismanage their code-signing keys. Sure enough signing keys were also one of the reported casualties of the breach, with signed malware turning up not too long after reports of the incident surfaced. (One report claims the sample discovered was just a proof-of-concept created by a security researcher, as opposed to actual malware found in the wild for offensive purposes.) Regardless, the certificate in question was quickly revoked by the certificate authority. At least for the  Authenticode scheme which is the de facto standard on Windows, revocation checking is enabled by default— unlike the half-baked way it is implemented for SSL by most web browsers— providing at least a modicum of assurance that this particular certificate is unlikely to be used for hiding malware.

What about all of the other Sony certificates? Such a large organization is likely to have multiple certificates used for different applications and different teams. What happened to the rest? For that  what about Sony SSL certificates? In a data-breach the probability of various assets getting compromised is highly correlated. It would be astonishing if an organization so negligent at managing cryptographic keys somehow exercised utmost caution to protect SSL keys. Why aren’t certificate authorities promptly revoking all Sony certificates and forcing the company to reissue? It is worth pointing out a CA does not have to wait for Sony to request revocation. Terms-of-use for most CAs include provisions that allow the CA to unilaterally revoke a certificate when it is believed to have been compromised; here is the example from GlobalSign. So are CAs being negligent in waiting for a “smoking gun” in the form of malware signed by the compromised key instead of proactively taking action?

This question exposes one of the basic conflicts of interest in code-signing systems with trust mediated by third-party certificate authorities— Authenticode being an example of such open models. There are risks associated with revoking as well as risk associated with not taking action:

  • Revoking a certificate could mean application relying on it break. In the case of code-signing previously signed binaries will no longer validate. Doomsday predictions range from bricked devices to webpages not loading correctly.
  • Not revoking on the other hand could mean that malicious binaries are signed under the Sony name and users tricked into installing such applications. In that case the CA would be guilty of negligence, in aiding and abetting attacks against third-parties who relied on the CA to vouch for Sony identity.

It turns out that first problem was already taken into account by Authenticode very early via time-stamping. Binaries signed by the software publisher are further counter-signed by a trusted third-party vouching for the current time that signature was observed. Revocation standards in turn allow specifying the time from which point onwards the certificate is to be considered untrusted. All signatures made before that time— based on the third-party timestamp— continue to validate. Signatures bearing a later time-stamp or none at all are voided.

So why are certificate authorities still erring on the side of not revoking certificates, when there is every reason to believe that Sony is not in control of its private keys? Put bluntly, CAs get paid by the software publisher and at the end of the day, is primarily responsible to the publisher, while occasionally throwing a bone to the CAB forum, a balkanized consortium of certificate authorities and browser vendors attempting to set baseline standards for issuance. The CA has very little responsibility to anyone else. Those users who ended up installing malware signed by “Sony” thinking it was a legitimate certificate? Tough luck. They are not the ones paying $$$ to the certificate authority.
Granted this question of liability has never been tested in an actual court case. CA could plausibly  pass the buck by pointing the finger at Sony, arguing that it is the certificate “subject”— in other words the customer paying the CA— that is solely responsible for initiating revocation. (There is no denying that Sony should have been quicker on the draw here.) But the fact that CAs go out of their way to reserve unilateral revocation rights undermines that argument: why reserve that right in the first place when CA is too conflicted to take action when the customer is clearly negligent?


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s