My next class:

Malware Signed With Valid SONY Certificate (Update: This was a Joke!)

Published: 2014-12-10. Last Updated: 2014-12-10 16:06:25 UTC
by Johannes Ullrich (Version: 1)
15 comment(s)

Update: Turns out that the malware sample that Kaspersky was reporting on was not actual malware from a real incident. But the story isn't quite "harmless" and the certificate should still be considered compromised. A researcher found the certificate as part of the SONY data that was widely distributed by the attackers. The filename for the certificate was also the password for the private key. The researcher then created a signed copy of an existing malware sample retrieved from Malwr, and uploaded it to Virustotal to alert security companies. Kaspersky analyzed the sample, and published the results, not realizing that this was not an "in the wild" sample. [1] The certificate has been added to respective CRLs.

--- original story ---

We haven't really mentioned the ongoing SONY compromise here. In part, because there is very little solid information public (and we don't want to just speculate), and also, without a good idea about what happened, it is difficult to talk about lessons learned.

However, one facet of he attack may have wider implications. Securelist is reporting that they spotted malware that is signed with a valid SONY certificate. It is very likely that the secret key used to create the signature was part of the loot from the recent compromise. Having malware that is signed by a major corporation will make it much more likely for users to install the malware. It also emphasizes again the depth at which SONY was (or is) compromised. [2]

An effort is underway to revoke the certificate. But certificate revocation lists are notoriously unreliable and slow to update so it may take a while for the revocation to propagate. 

Stolen certificate serial number: 01 e2 b4 f7 59 81 1c 64 37 9f ca 0b e7 6d 2d ce
Thumbprint: 8d f4 6b 5f da c2 eb 3b 47 57 f9 98 66 c1 99 ff 2b 13 42 7a

[2] https://twitter.com/afreak/status/542539515500298240
[1] http://securelist.com/blog/security-policies/68073/destover-malware-now-digitally-signed-by-sony-certificates/

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords:
15 comment(s)
My next class:

Comments

The correct way to handle this is for Microsoft to add it to the "untrusted publishers" list. If someone has the certificate (converted to DER), it can be blocked by adding it to "Untrusted Publishers", which can be scripted as:

certutil.exe -addstore Disallowed SONYSTOLEN.crt
PS4 hacked firmware next?
A copy of the actual certificate so that can be added to the "Untrusted Certificate" store would be helpful. Was not able to find it from the serial or fingerprint, which is often possible.
Remark that it is countersigned by COMODO -> timestamp is not spoofed.
I extracted the actual certificate, for blocking purposes : http://www.tillo.ch/temp/sony-malware.crt
Call off the dogs


http://www.csoonline.com/article/2857659/disaster-recovery/destover-variant-signed-with-stolen-sony-certificate-was-part-of-a-joke.html
Usually software is "signed" by a certificate, not "singed". Although I do like my malware lightly carbonized.
There is no such thing as a stolen certificate. Certificates do not contain secrets and are distributed with each signed file.

In order to _sign_ a file, you need access to the private key (associated with the public key included in the certificate).

I don't know who signed a file and uploaded it to VirusTotal. I bet it was not a Sony employee; hence the private key must have been stolen (not physically removed, but copied). That fact alone justifies revoking all certificates that include the particular public key (associated with the stolen private key).

A revoked certificate is definitely not a joke. It will render all files signed with the particular private key useless. This could affect quite a lot of Sony customers. "Fortunately" Windows does not always validate certificates when running signed executables.

Side note: I just found that certificate revocation checks in Windows do not behave as I expected. I downloaded the signed file from https://mega.co.nz/#!wJ1kmabL!VAtUck92jpYrHKxhky9BDXVHVsAwKOmiADPPqcV3AVg (source: https://twitter.com/ydklijnsma/status/542647173624909825). Note: the pw is infected.

If I select the file, choose Properties, open the Digital Signatures tab, select the entry and click details, Windows informs me that the certificate is revoked (as expected).

However, if I export the certificate to a file, and open that file, W7-64 does _not_ warn that the certificate is revoked (the behavior is identical if I download the .der certificate made available by tillo).

Also, if I export the certificate chain (as a .p7b file), and open that file, Windows does not tell me that the "child" certificate is revoked.

Does anyone know whether this behavior has always been there, or has been introduced with some Windows Update? (note: I've not yet installed yesterday's updates).
The term "stolen certificate" commonly applies to the secret key, because without it, the certificate is indeed not considered "stolen". The post notes that one important part of this was the easy guessable password for the secret key (but even just with the file lost, the key should be considered compromised).
As far as exporting the certificate: Odd that it is implemented that way, but it kind of makes sense. Revocation isn't a property recorded in the certificate itself. It can only be verified via the CRL or OSCP URL that is part of the certificate. I guess theoretically, a certificate could be un-revoked later on.

Diary Archives