KCI Attacks against TLS

Overview of the Attack

In a KCI-based MitM attack, an attacker who is in possession of a client certificate's private key installed at a victim, can impersonate any server. The attack is illustrated in the following figure.

Man-in-the-Middle Scenario / Motivation

Assume an attacker sits anywhere on the communication line between the client and the server. He can eavesdrop on all messages exchanged between client and server, and tamper with, modify, or block messages at his discretion. This is a common assumption (e.g., a hacker could control your wifi traffic or let your device automatically connect to a rogue access point, or he could sit on any network node between your device and the server, he could re-route your traffic using ARP Spoofing or BGP manipulations. The NSA uses QUANTUM INSERT, which amounts to equivalent capabilities). That is why many systems on the Internet use cryptographic protocols such as TLS to prevent attackers from eavesdropping on sensitive communication data and from modifying the plaintext of exchanged data.

Steps to Attack

However, the TLS protocol (also known as SSL) is very convoluted, old, and carries too much historical baggage. During a KCI-based MitM attack (KCI stands for "Key Compromise Impersonation"), as depicted in the figure above, the attacker interferes with the communication initialization of the TLS protocol between client and server, and forces the client to use insecure TLS handshake/authentication options together with a client certificate for which he is in possession of the private key. If the client bends to the server's demand, the attacker then impersonates the server, and the client establishes an encrypted and authenticated connection to the attacker, believing it is talking to the server. Subsequently, the attacker initiates a normal encrypted connection to the server. He then forwards messages from the client to the server (and vice versa), and is able to eavesdrop on the plaintext, and also to modify arbitrarily the content of the communication. For many web and mobile applications, a successful attack means that a user's session or profile is completely compromised and under the control of the attacker from this point on: Electronic payments may be initiated and re-directed to the attacker's account, private messages could be read and spoofed, etc. Possible damage is in most cases only limited by the attacker's imagination and creativity.

Controlling a Client Certficate

Various options for an attacker to control the private key of a client certificate installed at a client device exists and are conceivable. One very natural way that comes to mind would be to employ social engineering techniques: E.g., an attacker hands you a client certificate, so that you can access library resources, or be able to use a hotel's wifi (see video demo below). The attacker is then able to compromise connections to completely different, unrelated servers (e.g., to facebook). Other ways for an attacker to install client certificates are discussed in more detail in our research paper: For example, a software vendor might include a benign looking client certificate as a backdoor; or an also completely benign looking mobile app (e.g., a game) might install a client certificate in the system's certificate store, which an attacker then uses to exploit different apps (e.g., an electronic banking application). What aggravates the attack is that it is common practice in many systems to handle client certificates in an insecure way. We hope the publication of this attack raises awareness so that system implementers and administrators move to more secure practices.

Video Demo: Attacking Facebook

To illustrate that KCI-based MitM attacks are not just academically interesting but relevant in the real world, we demonstrate in a proof-of-concept exploit the practicability and feasibility of the attack using widely used systems: In the video below, a user uses the Safari web browser on Mac OS X to connect to facebook. Older Mac OS X systems (OS X 10.7 and earlier) remain vulnerable to the attack, and we recommend users to upgrade their systems to be secure. Also, this attack was recorded after facebook implemented successfully all possible server-side mitigations. Due to old server certificates still being valid for some time (and findable for people who know where to look at), this exact attack is still possible against unprotected, unpatched client machines. In the end of the video, we also show mitigation measures to protect your system from the attack in case your hardware does not allow you to update your operating system to the newest version. For the purpose of this proof-of-concept demonstration, the attacker in the video only swaps lovely cat pictures with an attacker-controlled picture, disseminating disinformation: "Facebook is closing down soon", is the message to the user; and, more disconcertingly: "All cats drowned". Furthermore, the attacker recommends leaving facebook and joining (the decentralized, community-run, non-profit, alternative social network) Diaspora instead. However, in a real attack, the attacker could easily do much more damage than this (while possibly remaining stealthy and fully undetected): The attack gives the attacker complete control over the client-side code running in the user's browser; he can present the user arbitrarily modified content, and even initiate actions on behalf of the user, such as sending of spoofed messages, or controlling facebook payment transactions.

During the first minute of the video, the original, unadulterated facebook profile is presented: Lovely cat photos and drawings. At minute 1:02, the user connects to the Internet (via a maliciously operated) hotel wifi network. At the captive portal of the hotel's wifi, the user is asked to authenticate with his last name and room number, and is subsequently tricked into installing a TLS client certificate. This legitimate looking wifi access point could very well be operated by an attacker sitting in the neighbouring hotel room in the real world. (However, this does not mean that an attacker necessarily has to be close to the victim to pull of this attack: This is just one way for an attacker to control a client certificate. Please find a more detailed discussion about different attack possibilities in the research paper). Captive portal software outside this demo exists which operates similarly. This completes phase 1 of the attack. In phase 2 of the attack, starting at minute 2:03 in the video, the attacker, under the hood, interferes with the connection initialization to facebook, and forces the client to use an insecure handshake with client authentication, requesting the previously installed certificate from the system. The video only displays the visible effects of the attack from the perspective of the victim. Minute 2:03 until 4:20 in the video demonstrate the result of the maliciously altered, attacker controlled communication between the client and facebook. Starting at minute 4:30, a mitigation measure for older, unpatched clients is presented (setting OCSP checking to strict mode, see discussion below).

Mitigation and Affected Systems

Considerations for Users

