November 17, 2011 2 Comments-
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:
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:
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:
Realtek Semiconductor Corp, used in Stuxnet:
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.
Snorre Fagerland is a Principal Security Researcher in the Malware Detection Team (MDT) at Norman.
Norman Blog Archive