近日，Google在12月發布的安卓系統安全公告中披露了一個名為“Janus”安卓漏洞(漏洞編號：CVE-2017-13156)。該漏洞可以讓攻擊者繞過安卓系統的signature scheme V1簽名機制，進而直接對App進行篡改。而且由于安卓系統的其他安全機制也是建立在簽名和校驗基礎之上，該漏洞相當于繞過了安卓系統的整個安全機制。

　　一旦攻擊者將植入惡意代碼的仿冒的App投放到安卓商店等第三方應用市場，就可替代原有的App做下載、更新。網友安裝這些仿冒App后，不僅會泄露個人賬號、密碼、照片、文件等隱私信息，手機更可能被植入木馬病毒，進而或導致手機被ROOT，甚至被遠程操控。

　　在第一時間監測到“janus”漏洞的情況后，頂象技術及時更新了“安全SDK”的防御策略，并率先發布了針對該漏洞的防護方案，以幫助廣大用戶防范基于該漏洞的攻擊威脅。

　　分析顯示，安卓5.0到8.0系統以及基于signature scheme V1簽名機制的App均受“Janus”漏洞影響;基于signature scheme V2簽名的App則不受影響。

　　安卓用戶：

　　1、盡快升級到最新版安卓系統;

　　2、短期內，盡量到官方網站更新、下載App。

　　安卓開發者：

　　1、盡快將App APK(安裝包)升級到最新的Signature scheme V2簽名機制;

　　2、及時校驗App APK文件的開始字節，以確保App是未被篡改;

　　3、頂象技術的“安全SDK”以更新防御機制，可以有效防護該漏洞。

　　“Janus”漏洞爆發原因是什么?

　　為了提升安卓系統的安全性，Google發布了新的簽名認證體系signature scheme V2。由于，signature scheme V2需要對App進行重新發布，而大量的已經存在的App APK無法使用V2校驗機制，所以為了保證向前兼容性，V1的校驗方式的還被保留，這就導致了“Janus”漏洞的出現。

　　Google為什么發布signaturescheme V2呢?那就盤點一下，近年來安卓系統曾爆出的一系列安全問題吧。

　　這些年，安卓系統爆出的簽名漏洞

　　“MasterKey”漏洞

　　“Janus”是一個簽名與校驗漏洞，其實，這不是安卓第一次爆出此類漏洞。在2013年 Black Hat上，Bluebox的安全團隊公布了一個“MasterKey”漏洞。該漏洞影響包括當時最新的安卓6.0系統及以下所有系統。那么，這些漏洞是怎么形成的呢?

　　“MasterKey”漏洞原理是基于APK(ZIP文件格式)里面的多個ZipEntry實現的，具體如下：

　　1. 向原始的App APK的前部添加一個攻擊的classes.dex文件(A);

　　2. 安卓系統在校驗時計算了A文件的hash值，并以”classes.dex”字符串做為key保存;

　　3. 然后安卓計算原始的classes.dex文件(B)，并再次以”classes.dex”字符串做為key保存，這次保存會覆蓋掉A文件的hash值，導致Android系統認為APK沒有被修改，完成安裝;

　　4. APK程序運行時，系統優先以先找到的A文件執行，忽略了B，導致漏洞的產生。

　　修復方式：

　　禁止安裝有多個同名ZipEntry的APK文件。

 

　　“9695860”漏洞

　　MasterKey漏洞爆出后沒多久，國內的“安卓安全小分隊”再爆出一個類似的漏洞。這個漏洞非常精巧：利用了Zip local file header在計算時候的一個整形溢出漏洞。

　　具體原因：

　　1. 向原有的APK中的classes.dex文件B替換為攻擊文件A，并添加一個大小為0xFFFD的extrafield;

　　2. 將原始dex文件B去除頭3個字節寫入extrafield;

　　3. Android系統在校驗簽名時使用的是Java代碼的short，將0xFFFD以16位帶符號整形的方式解析得到-3, 并解析出原始的文件B，Android認為程序APK無修改，正常安裝;

　　4. 系統在執行時使用C代碼的uint16，將0xFFFD以16位無符號整形方式，得到攻擊文件B。

　　這個漏洞的精巧之處在于，DEX文件以‘dex’字符串開頭，而classes.dex以這個字符串結尾，通過-3的值將這兩個內容在文件中重疊起來，因此這也限制了“9695860”漏洞只能對classes.dex進行攻擊。

 

