Security Advisory 2018-03-02 – WebUSB Bypass of U2F Phishing Protection

Tracking IDs: YSA-2018-02

Update June 13, 2018

In Chrome 61, released in September, 2017, Google included a feature called WebUSB. WebUSB allows websites to request direct access to USB devices through JavaScript. A web page could potentially access and interact with a USB device interface unless the operating system reserved exclusive access to that interface

On February 16, 2018, researchers Markus Vervier and Michele Orrù demonstrated how to circumvent the FIDO U2F origin check using WebUSB at OffensiveCon.  Yubico learned about this when we were contacted by a journalist at Wired Magazine on February 27, 2018. We reached out to Markus and Michele and they demonstrated the issue and showed us slides from their presentation on March 2, 2018. The research results we present below builds on Markus’s and Michele’s original work.

The origin check is performed by the FIDO Client (the web browser) and is a critical part of the U2F protocol that is used in preventing man-in-the-middle and phishing attacks. Markus and Michele showed how to use WebUSB to pass U2F requests to the USB CCID interface on the YubiKey NEO, thereby bypassing the origin check and creating a potential security issue. Yubico immediately began working with Google to remedy this issue and published  a security advisory on March 2, 2018.

The researchers said at the time that this exploit only worked on U2F devices that “…offer protocols for connecting to a browser other than the usual way FIDO U2F tokens communicate with a computer, known as the Human Interface Device or HID, which isn’t vulnerable to the attack.” (Wired Magazine, March 1, 2018).

The WebUSB security model was based on the theory that operating systems reserve exclusive access to certain sensitive USB device types, but it turns out that operating systems do not uniformly do so. Most U2F authenticators support U2F access only over the USB Human Interface Device (HID) interface. Linux does lock exclusive access to the USB HID interface. However, while investigating the claims in the article, we discovered that USB HID devices were accessible over WebUSB on other operating systems.

Using tools we developed for testing this, we were able to directly access all U2F devices we tested via HID, including those from other vendors than Yubico, bypass the origin check, and sign a fake U2F request. We are providing further details on our research and findings below. We first reported this issue to Google on March 1, 2018 and filed a formal bug report with Google on March 5, 2018. It was addressed in Chrome 67 and given CVE number CVE-2018-6125.

June 13th Update: We were just made aware that the original researchers reported the Windows HID issue to Google around the same time we submitted it to Google. We were not aware of this at the time, we independently discovered it while investigating the public CCID issue, and followed standard responsible disclosure practices by sending all our findings, including the Windows HID issue, only to the affected vendor in order to afford maximum protection for the ecosystem.

What Actions Do U2F Customers Need to Take?

Please update your Chrome browser to the latest version. Chrome 67 contains a device block list and interface class filtering. The latter prevents WebUSB access to audio, video, HID, mass storage, smart card and wireless controller interface classes. The former explicitly prevents access to certain sensitive devices, including a large number of U2F authenticators. This helps protect against using WebUSB to bypass the origin check, as well as a other potential problems.

