introduce

On September 15, chrome 61 released, enabling webusb as its default feature. Webusb is a JavaScript API that allows web pages to access connected USB devices. USB devices here refer to system and industrial USB devices, so common USB devices (such as webcam, HID or mass storage devices) are not supported. However, through the webusb API, many other USB devices can be accessed, and when the user authorizes the web page, he may not know the access level of the web page.

This article explores webusb's capabilities to gain insight into how it works, how it attacks, and privacy issues. We will explain the process required to access the device and how the browser handles permissions. Then we will discuss some security risks and demonstrate how a website can use webusb to establish an ADB connection to invade Android phones.

Basics

When the USB device is inserted into the host, the browser reads the descriptor sent by the device and stores it in the internal USB device memory. This process is handled by blink, chrome's browser kernel. The log can be viewed in chrome: / / device log (the get parameter "refresh = 1" is very useful).

According to the specification, a device can explicitly declare its support for webusb in the platform descriptor in its binary object store.

The browser stores each USB device in its own device memory. The accessibility of webusb is determined by native driver support. On windows, we can access every USB device processed by WinUsb driver through browser. Other devices such as mass storage devices, webcams or hid cannot be accessed through the network because they have special drivers for handling these devices.

According to the specification (and this blog post), once the device is registered, the browser will display a notification. It looks like this:

However, this kind of behavior is not easy to reproduce. We have tried on the following systems:

Windows 7, Chrome 61

Windows 10, Chrome 61

