581
一個網頁是如何從你的手機中盜竊數據的
介紹
今年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”。即使規範將協議“https://”和“https://”作為前綴，我們也可以選擇一個空協議，在這種情況下，我們應該可以在提供的URL本身中指定協議。
但是，Chrome已移除或根本沒有實現注入任意URL前綴的功能。以下是源文件中名為“webusb_descriptors.cc”的代碼片段。它解析接收到的描述頭，包括“iLandingPage”。將URL前綴限製為“https://”和“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("https://");
- 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設備。這可能導致設備被入侵。
本文作者：Covfefe
來源：51CTO
最後更新：2017-11-02 15:34:54