Plaintext Recovery Attacks Against SSH
Kenny Paterson
Information Security Group
Royal Holloway, University of London
kenny.paterson@rhul.ac.uk
Joint work with Martin Albrecht and Gaven Watson
1
Status of this talk
CINS/F1-01
• The results of this talk are unpublished but
submitted for publication.
• A security advisory was issued to the public
through the UK Centre for the Protection of
National Infrastructure (CPNI-957037, CVE2008-5161).
• From the advisory and subsequent vendor
patches it would be fairly easy to reverse
engineer the attack.
2
SSH
CINS/F1-01
Secure Shell or SSH is a network protocol that
allows data to be exchanged using a secure
channel between two networked devices. Used
primarily on Linux and Unix based systems to
access shell accounts, SSH was designed as a
replacement for TELNET and other insecure
remote shells, which send information, notably
passwords, in plaintext, leaving them open for
interception. The encryption used by SSH
provides confidentiality and integrity of data
over an insecure network, such as the Internet.
– Wikipedia
3
SSH
CINS/F1-01
• SSHv1 had several security flaws.
• SSHv2 was standardised in 2006 by the IETF in RFCs
4251-4254.
• RFC 4253 specifies the SSH Binary Packet Protocol
(BPP).
– Symmetric encryption and integrity protection for SSH packets,
using keys agreed in an earlier exchange.
• SSHv2 is widely regarded as being very secure.
– Notwithstanding a minor flaw in the BPP that allows
distinguishing attacks (Dai, Bellare et al.).
• Simple variants of the SSH BPP were proven secure by
Bellare et al. using the “provable security” approach.
– Key example: SSH using randomised padding and CBC mode
encryption with explicit IVs.
4
The SSH BPP
CINS/F1-01
•
•
•
•
Encode-then-Encrypt&MAC construction.
Sequence number is not sent on the wire.
Packet length is encrypted to hide true length of SSH packets on the wire.
RFC mandates 3DES-CBC and recommends AES-CBC.
– In fact, all originally specified optional configurations involve CBC mode, and
ARCFOUR is the only optional stream cipher.
5
CBC mode encryption
•
SSH uses a chained IV in CBC mode
– IV for this packet is the last ciphertext block from the previous packet.
– Effectively creates a single stream of data from multiple SSH packets.
6
CBC mode decryption
7
The basis for an attack
Our attack is possible due to an interaction of
the following BPP features:
• The packet length field encodes how much
data needs to be received before the MAC
should be checked. Thus this field must be
decrypted before the MAC is checked;
• The attacker can send data on an SSH
connection in small chunks (TCP);
• CBC mode is mandated;
• A MAC failure is visible on the network.
8
The attack
• The attacker intercepts a target ciphertext block
from the SSH connection.
• The attacker sends the target block as the first
block of a new SSH packet on the connection.
– The recipient will treat the first 32 bits of that block
as the packet length field.
• The attacker then feeds random ciphertext
blocks into the SSH connection.
– One block at a time, waiting to see what happens
with each new block.
9
The attack
• Once enough data has arrived, the recipient
checks the MAC.
– This check will fail with overwhelming probability.
– Consequently the connection is terminated with an
error message.
– The number of random blocks required to trigger the
error message reveals the content of the 32-bit
packet length field.
– Because of CBC mode, this in turn reveals 32 bits of
the target plaintext block.
• Needs some simple XOR arithmetic to account for effect of
changing the chaining variable.
10
Performance of the attack
• As described, the attack would succeed with
probability 1, but would require the injection of
around 227 random blocks.
• In practice, various sanity checks on the length
field are performed by implementations….
11
Performance of the attack
According to RFC 4253:
• “Note that the `packet_length' field is also encrypted,
and processing it requires special care when sending
or receiving packets.”
• “The minimum size of a packet is 16 (or the cipher
block size, whichever is larger) bytes (plus `mac').
Implementations SHOULD decrypt the length after
receiving the first 8 (or cipher block size, whichever is
larger) bytes of a packet.”
• “… implementations SHOULD check that the packet
length is reasonable in order for the implementation to
avoid denial of service and/or buffer overflow attacks.”
12
OpenSSH
• In the OpenSSH implementation, two sanity checks are
carried out.
• When each of the checks fails, the SSH connection is
terminated in subtly different ways.
• This allows:
– A first attack verifiably recovering 14 bits of plaintext with
probability 2-14.
– A second attack verifiably recovering 32 bits of plaintext with
probability 2-18 (for a 128-bit block cipher).
• Both attacks result in termination of the SSH
connection with high probability.
• We implemented the attacks against OpenSSH 4.7 –
and they work.
13
Two remarks
• If a plaintext is repeated at a fixed position in
SSH packets over multiple connections, then
the attack can be iterated to boost success
rate.
– Application to password extraction.
– Some clients automatically reconnect on session
termination.
• The attack applies even if a fresh random IV is
used for each packet.
– Assuming this is sent in clear on the connection.
– The iterated attack becomes more effective.
14
Vendor reactions
• OpenSSH published a statement and committed a first fix.
– See www.openssh.com/txt/cbc.adv
– Both the statement and the bugfix only address the probability 2-14
OpenSSH specific attack.
• SunSSH increased the version number because of a security
vulnerability ``for the first time''.
– However, it seems they only fixed the 2-14 attack.
• SSH.com acknowledged that their products are vulnerable and
claim to have addressed the issue.
• WinSSHD acknowledged that their product is vulnerable and
issued an update which successfully prevents the attack.
• Dropbear added counter mode cipher support, which avoids some
security problems with the standard CBC mode.
• …
15
Work-arounds
• Use counter mode.
– Configurable, some implementations currently only support
ARC4).
– Stateful version required to prevent attacker exploiting
keystream repeats.
• Enforce use of counter mode.
– Not standards compliant with RFCs as currently written.
• Randomise the length field if length check fails.
– Tricky to implement.
• Don't encrypt the length field.
– Invasive and makes certain DoS attacks easier.
• Redesign BPP to use authenticated encryption with
associated data (AEAD) algorithm.
– Invasive, and still can’t safely encrypt length field.
16
Comparison with proven security
• Recall that Bellare et al. proved that variants of
the SSH BPP are provably secure.
– In particular, SSH-$NPC, i.e. randomised, perpacket IV with random padding field.
– Our attacks apply to this variant.
• So what went wrong?
17
Comparison with proven security
• The security model of Bellare et al. does model
errors during the BPP decryption process.
– Connection teardown is modeled by disallowing
access to decryption and encryption oracles after
any error event.
– Only a single type of error message is output.
– Our 2-14 attack against OpenSSH exploits the fact
that the errors are distinguishable.
– But even allowing only one error type, there is a very
simple distinguishing attack having probability 1
against SSH-$NPC!
18
Comparison with proven security
• Security model of Bellare et al. assumes that
ciphertexts are “self-describing” in terms of
length.
– Ciphertexts and plaintexts are handled in the model
as “atomic” strings.
– The model does not allow for the possibility that the
amount of data needed to complete the decryption
process might be governed by data that is produced
during the decryption process itself.
– Indeed, after an initial description of the BPP packet
format, the length field never appears again in their
analysis!
19
Limitations of provable security
• Our attack on SSH illustrates some of the limitations of
current approaches to provable security.
• How do we know what system features should be
included in a security model?
– What is the right amount of abstraction?
– How close to the implementation level do we need to go to
capture all significant attack vectors?
• c.f. Attack against SSL/TLS by Canvel et al. versus Krawczyk’s
security proof for SSL/TLS Record Layer.
– How high do we need to go to handle interactions between
low-level cryptography and the overall system?
• c.f. Attacks against IPsec exploiting error messages carried by an
upper layer protocol (ICMP) (P. and Yau, Degabriele and P.)
20
Future directions
• Can we extend current security models for
protocols to handle “implementation” issues
such as data formats, error processing and
side channels?
– What about accurate modeling for SSH?
– See P. and Watson (SCN 2008) for an example of
how to provably immunize CBC mode encryption
against the special class of Padding Oracle attacks.
– Is there a general theoretical approach which shows
how to securely handle error messages?
21
A closing quote
From Bellare et al.:
…in the modern era of strong cryptography it
would seem counterintuitive to voluntarily use a
protocol with low security when it is possible to
fix the security of SSH at low cost.
• Provable security is one of the best tools we
currently have.
• But how do we know that “fixing” SSH actually
improves security?
– Our attack applies equally to current BPP and to
provably secure SSH-$NPC.
22