The signature on the rogue certificate that was used to sign the fake security update was obtained from a certificate for Microsoft’s Terminal Services Licensing Server. Terminal Services (now called Remote Desktop Services) allows a user to log in remotely via a network to another computer running Windows. This process requires a license. In businesses where many users need to access some server, a Terminal Services Licensing Server can be used as a license management system. Upon activation, a Licensing Server generates a public and secret key and automatically requests an X.509 certificate from Microsoft. These certificates chained to the Microsoft Root Authority certificate and could therefore be used to sign code in the name of Microsoft which was presumably not the intention of the developers. This chaining could have allowed attackers to exploit Windows Update for malicious purposes without any collision attack at all. Luckily, the certificates contain an extension which is marked critical that could not be “understood” by Windows Update. On Windows Vista and Windows 7, when a critical certificate extension is not recognized, the certificate is rejected so that, inadvertently, a simple attack on Windows Update was prevented.20 After the rogue certificate was discovered in June 2012, Microsoft revoked the certificate chain for Terminal Services (see the blog post [17]).
During the analysis of Flame, the rogue certificate was uncovered and sent to Marc Stevens via private communication. Using methods described in [24, Chapter 8] and [25], he verified that it was constructed by a chosen-prefix collision attack and reconstructed the underlyingdifferential paths of the collision attack. The legitimate counterpart of the rogue certificate is supposedly lost. We will now give a description of the two colliding certificates, according to [22]. A graphical representation from [22] follows in Figure3.1. A certificate for a Terminal Services Licensing Server consists of the following parts:
1. A serial number, composed of the number of milliseconds since boot, a constant CA index of 8 bits and a sequential 32-bit number
2. The validity period of the certificate
3. The Common Name (CN)“Terminal Services LS” 4. A 4072-bit RSA public key
5. The certificate extensions, including the one that prevents code signing for Windows Update 6. An MD5-based signature by the Certification Authority
The rogue certificate, on the other hand, has the following parts: 1. A serial number
20
This does not hold for Windows XP which simply ignores extensions that it does not recognize, even if they are marked critical. If the Flame authors had been content with attacking Windows XP, they would not have needed the collision attack.
2. The validity period
3. The Common Name “MS” 4. A 2048-bit RSA public key
5. A certificate extension called “issuerUniqueID” which is not used by Microsoft and ignored in Windows
6. An MD5-based signature
Figure 3.1: A schematic representation from [22] of the colliding certificates constructed for Flame. The colliding certificates were constructed as follows: On the side of the legitimate certificate, the serial number, validity period, common name and the beginning of the RSA key form the chosen prefix; on the side of the rogue certificate, it is the serial number, validity period, a full RSA public key and the beginning of the “issuerUniqueID”-field. Since the serial number and validity period in the legitimate certificate are filled in by the CA, the attackers had to guess these values. On the side of the legitimate certificate, the collision blocks are contained in the field for the RSA key – this is a good place to hide them since a cryptographic key is supposed to look random. Due to the incremental nature of MD5, it is possible to append identical suffixes to the legitimate and the rogue certificate after the collision has been achieved. The attackers then appended the required certificate extensions to both certificates. In the rogue certificate, they are hidden away in the “issuerUniqueID”-field, so that the critical extension does not take effect.
Guessing the sequential number in the serial number is relatively easy: The attackers could have submitted several legitimate certificates and observed the differences in the sequential numbers to estimate how many certificates the CA will sign in a given period of time. Furthermore, they could have submitted additional requests just before the targeted request time to advance the sequential number to the guessed value. The validity period depends only on the second in which the certificate is received by the CA. But since the serial number also contains the milliseconds since the boot of the signing computer, the CA had to receive the certificate in the exactly right millisecond for the attackers to succeed. Therefore, with near certainty the attackers had to make a large number of attempts.
It is worth noting that this attack could have been stopped at several different levels: Of course, a more secure hash-function could have been used. But also some non-cryptographic measures could have prevented the attack. Instead of accepting signatures from every certificate with code signing rights that chains to the Root Authority, Windows Update could have used a public key infrastructure (PKI) of its own that is isolated from other PKIs. The certificates from the Terminal Services chain could have been given an extension so that all certificates in the chain are prevented from code-signing. The serial numbers of the certificate could have included random bits to make guessing the right serial number for the chosen-prefix attack prohibitively hard.