獨家分析：安卓“Janus”漏洞的產生原理及利用過程

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

近日，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文件。

undefined

“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進行攻擊。

undefined

“9950697”漏洞 在“9695860”漏洞爆出不久後，APK文件中被髮現存在類似的整形溢出漏洞，這個比“9695860”漏洞更容易利用且可以攻擊APK中的任意文件。原因是安卓預設認為Zip中localfile header和central directory entry中的文件名長度和和extra的長度是一致的。安裝過程中java代碼在處理時出現溢出，讀取到了正常的文件B，通過校驗，APK正常安裝。運行過程中，C代碼處理時沒有溢出，讀取到了攻擊的文件A。

undefined

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解壓之後都對應一個文件。

undefined

影響的範圍 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，以防範該漏洞的攻擊。頂象技術是互聯網業務安全的引導者，致力於打造零風險的數字世界，成立於2017年4月，紅杉資本中國基金成員企業。頂象技術擁有領先的風控技術和智能終端安全技術，其首創的“共用安全”理念已成為新一代安全產品的標準架構。通過全景式業務安全風控體系、無感驗證、虛機源碼保護、安全SDK等方案和產品，賦予電商、金融、IoT、航空、游戲、社交等企業提供BAT級的業務安全能力，讓平臺和用戶免受薅羊毛、交易欺詐、賬號盜用、內容被惡意抓取、系統和App遭破解等風險威脅。 * 更多業務安全類的技術分享，請關註頂象官方博客：https://www.dingxiang-inc.com/blog