近日小編會陸續在專欄裡推送Android安全開發系列的文章，系列文章有部分是在聚安全的官方部落格裡更新過，時間跨度比較長，所以小編統一整理到專欄裡。對Android開發感興趣的小夥伴請關注聚安全和我們的安全專欄！當然，對APP安全有需求的小夥伴，可以去聚安全官網看看哦~

1、通用簽名風險簡介

1.1 Android應用簽名機制

阿里聚安全漏洞掃描器有一項檢測服務是檢測APP的通用簽名風險。Android系統要求安裝的應用必須用數字證書進行簽名後才能安裝，並且簽名證書的私鑰由應用開發者儲存。簽名證書的生成也由開發者自己生成。在應用安裝時會校驗包名（package name）和簽名，如果系統中已經存在了一個相同的包名和簽名的應用，將會用新安裝的應用替換舊的；如果包名相同但是簽名不同，則會安裝失敗。

為什麼需要數字簽名？

數字簽名是防止要保護的內容被篡改，用非對稱加密演算法

。

先對要保護的內容進行訊息摘要，用私鑰對訊息摘要進行加密，生成數字簽名，將數字簽名和要保護的內容一起分發出去。 內容接收者用公鑰對數字簽名解密得到傳送者給的訊息摘要A，內容接收者對接收到的內容進行用相同的訊息摘要演算法處理得到訊息摘要B，對比A和B是否相同，來判定傳送的內容是否被篡改。 正常的APK檔案是個ZIP壓縮檔案，除了應用的可執行檔案、資原始檔，還包括這些可執行檔案、資原始檔的摘要資訊，數字證書的公鑰資訊等。並且透過這些簽名信息可以確定APP和其開發者的關係。

進行簽名需要的工具有哪些？

對apk進行簽名需要用到簽名證書和簽名工具。Android系統要求對APP進行簽名的數字證書可以由開發者自己生成。簽名工具有

jarsigner

和

signapk

。jarsigner是Java本身自帶的一個工具，他也可以對jar進行簽名的；而signapk是專門為了Android應用程式apk進行簽名的工具。

二者的區別是：jarsigner工具簽名時使用的是keystore簽名檔案，signapk工具簽名時使用的是pk8，x509.pem檔案。

簽名後的檔案都有哪些？

應用簽名完後在應用的META-INF目錄下會有三個檔案：

CERT.RSA、CERT.SF和MANIFEST.MF。

MANIFEST.MF

中儲存了所有其他檔案的SHA1摘要並base64編碼後的值。

CERT.SF

檔案是對MANIFEST。MF檔案中的每項中的每行加上“\r\n”後，再次SHA1摘要並base64編碼後的值（這是為了防止透過篡改檔案和其在MANIFEST。MF中對應的SHA1摘要值來篡改APK，要對MANIFEST的內容再進行一次數字摘要）。

CERT.RSA

檔案：包含了簽名證書的公鑰資訊和釋出機構資訊。

對安裝包的校驗過程在原始碼的frameworks/base/core/java/android/content/pm/PackageParser。java類中可以看到，具體可看阿里聚安全部落格的另外一篇文章：Android5。1。1 - APK簽名校驗分析和修改原始碼繞過簽名校驗。

1.2 通用簽名風險

什麼是通用簽名？

搭建好Android開發環境後（使用Eclipse或Android Studio），對APK簽名的預設金鑰存在debug。keystore檔案中。在linux和Mac上debug。keystore檔案位置是在~/。android路徑下，在windows目錄下檔案位置是C：\user\使用者名稱。android路徑下。

除了debug。keystore外，在AOSP釋出的Android原始碼中，還有以下幾個證書是公開的，任何人都可以獲取，在原始碼的build/target/product/security目錄中：

這幾個證書的作用：

testkey

Generic default key for packages that do not otherwise specify a key。

platform

Test key for packages that are part of the core platform。

shared

Test key for things that are shared in the home/contacts process。

media

Test key for packages that are part of the media/download system。

verity

Test Key for verifiedboot system imagein Android Lollipop。 Sign boot。img，sign verity metadata in system。img。

通用簽名風險：

（1）如果攻擊者的應用包名與目標應用相同，又使用了相同的金鑰對應用進行簽名，攻擊者的應用就可以替換掉目標應用；

（2）另外目標應用的自定義許可權android：protectionlevel為“signature”或者“signatureOrSystem”時，保護就形同虛設；

