5. 攻擊所引發的後果

攻擊的輸出是Hoover利用通訊時間戳推斷的一連串使用者點選。在螢幕鍵盤輸入的用例場景中，輸出流轉換成使用者輸入的鍵位。在這一部分，我們討論可能的攻擊實現，技術，以及其中的思想。

5.1 侵犯使用者隱私

對於我們的攻擊，最直觀的後果是侵犯使用者隱私。實際上，深入分析點選流會暴露裝置主人的大量敏感資訊。要想知道為什麼，來看我們攻擊的輸出：

john

doehey hohn, tomorrow at noon, downtown starbucks is fne

with me.

google.compaypaljane.doehane1984

第一直覺，我們就能知道第一部分要麼是email要麼是簡訊。不僅如此，我們還知道收件人——可能是John——他們明天見面，而且我們還知道見面的時間地點。同樣的，第二部分我們知道使用者在用谷歌搜尋paypal，找某一個網站，然後後面她很可能登入網站，她的名字是Jane Doe,她的paypal賬號的資訊有可能是jane.doe（使用者名稱）和jane1984（密碼）。這只是一個簡單的例子，顯示了Hoover利用一連串使用者點選推斷使用者的敏感資訊是多麼容易。直觀上，也證明了如果敵手能夠獲取所有使用者輸入，在其他文字中找到密碼比隨機猜測要容易。

從上面的例子也可以觀察到，輸出存在一定的誤差，“j”和“h”——這兩個鍵位的位置比較接近。但是，因為是英語，利用基於字典的工具就可以糾正這個錯誤。如果包含錯誤的推斷鍵位是密碼——通常是無序序列——基於字典的技術可能就幫不上忙了。但是，在這些情況下，我們可以利用移動速度、角度和其他可能的特徵定義使用者的手指或觸控筆在鍵盤上的移動。很有可能這種措施能提高Hoover的鍵位推斷正確率，還有讓類似於‘j’和‘h’的鍵可以交換。記住這一點，從上面的例子中我們就可以很容易的推斷Jane的paypal密碼可能是jane1984.

深入研究使用者習慣對Hoover正確率的影響超出了本文的範圍。因此，這也說明這種攻擊的強度和廣度。

5.2 使用者的生物學資訊

到現在為止我們只是論述了在語義學上，通過聯絡Hoover手機到的使用者點選流，敵手能夠獲得什麼（例如，文字輸入，和朋友交換訊息，等等）。但是，Hoover收集到的資料還有其他隱患。實際上，它可以用來推測使用者的生物學資訊並刻畫使用者用裝置的互動方式。這是根據監聽器收集到的時間戳。

每次系統發生hover event，監聽器就會收集時間戳。尤其是，使用者按下（使用者點選），提起（輸入裝置離開螢幕）的時間戳。

根據這些時間戳，Hoover可提取到如下特徵：(i)點選時長。(ii)兩次連續點選的間隔，根據兩次touch down的間隔計算。(iii)兩次點選之間的懸浮時間，根據touch up event和下一個touch down event的間隔計算。這些特徵對於基於使用者生物學資訊的持續認證機制是必須的[29,36]。而且在[29,36]中提到的機制需要系統級實現，這很困難，而且會增加現有系統的複雜性。據我們所知，Hoover是第一款在app級實現的基於生物學資訊的認證機制。Hoover可以持續從點選中提取特徵去認證裝置主人，以及區分她與其他使用者，例如，盜取她裝置的小偷。

儘管有關生物學的資訊是一種認證的有效方法，但是同樣的資訊也可能被濫用傷害使用者。比如說，文獻[20]的作者就證明敵手是如何利用受害者的大量生物學資訊訓練並繞過基於按鍵的生物學認證系統。在這一點上，Hoover刻畫使用者輸入方式的潛在可能性在將來可能被人利用以傷害使用者。

6. 討論及應對策略

攻擊的成功依賴於對hover技術的不正當使用和Alert Window。現在我們來看可能的應對策略。我們發現，很難解決，要麼不能對抗攻擊，要麼會降低系統或hover技術的使用率。

6.1 限制使用hover event

本文所提到的攻擊利用Android作業系統關於hover event的資訊。尤其是，hover event的座標可以為螢幕上所有的view使用，即使這些view是後臺app（像Hoover）建立的。減輕攻擊的一種可能的方法是限制對hover event的檢測，僅允許前臺app形成的元件（包括view）。這樣，就算Hoover（執行在後臺）有覆蓋視窗的存在，攻擊者也無法在使用者進行輸入時追蹤輸入裝置的移動軌跡。但是這種方法會影響已存在的app的使用量，這些app為了更好的使用者體驗，以不同的方式使用Alert Window。一個例子就是，Facebook Messenger的ChatHead特性：如果它不能抓取hover event，這個特性就沒用，因為它都不能接收使用者點選。因此，一個view物件要麼同時註冊點選（觸控）事件和hover event，要麼就都沒有。

