Invisible YNK, a Code Signing Conundrum

This story starts with a compromized code signing certificate. It belongs to YNK Japan Inc, a subsidiary of YNK Korea. YNK makes online games such as “R.O.H.A.N : Blood Feud” and “Seal Online : Eternal Destiny”.

The certificate has the following data:

Serial Number: 046931BF57EBC5947D3DC4EE7A236E
Common Name: YNK JAPAN Inc
Status: Revoked
Validity (GMT): Nov 27, 2009 – Nov 27, 2011
Class: Digital ID Class 3 – Software Validation
Organization: YNK JAPAN Inc
Organizational Unit: Digital ID Class 3 – Microsoft Software Validation v2
State: Chuo-ku
City/Location: Nihonbashi Kodenmachou10-6
Country: JP
Serial Number: 6724340ddbc7252f7fb714b812a5c04d
Issuer Digest: 96c16fb10ef41f9736c50c5bac0ddd67

This certificate was compromised some time ago.  Common Computing Security Standards has listed this certificate as reported compromised since May 24th, 2011, when it was  found in a Hupigon backdoor, a quite common trojan from China.  Symantec (which acquired the Verisign authentication business some time ago) state that they received their first report about this certificate July 29th, 2011, and it was revoked the same day.

Correspondingly, the signed trojan look like this when checking it in Explorer:

So far, so good. But then I found more trojans signed with this certificate. Of many different types.  Among them were Sogu/Thoper trojans, used in several major targeted attacks. That, however, is a story for another post. In this post I’ll highlight a few of these signed trojans that surprised me. Like this one below (md5 c629a3b136b7e86a052de21d90f6fe00).

Cue a major double-take on my part.

This signed trojan still validates.  A different certificate perhaps? Nope. It’s the revoked one. This puzzled me to such an extent that I had to contact Symantec, confess to being a noob and ask why this happens. It’s actually very simple.

When Symantec (and I assume other CA’s) revoke a certificate, the revocation is active from the revocationDate field in the Certificate Revocation List (CRL). This means that files signed and timestamped after revocationDate, and files signed and not timestamped, will no longer validate. It also means that files signed and timestamped before revocationDate will validate, and such is the case with the trojan shown above. It is signed June 30. 2011, a month before revocation. It is worth noting that timestamping here means signed with a cryptographically valid timestamp, such as VeriSign Time Stamping Services.

I thought that the revocationDate field was the date when the revocation was first entered into the CRL. I am informed that this is the standard practice. However, the CA (Symantec in this case) will adjust the revocation date to a date predating a timestamp to ensure any known, bad time-stamped code is invalidated. They are quite concerned about setting the revocationDate too early, as that will potentially break legitimately signed customer software.

Back to the trojans. The one above is signed in June, and it’s now November, so this trojan has lived an undisturbed and validated life for about 4.5 months.

Then I found this (md5 b02b2ff605a07bd69b018f6381649a83).

And then I found this (md5 42377e72487529125ebe7c9502b94cd7):

And then I found this (md5 d7ef03e5893b90f5c61c71b6c5d58774):

April 13th. 2010. This earliest malware is interesting, as it was used while the stolen certificate was still relatively new, and one can assume that the target would be a high-value one.  This trojan is a small but nasty tcp-hooking rootkit component, designed to hide network connections on configurable ports. We don’t know what dropper installed it, but there are indications it was first used in South Korea.

When Symantec was informed about this, they took the case seriously. As of Tuesday, November 15th 2011, they confirmed that the revocationDate in the CRL (http://csc3-2009-2-crl.verisign.com/CSC3-2009-2.crl) for this certificate has been backdated:

Serial Number: 6724340DDBC7252F7FB714B812A5C04D
Revocation Date: Apr 12 00:00:00 2010 GMT

So now none of these signed trojans will validate anymore (as soon as the clients update the CRL). We think. Perhaps. Unless there are more trojans out there, signed at an earlier date. Clearly, no one really knows when this certificate was stolen.

For reference, here are the revocations for a couple of other interesting malwares:
C-Media Electronics Inc., used in the Duqu trojan:

Serial Number: 046931BF57EBC5947D3DC4EE7A236E
Revocation Date: Oct 14 18:01:50 2011 GMT (Crysys Labs alerted about this Oct 14th)

Realtek Semiconductor Corp, used in Stuxnet:

Serial Number: 5E6DDC87375082845814F442D1D82A25
Revocation Date: Jan 20 00:00:00 2010 GMT (known malicious use Jan 25th 2010)

The conclusion on this must be that unless you know exactly when a certificate was stolen, there is going to be uncertainty as to whether signed malware still exists and validates. It places a large responsibility on the CA’s to set revocation date with proper margins of error.  If not they will create a false sense of security and, in worst case, help signed malware stay below the radar longer than needed.

How to force update the CRL cache on Windows Vista or newer is detailed in this Technet article: http://blogs.technet.com/b/pki/archive/2007/09/13/how-to-refresh-the-crl-cache-on-windows-vista.aspx