This has been an interesting year for high-profile vulnerabilities and security research. In 2008, awareness has been raised about a number of high impact, remote code-execution vulnerabilities affecting both server- and client-side applications. Published attacks targeted important protocols used by critical Internet infrastructure. A number of flaws in the implementation of a number of cryptographic implementations have also been made public. In addition to the aforementioned issues, new exploitation techniques were demonstrated that emphasized the growing trend toward application-specific attacks targeting Web technologies.
Let's begin with a few high-profile memory corruption flaws on the Microsoft Windows front. The year started with a bang, MS08-001, which is a remotely exploitable memory-corruption vulnerability affecting the Microsoft Windows kernel. Then, in October we saw in-the-wild exploitation of a previously undisclosed RPC vulnerability affecting Microsoft Windows (MS08-067). In December we saw in-the-wild exploitation of a previously unknown and unpatched vulnerability affecting Internet Explorer (MS08-078).
On the critical infrastructure front, research was published regarding the targeting of two protocols that are critical to supporting Internet infrastructure. The first was Dan Kaminsky's much talked about DNS vulnerability that allowed attackers to easily insert arbitrary DNS records into an affected DNS server. The second piece of research demonstrated a man-in-the-middle attack abusing BGP.
On the cryptographic front, June marked the disclosure of a high-profile vulnerability affecting SNMPv3. Due to an implementation flaw, attackers were able to perform brute-force attacks against the HMAC authentication routine used in some SNMPv3 implementations. In May, a flaw in Debian's OpenSSL package was publicized. Due to a mistake made during testing, the entropy pool for the generation of cryptographic keys was limited to using Process IDs (PIDs), making brute-force attacks trivial.
The aforementioned cryptographic vulnerabilities make for an interesting segue into some research that was disclosed today. It looks like 2008 is going to end on an exceptionally high note (or a low one, depending on how you look at it). Today (December 30, 2008), three security researchers added to the list of cryptographic-implementation flaws when they gave a talk at the 23rd Chaos Communication Congress in Berlin. Their talk disclosed a vulnerability affecting certificate authority (CA) signing. A CA “signs” digital certificates, operating as a trusted third party to help ensure the validity of a certificate. The ability to create a rogue, signed certificate for an arbitrary site has extremely dangerous implications. This is what the attack presented today does.
First, a little bit of background information is required. In the past couple of years, researchers have identified a few attacks that leverage hash collisions computed using the MD5 algorithm. A hash collision means that computing a collision for a particular hash algorithm means finding two different messages, such that the hashes of those messages are the same, effectively proving the hash algorithm is technically not cryptographically secure. Computing hash collisions is not particularly easy and often requires large amounts of time and computational resources. The researchers who published this research overcame that limitation by using a cluster of PlayStation 3 video game consoles to brute-force hash collisions in MD5.
The attack targets CAs that specifically use the MD5 hash algorithm to issue certificates. According to the summary, in a nutshell, the attack breaks down like this:
1. Identify a CA that is accepted by most/all common Web browsers and uses MD5 to issue certificates.
2. Use a crafted request to obtain a certificate from the CA, which will collide with a specially crafted intermediary CA certificate (already in the attackers’ possession).
3. Copy the digital signature from the certificate issued by the CA into the attacker-generated intermediary certificate, effectively creating a trusted and signed CA under the attackers’ control.
4. Use the attacker-controlled certificate to sign arbitrary certificates, making them appear to come from a legitimate CA and thereby be trusted by third parties.
5. Use arbitrarily signed certificate for nefarious purposes.
Step two, listed above, is of course the non-trivial portion of this attack and a detailed explanation is certainly out of scope for this blog entry. For a detailed explanation of all the caveats and complexities involved, please refer to the link included at the end of this article.
The effects of this attack are important for several reasons and a particularly interesting use (a case noted by the authors of this research) is in creating convincing phishing scams. Used in conjunction with something like the DNS vulnerability published by Dan Kaminsky earlier this year, attackers would be able to create highly convincing websites to steal user credentials and all sorts of confidential information.
For example, say an attacker wanted to obtain legitimate authentication credentials to a specific financial institute’s online banking site. The attacker would set up a fake site designed to appear identical to the legitimate site. The attacker would then direct unsuspecting victims to this site in the hopes of luring them to attempt to log in and thus exposing their authentication credentials. This may be carried out via cross-site-scripting, distributing fake emails, or as previously mentioned leveraging a localized DNS poisoning attack. This is a common phishing scenario and is an easy way for an attacker to drain money from the accounts of victim users.
Previously, under most attack scenarios, the malicious and fake banking site would not contain a legitimate and/or trusted certificate and a users browser would flag it as untrusted. However, an attacker with a maliciously crafted CA certificate created using the aforementioned vulnerability would be able to sign a certificate for the malicious site, and due to the implied trust of the root CA that was manipulated to sign the malicious intermediary CA, the browser would trust the site and unknowingly flag it as safe.
When all of these conditions are fulfilled and carried out successfully, an attacker would be left with an extremely convincing and seemingly legitimate banking site that most users would never know to be malicious. By supplying a trusted certificate an attacker could greatly improve the chances of obtaining credentials.
The Internet threat landscape for 2009 is going to be interesting. So-called esoteric or “difficult” attacks are beginning to become reality. Time and time again new research has proven that seemingly “un-exploitable” scenarios are indeed exploitable given a sufficient period of time.
For further reading:
MD5 considered harmful today - Creating a rogue CA certificate