另一種可能的方法是減少由click引起的hover event，並限制第一個hover event僅為前臺Activity所用。這個方案會增加系統處理hover元件的複雜度，而且需要引入並恰當的管理新增的許可權。讓使用者去管理（複雜）許可權已經被證明不現實——大多數使用者更傾向於靜默同意他們要安裝的app所申請的所有許可權[18]。不僅僅是使用者，開發者也發現現有的許可權太複雜了，為了正確實現app功能，也更傾向於一次性申請所有許可權[9]。所以，在像Android這樣的開源系統中，引入額外的許可權並不是解決問題的正確方法。最後一種方法就是刪除或關掉裝置的hover特性。但是這樣會影響使用率。這也是為什麼Samsung裝置對於手指部分允許這種方法，但是對於觸控筆還是保留了hover。

6.2 Android 的觸控過濾特性

本節解釋為什麼filterTouchesWhenObscured機制不能用來抵禦我們的攻擊。首先，我們先簡要論述它的功能。Android系統的觸控過濾特性對於給定的UI元件，包括view，可以開啟或關閉。當給定的view開啟該功能時，所有在這個view外發生的點選（觸控）事件會被服務視窗模糊掉，不會收到任何觸控事件。也就是說，這個view不會從系統那裡收到關於這些點選的通知。

觸控過濾預設是關閉的，但是app開發者可以通過呼叫setfilterTouchesWhenObscured（boolean）或android:flterTouchesWhenObscured這個layout屬性為true的方式開啟。

如果Hoover要在點選時攔截元件，那觸控過濾就會危及它的隱密性——點選要到達的底層元件收不到點選，那麼使用者就會察覺。但是，Hoover從不在點選時阻擋螢幕區域。（要知道覆蓋視窗是及時建立和銷燬的，不會影響使用者互動，見第3部分）。所以即使所有服務和app都預設開啟觸控過濾，Hoover的正確率和隱密性也不會受到影響。

6.3 禁止0px view或者對FLAG_WATCH_OUTSIDE_TOUCH的啟用

Hoover利用0px view監聽螢幕上的觸控事件並告知惡意軟體點選的反生以便它能迅速啟用透明覆蓋視窗。因此，禁止服務建立0px view似乎是一種抵禦攻擊的簡單方法。但是，攻擊者也可以通過建立一個非常小的view，並將其置於螢幕上只要它不覆蓋前臺app的UI元件克服此困難。例如，可以是在底部的一條細細的黑線，所有不能和螢幕上的硬體邊界區分開來。

監聽器也用FLAG_WATCH_OUTSIDE_TOUCH檢測使用者何時點選。好像如果這個標誌是disabled，攻擊就會挺直。但是，沒有這個flag也可以用其他兩種方式替代：第一個是分析來自類似迴轉儀和加速計等感測器的資訊，在Android中接觸這些資訊不需要許可權[22]。第二個就是持續檢測proc資料夾中關於鍵盤處理的資訊，這在Android中也不需要許可權[17]。已有文獻證明這兩種方法在推測點選次數上的高正確率[17,22]。不僅如此，很多app都用到這個標誌。比如，當使用者在視窗外部點選時，該視窗要隨時反應（例如，消失）。這是一個很重要的標誌，很常用，而且很難說如果這個標誌disabled了，多少應用程式會崩潰。

6.4 限制透明View合理化或者限制系統服務

這種限制可以阻止利用透明覆蓋視窗。然而，高明的攻擊者依然有法子克服。比如，在鍵盤攻擊場景中，覆蓋視窗可以是非透明的並且是受害人手機上的鍵盤的複製圖。注意到鍵盤的佈局取決於裝置的規格（種類，模型，螢幕大小）。在Android中利用公開的WindowManager Interface的API可以很輕易的獲取這些資訊。那個類似鍵盤的覆蓋視窗就會像透明視窗那樣操作，而且不會被使用者察覺。如果攻擊者知道其設計和元件（例如，廣為人知的移動銀行或者Facebook的登陸介面），同樣的方法也可以用來手機使用者點選。

6.5 通知使用者關於覆蓋視窗，可信路徑

想法就是通過限制風格讓由後臺服務生成的view可以為使用者識別。限制風格是指在系統級別上應用容易辨認的邊框或結構，或者兩者。而且，系統應該強制所有的覆蓋view遵循這種風格，並限制它使用其他風格。但是，以可信路徑增加GUI控制元件[7,26,34]提醒使用者關於可能的攻擊（安全指示器）這種策略還沒有得到有效的驗證。這在文獻[7]的大量使用者研究中已經被證實：即使真的檢測到了可能的攻擊，而且應對策略已經準備就緒，依然有42%的使用者無動於衷。

