Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Malware Signed With Valid SONY Certificate (Update: This was a Joke!) - SANS Internet Storm Center SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Malware Signed With Valid SONY Certificate (Update: This was a Joke!)

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

Johannes

3132 Posts
ISC Handler
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
brian

4 Posts Posts
PS4 hacked firmware next?
Luke

1 Posts Posts
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.
Starlight

34 Posts Posts
Remark that it is countersigned by COMODO -> timestamp is not spoofed.
DidierStevens

195 Posts Posts
ISC Handler
I extracted the actual certificate, for blocking purposes : http://www.tillo.ch/temp/sony-malware.crt
tillo

7 Posts Posts
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
Anonymous
Posts
Usually software is "signed" by a certificate, not "singed". Although I do like my malware lightly carbonized.
Anonymous
Posts
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).
Erik van Straten

122 Posts Posts
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).
Johannes

3132 Posts Posts
ISC Handler
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.
Johannes

3132 Posts Posts
ISC Handler
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.
Johannes

3132 Posts Posts
ISC Handler
To clarify what I mean:

(1) If I look at the code signing certificate *as part of a signed file*, Windows *does* check for revocation.

(2) If I open a plain certificate file (double-click a .cer, .der or .p7b file), apparently Windows *does not* check for revocation.
Erik van Straten

122 Posts Posts
I uploaded a screen shot here: http://imgur.com/EMzjpL4

The same certificate: on the left it is shown as revoked, on the right it is not. While not necessarily a security issue, at least it's unexpected behavior.
Erik van Straten

122 Posts Posts
I would say just viewing the details of a certificate does not call for going the process of validating that certificate,
which requires checking external servers,

AND different applications can have different certificate validation requirements, when the certificate is actually being used.

For example: A SSL certificate has usages attached to it, it may be valid for some uses but not others.


If a code signing certificate is revoked or expires, and there is already code signed with the cert, which was also signed with a timestamping certificate,
then the code signing certificate is valid when checking the signatures of the old files signed before the certificate was invalidated,
but invalidated for signing new files after that certificate's expiration date.


So I would say.... just viewing a certificate in isolation isn't telling you if it's valid today for a given use.
Maybe you just want to review the details as quickly as possible without going through extra validation steps.


Perhaps Microsoft should add a button to that dialog box to say "Check certificate validity" and then show a green checkmark or red X
beside each enabled certificate usage.
Mysid

146 Posts Posts
@Mysid: indeed, Authenticode extends the validity of a signature beyond the validity timespan of a certificate, whether or not revoked (in the latter case, as you write, provided that that the signature was timestamped _before_ the date and time of theft of the private key, which might be long before the actual revocation request).

To say it differently, an Authenticode signature may be valid, even if the signing certificate has expired or is revoked.

But I don't see how this should affect the validity of a certificate in itself. If it has expired or is revoked, then that should be shown.

In fact, I'm not happy with Windows certificate viewer if I look at an expired certificate. The viewer's general tab shows the validity timespan, but does not "turn red" (show any warning) if a cert has expired. Worse, if I open the "Certification path" tab, it'll say, below "Certificate status": "This certificate is OK". Even if it has expired many years ago.

However, revocation often (as in this case), is a severe indication that something is very wrong. This information applies to the _certificate itself_, and should not simply disappear if I look at the properties of such a certificate, regardless of current use (if any, such as inclusion in a signed file).
Erik van Straten

122 Posts Posts

Sign Up for Free or Log In to start participating in the conversation!