介紹

今年9月15日，Chrome61發布，它啟用了WebUSB作為其默認功能。而WebUSB是一個Javascript API，可以允許網頁訪問已連接的USB設備。這里的USB設備是指系統和工業的USB設備，所以不支持常見的USB設備(比如網絡攝像頭，HID或大容量儲存設備)。然而通過WebUSB API，很多其他的USB設備可以被訪問，且當用戶授權給網頁時，自己可能根本不了解網頁獲取的訪問權限級別。

這篇文章探尋WebUSB的功能，以深入了解其工作原理，攻擊方法及隱私問題。我們會解釋訪問設備所需的過程，以及瀏覽器是如何處理權限的，然后我們會討論一些安全隱患，并演示一個網站如何使用WebUSB來建立ADB連接來入侵安卓手機。

基礎

當USB設備插入主機時，瀏覽器會讀取設備發送的描述符，然后將其儲存在內部USB設備儲存器中。此過程由Chrome的瀏覽器內核Blink處理。日志可以在chrome://device-log(GET參數“refresh = 1”非常有用)中查看。

根據規范，設備可以在其二進制對象存儲中的平臺描述符中明確地聲明對WebUSB的支持。

瀏覽器將每個USB設備存儲在自己的設備存儲器中。WebUSB的可訪問性由本機驅動程序支持所決定。在Windows上，我們可以通過瀏覽器訪問由WinUSB驅動程序處理的每個USB設備。其他的諸如大容量存儲設備，網絡攝像頭或HID等就無法通過網絡訪問了，因為它們具有處理這些設備的專用驅動程序。

根據規范(和本博客文章)，一旦設備注冊，瀏覽器就會顯示一條通知。看起來像這樣：

但是，這種行為不容易重現。我們在以下系統上嘗試過：

Windows 7, Chrome 61 
 
Windows 10, Chrome 61 
 