If you are a user who does not run anything very outlandish (i.e., default web browsers and mail clients on recent, security-supported versions of platforms such as MS Windows, Google Android, Apple iOS and Apple Mac OS X, Linux), the good news is, you are probably safe: We made sure to coordinate with major vendors such as Google, Microsoft, and Apple prior to the public disclosure of this vulnerability, and worked closely together with affected vendors to identify issues and to get things under control. On the server-side, we also worked with affected players, such as facebook (which symbolically rewarded us generously for our efforts via their bug bounty program), to implement mitigation measures. However, TLS/SSL is used by so many different systems and is implemented by almost uncountable program libraries (some of them proprietary, and not open to our scrutiny) that you might not fall into the first category of users. In this case, we would recommend to check with your system implementer. You are invited to contact us if you find any systems that are still affected by the issue. On the other hand, if you use systems that remain vulnerable (such as Mac OS X 10.7 and prior versions), but cannot update (e.g., because of old hardware), the only thing you can do to mitigate against this attack for some scenarios (i.e., when server adminstrators changed their certificates already accordingly) is to enable strict OCSP checking. How this option is set in Mac OS X is demonstrated at the end of the video demo above (starting at 4:30). However, this measure goes not without its own drawbacks.

Considerations for System Implementors, Administrators, and Security Testers

Since the vulnerability is in the protocol specification of TLS, it is not unlikely that the issue might re-surface in the future. In order to prevent this from happening, please consider carefully the mitigation measures as proposed in our research paper. In short,

• Check that server certificates set the X509 Key Usage extension correctly (In particular, do not set the KeyAgreement Bit for ECDHE handhakes)
• Check that clients do not support KCI vulnerable cipher suites
• Check that clients honor X509 Key Usage extensions
• Check that client certificates are generated and distributed only in a secure way (e.g., using the HTML5 keygen tag)

Mitigation Techniques that do not Work for KCI-based MitM Attacks

A range of mitigation techniques have been proposed and are in use against different MitM attacks. These mitigation mechanism include

• TLS Certificate Pinning
• Perspectives
• Convergence
• Tack
• DANE

Research Paper

We presented a technical research paper at a USENIX security conference. For further information and the technical particulars of the attack we suggest you read it or consult the additional resources:

• USENIX WOOT conference entry
• Presentation slides USENIX WOOT'15 (pdf)
• Research Paper USENIX WOOT'15 (pdf)

Abstract of the USENIX resarch paper

Protection of Internet communication is becoming more common in many products, as the demand for privacy in an age of state-level adversaries and crime syndicates is steadily increasing. The industry standard for doing this is TLS. The TLS protocol supports a multitude of key agreement and authentication options which provide various different security guarantees. Recent attacks showed that this plethora of cryptographic options in TLS (including long forgotten government backdoors, which have been cunningly inserted via export restriction laws) is a Pandora’s box, waiting to be pried open by heinous computer whizzes. Novel attacks lay hidden in plain sight. Parts of TLS are so old that their foul smell of rot cannot be easily distinguished from the flowery smell of ‘strong’ cryptography and water-tight security mechanisms. With an arcane (but well-known among some theoretical cryptographers) tool, we put new cracks into Pandora’s box, achieving a full break of TLS security. This time, the tool of choice is KCI, or Key Compromise Impersonation.

The TLS protocol includes a class of key agreement and authentication methods that are vulnerable to KCI attacks: non-ephemeral Diffie-Hellman key exchange with fixed Diffie-Hellman client authentication – both on elliptic curve groups, as well as on classical integer groups modulo a prime. We show that TLS clients that support these weak handshakes pose serious security concerns in modern systems, opening the supposedly securely encrypted communication to full-blown Man-in-the-Middle (MitM) attacks.

This paper (pdf) discusses and analyzes KCI attacks in regard to the TLS protocol. We present an evaluation of the TLS software landscape regarding this threat, including a successful MitM attack against the Safari Web Browser on Mac OS X. We conclude that the insecure TLS options that enable KCI attacks should be immediately disabled in TLS clients and removed from future versions and implementations of the protocol: their utility is extremely limited, their raison d’etre is practically nil, and the existence of these insecure key agreement options only adds to the arsenal of attack vectors against cryptographically secured communication on the Internet.

About ESSE, the RISE IT Security Team

IT security is a key topic of the Austrian company RISE GmbH. This is ensured by ESSE (Establishing Security), the RISE security team/research group for IT security. Our sophisticated staff has supervised and implemented many security critical projects in large IT infrastructures with world-class expert-knowledge in IT security. Tasks range from the planning of security architectures, over the creation of security concepts, conception and implementation of various security measures, to the planning of detailed security tests/penetration tests in different branches and scopes, e.g., banking & payment, countrywide ticketing systems, mobile systems, VoIP, cryptography & privacy-enhancing tools. ESSE cooperates closely with the identically-named research group at the Technical University of Vienna, and regularily cross-pollinates with a range of internationally renowned security researchers both from industry and academia.

ESSE is responsible for the IT security of many IT systems and IT components which are used worldwide, e.g., RISE Gatekeeper, our application-level firewall for client to backend communicaton which uses secure channels based on proven, modern, state-of-the-art cryptographic primitives instead of the dated and seedy TLS protocol; various payment systems and banking applications; or ticketing, access control, and campus administration systems.

Contact

If you want to contact us, if you have further questions on the KCI TLS vulnerability, or if you want to engage us to solve your security problems, please drop us a line: kcitls@rise-world.com.

About RISE

Copyright