VAPTAi: A Threat Model for Vulnerability Assessment and Pentesting of Android and iOS Mobile Banking Apps

Posted on | Post modified | In |

VAPTAi: A Threat Model for Vulnerability Assessment and Penetration Testing of Android and iOS Mobile Banking Apps

:::info Bojjagani, S., & Sastry, V. N. (2017, October). VAPTAi: a threat model for vulnerability assessment and penetration testing of android and iOS mobile banking apps. In 2017 IEEE 3rd international conference on collaboration and internet computing (CIC) (pp. 77-86). IEEE. :::

Introduction

隨著移動設備的使用急速增加，Mobile Banking Application(MBA)也備受黑客和惡意使用者的目標。這些MBA存儲、傳輸和存取敏感和機密資訊，因此必須優先確保其安全性。本文提出了一個威脅模型，以系統性地測試和分析行動銀行應用程式，檢測和緩解應用程式級和通信級別的漏洞。作者對5個Android和3個iOS的MBA進行了安全測試，發現了許多未知漏洞，並展示了MBA易受中間人攻擊的情況。部分MBA使用簡單的HTTP協議傳輸用戶數據，未考慮安全要求。多數情況下，MBA無條件接受偽造或自簽名的證書，導致SSL/TLS中間人攻擊。

Background

Proposed Method

圖片

Threat Type

  • Insecure Data Storage (V1)
    • 開發團隊假設用戶或惡意軟體無法訪問移動設備的文件系統，在設備上存儲機密數據
    • Rooting或Jailbreak設備可繞過任何加密保護，讓攻擊者可以使用專門工具查看應用程序數據
  • Lack of Binary Protection (V2)
    • 移動應用程序缺乏二進制保護，可被攻擊者輕易修改、逆向工程和分析
  • Unintended Data Leakage (V3)
    • 開發者在移動應用程序開發過程中，無意間將敏感數據放置在設備上的不安全位置
  • Malware in Apps (V4)
    • 由於Android應用程序在市場上的流行，攻擊者和惡意軟件開發者的主要目標是利用應用程序中的漏洞
  • Weak Cryptography (V5)
    • 使用了易受攻擊的加密算法或在加密過程中存在缺陷
  • Insufficient Transport Layer Protection (V6)
    • 移動應用程序與服務器之間的通信使用安全套接層(SSL/TLS)設置不當，可能遭受中間人、重放、網路釣魚等攻擊
      1. Man-in-the-Middle (MitM) Attack
      2. Replay Attack
      3. Phishing Attack
      4. Session Hijacking
      5. Masquerade: 攻擊者可以通過偽造MAC地址來假扮任何工作站或無線電站
      6. Traffic Analysis and Wi-Fi Sniffing
      7. Account Lock-out attack: 攻擊者可以嘗試多次使用錯誤密碼登錄，導致用戶帳戶被鎖定
  • Privilege Escalation Attack (V7)
    • Android權限模型主要在應用程序級別運行，攻擊者可利用源碼中的漏洞獲得更高權限

How to test(Static Analysis)?

主要分析APK文件的結構，包括AndroidManifest.xml清單文件和classes.dex反編譯代碼，檢測不安全的API調用和潛在的數據流洩露問題。使用工具如Drozer、Virus-Total、Apktool等。 圖片

How to test(Dynamic Analysis)?

搭建測試環境，包括一台充當惡意接入點的筆記本電腦、一個Cisco無線接入點、一部Android測試手機以及一台模擬銀行伺服器。使用BurpSuite作為中間人代理，攔截手機APP與銀行伺服器之間的通信，監測是否存在證書驗證不當等問題。 圖片

Experiment

Dataset

圖片 作者抽取了五個 Android 和三個 iOS 行動銀行應用程式作為樣本，這些應用程式目前由印度國有公共部門銀行部署並由各自的客戶使用。然而，出於安全和聲譽原因，我們對我們考慮測試其銀行應用程式的銀行的確切名稱進行了匿名化。這些銀行大多數都使用外部開發人員（稱為供應商，在表三中匿名為 D1、D2 等）來開發銀行應用程式。

Static Analysis

