On 06/12/2012 04:09 AM, Marc Stevens wrote:
They were limited to a millisecond time-window to request the original
cert for their attack to succeed.
That means they probably needed a lot more attempts than the 9 attempts
(over 4 weekends) we needed.
From Sotirov's http://www.trailofbits.com/resources/flame-md5.pdf :
Serial number format:
o number of milliseconds since boot (4 bytes)
o CA index (fixed 2 byte value)
o sequential certificate number (4 bytes)
So I see three challenges:
a) Ensuring the request goes to the correct server. If there are
multiple boxes behind a load balancer serving requests this could be an
issue. But given the format of the serial number and that the CA index
always seems to be '00 00' we can assume this isn't a problem. If there
are load-balanced signing servers, their likely working off of a shared
consistent database.
b) Submitting the CSR at the correct millisecond. It's not uncommon for
internet timing jitter to be +- 1 ms or less:
PING google.com (173.194.64.100) 56(84) bytes of data.
64 bytes from oa-in-f100.1e100.net (173.194.64.100): icmp_req=1 ttl=43
time=48.6 ms
64 bytes from oa-in-f100.1e100.net (173.194.64.100): icmp_req=2 ttl=43
time=47.5 ms
64 bytes from oa-in-f100.1e100.net (173.194.64.100): icmp_req=3 ttl=43
time=48.0 ms
64 bytes from oa-in-f100.1e100.net (173.194.64.100): icmp_req=4 ttl=43
time=47.8 ms
64 bytes from oa-in-f100.1e100.net (173.194.64.100): icmp_req=5 ttl=43
time=47.6 ms
64 bytes from oa-in-f100.1e100.net (173.194.64.100): icmp_req=6 ttl=43
time=48.2 ms
The attacker could probably do even better if he sent the request from a
box hosted on a nearby network. So this shouldn't present too much of a
problem.
c) Getting the predicted cert number. The cert numbers in the pdf
Feb 23 19:21:36 2010 GMT 14:51:5b:02:00:00:00:00:00:08
Jul 19 13:41:52 2010 GMT 33:f3:59:ca:00:00:00:05:25:e0
Jan 9 20:48:22 2011 GMT 47:67:04:39:00:00:00:0e:a2:e3
suggest that these were increasing at the rate of about 1094840 per year
and that there was about 29 s on average between issuances. Assuming MS
Terminal Services activations are twice as likely to happen during
business hours (the actual factor is probably much larger than that),
then probably there is a time of the week at which there is 60 s or more
between activations.
From the publicly documented demonstration at
http://www.win.tue.nl/hashclash/rogue-ca/ :
In a three day period from Thursday night to Sunday night, [RapidSSL] typically
issues between 800 and 1000 certificates.
Which is about 324 s on average between issuances.
So the timing target was a bit tighter for the Flame attackers than the
rogue-ca researchers, but not prohibitive.
What is unclear is if there are any effective costs or rate limitations
on how often one can 'activate' an MSTS license server. A compute
cluster faster than 200 PS3s could cut down on the number of license
certs that were burned to make the attack work.
- Marsh
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
