Phishing Attacks on Modern Android
出處:CCS 2018
作者:Simone Aonzo, Alessio Merlo, Giulio Tavella, Yanick Fratantonio
原文連結: ofollow,noindex" target="_blank">http://www.s3.eurecom.fr/~yanick/publications/2018_ccs_phishing.pdf
文章概述
安卓系統為了便利性引入了許多新的功能。這篇文章中,作者對現有的四款比較著名的密碼管理App以及安卓系統提供的Google Smart Lock(GSL)服務進行了分析,並利用密碼管理器(Password Managers, PMs in short)和即時App(Instant App)這兩個新功能在設計上的不足針對自動填充密碼功能實現了安卓系統上的全新釣魚攻擊。該種攻擊方式比現有的釣魚攻擊方式更容易實現。在此基礎上,作者設計了新的API來避免該種釣魚攻擊方式的發生,但他也表示自動填充密碼功能的安全實現需要整個開發者社群共同努力。
研究背景
1. 移動端密碼管理 (Mobile password managers)
密碼管理技術最早在Web端被廣泛使用,可以幫助使用者針對不同的網站建立不同的偽隨機密碼,並在使用者登入時根據域名提示並填充相應的登入密碼,在提供便利性的同時減少簡單密碼、易猜測密碼、跨站使用相同密碼等不安全現象的發生。隨著移動平臺的發展,密碼管理技術也被移植到移動端,並以App的形式提供類似的管理、提示並自動填充密碼的功能。如果要實現自動填充功能,必然涉及到App之間的互動,然而安卓的沙盒機制對此有所限制。目前來看有三種機制能夠幫助繞過沙盒的限制,實現這一功能: 1. Accessibility Service(a11y, in short) a11y本意是用來幫助殘疾人士的,它使得執行在後臺的App能夠在“Accessibility Events”出現的情況下接收來自系統的回撥,同時App也可以獲取一些目前執行的App的一些上下文資訊,包括App的包名等。開發人員利用這一功能開發出很多新的用途,其中提示並自動填充密碼就是其中之一。PMs利用a11y來確定使用者在使用哪一App、當前介面是否有可以填充憑證(credentials)的欄位,並利用它來和目標App進行互動。然而,近些年很多研究表明a11y也被用來進行竊取使用者個人資訊等惡意操作。因此,Google也在系統層面上開發出新的Autofill Framework幫助開發者實現自動填充密碼功能。 2. Autofill Framework Autofill Framework在安卓8.0之後被引入,它可以讓PMs確定使用者正在和哪一個App進行互動,也可以讓App利用程式設計方式填充憑據欄位。但這要求想要適配的App申請BIND_AUTOFILL_SERVICE許可權並補充相關的XML屬性。 3. OpenYOLO(YOLO stands for “You Only Login Once”) OpenYOLO協議是Google和Dashlane共同開發的協議,協議包含客戶端和服務端兩部分,不依賴於a11y和Autofill Framework,但它需要對那些支援提示並自動填充密碼功能的App進行改寫,在已有程式碼中增加OpenYOLO客戶端。實際執行時,客戶端通過Intent等機制和服務端(在適配OpenYOLO協議的PMs中)進行通訊獲取相關憑證,具體如下圖所示。
然而,根據作者的研究,這三種機制在設計上存在一個通病:利用App的包名作為識別App的主要資訊。這也是之後作者設計的釣魚攻擊能夠成功的原因之一。
2. 即時App (Instant App)
即時App技術由Google實現,允許使用者在不安裝App的情況下進行“試用”。開發者需要上傳他們App的一小部分,也就是Instant App, 並附上一個URL pattern,谷歌會利用Digital Asset Links協議驗證URL pattern所屬域名和App是否互相對應。實際應用場景中,使用者點選某一URL並確認後,Instant App(小於4M)即被下載並執行在使用者的裝置上,功能上類似國內的微信小程式,但在實現技術上有所不同。 然而這種技術能夠讓攻擊者在不需要安裝App的情況下對使用者裝置UI擁有完全的控制,更便於惡意App偽裝為真正的App,進而使得作者設計的釣魚攻擊在實際場景中更容易實現。
案例分析
1. The Mapping Problem
和Web端可以直接利用域名來確認服務端身份不同,在移動端PMs需要建立起App與其關聯的網站之間的對映(Mapping)才能確定應該提示並填充哪一個憑證。然而PMs所建立對映存在的問題可能導致釣魚攻擊的成功,因此作者對4款著名PM App: Keeper、Dashlane、LastPass、1Password以及GSL進行了人工分析,指出了各自存在的問題。這也為釣魚攻擊的成功實施做好了準備。
2. 分析步驟
- 確定是否使用目標App的包名作為判斷是否提供憑證填充的唯一資訊
- 如果確定包名是唯一資訊,則進行逆向分析明確包名和域名之間的對映規則
- 嘗試利用對映規則存在的漏洞進行攻擊
3. 分析詳情
- Keeper Keeper有超過一千萬的下載量,支援a11y和Autofill Framework。在獲取到目標App的包名後,Keeper嘗試在Google play Store中訪問對應包名的網頁(比如對於包名com.facebook.katana, 對應的網頁為 https://play.google.com/store/apps/details?gl=us&id=com.facebook.katana ),如果網頁存在,Keeper對返回的網頁進行解析並找到其中“開發者網站(app developer website field)”欄位,並將其作為該包名對應的域名。然而這種對映方式很容易被攻擊者利用,因為“開發者網站”欄位的資訊並不能被信任,App釋出者上傳了自己的App後可以任意修改該欄位。
- Dashlane Dashlane有超過100萬的下載量,支援a11y、Autofill Framework和OpenYOLO。它硬編碼了包名-域名的對映,其中包含81個條目。初次之外,對於不在其中的包名,它將包名按點分開為三個部分(aaa.bbb.ccc分為aaa,bbb,ccc),對於每一部分,檢查是否存在至少三個字元包含在它硬編碼對映的網站欄位中,比如xxx.face.yyy或xxx.facts.yyy和facebook.com對應。這種方式很容易被攻擊。
- LastPass LastPass也有超過100萬的下載量,支援a11y、Autofill framework和OpenYOLO。對於包名為aaa.bbb.ccc的App,它將其和以bbb.aaa結尾的域名對映起來。這種方式很容易進行攻擊,因為攻擊者可以任意設定惡意App的包名,只要不和應用市場中的其他包名重複即可。此外LastPass也提供了一種”crowdsourced mapping”的對映方式,但對這種方式只存在理論上的攻擊可能。
- 1Password 1Password也有超過100萬的下載量,支援a11y、Autofill framework和OpenYOLO。它不進行對映,而是將整個憑據列表展示給使用者由其自行選擇。在喪失了便利性的同時也增加了安全性,不易於攻擊。
- Google Smart Lock GSL在Chrome上集成了PM功能,因此也被作者作為分析的物件。GSL的對映相對安全,因為需要開發者提供很多資訊來保證對映的正確。但該種方式相對麻煩,如果Google能夠公開它的對映資料庫,那會非常有利於PMs安全性的提升。
實際攻擊
結合密碼管理和即時App兩個功能的缺陷,作者進行了如下的攻擊。 假設如下圖(a)中場景,使用者訪問網站,並有仿冒的Facebook的“Like”按鈕,按鈕連結到攻擊者掌控的Instant App。一旦使用者點選了Like按鈕,會有圖(b)中請求使用者確認啟動Instant App的提示,該Instant App使用“Open With”作為名稱,圖示為純白色方框,這就誤導使用者點選“OPEN APP”按鈕,並自動下載Instant App。經過圖©所示等待頁面(約一秒)後,如圖(d),App啟動。因為app包名被設定為com.facebook.*形式,LastPass自動提示使用真正的Facebook憑證,一旦使用者點選該懸浮框進行確認,那麼憑證便會洩露到攻擊者手中。 在此基礎之上,作者也評估了這些PMs對於隱藏的密碼輸入框是否有抵禦能力。作者用如下幾種方式將密碼輸入框“隱藏”併成功獲取憑證:
- 透明度alpha設定為0.01,設定為0則會失敗
- 大小設定為1dp * 1dp
- 文字顏色與背景色相同(只對a11y有效)
- 設定invisible標籤(只對Autofill Framework有用)
保護方式
能夠抵禦這種攻擊的方式有很多,作者提出getVerifiedDomainNames()這一API,能夠幫助PMs更好地確認App所對應的網站。該API具體實現邏輯如下圖所示。但API要想正常工作還需要整個開發者社群的共同努力。總結
文章提出一個全新的釣魚攻擊方式,從新的功能出發,挖掘其中的問題。這也提示我們要關注Android系統不斷更新的一些新功能,新功能在提升便利性的同時也可能帶來新的安全問題。但是相對於一些工作分析了超過20個PM App文章只分析了4個App,有些結論的一般性還需要進一步論證。文章一些釣魚攻擊的技術,如偽造App名稱等也是值得學習的。