作者針對五款Android MBA做靜態分析，發現以下漏洞，以及漏洞數量呈如下圖 圖片

  1. External storage access 應用程序將敏感數據存儲在外部可訪問的存儲空間，容易遭受數據洩露，主要是利用READ/WRITE_EXTERNAL_STORAGE permission這個API進行讀寫
  2. Exported activities to other apps 在Android應用程序中，活動組件(Activity)默認是不對其他應用程序公開的，但開發者可以將其設置為”exported”(導出)，這樣其他應用程序就可以訪問和利用這些活動組件。論文中提到，在對Android MBA進行靜態分析時發現，部分應用程序將自己的活動組件不當地導出，這可能會帶來以下安全隱患:
    • 權限提升攻擊: 其他惡意應用程序可以通過訪問導出的活動組件，獲得比自身更高的權限。
    • 敏感數據洩露: 導出的活動組件可能包含一些敏感的用戶數據，被其他應用程序讀取和利用。
    • 應用程序功能遭到劫持: 惡意應用程序可以通過調用導出的活動組件，劫持合法應用程序的功能。 圖片
  3. Permits data to be stored in back-end databases and restored 應用程序允許將數據備份到後端數據庫，可能導致敏感數據洩露
  4. The app is Debuggable 應用程序被標記為debuggable，攻擊者可利用此漏洞進行更深入的分析和攻擊
  5. Hard-coded cryptographic key 應用程序使用硬編碼的加密密鑰，容易被逆向工程獲取
  6. The app contains native code
    • 什麼是 native code? 在Android應用程序中,除了使用Java寫的代碼外,還可以包含C/C++的本地代碼。這就是所謂的 native code。
    • 為什麼 native code 可能存在安全隱患?
      • 本地代碼是直接與底層系統交互的,相較於高級語言Java,它更容易出現內存管理、邊界檢查等安全漏洞。
      • 這些漏洞可能被攻擊者利用，導致應用程序被破壞、篡改甚至執行任意代碼。
    • 論文中的發現
      • 在對Android MBA進行靜態分析時，作者發現它們都包含了一些本地代碼組件。
      • 由於這些本地代碼沒有經過足夠的安全審查和測試，可能存在一些未知的安全隱患。
    • 解決方案
      • 開發者在使用本地代碼時，應該格外小心謹慎，確保代碼的安全性。
      • 可以考慮使用更安全的技術，如Java Native Interface (JNI)來調用本地代碼，並進行嚴格的輸入驗證。
      • 同時應該對整個應用程序的安全性進行全面評估和測試。
  7. Allows cryptographic algorithms in ECB mode 應用程序使用ECB模式的加密算法，存在安全性問題
  8. Check for dangerous permissions used by the app
    • Android 權限機制: Android系統採用權限機制來控制應用程序對系統資源和敏感數據的訪問。應用程序需要在安裝時申請相應的權限才能訪問特定的系統功能或資源。
    • 危險權限:
      • Android系統將一些權限定義為”dangerous permissions”,因為這些權限可能會給用戶的隱私和安全帶來風險。
      • 例如讀取聯繫人通訊錄、獲取位置信息等權限。
    • 論文中的發現:
      • 在對Android MBA進行靜態分析時,作者發現這些應用程序申請了過多不必要的危險權限。
      • 這可能使應用程序面臨嚴重的安全隱患,因為攻擊者可以利用這些權限竊取用戶敏感數據或進行其他惡意操作。
    • 潛在的危害:
      • 應用程序獲取過多不必要的危險權限,會大大增加用戶的隱私和安全風險。
      • 即使應用程序本身沒有惡意,但仍可能被攻擊者利用這些權限進行各種攻擊活動。
    • 解決方案:
      • 開發者應該審慎評估應用程序所需的權限,儘量減少申請不必要的危險權限。
      • 對於確實需要的權限,也應該向用戶清晰解釋其必要性和用途,獲取用戶的授權同意。 圖片
  9. Allows Reflection code 應用程序允許使用反射機制，可能遭受代碼注入攻擊
  10. Uses object Deserialization 應用程式呼叫 java.io.ObjectInputStream.readObject() 方法將物件反序列化到記憶體中。物件反序列化是漏洞的常見來源，特別是當物件可能來自不受信任的來源時。建議盡可能避免物件反序列化，或以其他方式強化 ObjectInputStream 抵禦攻擊。一種強大的強化技術是重寫resolveClass()，僅允許預期的類別。可以透過子類化ObjectInputStream來實現。
  11. Insecure Pseudo-random number generation 應用程序使用不安全的隨機數生成機制，容易被攻擊者預測和利用
  12. Broadcast receivers accessible to other apps
    • 什麼是 Broadcast Receivers?: Broadcast Receivers是Android應用程序中的一種組件,用於接收系統或其他應用程序發送的廣播消息。
    • 漏洞原因:
      • 如果Broadcast Receivers被設置為”exported”(導出),那麼其他應用程序就可以向其發送廣播消息並觸發相應的行為。
      • 這可能導致敏感數據洩露或惡意代碼執行的安全隱患。
    • 論文中的發現:
      • 在對Android MBA進行靜態分析時,作者發現部分應用程序將自己的Broadcast Receivers不當地導出,存在安全風險。
    • 潛在的危害:
      • 惡意應用程序可以向導出的Broadcast Receivers發送特製的廣播消息,從而觸發應用程序的特定功能,如讀取用戶敏感數據。
      • 攻擊者還可以利用導出的Broadcast Receivers進行權限提升或遠程代碼執行等攻擊。
    • 解決方案:
      • 開發者應該仔細檢查自己應用程序中Broadcast Receivers的導出情況,盡量減少不必要的導出。
      • 對於必須導出的Broadcast Receivers,要確保其安全性,如進行權限控制、輸入數據驗證等。 圖片
  13. Content providers accessible to other apps and App allows SQL Injection 應用程序的內容提供者未經適當保護，容易遭受SQL注入攻擊
  14. The source code is not Obfuscated 應用程序的源代碼缺乏混淆保護，容易被逆向工程和分析
  15. Logs information 應用程序將敏感信息記錄在未加密的日誌中，存在數據洩露風險
  16. Does app executes environment commands 應用程序允許執行系統命令，可能被攻擊者利用進行提權或遠程控制
  17. Uses cipher that does not provide Integrity 應用程序使用不提供完整性保護的加密方式，容易遭受中間人攻擊
  18. Use of weak security algorithms or hash functions 應用程序採用了安全性較弱的加密算法或雜湊函數，存在破解風險
  19. Weakly configured XML parser 該應用程式可能使用配置不當的 XML 解析庫。如果從不信任的來源解析 XML，則可能會導致 XXE 和DoS 攻擊。建議使用安全處理功能來防止DoS攻擊，並禁止「document type declaration（DTD）」以防止大多數XXE攻擊。如果無法禁止 DTD，則應停用外部實體和外部文件類型。
  20. Weak construction of socket factory 應用程序的socket工廠構建存在安全隱患，可能導致中間人攻擊等問題

