Android手機App安全漏洞整理(小結(jié))
本文主要介紹了APP安全漏洞整理,分享給大家,具體如下:
1.源碼安全漏洞
1.1 代碼混淆漏洞
當(dāng)前APK文件的安全性是非常令人堪憂的。APK運行環(huán)境依賴的文件/文件夾 res、DEX、主配文件Lib 只有簡單的加密或者甚至沒有任何加密。諸如apktool這類工具可輕易將其破解,再配合其他例如dex2jar、jd-gui等工具基本可以做到:源碼暴露、資源文件暴露、主配文件篡改、核心SO庫暴露、暴力破解惡意利用等。因此需要對安卓代碼進(jìn)行代碼混淆。
代碼混淆(Obfuscated code)亦稱花指令,是將計算機程序的代碼,轉(zhuǎn)換成一種功能上等價,但是難于閱讀和理解的形式的行為。將代碼中的各種元素,如變量,函數(shù),類的名字改寫成無意義的名字。比如改寫成無意義的單個或多個字母,如a,Ac,甚至改寫成“__”這樣的符號,使得閱讀的人無法根據(jù)名字猜測其用途。代碼混淆并不能真正阻止反向工程,只能增大其難度。因此,對于對安全性要求很高的場合,僅僅使用代碼混淆并不能保證源代碼的安全,但是可以在一定程度上保護(hù)開發(fā)者的勞動成果。
1.2 Dex保護(hù)漏洞
Dex是Dalvik VM executes的全稱,即Android Dalvik執(zhí)行程序,相當(dāng)于安卓中的.exe文件,Dex為Android應(yīng)用的核心,保護(hù)不當(dāng)容易被反編譯,暴露程序重要信息,面臨被植入廣告、惡意代碼、病毒等風(fēng)險。
另外當(dāng)使用DexClassLoader加載外部的 apk、jar 或 dex文件,當(dāng)外部文件的來源無法控制時或是被篡改,此時無法保證加載的文件是否安全。加載惡意的dex文件將會導(dǎo)致任意命令的執(zhí)行。
1.3 so保護(hù)漏洞
so庫一般是程序里面核心代碼塊,通過Android提供的NDK技術(shù)將核心代碼用安全性更高的C/C++語言實現(xiàn)并提供給Java層調(diào)用來保證程序核心代碼的安全。高性能的代碼一般都會采取C/C++實現(xiàn),通過Android的NDK技術(shù)來讓Java層直接使用。其安全性相對于Java會高很多,相對于Java代碼來說其反編譯難度要大很多,但對于經(jīng)驗豐富的破解者來說,仍然是很容易的事,可以通過暴力破解或國外高價工具來將其破解。應(yīng)用的關(guān)鍵性功能或算法,都會在so中實現(xiàn),如果so被逆向,應(yīng)用的關(guān)鍵性代碼和算法都將會暴露。
1.4 調(diào)試設(shè)置漏洞
如果在AndroidManifest.xml配置文件中設(shè)置了application屬性為debuggable=“true”,則應(yīng)用可以被任意調(diào)試,這就為攻擊者調(diào)試和破解程序提供了極大方便。如果開啟,可被Java調(diào)試工具例如jdb進(jìn)行調(diào)試,獲取和篡改用戶敏感信息,甚至分析并且修改代碼實現(xiàn)的業(yè)務(wù)邏輯,例如竊取用戶密碼,繞過驗證碼防護(hù)等。
2. 組件安全漏洞
2.1組件導(dǎo)出漏洞
組成Apk的四個組件,Activity,Service,Broadcast Receiver 和Content Provider,如果設(shè)置了導(dǎo)出權(quán)限,都可能被系統(tǒng)或者第三方的應(yīng)用程序直接調(diào)出并使用。組件導(dǎo)出可能導(dǎo)致登錄界面被繞過、信息泄露、數(shù)據(jù)庫SQL注入、DOS、惡意調(diào)用等風(fēng)險。
2.2 Activity組件漏洞
Activity是Android組件中最基本也是最為常見用的四大組件之一,是一個負(fù)責(zé)與用戶交互的組件。Activity組件中存在以下常見的漏洞。
(1)activity綁定browserable與自定義協(xié)議
activity設(shè)置“android.intent.category.BROWSABLE”屬性并同時設(shè)置了自定義的協(xié)議android:scheme意味著可以通過瀏覽器使用自定義協(xié)議打開此activity??赡芡ㄟ^瀏覽器對app進(jìn)行越權(quán)調(diào)用。
(2)ActivityManager漏洞
ActivityManager類中的killBackgroundProcesses函數(shù),用于殺死進(jìn)程,屬于風(fēng)險API。
還有通過ActivityManager被動嗅探intent。Intent嗅探腳本首先調(diào)用一個Context.getSystemService()函數(shù),并傳給它一個ACTIVITY_SERVICE標(biāo)志的標(biāo)識符,該函數(shù)返回一個ActivityManager類的實例,它使得該腳本能夠與activity manager進(jìn)行交互,并通過這個對象調(diào)用ActivityManager.getRecentTasks()方法。最后把intent相關(guān)的信息格式化成字符串返回出來。
2.3 Service組件漏洞
Service作為Android中四大組件之一,擁有重要的地位。Service具有和Activity一樣的級別,只是沒有界面,是運行于后臺的服務(wù)。其他應(yīng)用組件能夠啟動Service,并且當(dāng)用戶切換到另外的應(yīng)用場景,Service將持續(xù)在后臺運行。另外,一個組件能夠綁定到一個service與之交互(IPC機制),例如,一個service可能會處理網(wǎng)絡(luò)操作,播放音樂,操作文件I/O或者與內(nèi)容提供者(content provider)交互,所有這些活動都是在后臺進(jìn)行。從表面上看service并不具備危害性,但實際上service可以在后臺執(zhí)行一些敏感的操作。
Service存在的安全漏洞包括:權(quán)限提升,拒絕服務(wù)攻擊。沒有聲明任何權(quán)限的應(yīng)用即可在沒有任何提示的情況下啟動該服務(wù),完成該服務(wù)所作操作,對系統(tǒng)安全性產(chǎn)生極大影響。
2.4 Broadcast Receiver組件漏洞
Broadcast Receiver是“廣播接收者”的意思,就是用來接收來自系統(tǒng)和應(yīng)用中的廣播。
(1)權(quán)限管理不當(dāng)
Broadcast Receiver執(zhí)行一些敏感操作時,會通過intent來傳遞這些信息,這種傳遞數(shù)據(jù)的方式是容易被惡意攻擊的。在發(fā)掘broadcastreceiver中的漏洞時,最大的問題是確定輸入是否可信,以及破壞性有多強。
以下面這段代碼為例(有縮略):
<receiver android:name=”.broadcastreceivers.SendSMSNowReceiver” android:label=”Send SMS”> ………… <actionandroid:name=”org.owasp.goatdroid.SOCIAL_SMS” /> ………… <uses-permissionandroid:name=”android.permission.SEND_SMS”/> …………
在上面這段代碼中,濫用了一個沒有進(jìn)行適當(dāng)權(quán)限保護(hù)的broadcast receiver,由于這個組件缺乏權(quán)限保護(hù),使得攻擊者可以在沒有發(fā)送短信權(quán)限的情況下發(fā)送短信,這個漏洞的危害在于,攻擊者可以在用戶不知情的情況下發(fā)送短信去訂購一個付費服務(wù),或者泄漏設(shè)備中的信息。
(2)BroadcastReceiver導(dǎo)出漏洞
當(dāng)應(yīng)用廣播接收器默認(rèn)設(shè)置exported='true',導(dǎo)致應(yīng)用可能接收到第三方惡意應(yīng)用偽造的廣播,利用這一漏洞,攻擊者可以在用戶手機通知欄上推送任意消息,通過配合其它漏洞盜取本地隱私文件和執(zhí)行任意代碼。
(3)動態(tài)注冊廣播組件暴露漏洞
Android 可以在配置文件中聲明一個receiver或者動態(tài)注冊一個receiver來接收廣播信息,攻擊者假冒APP構(gòu)造廣播發(fā)送給被攻擊的receiver,是被攻擊的APP執(zhí)行某些敏感行為或者返回敏感信息等,如果receiver接收到有害的數(shù)據(jù)或者命令時可能泄露數(shù)據(jù)或者做一些不當(dāng)?shù)牟僮鳎瑫斐捎脩舻男畔⑿孤┥踔潦秦敭a(chǎn)損失。
2.5 Content Provider組件漏洞
Content Provider為存儲和獲取數(shù)據(jù)提供統(tǒng)一的接口??梢栽诓煌膽?yīng)用程序之間共享數(shù)據(jù)。
(1)讀寫權(quán)限漏洞
Content Provider中通常都含有大量有價值的信息,比如用的電話號碼或者社交帳號登錄口令,而確認(rèn)一個content provider是否有能被攻擊的漏洞的最好的辦法,就是嘗試攻擊它一下。
可以用drozer來尋找一些不需要權(quán)限的contentprovider:
dz> runapp.provider.info –permission null
這條命令能列出所有不需要任何讀寫權(quán)限的Content Provider,然后找到相對應(yīng)的包,去訪問給定包存放在它的Content Provider中的數(shù)據(jù)。如果一些Content Provider的URI不需要讀權(quán)限,那就可以通過drozer工具提取其中的數(shù)據(jù)。在某些情況下,設(shè)置和執(zhí)行讀寫權(quán)限不當(dāng),也會將ContentProvider中的數(shù)據(jù)暴露給攻擊者。除了提取數(shù)據(jù),對于寫權(quán)限管理不當(dāng)?shù)腃ontent Provider還可以向其中寫入數(shù)據(jù),使得攻擊者可以將惡意數(shù)據(jù)插入到數(shù)據(jù)庫中。
(2)Content Provider中的SQL注入漏洞
和Web漏洞類似,安卓APP也要使用數(shù)據(jù)庫,那就也有可能存在SQL注入漏洞。主要有兩類,第一類是SQL語句中的查詢條件子語句是可注入的,第二類是投影操作子句是可注入的。使用drozer可以很容易的找出查詢條件子句可注入的content provider。
dz> runapp.provider.query [URI] –selection “1=1”
也可以使用其他恒為真的值,例如“1-1=0”,“0=0”等等。如果APP存在SQL注入漏洞,那么輸入這行指令后就會返回數(shù)據(jù)庫中的整張表。
(3)Provider文件目錄遍歷漏洞
當(dāng)Provider被導(dǎo)出且覆寫了openFile方法時,沒有對Content Query Uri進(jìn)行有效判斷或過濾。攻擊者可以利用openFile()接口進(jìn)行文件目錄遍歷以達(dá)到訪問任意可讀文件的目的。
2.6 Intent組件漏洞
Intent(意圖)主要是解決Android應(yīng)用的各項組件之間的通訊。
(1)隱式意圖調(diào)用漏洞
封裝Intent時采用隱式設(shè)置,只設(shè)定action,未限定具體的接收對象,導(dǎo)致Intent可被其他應(yīng)用獲取并讀取其中數(shù)據(jù)。Intent隱式調(diào)用發(fā)送的意圖可能被第三方劫持,可能導(dǎo)致內(nèi)部隱私數(shù)據(jù)泄露。
(2)意圖協(xié)議URL漏洞
intent schemeURLs(意圖協(xié)議URL),可以通過解析特定格式的URL直接向系統(tǒng)發(fā)送意圖,導(dǎo)致自身的未導(dǎo)出的組件可被調(diào)用,隱私信息泄露。
2.7 WebView組件漏洞
WebView是一個基于webkit引擎、展現(xiàn)web頁面的控件。
(1)Webview明文存儲密碼風(fēng)險
Android的Webview組件中默認(rèn)打開了提示用戶是否保存密碼的功能,如果用戶選擇保存,用戶名和密碼將被明文存儲到該應(yīng)用目錄databases/webview.db中。而本地明文存儲的用戶名和密碼,不僅會被該應(yīng)用隨意瀏覽,其他惡意程序也可能通過提權(quán)或者root的方式訪問該應(yīng)用的webview數(shù)據(jù)庫,從而竊取用戶登錄過的用戶名信息以及密碼。
(2)Webview遠(yuǎn)程代碼執(zhí)行漏洞
Webview是Android用于瀏覽網(wǎng)頁的組件,其包含的接口函數(shù)addJavascriptInterface可以將Java類或方法導(dǎo)出以供JavaScript調(diào)用,實現(xiàn)網(wǎng)頁JS與本地JAVA的交互。由于系統(tǒng)沒有限制已注冊JAVA類的方法調(diào)用,因此未注冊的其它任何JAVA類也可以被反射機制調(diào)用,這樣可能導(dǎo)致被篡改的URL中存在的惡意代碼被執(zhí)行,用戶手機被安裝木馬程序,發(fā)送扣費短信,通信錄或者短信被竊取,甚至手機被遠(yuǎn)程控制。
(3)Webview繞過證書校驗漏洞
客戶端的Webview組件訪問使用HTTPS協(xié)議加密的url時,如果服務(wù)器證書校驗錯誤,客戶端應(yīng)該拒絕繼續(xù)加載頁面。但如果重載WebView的onReceivedSslError()函數(shù)并在其中執(zhí)行handler.proceed(),客戶端可以繞過證書校驗錯誤繼續(xù)訪問此非法URL。這樣將會導(dǎo)致“中間人攻擊”,攻擊者冒充服務(wù)器與銀行客戶端進(jìn)行交互,同時冒充銀行客戶端與銀行服務(wù)器進(jìn)行交互,在充當(dāng)中間人轉(zhuǎn)發(fā)信息的時候,竊取手機號,賬號,密碼等敏感信息。
(4)未移除有風(fēng)險的Webview系統(tǒng)隱藏接口
android webview組件包含3個隱藏的系統(tǒng)接口:searchBoxJavaBridge, accessibilityTraversal以及accessibility,惡意程序可以利用它們實現(xiàn)遠(yuǎn)程代碼執(zhí)行。需通過顯示調(diào)用removeJavascriptInterface移除這三個系統(tǒng)隱藏接口。
(5)WebView忽略SSL證書錯誤
WebView調(diào)用onReceivedSslError方法時,直接執(zhí)行handler.proceed()來忽略該證書錯誤。忽略SSL證書錯誤可能引起中間人攻擊。
3.數(shù)據(jù)安全漏洞
3.1 數(shù)據(jù)存儲漏洞
(1)SharedPreferences漏洞
當(dāng)使用getSharedPreferences打開文件,第二個參數(shù)設(shè)置為MODE_WORLD_READABLE或MODE_WORLD_WRITEABLE。當(dāng)前文件可以被其他應(yīng)用讀取或?qū)懭氪鄹?,?dǎo)致信息泄漏或更嚴(yán)重的問題。
(2)File任意讀寫漏洞
如果開發(fā)者使用openFileOutput(String name,int mode)方法創(chuàng)建內(nèi)部文件時,使用MODE_WORLD_READABLE或 MODE_WORLD_WRITEABLE模式,就會讓這個文件變?yōu)槿挚勺x或全局可寫的。
3.2 數(shù)據(jù)加密漏洞
(1)明文數(shù)字證書漏洞
Apk中使用的數(shù)字證書可被用來校驗服務(wù)器的合法身份,以及在與服務(wù)器進(jìn)行通信的過程中對傳輸數(shù)據(jù)進(jìn)行加密、解密運算,保證傳輸數(shù)據(jù)的保密性、完整性。明文存儲的數(shù)字證書如果被篡改,客戶端可能連接到假冒的服務(wù)端上,導(dǎo)致用戶名、密碼等信息被竊??;如果明文證書被盜取,可能造成傳輸數(shù)據(jù)被截獲解密,用戶信息泄露,或者偽造客戶端向服務(wù)器發(fā)送請求,篡改服務(wù)器中的用戶數(shù)據(jù)或造成服務(wù)器響應(yīng)異常。
(2)AES/DES弱加密
在AES加密時,使用“AES/ECB/NoPadding”或“AES/ECB/PKCS5padding”的模式。ECB是將文件分塊后對文件塊做同一加密,破解加密只需要針對一個文件塊進(jìn)行解密,降低了破解難度和文件安全性。
(3)setSeed偽隨機數(shù)漏洞
本地加密時如果使用SecureRandom中的setSeed方法設(shè)置種子將會造成生成的隨機數(shù)不隨機,使加密數(shù)據(jù)容易被破解。在SecureRandom生成隨機數(shù)時,如果不調(diào)用setSeed方法,SecureRandom會從系統(tǒng)中找到一個默認(rèn)隨機源。每次生成隨機數(shù)時都會從這個隨機源中取seed。
3.3 數(shù)據(jù)傳輸漏洞
(1)SSL通信服務(wù)端檢測信任任意證書
自定義SSL x509 TrustManager,重寫checkServerTrusted方法,方法內(nèi)不做任何服務(wù)端的證書校驗。黑客可以使用中間人攻擊獲取加密內(nèi)容。
(2)未使用HTTPS協(xié)議的數(shù)據(jù)傳輸
無線傳輸?shù)臄?shù)據(jù)能被第三方輕易截獲,由于客戶端與服務(wù)器之間的傳輸數(shù)據(jù)遵循通信協(xié)議指定的格式和內(nèi)容類型,如果未使用加密措施,傳輸數(shù)據(jù)可被還原成網(wǎng)絡(luò)層的數(shù)據(jù)包并進(jìn)行解包分析,直接暴露用戶的各種關(guān)鍵數(shù)據(jù),例如用戶名,密碼等。加入了SSL(Secure SocketLayer)子層實現(xiàn)的HTTPS協(xié)議可確保數(shù)據(jù)在網(wǎng)絡(luò)上加密傳輸,即使傳輸?shù)臄?shù)據(jù)被截獲,也無法解密和還原。
(3)HTTPS未校驗服務(wù)器證書漏洞
使用HTTPS協(xié)議時,客戶端必須對服務(wù)器證書進(jìn)行完整校驗,以驗證服務(wù)器是真實合法的目標(biāo)服務(wù)器。如果沒有校驗,客戶端可能與仿冒的服務(wù)器建立通信鏈接,即“中間人攻擊”。仿冒的中間人可以冒充服務(wù)器與銀行客戶端進(jìn)行交互,同時冒充銀行客戶端與銀行服務(wù)器進(jìn)行交互,在充當(dāng)中間人轉(zhuǎn)發(fā)信息的時候,竊取手機號,賬號,密碼等敏感信息。
(4)HTTPS關(guān)閉主機名驗證
構(gòu)造HttpClient時,設(shè)置HostnameVerifier時參數(shù)使用ALLOW_ALL_HOSTNAME_VERIFIER或空的HostnameVerifier。關(guān)閉主機名校驗可以導(dǎo)致黑客使用中間人攻擊獲取加密內(nèi)容。
(5)開放socket端口
app綁定端口進(jìn)行監(jiān)聽,建立連接后可接收外部發(fā)送的數(shù)據(jù)。攻擊者可構(gòu)造惡意數(shù)據(jù)對端口進(jìn)行測試,對于綁定了IP 0.0.0.0的app可發(fā)起遠(yuǎn)程攻擊。
3.4 日志信息漏洞
(1)調(diào)試日志函數(shù)調(diào)用風(fēng)險
調(diào)試日志函數(shù)可能輸出重要的日志文件,其中包含的信息可能導(dǎo)致客戶端用戶信息泄露,暴露客戶端代碼邏輯等,為發(fā)起攻擊提供便利,例如:Activity的組件名,是Activity劫持需要的信息;通信交互的日志,會成為發(fā)動服務(wù)器攻擊的依據(jù);跟蹤的變量值,可能泄露一些敏感數(shù)據(jù),輸入的賬號、密碼等。
4.業(yè)務(wù)邏輯漏洞
4.1 權(quán)限漏洞
(1)全局文件可讀寫
APP在創(chuàng)建內(nèi)部存儲文件時,將文件設(shè)置了全局的可讀權(quán)限。攻擊者惡意讀取文件內(nèi)容,獲取敏感信息,或惡意寫文件,破壞完整性。
(2)敏感權(quán)限調(diào)用
在Manifest文件中調(diào)用一些敏感的用戶權(quán)限,敏感行為包括發(fā)送、攔截短信,讀取、修改通訊錄、通話記錄,撥打電話,發(fā)送地理位置,使用攝像頭,訪問瀏覽器歷史記錄等。函數(shù)調(diào)用這些敏感行為,可能導(dǎo)致用戶隱私數(shù)據(jù)泄露,釣魚扣費等風(fēng)險。
(3)冗余權(quán)限
如果調(diào)用了非必須的權(quán)限,就會出現(xiàn)冗余權(quán)限,冗余權(quán)限可導(dǎo)致串謀攻擊,串權(quán)限攻擊的核心思想是程序A有某個特定的執(zhí)行權(quán)限,程序B沒有這個權(quán)限。但是B可以利用A的權(quán)限來執(zhí)行需要A權(quán)限才能完成的功能。
4.2 業(yè)務(wù)漏洞
業(yè)務(wù)漏洞需要依靠機器和人共同檢測,需要根據(jù)應(yīng)用功能作用的不同來進(jìn)行判斷。機器可以檢測一些通用的業(yè)務(wù)漏洞,例如廣告、非授權(quán)下載、扣費短信等業(yè)務(wù),而人工則判斷應(yīng)用在面向不同業(yè)務(wù)邏輯時產(chǎn)生的漏洞,例如登錄驗證不完善、不可信的敏感數(shù)據(jù)交付等。
以上就是本文的全部內(nèi)容,希望對大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。
相關(guān)文章
Android使用PullToRefresh完成ListView下拉刷新和左滑刪除功能
ListView下刷新刷功能相信從事Android開發(fā)的猿友們并不陌生,本文就帶領(lǐng)一些剛?cè)腴Tandroid的朋友或者一起愛分享的朋友來簡單的實現(xiàn)ListView的下拉刷新和左滑刪除效果。感興趣的朋友一起看看吧2016-11-11Android實現(xiàn)美團(tuán)、大眾點評的購買懸浮效果(ScrollView滾動監(jiān)聽)
這篇文章主要為大家詳細(xì)介紹了Android對ScrollView滾動監(jiān)聽,實現(xiàn)美團(tuán)、大眾點評的購買懸浮效果,具有一定的參考價值,感興趣的小伙伴們可以參考一下2017-02-02Android組件創(chuàng)建DrawerLayout導(dǎo)航
這篇文章主要為大家詳細(xì)介紹了Android組件創(chuàng)建DrawerLayout導(dǎo)航的相關(guān)資料,具有一定的參考價值,感興趣的小伙伴們可以參考一下2017-01-01android byte[] 和short[]轉(zhuǎn)換的方法代碼
這篇文章主要介紹了android byte[] 和short[]轉(zhuǎn)換的方法代碼,有需要的朋友可以參考一下2014-01-01Android Studio導(dǎo)入so文件到項目中的實例詳解
這篇文章主要介紹了Android Studio導(dǎo)入so文件到項目中的實例詳解的相關(guān)資料,希望通過本文能幫助到大家,需要的朋友可以參考下2017-09-09Android實例代碼理解設(shè)計模式SOLID六大原則
程序設(shè)計領(lǐng)域, SOLID (單一功能、開閉原則、里氏替換、接口隔離以及依賴反轉(zhuǎn))是由羅伯特·C·馬丁在21世紀(jì)早期 引入的記憶術(shù)首字母縮略字,指代了面向?qū)ο缶幊毯兔嫦驅(qū)ο笤O(shè)計的基本原則2021-10-10