A Mitmproxy-based Dynamic Vulnerability Detection System For Android Applications

:::info Lv, X., Peng, T., Tang, J., He, R., Hu, X., Jiang, M., … & Cao, W. (2022, December). A Mitmproxy-based Dynamic Vulnerability Detection System For Android Applications. In 2022 18th International Conference on Mobility, Sensing and Networking (MSN) (pp. 408-416). IEEE. ::: 這一篇也和我想做的主題有一點關聯，他是利用MITMProxy-based達到偵測應用程式在做Hotfix時，有沒有Code Injection(dex injection)的問題。

Introduction

現在有很多的App都會實現Hotfix這項技術，也就是不斷電更新，傳統的App更新方式為廠商發佈新的版本後，使用者需要重新卸載再安裝新的版本，但現在有了Hotfix的技術，使用者在沒有感知的情況下就會自動完成更新，如下圖所述，當然在更新之前會進行驗證Hash、SSL憑證和簽章，但如果沒有簽章呢?是不是就可以被MITM篡改Hash和進行Code Injection，這一篇文章就是在自動化的檢測這件事情的可行性

Background

• Hotfix的流程 按照論文中的說明，利用hotfix更新patch的方式當然不是直接從server傳過來到client端，而是會把dex file打包成.jar或是.zip的patch package，然後放在某個地方。從server那邊會送出一個json file，裡面有一個URL Key會紀錄這個打包好的patch package在哪裡，然後client端自行去下載會來進行patch
• Android的簽章 在Android系統安全中有3個主要的技術: Permission Management, Signature Authentication, 以及Sandbox Mechanism，現在主要探討的問題就是在簽章的技術底下。Android的數位簽章總共會包含三個東西: MANIFEST.MF, CERT.SF, CERT.RSA
  • MANIFEST.MF 是一個Digest File也就是存所有更新的打包檔案的Hash Value
  • CERT.SF 是一個Signature File，他會用SHA1計算MANIFEST.MF中的所有東西再用Base64進行Encode
  • CERT.RSA 存放Public Key+加密演算法是哪一個+用自己的Private Key加密CERT.SF中的所有東西的結果 綜上所述，如果一個廠商在進行Hotfix更新時，被MITM Hijack，那MANIFEST.MF和CERT.SF可以被換掉，但CERT.RSA這個檔案，因為沒有廠商的私鑰，故無法替換

Proposed Method

• Phase I: Packet location 這個環節是為了要從所有Client和Server之間的封包中找出存在Hotfix URL的那一個封包以及實際把他提取出來放到Data.csv中
  • 看Response的Content-Type是否為application/json :::spoiler
  • 看該json file的內容是否有URL Key
  • 看URL Value的最後是否為.jar或是.zip :::spoiler
• Phase II: Packet extraction 實際把Data.csv中的URL進行Request然後把檔案下載下來，並且偵測有無憑證，否則就把疊代的把dex file翻出來
• Phase III: Pushing the packet 如上圖，有了dex file之後就是直接去搜尋有無MANIFEST.MF檔案(並且確定沒有CERT.RSA和CERT.SF或是其他簽章的File)，其中會紀錄哪裡是entry class；如果沒有就用objection這個dex injection tool去找，然後:
  1. Decompile→smali code(只能在smali中進行修改)
  2. Injection something :::spoiler
  3. Compile to dex file
  4. Modify URL in JSON & md5 hash 修改完成的dex file會放在attacker的本地端，所以要把json file中的URL換掉，另外md5也要換成新的dex file的hash 本次的重點不是code injection會造成多大的危害，他只是想要證明這個Vulnerability確實存在，所以他只有insert一個簡單的log code在裡面而已

Experiment

本文提供三個research questions當作實驗的主軸

• What is the detection performance in previously collected applications with known dex injection vulnerabilities? 作者準備53個已知有dex injection的app以及47個沒有問題的app進行偵測，發現可以100%偵測出哪一個是有問題的App，以及花費的時間也很短，代表該系統提供很好的efficiency和accuracy
• Can our system effectively detect vulnerabilities in unknown apps from the app market? 那對於未知的App，該系統還有一樣的優勢嗎?作者準備了市面上1000個App進行偵測，發現有34個App會有hotfix dex injection的問題 其中，打勾的代表廠商已經修掉了，問號則是還沒有。作者還有判斷這34個分別是哪一個類別的App以及他們是藉由HTTP或者是HTTPS進行傳輸，這部分可以直接看論文，不太重要
• Is there an improvement in detection performance compared with other methods? 針對其他tool的比較如上