1 / 22

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. Plaintext Recovery Attacks Against SSH. Status of this talk. The results of this talk are unpublished but submitted for publication.

gizi
Download Presentation

Plaintext Recovery Attacks Against SSH

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Kenny Paterson Information Security Group Royal Holloway, University of London kenny.paterson@rhul.ac.uk Joint work with Martin Albrecht and Gaven Watson Plaintext Recovery Attacks Against SSH

  2. Status of this talk • 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, CVE-2008-5161). • From the advisory and subsequent vendor patches it would be fairly easy to reverse engineer the attack. CINS/F1-01

  3. SSH 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 CINS/F1-01

  4. SSH • 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. CINS/F1-01

  5. The SSH BPP • 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. CINS/F1-01

  6. 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.

  7. CBC mode decryption

  8. 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.

  9. 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.

  10. 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.

  11. 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….

  12. 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.”

  13. 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.

  14. 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.

  15. 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. • …

  16. 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.

  17. 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, per-packet IV with random padding field. • Our attacks apply to this variant. • So what went wrong?

  18. 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!

  19. 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!

  20. 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.)

  21. 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?

  22. 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.

More Related