Android安全開發之通用簽名風險
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的最新版，但都已經用了新的簽名；也不排除應用被惡意攻擊者反編譯重打包后使用通用簽名證書簽名）。 另外還有不少私有簽名證書泄露、濫用的（使用通用簽名證書其實就相當于泄露了簽名證書）情況。
以烏云公開的WooYun-2014-67027為例，有安全研究人員發現有一個數字證書簽名被很多銀行的手機客戶端所使用。與此同時還發現了幾款個人開發者類應用也使用了此證書簽名。而這種數字簽名被濫用的行為存在極大的安全隱患。
解壓應用安裝包，可用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/studio/publish/app-signing.html
[4] Min Zheng，DroidRay: A Security Evaluation System for Customized Android Firmwares
[5] Signing Builds for Release， https://source.android.com/devices/tech/ota/sign_builds.html
來自：http://jaq.alibaba.com/community/art/show?articleid=457