In addition, we strongly recommend that customers be very careful with granting WebUSB access to any USB devices. The user must approve access on a per website, per device basis, but once it is granted, it is granted permanently. The user may, however, go to Chrome USB devices setting (chrome://settings/content/usbDevices) to manually revoke any granted access.

What Actions Do U2F Vendors Need to Take?

U2F vendors’ devices are likely protected by the blanket restrictions on access to HID devices. However, we encourage all vendors to evaluate if the U2F features of their devices are accessible over any other interfaces that are permitted by the U2F standard. If a particular interface class is not blocked, the vendor can request that Google add the device to the block list.  

Details of the Issue – WebUSB Background

WebUSB is a W3C community standard written by Google. Only Chrome implements this standard at this time. WebUSB enables device manufacturers and application developers to write device drivers in JavaScript for USB connected devices, enabling them to be accessed directly by any website on the Internet.

The goal of the WebUSB community group is to enable hardware manufacturers to develop web based applications that use their devices without installing drivers on the host computer. WebUSB was developed with the intent to to support hardware peripherals such as special-purpose educational, scientific and industrial devices in a sandboxed web application. Google enabled WebUSB by default in Chrome 61. There is currently no way for a customer to disable WebUSB in Chrome, nor can an enterprise administrator do so on a fleet of computers.

Report

Yubico learned of Markus and Michele’s research on February 27, 2018, Yubico began investigating immediately upon receiving notification of this issue, and published a security advisory on March 2, 2018.

Exploit Details

The U2F authentication flow is depicted in figure 1, below. The U2F protocol is designed to mitigate phishing attacks on web applications by ensuring that authentication requests originate from the correct site. This prevents a phishing site from executing a man-in-the-middle attack and gain access to a U2F protected site. The protocol requires the U2F client – the web browser – to perform this check. The U2F authenticator, in this case the YubiKey, cannot do so as it does not have access to the data required to do it, namely, the site the request was received from.

Because the browser is expected to verify the legitimacy of U2F requests, the hardware authenticator trusts, and responds to, is consequently a major security problem as it side-steps a key part of the U2F protocol.

Figure 1 – FIDO U2F Authentication Flow

In a phishing attack, an attacker would create a malicious website that mimics the look and feel of the legitimate site.

The attacker then tricks the user into presenting their username and password to the malicious web app which transmits them to the legitimate site for verification. In a single-factor authentication scenario – i.e. where only a username and password is used for authentication, the attacker is now logged into the legitimate website as the user.

When two-factor authentication using U2F is used, The legitimate site, after verifying the username/password, generates a challenge and sends it along with a “key handle” and an AppID (relying party URL) to what it thinks is the user, but which in the phishing attack is actually a malicious web site. The key handle contains information that enables the U2F authenticator to sign the authentication request, and the AppID is used to perform the origin check. The malicious web site passes this information along to the U2F client – the customer’s web browser. The browser verifies that the site it received the request from matches the AppID. In the phishing attack, this check fails, and the request is discarded.

However, under WebUSB the malicious site requests direct access to the authenticator over WebUSB. The customer is asked to approve this request through a Google Chrome pop-up message. If approved, the malicious web site now sends the raw authentication request to the U2F authenticator via the WebUSB API. The authenticator has no way to determine that this request is not coming through the normal browser channel, and assumes the origin check has passed. Consequently, the authenticator signs to request and returns it to the phishing site. This is shown in Figure 2.

Most U2F authenticators are USB devices that provide access to the U2F features over the USB HID interface. However, the U2F standard does not require that U2F is only permitted over HID and for different physical interfaces, other interface classes are used. For instance, a near-field communication (NFC) authenticator, such as the YubiKey NEO, provides U2F functionality over the chip card interface device (CCID) when used over NFC, and supports this interface over USB as well. This is permitted by the U2F standard.

The original researcher’s report demonstrated how to bypass the origin checking by accessing the USB CCID interface via WebUSB. 

Figure 2 – FIDO U2F Phishing Attack Using WebUSB

Difference Between What Yubico Found and What Was Reported in February

The vulnerability that was reported to us in February mentioned that CCID is the only affected interface. Yubico’s own researchers developed a mechanism to access HID devices that worked on Windows and Mac, enabling us to execute a man-in-the-middle attack under certain conditions on a far broader range of platforms using any USB U2F authenticator from any vendor.

Considering the significant impact of this discovery we opted to help protect all U2F customers by responsibly disclosing our findings to Google and working with Google to help protect our mutual customers.

Scope of the Issue

Customers running chrome version 61-66 are at risk from this issue. Customers who upgrade to Chrome 67 are protected.

Affected Protocols

Prior to Chrome 67, WebUSB could also be used to attack other device types and protocols. For instance, Markus and Michele were able to use it to obtain a PGP signature from a PGP enabled YubiKey over WebUSB. A modified exploit could obtain a smart card signature from a USB-connected smart card (although those typically require the user to enter a PIN code).

Is This a Flaw in a Yubico Product?

No. Yubico successfully bypassed the origin check on all U2F authenticators we tested from multiple vendors. WebUSB enables phishing sites to bypass the U2F origin check, but the origin check is the responsibility of the U2F client – the web browser – not the authenticator. The YubiKey used in the original researcher’s report operates exactly as intended and within the requirements of the U2F protocol. Other devices, such as smart cards, would also be directly accessible by WebUSB, enabling other exploit scenarios. The flaw is that WebUSB allows direct access to USB devices from web sites, bypassing protections the browser and the host OS are expected to perform.

Timeline

2017-09-06 Google releases Chrome 61 with WebUSB enabled by default
2018-02-16 Researchers give a talk at OffensiveCon about how they were able to generate an assertion from a YubiKey Neo using WebUSB over smart-card interface.
2018-02-27 Yubico notified about CCID issue and we started investigating
2018-03-01 Yubico researchers discover that HID interfaces can be claimed on Windows and does preliminary private outreach to Google with information on this finding. Google requests formal bug report
2018-03-02 Yubico talks to researchers about the CCID vector, and publishes a Security Advisory
2018-03-03 Researchers formally report ability to claim HID interfaces to Google. The content of this bug report was shared with Yubico on 2018-06-13
2018-03-04 Yubico confirms that all the FIDO U2F tokens were affected by the WebUSB HID vulnerability
2018-03-05 Yubico formally notifies Google of the HID, NFC, and smartcard/CCID specific vulnerabilities in bug 818592
2018-03-06 Google disables WebUSB via remote kill switch
2018-03-06 Google rolls out Chrome 65 with blacklist for Yubico devices and other FIDO U2F devices manufactured by other vendors
2018-03-07 Google enables WebUSB with blacklist in place for Yubico devices
2018-05-29 Google rolls out Chrome 67 with interface class filtering for Audio, Video, HID, Mass Storage, Smart Card, Wireless Controller interface classes

 

Update March 7, 2018

Today, Google released Chrome 65. Chrome 65 blocks access to all impacted Yubico products over WebUSB, which protects against WebUSB Bypass of the U2F Phishing Protection against YubiKeys. This updated browser version also re-enables WebUSB. All YubiKey users are now protected from this unintended issue and we will continue to work with Google to ensure that Yubico customers remain protected.

To check whether you are using the latest version of Chrome, please navigate to chrome://help in your browser address bar. You must restart Chrome to complete the installation.

Update March 6, 2018

Today, Google published an automatic fix to existing Google Chrome users that disables WebUSB to address this issue in the interim. YubiKey NEO users are now safe from this unintended issue. WebUSB being disabled blocks attempted attacks until a permanent fix is available. The automatic fix is being made available without a separate Chrome update as long as you are using the latest version of Chrome. To make sure you are using the latest version of Chrome, go to chrome://help in your browser address bar to automatically check. We continue to work with Google on addressing these issues permanently.

Background

On February 27, 2018, Yubico was informed of a conference presentation on February 16, 2018 that demonstrated a potential security issue with the new WebUSB feature in Google Chrome. WebUSB allows websites to directly access USB devices. The presentation used a YubiKey NEO to demonstrate how an attacker could use WebUSB to bypass the origin checking built into Chrome that provides phishing protection for the U2F protocol.

In the demonstration it was shown that if a victim agreed to give a phishing site access via WebUSB to the YubiKey NEO in the USB port, and the victim also was successfully tricked into touching the YubiKey NEO, the U2F phishing protection could be bypassed. The researchers argued that this could be achieved with social engineering.

Summary Of The Issue

The U2F protocol was designed to protect against phishing by requiring that the origin of authentication requests for the intended website be automatically and transparently validated by the U2F client (the browser) and sent to the authenticator (the authentication token) without the need for user involvement. In certain circumstances, WebUSB allows an attacker to bypass the browser U2F origin verification and pass information directly to the authenticator. This means the information may not be trustworthy and as a result may cause the authenticator to process authentication requests originating from a phishing site.

Mitigating Factors

We recommend that users click “Cancel” in response to any dialog boxes appearing in Chrome requesting WebUSB access to YubiKeys. The attack cannot proceed unless the user explicitly grants access to the U2F device by clicking “Connect” in response to the WebUSB request. The user must approve WebUSB access on a per-site and per-device basis so it is important for users to not click “Connect” for any website.

Figure 1 shows the approval dialog:

WebUSB Example
Figure 1: The WebUSB Access Approval Dialog for the Chrome Browser

 

In addition, because WebUSB does not provide a way to bypass the test-of-user-presence in the YubiKey NEO, for the phishing attack to succeed, the user would also have to touch the key to approve the authentication request.

The researchers were careful to note that their “technique doesn’t demonstrate a flaw in Yubico’s products so much as a very unintended byproduct of Chrome’s WebUSB feature”.

Solution

In Chrome 65, which is currently in beta, Google plans to implement a block list for WebUSB that is expected to mitigate this issue.

It is always important to keep browsers up to date with the latest patches. To make sure you are using the latest version of Chrome, go to chrome://help in your browser address bar to automatically check.

FAQ

  • Why can the U2F Authenticator not validate the origin?
    • Under the U2F protocol, the browser is responsible for validating the origin of the authentication request and sending it to the authenticator because the browser is the only component that has the information to do so. The authenticator relies on the site information provided by the browser being trustworthy. The researchers demonstrated how WebUSB can send arbitrary site information directly to the authenticator, bypassing the trusted path between the browser and the authenticator.
  • Is there a way to disable WebUSB entirely?
    • On March 6, 2018, Google published an automatic fix to existing Google Chrome users that disables WebUSB to address this issue in the interim.
  • I approved WebUSB access for a site/device. How do I revoke it?
    • Open Chrome Settings
    • Scroll to the bottom and click Advanced
    • Click on Content settings
    • Click on USB devices
    • Locate the device you wish to remove, and the website you want to revoke access from, then click the three dots and select “Remove”