Image for post
Image for post

This Attack Has Been Around for 20 Years — And It’s Back Again With The Bleichenbacher Oracle Attack on VPNs

The Bleichenbacher attack [here] just refuses to go away. It has been known about for 20 years, and has been the core of many attacks on SSL. It also returned in 2017 in the form of ROBOT (Return Of Bleichenbacher’s Oracle Threat https://robotattack.org/), and now at the core of a new VPN vulnerability.

Introduction

We have a long legacy within cryptography, and where our tunnels are set up by the client selecting from a number of possible methods that the server provides. Unfortunately, this can leave a race to the bottom, where an intruder can force a downgrade attack, and where they pick the cryptography suites which are known to be weak. These include MD5, RC4, DES and others.

Now the IPSec protocol — which creates VPNs and is often the core foundation of corporate security — has been shown to have a vulnerability with the IKEv1 key exchange method. This vulnerability allows an intruder to listen to the secure communications. While an upgraded protocol — IKEv2 — was meant to replace IKEv1, it is still supported on many networks.

The paper has been published in USENIX (15–17 August 2018) and involves researchers from Ruhr-University Bochum and the University of Opole [paper]:

Image for post
Image for post

Bleichenbacher Oracle Attack

The new attack is defined as the Bleichenbacher Oracle Attack (rated with a CVSS score of 5.9 — and a medium risk). Just like the original attack (which is outlined in the next section), it operates by sending errors to the VPN server, and where the server replies with corrupted messages. These returned messages allow the intruder to discover a bit more of the information each time, and then can mimic one of the parties involved in the secure tunnel.

The vulnerability is not based on the standard, but on poor implementation from vendors. At the current time, four vendors have been shown to be weak against the attack:

Another part of the paper outlines that both the IKEv1 and IKEv2 methods are weak when using a Pre-Shared Key (PSK).

Let’s first under outline the basic principles of the Bleichenbacher’s attack.

Bleichenbacher’s attack

A demo of the core principles are here.

Let’s say that Eve is attacking the server. In the message she sends, there’s padding of the pre-shared key (as it is much smaller than the public modulus — n). In PKCS#1 v1.5 padding we then have two bytes at the start:

Eve then captures the cipher in the handshake and which contains the SSL pre-shared key (M):

C=M (mod N)

She then plays it back to the server, but adds an ‘s’ value (where she multiplies the cipher (c ) by s to the power of e (mod N)):

C′=C×(sᵉ) (mod N)

where e and N are the known public key elements. The server decrypts and gets:

M′=(C(sᵉ))ᵈ (mod N)=C d×sᵉᵈ (mod N)=M×s (mod N)

M=Cs

When the server reads this, the first two bytes are likely to be incorrect, so it responds to say “Bad Crypto!”. Eve then keeps trying with different s values, until the server gives her a positive response, and she’s then on her way to finding the key. As we have 16 bits at the start, it will take us between 30,000 (1 in 215 which is 1-in-32,728) and 130,000 attempts (1 in 217 which is 1-in-131,073) to get a successful access.

We use padding to make sure that M (the pre-shared key) is the same length as the modulus (n). As M is only 48 bytes, we need to pad to give a length equal to n (256 bytes for a 2048-bit key).

Image for post
Image for post

In the end we just need to divide the original cipher by the value we have found, and we get M.

In this case we capture the cipher with M (which starts with \x00\x02), and then play it back with the addition of sᵉ, and then detect when there is a success in the cipher code:

Let’s select:

The calculation of n and PHI is:

We can select e as:

Next we can calculate d from:

Then, with a message of 688, we get:

Cipher=(688)⁷⁹ mod 3337=1570

Decoded=(1570)¹⁰¹⁹ mod 3337=688

A sample run is [here]:

Conclusions

TLS 1.3 finally closes the door (hopefully) on the Bleichenbacher’s attack. Your organisation should aim to migrate to TLS 1.3, and switch have already switched off SSL v2, SSL v3, and TLS 1.0, but should be looking to migrate away from TLS 1.1. But the attack refuses to go away, and where it has now identified as a significant vulnerability on VPN systems.

Here is a bit of fun with the attack:

ASecuritySite: When Bob Met Alice

This publication brings together interesting articles…

Prof Bill Buchanan OBE

Written by

Professor of Cryptography. Serial innovator. Believer in fairness, justice & freedom. EU Citizen. Auld Reekie native. Old World Breaker. New World Creator.

ASecuritySite: When Bob Met Alice

This publication brings together interesting articles related to cyber security.

Prof Bill Buchanan OBE

Written by

Professor of Cryptography. Serial innovator. Believer in fairness, justice & freedom. EU Citizen. Auld Reekie native. Old World Breaker. New World Creator.

ASecuritySite: When Bob Met Alice

This publication brings together interesting articles related to cyber security.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store