這種可信路徑方法可以在使用者與惡意軟體互動時抵抗phishing（釣魚）攻擊。但是，要注意這並不是我們的攻擊方式，在我們的攻擊中，惡意軟體一直在後臺執行，而且不會影響使用者與前臺app的互動。即使安全指示器並不像文獻[7]那樣基於app，而是基於view出現，也須注意到Hoover不是靜態的。相反的，它在點選後出現的時間非常短（70ms），此時使用者的注意力並不在安全指示器上。

6.6 保護敏感view

這個想法是限制service生成的敏感view或者元件，像登入時的鍵盤，或者新app的安裝按鈕，被其他service的view（包括Alert

Window和Toast）覆蓋。一個可能的實現方案如下：引入在view類中引入新的屬性以明確對於給定的例項是否應該“可覆蓋（coverable）”。當設定了這個屬性，系統就強制螢幕上覆蓋它的的其他物件被“推出到”該view的邊界，例如，到螢幕上不會覆蓋它的其他區域。顯然，謹慎設計她的app並堅定需要不可覆蓋（non-coverable）是app開發者的責任。

另外，這些型別的view應該有一個最大尺寸並且不能覆蓋整個螢幕。不然，它就不可以應用其他服務，包括系統服務，在non-coverable的view下顯示Alert Window。這個方案可以減輕我們的攻擊和其它依賴於覆蓋視窗的攻擊，即使使用的是其他方法，例如phishing或者clickjacking。但是，對於開發者來說負擔太大，既要區分UI元件為coverable和non-coverable，還要考慮預料不到其他app或系統服務形成的view，像螢幕上的資訊提醒，系統Alert Window，等等。

7. 相關工作

要實現推斷使用者輸入這個目標的最大挑戰來自Android的基本規則：一次點選只能指向（然後被抓取）一個app。但是，前人的工作已經表明，惡意軟體可以利用好幾種技術繞過這條規則並推斷使用者輸入（例如，盜取密碼）。我們可以將手機應用phishing作為使用者輸入推斷的一個例子，其目標是盜取被釣魚的軟體的鍵盤輸入（通常是登入憑證）。雖然很有效，但是釣魚攻擊的限制就是它不能在官方應用市場釋出。而且，和我們的技術不同，釣魚攻擊需要分開對每一個app分別實現。

Hoover不會影響使用者體驗。相對於UI redressing（例如clickjacking）攻擊，它們也能夠移動裝置上的輸入推斷[7,14,24,27,28,35]，Hover具有更強的魯棒性和隱密性。UI redressing技術使用覆蓋視窗的方法和我們的在概念上不同。它們通常是用Alert Window或者Toast資訊覆蓋該使用者的元件[7,24]，在點選時，這樣要麼將使用者指向惡意介面（例如，假冒的釣魚登入視窗），要麼通過阻礙受害程式的功能影響使用者輸入（例如，覆蓋整個螢幕鍵盤的視窗）。這些攻擊會影響正常使用者體驗：受害程式不能接收輸入，那麼使用者就會察覺。

在系統範圍內推斷使用者輸入的另一個方法是利用通過手機平臺上類似迴轉儀，加速器等感測器收集到的資料[10,13,19,21-23,31,33,37]。讀取這些感測器資訊通常不需要特殊許可權。但是，這些感測器提供的訊號精確度低，因為它取決於環境條件（例如，使用者在執行的大巴上使用迴轉儀）。所以，根據邊通道得到的輸入位置一般正確率不足以區分全螢幕鍵盤按下的鍵。相對的，已經證明Hoover有高正確率，而且在觸控筆的場景下，推斷使用者鍵盤敲擊的誤差為2px。不同的是，在豎屏模式下的基於麥克風的推斷使用者擊鍵效果很好。另外，它的正確率取決於環境噪聲。

8. 總結

本文我們提出了一種新的使用者輸入推斷攻擊。我們實現了Hoover，一款概念驗證惡意軟體用來記錄使用者在支援hover技術的裝置上的輸入，不論是手指還是觸控筆。與前人不同的是，Hoover以高精確率和高粒度（在螢幕上點選位置級別上）記錄使用者的所有輸入。這個攻擊並不針對於某一給定的app，而是系統範圍內的，而且對使用者透明：它不以任何方式影響使用者與裝置的互動。

本文我們並沒有區分不同的手指。但是我們最初的實驗已經之處訓練per-finger模型可以提高攻擊正確率。應用技術檢測使用者使用的是哪一個手指[12]，並用正確的手指模型也可以提高正確率。這有待將來。

本文由看雪翻譯小組 lumou 編譯，來源Enis Ulqinaku、Luka Malisa、Julinda Stefa、Alessandro Mei、Srdjan Čapkun@ethz.ch 轉載請註明來自看雪社群

​