Debian, Chromium 60 (啟用了chrome://flags/#enable-experimental-web-platform-features) 
 
Debian, Google Chrome 61 
 
Arch Linux, Chromium 61 
 
Arch Linux, Google Chrome 61 

Platform Descriptor中有一個有趣的元素叫做“iLandingPage”。即使規范將協議“http://”和“https://”作為前綴，我們也可以選擇一個空協議，在這種情況下，我們應該可以在提供的URL本身中指定協議。

但是，Chrome已移除或根本沒有實現注入任意URL前綴的功能。以下是源文件中名為“webusb_descriptors.cc”的代碼片段。它解析接收到的描述頭，包括“iLandingPage”。將URL前綴限制為“http://”和“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); 

請求訪問設備

網頁可以打開提示請求訪問設備，它必須指定過濾器來過濾可用的設備。如果過濾器為空，那么即允許用戶從所有可用設備中選擇設備。打開的提示如下所示：

用戶可以看到所有(過濾的)可用設備。設備名稱引用于自身所發送的產品名稱。如果沒有指定產品名稱，Chrome會嘗試通過有關設備的已知信息來猜測一個表達性的名稱。然后，它會將設備命名為“來自<vendor_name>”的未知設備。用戶選擇設備并點擊“連接”后，即可授予訪問設備的權限。

權限處理

權限由Chrome的permission API處理。一旦向網頁授予權限訪問設備，權限會一直持續，直到用戶手動撤銷。處理權限的API根據其根源區分“網頁”，即當具有匹配的協議，主機和端口時，瀏覽器就會認為這個網頁與另一網頁相同。瀏覽器識別唯一設備的行為不是很明顯，用于識別的候選目標由設備在其描述頭中發送。候選目標如下：

GUID 
 
Vendor ID 
 
Product ID 

雖然GUID是唯一的ID，但它不能用于識別設備。以下是多次插入和拔出測試設備的日志的截圖，可見每次設備都有不一樣的GUID，即便如此，每次插入后設備都被許可且可以訪問，不需要進一步的許可請求。

這表明Chrome使用Vendor ID和Product ID的組合來標識設備。

訪問設備

一旦網頁被授予訪問設備的權限，那么就可以訪問它了。首先其必須打開設備，打開設備的過程中就開始了與設備的會話，然后設備會被鎖定，這樣同一瀏覽器會話中的其他選項卡就無法訪問了。但是另一個瀏覽器的另一個網頁仍然可以打開相同設備。

為了與設備進行通信，瀏覽器必須聲明要與之通信的接口。在聲明接口之后，主機上的任何其他應用程序都是無法聲明的。使用聲明的接口，頁面可以與指定接口的端點通信。

接下來，頁面啟動控制傳輸來設置設備，這基本上指定了它希望與設備通信的方式以及所要求的確切功能。一旦設備設置好，它就可以傳輸數據，并且完成USB設備接口的所有功能。

檢查WebUSB的支持

我們構建了一個小型概念性證明(PoC)工具，可以輕松確定WebUSB是否支持設備。該工具測試是否能至少聲明一個已連接的USB設備的接口，如果存在，那么就意味著它可以與設備通信，因此該設備是被支持的。

不過該工具無法測試USB設備是否完全不受支持，因為無法聲明接口的原因有所不同。該接口可以被另一個程序聲明，或瀏覽器可能沒有系統(Linux)的訪問權限。

該工具是一個簡單的靜態網站。你可以點擊這里下載。這是它的外觀：

要測試設備是否支持，請單擊“選擇設備”按鈕打開權限提示。此提示將列出所有可用的USB設備。通過選擇所需的設備并單擊“連接”，工具將打開設備，并遍歷每個可用的界面，并嘗試聲明。結果記錄在頁面底部的表格中。被聲明的interfaces列顯示可以聲明的接口編號。

如果要在其他地方使用受支持的設備，則需要刷新站點或關閉該選項卡。

安全性考慮

總體來說WebUSB是安全的，但是像所有新添加的代碼一樣，它擴大了代碼庫，因此也擴大了瀏覽器的受攻擊面。這是一種新技術，所以問題是不可避免的，在這方面的一些安全狀況已經有了初步意見。

WebUSB在Chrome的瀏覽器內核Blink中運行。因此，發現WebUSB中的內存崩潰可能并不比Blink中其他地方的內存崩潰更影響更大。

實現WebUSB的網站應確保節制使用XSS是一個優先事項。利用XSS漏洞的攻擊者可能具有與網站相同的對已連接設備的訪問權，期間用戶并不會注意到。

處理WebUSB的權限對于用戶可能不是很明顯。當頁面請求訪問USB設備時，向用戶發出的通知不包含任何警告，而該站點從這時起將具有對該設備的完整的，靜默的USB訪問權限。

我們構建了一個概念性證明(PoC)來證明這個問題。在這種情況下，基于WebUSB的ADB主機實現被用于訪問連接的Android手機。一旦用戶接受請求，該頁面使用WebUSB可以從相機文件夾中檢索所有圖片。【點擊這里下載PoC】

通過這種訪問級別，網站不僅可以從文件系統中竊取每個可讀取的文件，還可以安裝APK，訪問攝像頭和麥克風來監視用戶，并可能將權限升級到root。

該示例受到用戶交互的高度限制，因此風險大大降低 – 用戶必須向其手機授予網頁權限，在其手機上激活USB調試，并最終允許來自主機的ADB連接。到目前為止，這只適用于Linux，因為在Windows中的實現相當不穩定。然而，它既可以作為在WebUSB上運行復雜協議的示例，也可以顯示WebUSB請求的一次點擊如何導致數據泄露。

您可以在下面的視頻中看到PoC的操作。有兩個虛擬機，左邊的一個作為惡意的Web服務器，右邊的一個作為受害者。網站連接到手機后，ADB連接在手機上確認。然后檢索所有拍攝的照相機圖像并將其顯示出來。【點擊這里下載源碼】

視頻地址：https://labs.mwrinfosecurity.com/assets/Uploads/WebADB-Demo.mp4

進一步的研究

進一步的研究可能集中在發現實現WebUSB的缺陷，并可能會披露內存崩潰bug。然而，代碼庫相對較小，并且新的修復也在持續寫入。

另一個有趣的調查對象是用惡意的USB設備攻擊Chrome。前者可能會發送錯誤的USB描述符，并可能在瀏覽器中觸發未預期的行為。 Chrome可以為WebUSB(chrome://usb-internals/)添加虛擬測試設備，這很有幫助。這樣的攻擊向量需要物理訪問設備，所以顯得有點不太現實。

另外，在研究WebUSB或任何其他新的網絡標準時，如Web藍牙或Web NFC，請記住，這些功能日新月異，甚至一個月前的信息可能已經過時了。

總結

一般來說，由于在有限的審查期間管理和限制，WebUSB被確定具有良好的安全標準。支持的設備非常有限，WebUSB無法訪問網絡攝像頭，HID和大容量存儲設備。然而進一步研究后，我們發現這是一個有趣的技術，特別是在引入重大變化或附加功能時。

建議用戶永遠不要讓不受信任的網站訪問包含任何敏感數據的USB設備。這可能導致設備被入侵。