KCI Attacks against TLS

Protection of Internet communication is crucial
in today's hyperconnected world. The industry
standard for encrypting private and sensitive
communication data over potentially adversarial
controlled network cables and radio signals is TLS.
ESSE, the security team of
RISE
GmbH, discovered a new vulnerability in the ageing TLS
protocol. The newly discovered weakness allows to open supposedly
securely encrypted TLS communication to full-blown Man-in-the-Middle (MitM) attacks: An attacker can
impersonate trusted servers without being in possession of the servers' secret
keys, and can so eavesdrop on the unencrypted messages, snoop on passwords,
love letters, payment data, and modify personal, private communication and
transactions at will. Highly used systems such as the Safari Web Browser on Mac
OS X and Facebook have been vulnerable to the attack. Paired with insecure
practices common in various systems, we found the attack to be easily
exploitable. Outdated, insecure protocol options have to be disabled by system
implementers, and secure practices concerning the handling and configuration of
client and server certificates have to be adopted by the wider Internet
community in order to bury the issue forever as an historical anecdote in the
annals and history books of cryptographic communication.

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.

Attack Demo

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

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

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

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

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.