Dynamic Analysis

  • D1-Bank_1
    • 未能正確驗證SSL/TLS證書
    • 使用不安全的加密演算法
    • 在明文形式傳輸敏感數據 圖片
  • D2-Bank_2
    • 未對通信進行Integrity Protection，如果被Mitm則使用者不會知道 圖片 圖片
    • Phishing: 如果客戶不知道原始伺服器，則應用程式可能會連接到與合法伺服器完全相同的另一台伺服器。基於這個原因，網路釣魚攻擊是可能的
  • D3-Bank_3 & D3-Bank_4
    • 使用不安全的加密演算法
    • 在明文形式傳輸敏感數據
    • 存在中間人攻擊的風險: 由 D3 應用程式開發人員開發的所有手機銀行應用程式（D3-Bank 3 除外）均表現出與 D3-Bank 4 相同的行為 圖片
  • D4-Bank_5
    • 可執行帳戶鎖定攻擊

Conclusion & Future Work

在本文中，我們提出了一個威脅模型，有助於系統地測試和分析行動銀行應用程式。它有助於檢測和緩解應用程式和通訊層級的漏洞。我們主要關注Android和iOS行動銀行應用程式兩個主要平台的安全測試。本文解決了 MBA 中的各種未知漏洞以及應用程式動態分析過程中 MitM 攻擊的實施。結果表明，即使應用程式使用 HTTPs 協定運行，由於傳輸層保護不足，導致銀行伺服器端和行動應用程式的 SSL 框架實現不佳，因此很容易發生 MitM 攻擊。我們對各種已root、越獄和未越獄的設備進行了安全測試，並識別了常見漏洞。雖然在先前的作品中，作者確定了一些攻擊，但沒有提供緩解漏洞的技術。每個組織、金融機構、銀行和第三方實驗室都需要按照建議進行深入的漏洞評估，每年一次或兩次對MBA進行安全檢查，以發現漏洞和漏洞。因此，本文討論了 MBA 發展的安全性問題。未來的工作包括專注於運行其他平台（例如黑莓和 Windows）的其他行動裝置。然而，需要對安全威脅進行詳細研究，這需要銀行方提供實際的用戶憑證，因此保留為未來的工作。