支付、網銀金融App安全嗎?你必知的白帽App資安漏洞分析!

2021/08/09

支付、網銀金融App的使用越來越深入我們生活中,而金融App的安全以及網路App資安漏洞分析,也顯的越來越重要。以下就也針對傳統SDK的偵測來做個介紹吧!讓你可以更明白瞭解白帽的資安漏洞分析!

而金融App的安全,除了金融單位和一般使用者非常重視之外,現行法規還有相當多針對金融App所做的資訊安全規範,以期達到符合金融App安全的最高準則。     全球幾個主要的先進國家,針對金融App的安全保護都還是採用傳統的SDK方式。SDK這類的安全防護機制主要是針對使用者的環境進行三種不同狀況的檢測,SDK則再依據檢測出來的狀況,進行所謂的反制動作。

相關對應整理如下:

傳統SDK偵測狀況

反制動作

1.使用者環境是否為越獄(JB或是Root)

金融App閃退-無法執行

2.使用者環境記憶體是否被偵測除錯

金融App閃退-無法執行

3.金融App是否被攻擊(完整性校驗)

金融App閃退-無法執行

這類的SDK保護方式簡單來說為一進一出,它必須偵測到已知的被駭行為,才能進行反制效果,這樣的保護雖然簡單直接,但實際上卻存在1個安全保護上的重大盲點。

傳統SDK偵測的重大盲點為何?

即SDK必須偵測到『被駭行為』才能出現『反制動作』。駭客可以運用這邏輯上的盲點,只要讓SDK不會偵測到『被駭行為』或是SDK永遠只能偵測到允許的『被駭行為』就不會出現『反制效果』。例如:讓SDK永遠只能偵測到使用者環境是沒有越獄的(欺騙偵測功能)。

該如何透過正確的SDK偵測,保護金融App的資訊安全?

步驟一:分析原始碼    
使用SDK針對金融App進行保護,通常都是使用混淆的方式來增加被駭客解析原始碼的困難度,但由於混淆會增加金融App的原始碼容量,所以往往會因為效能問題,無法將全部的金融App原始碼進行混淆保護,反而造成金融App資安的破口。
本次測試中如下圖所示,只要使用市面上常見的反編譯工具(frida 、IDA pro…等等),就能將原始碼狀況解析出來,由於SDK混淆太多會造成程式執行效能的問題,所以該金融App並不是全部的原始碼都有混淆保護,從中就能看到大量的重要函數曝露出來,可以方便進行原始碼的解析。

原始碼函數


從解析出來的原始碼函數,可以清楚看到綠色的函數寫上:executing shutdown hook for 或是crashlytics shutdown hook for這樣的檢測條件和結果,接下來只要針對這些函數做修改或是Bypass功能即可。

步驟二:檢測是否可被工具進行記憶體偵錯    
解析完金融App原始碼,了解SDK的安全檢測邏輯後,下一步就是使用工具針對金融App進行記憶體偵錯檢測,以便於了解金融App的動態程式執行的邏輯。
這樣的工具原本是開發者可用來輔助我們追蹤出錯誤之所在,在偵錯器的控制之下,我們可以逐行地執行程式、設定中斷點( break points)、檢視變數的值。 許多程式的錯誤可以利用這些技巧迅速地找出來,減少偵錯所需的時間與精力。
但相對的,同樣的工具也成了駭客了解金融App程式執行的邏輯,找到每一個程式邏輯的中間點,在程式執行結束前加入中斷點進行植入式攻擊,讓該程式執行成駭客想要的結果內容。
該測試案例透過IDA執行後,證明可以被記憶體偵錯,代表這個金融App並沒有做到防止記憶體偵錯(Anti-Debugger)的功能。在了解該案例的程式執行邏輯後,接下就可以選擇想要執行的程式斷點,開始實驗植入攻擊或Hook攻擊的動作。
執行的程式斷點
步驟三:螢幕劫持(Hijack)測試
Hijack駭客攻擊主要是為取得螢幕、鍵盤的控制權而惡意開發出一種攻擊行為,目前已經從PC平台大規模橫跨到智慧型手機上
在本次的測試中,由於使用工具後已經可以從手機記憶體上,了解該金融App的程式執行的順序,所以我們選擇在使用者帳號密碼登入前,實作一個頁面覆蓋在原先帳號密碼登入頁面上,所以使用情境就成了使用者才必須先看到Hijack的頁面,輸入完相關的資料後,才能進入正常的帳號密碼登入頁,在這過程中使用者的帳號密碼早已經落入駭客手中,造成資安上的疑慮。
在本次的測試中,該金融App除了沒有防止記憶體偵錯(Ati-Debugger)的防禦功能之外,也沒有做到偵測被螢幕劫持和完整性校驗的能力,所以在實驗的過程中,就可以輕易得達到我們想要的測試結果。