（3）如果裝置使用的是第三方ROM，而第三方ROM的系統也是用AOSP預設的簽名，那麼使用如果使用系統級簽名檔案簽名過的應用，許可權就得到了提升。

對於普通開發者如果自己的簽名證書洩露也可能發生(1)、(2)條所提到的風險。

2、通用簽名風險示例

使用通用簽名的公開案例非常少，不過我們阿里聚安全漏洞掃描器還是發現了一些應用使用了通用簽名，掃描結果資料庫中查到曾經有

819個APP使用了AOSP的簽名證書

（排查了幾個APP的最新版，但都已經用了新的簽名；也不排除應用被惡意攻擊者反編譯重打包後使用通用簽名證書籤名）。 另外還有不少私有簽名證書洩露、濫用的（使用通用簽名證書其實就相當於洩露了簽名證書）情況。

舉個例子，有安全研究人員發現有一個數字證書籤名被很多銀行的手機客戶端所使用。與此同時還發現了幾款個人開發者類應用也使用了此證書籤名。而這種數字簽名被濫用的行為存在極大的安全隱患。

解壓應用安裝包，可用keytool檢視應用的簽名證書資訊：

keytool -printcert -v -file META-INF/CERT。RSA

經挖掘和分析，研究人員發現目前共有23款不同銀行手機銀行客戶端使用該簽名：

在應用市場內，目前共發現6款個人開發的應用同時使用該數字證書籤名：

事情發生的原因是銀行的外包開發管理不嚴，不同銀行的APP居然用同樣的數字證書籤名，並且開發者還將證書用於了個人APP的開發中。如果簽名證書被惡意攻擊者獲取，可以編寫安裝是能直接替換掉這些銀行客戶端的惡意APP。

還可以使用AOSP通用簽名提升應用許可權：

本人直接編譯AOSP原始碼得到的ROM，使用AOSP的預設證書，在設定->關於手機，版本號中可檢視到：

對於普通的用預設debug。keystore證書籤名的App，如果在AndroidManfiest。xml的manifest節點加入android：sharedUserId=”android。uid。system”這個屬性，安裝時會提示錯誤：

如果對app-debug。apk使用AOSP提供的platform。x509。pem和platform。pk8重新簽名，則可以安裝成功：

檢視應用的程序屬性，已是system使用者組。

目前有不少的第三方ROM使用的AOSP提供的預設簽名（見參考［4］的論文中所提）。

3、阿里聚安全對開發者建議

（1）上線前用阿里聚安全的漏洞掃描器進行一下檢查。

阿里聚安全的漏洞掃描器目前已能檢查出通用簽名風險，未來可能增加檢測證書是否洩漏風險。還可以發現其他安全風險。

（2） 生成自己專有的簽名證書，證書分類使用。

使用keytool工具生成。keystore的數字證書：

keytool -genkey -v -keystore my-release-key。keystore

-alias alias_name -keyalg RSA -keysize 2048 -validity 10000

使用jarsigner工具對打包好的APK進行簽名：

jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1

-keystore my-release-key。keystore my_application。apk alias_name

使用openssl生成pk8和x509。pm的證書，參考如下：

使用signapk工具和pk8、x509。pm證書對打包好的APP簽名：

java -jar signapk。jar platform。x509。pem platform。pk8 input。apk output。apk

或者Gradle打包配置設定：

（3）做好安全培訓，規範開發流程，證書之類的統一管理。

（4）個人開發者在往開源平臺上傳程式碼時，注意不要將簽名證書的私鑰上傳。

搜了下github，有不少開發者將其release版的keysotre上傳了，並且在gradle檔案上寫上了keystore的訪問密碼。如下：

參考

［1］ Sign Your App

https：//

developer。android。com/s

tudio/publish/app-signing。html

［2］ Android簽名機制之—簽名過程詳解，Android簽名機制之——-簽名過程詳解 - 生死看淡，不服就幹！ - 部落格頻道 - CSDN。NET

［3］ 數字簽名是什麼，數字簽名是什麼？ - 阮一峰的網路日誌

［4］ Min Zheng，DroidRay： A Security Evaluation System for Customized Android Firmwares

［5］ Signing Builds for Release，

https：//

source。android。com/devi

ces/tech/ota/sign_builds。html

［6］ android/platform_build

作者：伊樵、舟海、呆狐@阿里聚安全，更多Android安全技術文章，請持續關注阿里聚安全的安全專欄