如何進行Janus安卓簽名漏洞預警分析

這期內容當中小編將會給大家帶來有關如何進行Janus安卓簽名漏洞預警分析，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

0x00背景介紹

2017年7月31日 GuardSquare向Google報告了一個簽名漏洞并于當天收到確認。Google本月修復了該漏洞，編號CVE-2017-13156。

經過360CERT分析確認，該問題確實存在，影響較為嚴重。攻擊者可以繞過簽名驗證機制構造惡意程序更新原有的程序。

0x01 事件概述

該漏洞產生的根源在于將DEX文件和APK文件拼接之后校驗簽名時只校驗了文件的APK部分，而虛擬機執行時卻執行了文件的DEX部分，導致了漏洞的發生。由于這種同時為APK文件和DEX文件的二元性，聯想到羅馬的二元之神Janus，將該漏洞命名為Janus漏洞。

0x02 事件影響

影響Android5.0-8.0的各個版本和使用安卓V1簽名的APK文件。

0x03 事件詳情

1.     技術細節

Android支持兩種應用簽名方案，一種是基于JAR簽名的方案（v1方案），另一種是Android Nougat(7.0)中引入的APK簽名方案v2（v2方案）。

v1簽名不保護APK的某些部分，例如ZIP元數據。APK驗證程序需要處理大量不可信（尚未經過驗證）的數據結構，然后會舍棄不受簽名保護的數據。這會導致相當大的受攻擊面。此外，APK 驗證程序必須解壓所有已壓縮的條目，而這需要花費更多時間和內存。為了解決這些問題，Android7.0中引入了APK簽名方案v2。在驗證期間，v2方案會將APK文件視為 Blob，并對整個文件進行簽名檢查。對APK進行的任何修改（包括對ZIP元數據進行的修改）都會使 APK 簽名作廢。這種形式的APK驗證不僅速度要快得多，而且能夠發現更多種未經授權的修改。

        如果開發者只勾選V1簽名不會有什么影響，但是在7.0上不會使用更安全的V2簽名驗證方式；只勾選V2簽名7.0以下無法正常安裝，7.0以上則使用了V2的方式驗證；同時勾選V1和V2則所有機型都沒問題。此次出現問題的是V1簽名方案。簡單地說，把修改過的dex文件附加到V1簽名的apk文件之前構造一個新的文件，V1方案只校驗了新文件的apk部分，而執行時虛擬機根據magic header只執行了新文件的dex部分。

         我們來看一下已經公布的POC (https://github.com/V-E-O/PoC/tree/master/CVE-2017-13156)的原理。janus.py接受dex文件和apk文件作為輸入，組合起來輸出。

         讀取dex文件：

讀取apk文件：

      Apk其實就是一個zip。簡單地說zip文件格式由文件數據區、中央目錄結構和中央目錄結束節組成。

其中中央目錄結束節有一個字段保存了中央目錄結構的偏移。代碼中搜索中央目錄結束節的固定結束標記x06054b50定位到中央目錄結構的偏移，將其加上dex文件的大小，因為我們要把dex文件插到apk前面。

      接下來依次更新中央目錄結構數組中的deHeaderOffset字段也就是本地文件頭的相對位移字段。通過deHeaderOffset字段可以直接獲取到對應文件的文件數據區結構的文件偏移，就可以直接獲取到對應文件的壓縮數據了。同樣也是因為dex文件插在前面了所以直接加上dex文件的大小。

最后更新dex部分的file_size字段為整個dex+apk的大小，使用alder32算法和SHA1算法更新checksum和signature字段。

下面做一個非常簡單的測試。

在APK文件中寫一個彈出Hello的toast，同時采用V1簽名方案簽名：

安裝到手機上：

將編譯好的apk解壓得到dex文件，baksmali.jar反編譯dex文件得到smali代碼，將hello隨便改成另外一個字符串：

用smali.jar回編譯成dex文件，使用提供的腳本把dex文件和原來的apk打包生成out.apk：

安裝到手機上成功通過了簽名校驗并且執行了修改的dex中的代碼：

在我android8.0沒有打補丁的手機上如果采用了V2簽名方案不受該漏洞影響，更新不了原來正常的程序：

2.     補丁分析

補丁非常簡單，強制校驗了zip的frSignature：

0x04 修復建議

1、開發者在開發應用程序時勾選V2簽名方案

2、各廠商應及時發布補丁，確保用戶盡快更新系統

3、用戶應在正規的應用市場下載程序

上述就是小編為大家分享的如何進行Janus安卓簽名漏洞預警分析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。