螢幕劫持(Hijack)測試

步驟四:二次打包測試
證明App有沒有完整性校驗的能力,最好的方式就是二次打包(Re-Package)。

二次打包就是透過對App的程式邏輯和安全性了解後,再進行程式碼的竄改插入惡意內容,不管從效能、使用者體驗、外觀它都跟正版的APP一模一樣,但是背後悄悄執行著可怕的程式,可能會在不知不覺中浪費手機電量、流量、惡意扣費、偷窺隱私等等行為。

其實二次打包問題只是Android應用安全風險中的一部分, 一般是透過反編譯工具於APP中插入廣告程式碼與相關配置,然後透過第三方應用市場、私人論壇釋出給不知情的消費者使用。

測試的過程中,我們將原本出現的廣告頁面修改成任意想要的內容(Test),並可以正常持續的執行這個金融App,結果證明該案例並沒有足夠的完整性校驗能力,來抵禦外部駭客的二次打包攻擊。


二次打包測試

步驟五:動態植入測試
所謂的動態植入測試,就是可以在App啟動執行的動態過程中,開始輸入修改指令加入攻擊的內容,這樣的測試方式可以證明App是否能防禦在同一個device中被另外一個App發動被駭攻擊。
本次的案例,在firda的動態測試影片中(如下影片),可以在任何一個程式執行的過程中,植入想要修改的內容,足以證明該金融App本身的防禦機制非常薄弱,如果連Server端或是中間傳輸也沒有做任何防禦手段,是無法阻擋駭客的攻擊。


結論:
現在支付、網銀金融App肩負網路上交易的重責大任,將實際有形的現金轉換成App裡的金融數字,這是不容有些許差池錯誤或是資安漏洞,除了會破壞使用者對金融App的絕對信任感之外,更會讓金融秩序因為資安的問題造成大亂,著實需要每一個金融單位200%的重視。
但令人惋惜的是,至今還是有許多金融單位依舊是掩耳盜鈴的鴕鳥心態,以符合現有法規為原則,但法規內可能尚有不完全或是法規之外的資安風險,並不會受到重視及立即改善,往往都要等到風險造成了傷害,再來事後補救亡羊補牢。
駭客的攻擊技術是與時俱進的,唯有持續不斷得加強演練和測試不同風險漏洞,並即刻找到修補加強的方式,料敵從嚴才能將金融App的安全性提到最嚴謹的狀態。
最後建議,開發人員一定要懂得如何針對APP進行混淆、分割、重組、加密重要資訊,讓被駭的風險機率下降。如果開發團隊不太瞭解如何操作,請找專業的App安全公司,可以對APP進行全面的安全評估,以白帽駭客的想法對Mobile App的各個環節進行滲透型測試+動態植入測試,挖掘APP存在的漏洞和相對的風險,進而提早修補來提高Mobile App的安全性。  

延伸閱讀:
App手機行動裝置的Xposed軟件攻擊模式,該如何防禦網路資安?
常見的手機APP駭客工具-FRIDA,預防你的網站遭受駭客攻擊!
注意!行動裝置App資安檢測最需要注意「防記憶體偵測」技術!

其他訊息