[cryptography] Microsoft Sub-CA used in malware signing
ondrej.mikle at nic.cz
Mon Jun 11 12:38:46 EDT 2012
On 06/11/2012 11:06 AM, Ben Laurie wrote:
> On Mon, Jun 11, 2012 at 1:56 AM, Nico Williams <nico at cryptonector.com> wrote:
>> On Sun, Jun 10, 2012 at 3:03 PM, Florian Weimer <fw at deneb.enyo.de> wrote:
>>> * Marsh Ray:
>>>> Marc Stevens and B.M.M. de Weger (of
>>>> http://www.win.tue.nl/hashclash/rogue-ca/) have been looking at the
>>>> collision in the evil CN=MS cert. I'm sure they'll have a full report
>>>> at some point. Until then, they have said this:
>>>>> [We] have confirmed that flame uses a yet unknown md5 chosen-prefix
>>>>> collision attack.
>>> Does this mean they've seen the original certificate in addition to
>>> the evil twin?
>> The evil twin has the nasty bits[*] in the issuerUniqueID field, which
>> is weird, and the ID is not one likely to be generated by any CA.
>> Would the original have it?? I don't see why the TS CA would have
>> issued certs with issuerUniqueIDs under any circumstances, which is
>> why it's interesting the the evil twin had any evil bits.
> Surely the whole point is that the collision is used to switch
> <something> to issuerUniqueID in order to hide the stuff that would've
> stopped the cert from working. I haven't looked, but I'm prepared to
> bet it would not be hard to figure out what the original cert must
> have looked like.
The <something> was almost surely ASN.1 structure for extensions, since
it's right after SPKI structure and last field in TBSCertificate
structure. The other options (issuerUID and subjectUID) are almost never
used (seems that UIDs can't be part of CSR). Extensions and
issuer/subject UID are at the same level in the ASN.1 tree.
Thus if the hypothesis about MD5 collision is true, attacker needed to
flip just one tag-length-value (TLV) tuple, any remaining bits flipped
due to collision could be hidden inside the bitstring value of issuerUID.
Here's what the "evil twin" headers probably looked like (starting with
the place where issuerUID encoding begins):
MS.der (the one we have):
81 82 03 78 00 6A 4C E0 ... for issuerUID
- tag identifier octet 0x81, length encoded in 2 bytes (0x82), length 0x378
- 00 6A 4C E0 ... are the first bytes of value
MS-evil-twin.der (one we don't have):
A3 82 03 78 30 82 x y ... for extensions
- tag identifier octet 0xA3, length encoded in 2 bytes (0x82), length
must be the same 0x378
- "30 82 x y" stand for internal constructed sequence of extensions,
followed probably again by "30 n" because every extension is sequence
Starting with the tag identifier octet, the changes between the two are
(counting bits from 1):
- class is unchanged (context-specific, highest bits 10)
- bit 6 (primary/constructed) flipped to 0 (primary); flipping from
constructed has advantage of not having to fix additional TLV inside a
- octet 0xA3 encodes the  tag, constructed (constructed requires TLV
to follow, like the 30 82 ...),  meaning this should be interpreted
- octet 0x81 encodes the  tag, primitive, implicit from spec,
interpreted as bit string 00 6A 4C E0 ...,  meaning it should be
interpreted as issuer UID
In the "evil twin certificate" the first extension would have probably
been an extension with a string field which the signing software
considers harmless. That would allow the signing to occur and "pad" that
string field with other flipped bits that could otherwise screw the
cert's interpretation. Still, that's quite a few bytes that need a fixed
value around the place of collision in the "evil twin certificate".
Second strange thing I noticed is that OIDs for the two signature
algorithm fields differ: md5WithRSA (1 3 14 3 2 3) and
md5withRSAEncryption (1 2 840 113549 1 1 4) - RFC 5280 says they must be
> Has anyone got the evil cert as a binary? I could probably reconstruct
> it from the bazillion dumps out there, but I can't be bothered.
It was attached to one of Marsh's posts, attaching DER-encoded again.
Took me a while as well to realize that we have it already - the
certutil.exe dumps on the web have byte order of signature reversed.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1668 bytes
Desc: not available
More information about the cryptography