Debian, chromium 60 (chrome: / / flags / "enable experimental web platform features enabled)

Debian, Google Chrome 61

Arch Linux, Chromium 61

Arch Linux, Google Chrome 61

There is an interesting element in the platform descriptor called "ilandingpage". Even if the specification prefixes the protocols "http: / /" and "HTTPS: / /", we can choose an empty protocol. In this case, we should be able to specify the protocol in the provided URL itself.

However, chrome has removed or does not implement the ability to inject arbitrary URL prefixes at all. The following is a snippet of code in the source file called "webusb_descriptors. CC". It parses the received description headers, including "ilandingpage.". Limit the URL prefix to "http: / /" and "HTTPS: / /".

// Look up the URL prefix and append the rest of the data in the descriptor.  std::string url;  switch (bytes[2]) {    case 0:      url.append("http://");      break;    case 1:      url.append("https://");      break;    default:      return false;  }  url.append(reinterpret_cast<const char*>(bytes.data() + 3), length - 3);

Request access to device

Web pages can open prompts to request access to devices, which must specify filters to filter available devices. If the filter is empty, the user is allowed to select a device from all available devices. The prompt to open is as follows:

Users can see all available devices. The device name refers to the product name sent by itself. If no product name is specified, chrome tries to guess an expressive name from known information about the device. It then names the device "unknown device from < vendor? Name >". After the user selects the device and clicks "connect", he can be granted access to the device.

Permission processing

Permissions are handled by Chrome's permission API. Once the web page is granted access to the device, the access continues until the user manually revokes it. The API that handles permissions distinguishes "web page" according to its origin, that is, when there is a matching protocol, host and port, the browser will think that this web page is the same as another web page. The behavior of the browser to identify the unique device is not obvious, and the candidate target for identification is sent by the device in its description header. The candidate targets are as follows:

GUID

Vendor ID

Product ID

Although a GUID is a unique ID, it cannot be used to identify a device. The following is a screenshot of the log of inserting and pulling out the test device multiple times. It can be seen that each device has a different guid. Even so, after each insertion, the device is licensed and accessible, and no further license request is required.

This indicates that chrome uses a combination of vendor ID and product ID to identify the device.

Access device

Once a web page is granted access to the device, it can be accessed. First, it has to open the device. During the process of opening the device, it starts the session with the device, and then the device is locked, so that other tabs in the same browser session cannot be accessed. But another web page in another browser can still open the same device.

In order to communicate with a device, the browser must declare the interface to communicate with. After the interface is declared, any other application on the host cannot be declared. Using the declared interface, the page can communicate with the endpoint of the specified interface.

Next, the page starts the control transfer to set up the device, which basically specifies how it wants to communicate with the device and the exact functionality it requires. Once the device is set up, it can transfer data and complete all functions of USB device interface.

Check webusb support

We built a small proof of concept (POC) tool to easily determine if webusb supports devices. The tool tests whether it can declare the interface of at least one connected USB device. If it exists, it means that it can communicate with the device, so the device is supported.

However, the tool cannot test whether the USB device is not supported at all, because the reason why the interface cannot be declared is different. The interface can be declared by another program, or the browser may not have access to the system (Linux).

The tool is a simple static website. You can download it here. This is what it looks like:

To test whether the device supports it, click the select device button to open the permission prompt. This prompt lists all available USB devices. By selecting the device you want and clicking connect, the tool opens the device, traverses each available interface, and attempts to declare it. The results are recorded in the table at the bottom of the page. The declared interfaces column shows the number of interfaces that can be declared.

If you want to use supported devices elsewhere, you need to refresh the site or close the tab.

Security considerations

In general, webusb is secure, but like all newly added code, it expands the code base, so it also expands the attack area of the browser. This is a new technology, so the problem is inevitable, and there are preliminary opinions on some security conditions in this regard.

Webusb runs in blink, chrome's browser kernel. Therefore, it is found that the memory crash in webusb may not be more influential than that in other places in blink.

Web sites that implement webusb should ensure that XSS usage control is a priority. An attacker exploiting an XSS vulnerability may have the same access to a connected device as a web site, during which the user does not notice.

The authority to handle webusb may not be obvious to the user. When a page requests access to a USB device, the notification sent to the user does not contain any warnings, and the site will have complete, silent USB access to the device from this time on.

We construct a proof of concept (POC) to prove the problem. In this case, the webusb based ADB host implementation is used to access the connected Android phone. Once the user accepts the request, the page uses webusb to retrieve all the pictures from the camera folder. [click here to download POC]

With this access level, websites can not only steal every readable file from the file system, but also install APK, access cameras and microphones to monitor users, and possibly upgrade permissions to root.

This example is highly limited by user interaction, so the risk is greatly reduced - users have to grant web rights to their phones, activate USB debugging on their phones, and finally allow ADB connections from the host. So far, this only applies to Linux, because the implementation in windows is quite unstable. However, it can be used as an example of running a complex protocol on webusb, or it can show how a single click of a webusb request results in data disclosure.

You can see the POC operation in the video below. There are two virtual machines, one on the left as a malicious web server and one on the right as a victim. After the website is connected to the mobile phone, the ADB connection is confirmed on the mobile phone. Then all the captured camera images are retrieved and displayed. [click here to download the source code]

Video address: https://labs.mwrinfosecurity.com/assets/uploads/webadb-demo.mp4

Further research

Further research may focus on finding flaws in the implementation of webusb and may reveal memory crash bugs. However, the code base is relatively small, and new fixes continue to be written.

Another interesting object of investigation is to attack Chrome with a malicious USB device. The former may send the wrong USB descriptor and may trigger unexpected behavior in the browser. Chrome can help by adding virtual test devices to webusb (chrome: / / USB internals /). Such an attack vector requires physical access to the device, so it seems a bit unrealistic.

In addition, when studying webusb or any other new network standards, such as web Bluetooth or web NFC, please keep in mind that these functions are changing with each passing day, and even the information a month ago can be outdated.

summary

In general, webusb is determined to have good security standards due to management and restrictions during a limited review period. The devices supported are very limited, webusb cannot access webcam, hid and mass storage devices. However, after further study, we found that this is an interesting technology, especially when introducing significant changes or additional functions.

It is recommended that users never allow untrusted websites to access USB devices containing any sensitive data. This may cause the device to be intruded.

*Reference source: mwinfo security, covfefe compilation, reprint please indicate from freebuf.com