HTTPS Bicycle Attack - obtaining passwords from TLS encrypted browser requests

A paper detailing a new attack vector on TLS was released on December 30. The attack, known as the HTTPS Bicycle Attack, is able to determine the length of specific parts of the plain-text data underneath captured TLS packets using a side-channel attack with already known information. The attack has a few prerequisites but could be applied in a real world scenario, and is completely undetectable due to its passive nature.

Executive Summary

The HTTPS Bicycle attack can result in the length of personal and secret data being exposed from a packet capture of a user's HTTPS traffic. For example, the length of passwords and other data (such as GPS co-ordinates) can be determined simply by analysing the lengths of the encrypted traffic.

Some of the key observations of this attack are as below:

• Requires a packet capture containing HTTPS (TLS) traffic from a browser to a website
• The TLS traffic must use a stream-based cipher
• Can reveal the lengths of unknown data as long as the length of the rest of the data is known - this includes passwords, GPS data and IP addresses
• Packet captures from several years ago could be vulnerable to this attack, with no mitigation possible
• The real world impact is unknown, as there are several prerequisites that may be hard to fulfill.

This leads us into interesting discussions on the resilience of passwords as a form of authentication method. First we will explain how the attack works.

How Does the Attack Work?

The Bicycle attack, in the context of obtaining the length of a user's password from a browser request, is fairly simple. All a user needs to do is have a packet capture of requests to a known site, including an authentication (login) request containing an already known username and an unknown plain-text password. If an attacker can determine the user's browser and how that browser would send requests to the site, they can subtract the length of all the known data the browser would send except for the piece of information they are interested in, which will result in them knowing the length of the unknown data.

This particular attack scenario can be summarised from the point of view of an attacker:

1. Obtain a packet capture (i.e. via a Man-in-the-Middle attack) which has stream-cipher TLS traffic of encrypted browser requests to a known website, including one where there was likely to be a password sent in an authentication request. The target site may be revealed in the packet capture in the form of a DNS request, or the attacker may be able to find this out with some reconnaissance.
2. Obtain a "User-Agent" string from the packet capture or determine which browser the target was using.
3. Replicate browser requests to the site using the same browser as determined in (2). This will reveal the lengths of the requests to various pages on the site.
4. From the encrypted TLS payloads of the browser requests in the packet capture, extract the lengths of the payloads.
5. Compare the Pearson correlation coefficient for the plain-text and encrypted requests. This will enable us to compare plain-text and encrypted request lengths in order to reveal which encrypted TLS requests are for which pages (URLs) of the website.
6. From (5) you should now know which TLS encrypted request is for the login page of the website. You can then subtract the length of the known headers that the browser would send to this page, including any possible cookies that are static enough in length to be determined. Also subtract the length of the posted or queried data containing the user's username that we already know, and anything else that is possible to pre-determine in the request.
7. The length you end up with should be the length of the user's password

Cracking Passwords

If we successfully reproduce the Bicycle attack and obtain the length of a user's password, we must still try to crack the password and this can only be done by sending login requests to the target website unless we can leverage a known plain-text attack vulnerability on the stream-cipher. If we know that the password length is 8 characters and only contains letters and no numbers or symbols, we have a dictionary containing 200,000 possible 8 character passwords in which our target password exists, and we are able to send 10 login requests to the target website every second, then the password should be revealed within 5.5 hours. This could be further improved by checking for more common passwords first. However, this kind of approach requires that the website we are sending the login attempts to has no threshold or prevention on failed login attempts.

It would not be feasible to do a true brute forcing of the password by sending login attempts to the target website, so our password should be good enough to avoid typical dictionary attacks. A strong password of at least 8 characters which contains numbers and symbols should make cracking a lot more difficult.

How Can the Attack be Mitigated?

This attack cannot be mitigated for packet captures that already exist and are vulnerable as per the requirements mentioned. However, a strong password as previously suggested will ensure that cracking it is somewhat unfeasible. Two-factor authentication for websites will also prevent access to your account, even if your password is compromised.

It is also recommended that web platform developers and website operators ensure that they do not allow their web applications to expose browsing users to this vulnerability.

In order to prevent this attack in any future scenarios, the following criteria should be met by website operators:

• Turn off support for TLS stream-ciphers.
• Ensure that you are supporting the newest version of TLS, currently version 1.2.

And the following criteria should be met by web platform developers:

• For any secret information (such as passwords, GPS co-ordinates, unique IDs etc.) being sent in browser requests, ensure that they are padded or hashed to a fixed length.

Summary

On the surface, and despite the requirements for a successful attack, the HTTPS Bicycle attack is a real and dangerous threat that could potentially result in a new wave of personal and secret information being divulged in the near future. It is yet to be determined how wide scale this issue could be and how feasible the attack is in a real world scenario, but the lack of retrospective mitigation poses a big risk to users. In this case the burden of mitigation falls on the shoulders of the user who should ensure his or her password is sufficiently strong, and also the website operators and web platform developers who should ensure that they are fully up to date and are taking steps to prevent this attack from occurring in the future.

You can keep up to date with the discussion of HTTPS Bicycle on Reddit at https://www.reddit.com/r/netsec/comments/3zc5qu/https_bicycle_attack/

References

Guido Vranken (2015), "HTTPS Bicycle Attack", https://guidovranken.files.wordpress.com/2015/12/https-bicycle-attack.pdf