　　“9950697”漏洞

　　在“9695860”漏洞爆出不久后，APK文件中被發現存在類似的整形溢出漏洞，這個比“9695860”漏洞更容易利用且可以攻擊APK中的任意文件。

　　原因是安卓默認認為Zip中localfile header和central directory entry中的文件名長度和和extra的長度是一致的。安裝過程中java代碼在處理時出現溢出，讀取到了正常的文件B，通過校驗，APK正常安裝。運行過程中，C代碼處理時沒有溢出，讀取到了攻擊的文件A。

 

　　Google發布了signature scheme V2簽名機制

　　以上的一系列漏洞全部出在基于jarsigner機制建立起來的簽名和校驗機制signature scheme V1出現。Google也意識到了這套機制的缺陷，所以，發布了重新設計的Siginature scheme V2簽名機制。

　　Siginature scheme V2 APK文件整個內容進行簽名，目標是任何對APK的修改都會導致檢驗的失敗。

　　目前signature scheme V2已經在安卓7.0系統及以上的版本中支持。

　　“Janus”漏洞的攻擊原理和利用過程

　　攻擊原理

　　1、安卓在4.4中引入了新的執行虛擬機ART，這個虛擬機經過重新的設計，實現了大量的優化，提高了應用的運行效率。與“Janus”有關的一個技術點是，ART允許運行一個raw dex，也就是一個純粹的dex文件，不需要在外面包裝一層zip。而ART的前任DALVIK虛擬機就要求dex必須包裝在一個zip內部且名字是classes.dex才能運行。當然ART也支持運行包裝在ZIP內部的dex文件，要區別文件是ZIP還是dex，就通過文件頭的magic字段進行判斷：ZIP文件的開頭是‘PK’, 而dex文件的開頭是’dex’.

　　2、ZIP文件的讀取方式是通過在文件末尾定位central directory, 然后通過里面的索引定位到各個zip entry，每個entry解壓之后都對應一個文件。

 

　　影響的范圍

　　1. 安卓5.0-8.0的各個版本系統;

　　2. 使用安卓Signaturescheme V1簽名的App APK文件。

　　利用過程

　　1、攻擊者可以向APK文件的開始位置放置一個攻擊的DEX文件A;

　　2. 安卓系統在安裝時用ZIP的讀取機制從末尾開始進行文件的讀取，讀取到了原始的APK內容，并且以V1的方式進行校驗，認為這個文件是正常的，沒有篡改，APK安裝成功;

　　3. 在運行時，Android的ART虛擬機從文件頭開始讀取，發現是一個DEX文件，直接執行，攻擊文件A被最終執行。

　　帶來的威脅

　　可以在沒有apk所有者的證書的情況下對apk進行修改，并且繞過校驗機制安裝在用戶的手機上，造成的可能后果如下：

　　1. 對存儲在原手機上的數據進行讀取，例如金融類APP的銀行密碼、支付密碼、token; 通信類APP的聊天記錄、圖片、通信錄

　　2. 對用戶的輸入做各種監聽、攔截、欺詐，引導用戶輸入密碼，轉賬。

　　3. 利用這個漏洞可以更新Android的系統APP，從獲得更高的系統權限，甚至root/越獄，為其他攻擊做準備

　　頂象技術的防護及修復建議

　　頂象技術一直關注移動端、WEB端上的各類風險以及各平臺的業務威脅。及時分析監測到漏洞和威脅，并做好針對性的防護措施，由此積累了大量與黑灰產對抗的實戰經驗。頂象技術將這些實戰經驗以“安全SDK”的產品方式共享給用戶，從而幫助用戶建立高效的防御體系，有效防御各類新型的、復雜的惡意攻擊和威脅。

　　在第一時間監測到“janus”漏洞的情況后，頂象技術及時更新了“安全SDK”的防御策略，并率先發布了針對該漏洞的安全防護方案，以幫助廣大用戶防范基于該漏洞的攻擊威脅。

　　安卓用戶：

　　1、盡快升級到最新版安卓系統;

　　2、盡量到官方網站更新、下載App，短期內不用使用第三方安卓應用市場更新或下載App。

　　安卓開發者：

　　1、將App APK升級到最新的Signature scheme V2簽名機制;

　　2、開發者及時校驗App APK文件的開始字節，以確保App未被篡改;

　　3、使用頂象技術提供的安全SDK，以防范該漏洞的攻擊。