| ]

Details about how MD5 weaknesses especially what is refered to as known prefix collisions were used to help to compromise the trust put into one of the CA's that is builtin major browsers :

Quick Summary:
Not all CAs using MD5 are automaticaly broken, three things were required :
- MD5 signed CA
- prediction of the Serial Number (RapidSSL increments by one)
- prediction of the certificate validity date (RapidSSL issues always 6 second after your press the button.
- A way to find collisions fast enough

Only with these 4 things in place it was possible to pull this off.

More information :

2004 - first attacks against md5
2006 - Colliding PKCS Certificates http://www.win.tue.nl/~bdeweger/CollidingCertificates/
2007 - know prefix collision attacks against md5 futher speeding up the time it takes to find collisions.

Basicaly the stage for the attack shown this year at 25c3 attack was already set in 2006 however the Serial number + Validity period were a problem, because you don't know where they are (in the data) in advance.

So how to reduce the entropy (uncertainty what the validty of the certficate is) ? They found a way to use the RAPIDSSL autonomous system which gives the certificate extactly 6 seconds after you click the I approve button.

What about the Serial number? How to predict the serial number ? RapidSSL just incremented the serial number by one...

This means they potentialy could predict the serial number,however they need three days to bruteforce the collisions - so they needed to get the serial number right for that date - they choose sunday night because the entropy introduced by customer buying certificates hindered the process of hitting the sweet spot.

The required 4 attempts, the three previous times someone else got the Serial Number they targeted.

The question what happens with certificates that use MD5 checksums have been
openly asked (and tried to be answered) in 2005 as shown here :

Summary :
Academic research + hacker ingeniousty at it's finest. We need more of it. Awesome.
This only worked because RapidSSL incremented the serial number by 1 and they could predict the validity date.

So, in other words : Remove (or edit the Trustsettings) for the following CA's -

Firefox :
* RapidSSL
C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness CA-1
* FreeSSL (free trial certificates offered by RapidSSL)
C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Network Applications
* TC TrustCenter AG
C=DE, ST=Hamburg, L=Hamburg, O=TC TrustCenter for Security in Data Networks GmbH, OU=TC TrustCenter Class 3 CA/emailAddress=certificate@trustcenter.de
* RSA Data Security
C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
* Thawte
C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
* verisign.co.jp
O=VeriSign Trust Network, OU=VeriSign, Inc., OU=VeriSign International Server CA - Class 3, OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign

(Thanks to Security4all)

| ]

Relates to this story :

Here is the extracted shellcode from the IE7 0day referenced above.
XOR encoded payload for analysis - compile and run it through Ollydbg.

The decrypted shellcode is available for download here :

I was not interested in posting the 0day, but somebody choose to do so on milw0rm.com, so I might aswell link there : http://milw0rm.com/sploits/2008-iesploit.tar.gz

HDmoore posted a nice analysis here : http://www.breakingpointsystems.com/community/

Update 3
11/12/2008 - 04:19
5 out of 32 scanners recognising the 0day in HTML form

11/12/2008 - 17:34
7 out of 38 scanners recognising the exploit

12/12/2008 - 17:04
11 out of 38 scanners recognising the exploit

13/12/2008 - 17:00
12 out of 38 AV engines recognise the exploit

14/12/2008 - 19:45
14 out of 38 AV engines recognise the exploit

15/12/2008 - 18:25
Still 14 out of 38 AV engines recognise the exploit

16/12/2008 - 18:25
15 out of 38 AV engines recognise the exploit

17/12/2008 - 18:25
Still at 15 out of 38 AV engines recognise the exploit

19/12/2008 - 16:04
18 out of 38 AV engines recognise the exploit

20/12/2008 - 16:04
19 out of 38 AV engines recognise the exploit

21/12/2008 - 16:04
20 out of 38 AV engines recognise the exploit

22/12/2008 - 16:04
21 out of 38 AV engines recognise the exploit

23/12/2008 - 16:04
21 out of 38 AV engines recognise the exploit

24/12/2008 - 16:04
22 out of 38 AV engines recognise the exploit


26/12/2008 - 16:04
22 out of 38 AV engines recognise the exploit (Result misses Securecomputing)

27/12/2008 - 16:04
22 out of 38 AV engines - (Result misses VBA32)

28/12/2008 - 16:04
22 out of 38 AV engines - (Result misses VBA32)

21 out of 38 AV engines - (CA) E-trust no longer recognises the sample, Esafe missing