---
# System prepended metadata

title: A Mitmproxy-based Dynamic Vulnerability Detection System For Android Applications
tags: [Meeting Paper, NTU]

---

# 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，這一篇文章就是在自動化的檢測這件事情的可行性
![圖片](https://hackmd.io/_uploads/SkTTS9hGA.png)

## 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
![圖片](https://hackmd.io/_uploads/B1Ti653GA.png)
* Phase I: Packet location
    這個環節是為了要從所有Client和Server之間的封包中找出存在Hotfix URL的那一個封包以及實際把他提取出來放到Data.csv中
    * 看Response的Content-Type是否為application/json
        :::spoiler
        ![圖片](https://hackmd.io/_uploads/By01MinGA.png)
    * 看該json file的內容是否有URL Key
    * 看URL Value的最後是否為.jar或是.zip
        :::spoiler
        ![圖片](https://hackmd.io/_uploads/HJyMfi3z0.png)
* Phase II: Packet extraction
    ![圖片](https://hackmd.io/_uploads/rJQQNs2M0.png)
    實際把Data.csv中的URL進行Request然後把檔案下載下來，並且偵測有無憑證，否則就把疊代的把dex file翻出來
* Phase III: Pushing the packet
    ![圖片](https://hackmd.io/_uploads/SJ5v4s3z0.png)
    如上圖，有了dex file之後就是直接去搜尋有無MANIFEST.MF檔案(並且確定沒有CERT.RSA和CERT.SF或是其他簽章的File)，其中會紀錄哪裡是entry class；如果沒有就用objection這個dex injection tool去找，然後:
    1. Decompile→smali code(只能在smali中進行修改)
    2. Injection something
        :::spoiler
        ![圖片](https://hackmd.io/_uploads/r1QjNo3fC.png)
    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?
    ![圖片](https://hackmd.io/_uploads/H1eUpHj3MA.png)
    作者準備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的問題
    ![圖片](https://hackmd.io/_uploads/Sy7hLinfC.png)
    其中，打勾的代表廠商已經修掉了，問號則是還沒有。作者還有判斷這34個分別是哪一個類別的App以及他們是藉由HTTP或者是HTTPS進行傳輸，這部分可以直接看論文，不太重要
* Is there an improvement in detection performance compared with other methods?
    ![圖片](https://hackmd.io/_uploads/HJh8djhMR.png)
    針對其他tool的比較如上