Android證書驗證存漏洞 開發者身份信息可被篡改
責編：admin ｜2014-12-04 13:06:18近期在國內網易，雷鋒網等網站爆出谷歌市場上的索尼官方的備份與恢復應用“Backup and Restore”被黑的消息。新聞顯示：目前索尼官方的備份與恢復應用“Backup and Restore”已經被黑客徹底破解；甚至在Google Play商店里該應用的所有權都被黑客修改；目前仍不清楚使用破解修改版本的應用，會否對用戶造成損害；建議用戶盡量避免使用，刪除已下載的應用；目前在 Google Play上應用管理權都歸于“HeArt HaCkEr Group”，開發者信息顯示“Nirav Patel Kanudo”。
阿里錢盾專家分析認為，Android證書驗證機制存在漏洞，開發者身份信息可以任意篡改，而不會影響應用APK的安裝、升級、運行等操作。針對這一情況，阿里錢盾(qd.alibaba.com)團隊也專門進行了研究和提出了相應的解決措施。
Android證書驗證機制
首先，詳細說明Android應用程序安裝文件APK的證書驗證機制。
1. 基本算法
(1)消息摘要 -Message Digest
簡稱摘要，在消息數據上，執行一個單向的Hash函數，生成一個固定長度的Hash值，也稱為數字指紋，消息摘要有以下特點：
1. 通過摘要無法推算得出消息本身。
2. 如果修改了消息，那么摘要一定會變化(除開碰撞情況)。
3. 消息摘要只能保證消息的完整性，并不能保證消息的不可篡改性。
在Android證書里，一般采用SHA-1算法來生成摘要值。
(2)數字簽名 – Signature
消息的發送者用自己的私鑰對消息摘要進行加密，產生一個加密后的字符串，稱為數字簽名。因為發送者的私鑰保密，可以確保別人無法偽造生成數字簽名，也是對信息的發送者發送信息真實性的一個有效證明。數字簽名是 非對稱密鑰加密技術 + 數字摘要技術 的結合。
數字簽名技術是將信息摘要用發送者的私鑰加密，與原文一起傳送給接收者。接收者只有用發送者的公鑰才能解密被加密的信息摘要，然后接收者用相同的Hash函數對收到的原文產生一個信息摘要，與解密的信息摘要做比對。如果相同，則說明收到的信息是完整的，并且是由該發送者生成的(因為只有發送者才擁有對應的私鑰)。
(3)數字證書 – Certificate
數字證書是一個經證書授權中心數字簽名的包含公開密鑰擁有者信息以及公開密鑰的文件。
證書包含的有效信息有：證書版本、證書序號、證書頒發機構、證書有效期、證書擁有者和擁有者公鑰，以及證書頒發機構對該證書的簽名。
需要注意的是Android APK中的CERT.RSA證書可以是自簽名的，并不需要這個證書是第三方權威機構發布或者認證的，用戶可以在本地機器自行生成這個自簽名證書。
當使用某證書時，需要驗證該證書的合法性：使用證書頒發者的公鑰，然后對整個證書(除了證書數字簽名以外)采用給定的證書簽名算法計算，然后將計算結果同證書數字簽名對比，相同則可以證明該證書確實由證書頒發者頒發的合法證書；不同則說明有篡改存在，證書不合法。
2. Android證書組成
APK文件實際上是一個壓縮文件包，我們將文件后綴.APK修改為.zip，可以使用解壓縮軟件直接打開。如weixin.APK
(1) MANIFEST.MF
遍歷APK包中除了META-INF 文件夾以外的所有文件，利用SHA1算法生成這些文件的消息摘要，然后轉化為對應的base64編碼。MANIFEST.MF存儲的是文件的摘要值，保證完整性，防止文件被篡改。weixin的MANIFEST.MF：
Manifest-Version： 1.0
Created-By： 1.7.0_45 (Oracle Corporation)
Name： r/t/a3k.xml
SHA1-Digest： c6GfCzDzRo75w7HwMzjcPXGi++I=
Name： r/v/a1m.png
SHA1-Digest： Ao27xq4nYyBR5Z0yG07pN0MtlKI=
……
(2) .SF
xx.SF文件(xx為使用者證書的自定義別名，默認為CERT，即CERT.SF)，保存的是MANIFEST.MF的摘要值， 以及MANIFEST.MF中每一個摘要項的摘要值，然后轉化成對應的base64編碼。雖然該文件的后綴名.sf(SignatureFile)看起來是簽名文件，但是并沒有私鑰參與運算，也不保存任何簽名內容。
weixin的COM_TENC.SF：
Signature-Version： 1.0
SHA1-Digest-Manifest-Main-Attributes： sY6+RQ4DWdnxCfSpiwTT6GRIwA0=
Created-By： 1.7.0_45 (Oracle Corporation)
SHA1-Digest-Manifest： GduDrpyEw/pgWazHpioH6+7MyKo=
Name： r/t/a3k.xml
SHA1-Digest： b6IQQJD88w4yCVk0QHuy2cySHTE=
Name： r/v/a1m.png
SHA1-Digest： HqlAkc/TpMyeU/jhapu/Pxg1QLQ=
……
(3) .RSA / .DSA
.RSA / .DSA文件(后綴不同采用的簽名算法不同，.RSA使用的是RSA算法， .DSA使用的是數字簽名算法DSA，目前APK主要使用的是這兩種算法)，保存的是第二項.SF文件的數字簽名，同時還會包括簽名采用的數字證書(公鑰)。特別說明，當使用多重證書簽名時，每一個.sf文件必須有一個.RSA/.DSA文件與之對應，也就是說使用證書CERT1簽名時有CERT1.SF和CERT1.RSA，同時采用證書CERT2簽名時又會生成CERT2.SF和CERT2.RSA。
weixin的COM_TENC.RSA(解碼后)：
Certificate：
Data：
Version： 3 (0x2)
Serial Number： 1295447972 (0x4d36f7a4)
Signature Algorithm： sha1WithRSAEncryption
Issuer： C=86， ST=Guangdong， L=Shenzhen， O=Tencent Technology(Shenzhen) Company Limited， OU=Tencent Guangzhou Research and Development Center， CN=Tencent
Validity
Not Before： Jan 19 14：39：32 2011 GMT
Not After ： Jan 11 14：39：32 2041 GMT
Subject： C=86， ST=Guangdong， L=Shenzhen， O=Tencent Technology(Shenzhen) Company Limited， OU=Tencent Guangzhou Research and Development Center， CN=Tencent
Subject Public Key Info：
Public Key Algorithm： rsaEncryption
Public-Key： (1024 bit)
Modulus：
…..
Exponent： 65537 (0x10001)
Signature Algorithm： sha1WithRSAEncryption
……
.SF Signature Algorithm： sha1WithRSAEncryption
……
.RSA文件包括證書和.SF簽名2個部分，其中證書里面也有一個簽名，是證書頒發者對該證書的簽名。
對APK的證書簽名具體原理和算法，可以參考
https：//Android.googlesource.com … ignAPK/SignAPK.java
3. Android證書驗證機制
Android 系統不允許安裝沒有任何數字簽名的應用APK程序，所有應用程序必須使用某個證書進行簽名(一般為應用開發者自簽名證書)：
APK源文件，首先由應用開發者使用自己的私鑰，對整個文件進行簽名，生成上述的三個文件，然后打包成簽名后的APK文件；然后發布到市場，圖示是Google市場。
用戶從市場下載APK安裝文件，在真正安裝APK前，會首先驗證數字簽名。具體步驟：
(1) 首先計算除META-INF 文件夾以外所有文件的SHA1摘要值，同MANIFEST.MF文件中的摘要值做比對。如果不同，則證明源文件被篡改，驗證不通過，拒絕安裝。
(2) 計算MANIFEST.MF的摘要值， 以及MANIFEST.MF中每一個摘要項的摘要值，同.SF文件中的摘要值做比對。如果不同，則證明.SF被篡改，驗證不通過，拒絕安裝。
(3) 從.RSA 文件中取出開發者證書，然后從證書中提取開發者公鑰，用該公鑰對.SF文件做數字簽名，并將結果同.RSA文件中的.SF簽名進行比對。如果不同，則驗證不通過，拒絕安裝。
存在的問題
2014年報出來的Fake ID漏洞，是對證書鏈的驗證方法存在漏洞，沒有對證書本身的簽名進行驗證(不同于.SF簽名)，場景：證書頒發者A對證書B進行簽名，然后使用證書B對APK的.SF文件簽名，而安裝APK時僅僅驗證了證書B對.SF文件的數字簽名，而沒有驗證頒發者A對該證書B本身的數字簽名。目前，GOOGLE已經對該漏洞進行了修復，但筆者認為，該修復并不完全：僅僅修復了證書鏈的認證方法，沒有對自簽名證書中的證書數字簽名進行驗證，存在著一定的問題。
代碼段org.apache.harmony.security.utils. JarUtils：
191 // Signer is self-signed
192 if (signer.getSubjectDN().equals(signer.getIssuerDN())){
193 return (X509Certificate[])chain.toArray(new X509Certificate[1])；
194 }
當采用自簽名證書時，Android直接跳過驗證，將證書加入了合法證書列表。這導致攻擊者拿到.RSA / .DSA文件后，可以對其中的證書(除了證書擁有者公鑰之外)隨意篡改，包括證書序號、證書有效期、證書擁有者名字等等。而Android在安裝APK時，僅僅使用了證書中的公鑰，其它信息未使用也未作任何驗證，只要使用公鑰驗證.SF文件的數字簽名通過就可以正常安裝使用。
1. 證書有效期篡改
以weixin的COM_TENC.RSA證書為例，直接修改證書有效期(僅僅改動COM_TENC.RSA文件)：
Certificate：
……
Validity
Not Before： Jan 19 14：39：32 2011 GMT
Not After ： Jan 11 14：39：32 2011 GMT
……
很明顯的證書有效期錯誤，結束時間比開始時間還早，但是修改后的APK依然可以正常安裝、運行，因為COM_TENC.RSA文件里的公鑰(證書的一部分)和.SF文件都沒有修改，可以通過Android證書驗證機制。
聯想開來，某個已過期的證書依然可以使用，假如某個擁有高權限的證書已經過期，危害會很大。例如Adobe頒發過某個證書C(使用Adobe公鑰簽名該證書)，然后證書C過期了，但是由于用Adobe的公鑰驗證該證書仍然可以通過(修復過的證書鏈認證可以通過，除非Adobe吊銷它自己的證書)，而Android并沒有驗證證書有效性，所以用證書C簽過名的APK依然擁有Adobe的高權限。
2. 證書擁有者主體篡改
以weixin的COM_TENC.RSA證書為例，直接修改證書擁有者名字(僅僅改動COM_TENC.RSA文件)：
Certificate：
……
Issuer： C=86， ST=Guangdong， L=Shenzhen， O=abcdefg Technology(Shenzhen) Company Limited， OU=abcdefg Guangzhou Research and Development Center， CN=abcdefg
Validity
Not Before： Jan 19 14：39：32 2011 GMT
Not After ： Jan 11 14：39：32 2011 GMT
Subject： C=86， ST=Guangdong， L=Shenzhen， O=abcdefg Technology(Shenzhen) Company Limited， OU=abcdefg Guangzhou Research and Development Center， CN=abcdefg
……
將開發者信息修改為了abcdefg，但是修改后的APK依然可以正常安裝、運行，因為COM_TENC.RSA文件里的公鑰(證書的一部分)和.SF文件都沒有修改，可以通過Android證書驗證機制。
聯想開來，開發者主體信息很容易修改，造成知識版權問題，例如可以把Google開發的APK的開發者證書信息修改成我自己的名字，擴大影響力；或者，把自己開發的惡意APK冠上Google的名字。
3. 證書吊銷CRL
Android證書機制并沒有引入CRL吊銷機制，已經吊銷但擁有合法簽名的證書依然可以使用，和第一項證書過期類似(證書過期，也是吊銷的一種方法)。
但是，證書吊銷還有另外一個應用，當發現某個證書的私鑰有泄露或是被破解時，業界常用的手法是吊銷該證書，加入CRL列表，例如2012年發生的Yahoo Axis私鑰泄露事件。在Android系統里，并沒有采用證書吊銷機制，設想場景：Adobe頒發過某個證書D(使用Adobe公鑰簽名該證書)，然后證書D在使用過程中發生了私鑰泄露，那么此時只有吊銷Adobe自己的根證書才能真正使證書D失效，成本大而且會影響其他Adobe簽過名的證書。
Google的態度
筆者就上述問題上報過Google Security。Google回復，證書機制只是用來認證開發者擁有該證書的私鑰，并不驗證證書本身的合法性(因為自簽名系統，每個人都可以成為自己的證書頒發者)。而證書有效期問題，Google Play自己的市場有驗證，但在Android系統里沒有引進(為什么？)，對其它第三方市場不保證。然后，證書吊銷CRL機制，因為沒有好的方法實現，所以沒做。
筆者認為，目前可以加強的是自簽名證書的驗證機制(增加一行驗證代碼即可)，對自簽名證書的數字簽名也使用自簽名證書的公鑰進行驗證，可以杜絕對.RSA/ .DSA文件的任意篡改。
Hi Yichin，
The behavior you describe is working as intended. App signing certificates for Android are only designed to identify that the author of an app has the private key for that certificate， not to verify their actual identity. There is currently no way to effectively revoke a certificate used to sign an APK.
This is documented here： https：//source.Android.com/devices/tech/security/
"Applications can be signed by a third-party (OEM， operator， alternative market) or self-signed. Android provides code signing using self-signed certificates that developers can generate without external assistance or permission. Applications do not have to be signed by a central authority. Android currently does not perform CA verification for application certificates."
There is also more information here：
http：//developer.Android.com/tools/publishing/app-signing.html
Regarding expired certificates， we actually enforce that APKs published in Play not expire until 2033：
"If you plan to publish your apps on Google Play， the key you use to sign these apps must have a validity period ending after 22 October 2033. Google Play enforces this requirement to ensure that users can seamlessly upgrade apps when new versions are available."
Although， at this time， the Android platform itself does not enforce the validity period.
-jon
Sony官方系統應用偽造的原因分析
Google Play市場上出現了偽造的Sony官方系統應用，并且可以被用戶覆蓋升級本機的合法系統應用。Android應用的覆蓋升級，前提要求是應用的覆蓋前后2個版本擁有相同的開發者公鑰(不是證書，僅僅是公鑰)，只要前后的2個公鑰相同，Android默認前后2個開發者擁有相同的私鑰，據此認定是同一個開發者。也就是說，偽造者和Sony使用的是相同的公鑰。
偽造者使用的是同Sony相同的公鑰，卻可以將應用開發者身份信息隨意修改，將Sony Mobile Communications修改成Nirav Patel Kanudo。如果Android對自簽名證書也進行過驗證，則可以杜絕這種行為，因為一旦證書擁有者被篡改，那么該證書的數字簽名不可能通過驗證。
由于新聞信息簡短，而且偽造的APK已經下架(沒有拿到樣本)，筆者做以下推論分析：
(1) Sony的Google賬號可能有泄露，攻擊者可以使用Sony賬號在Google市場上傳APK。
(2) Sony 私鑰沒有泄露。該APK仍然是官方出品的APK，但是被攻擊者修改了證書文件里的證書擁有者信息，將Sony Mobile Communications修改成了Nirav Patel Kanudo。應用本身無害，用戶使用沒有問題。
(3) Sony私鑰有泄露。攻擊者修改了官方應用APK(可能植入惡意代碼)，然后使用Sony的私鑰對修改后的APK重新打包簽名，而且修改了證書文件里的證書擁有者信息(將Sony Mobile Communications修改成了Nirav Patel Kanudo)，并上傳到了Google Play。應用有害，用戶使用有風險。
不管是以上哪種情況，可以確認的是自簽名證書中的開發者身份信息可以任意修改，Android系統缺少對自簽名證書里的數字簽名的驗證，僅僅實現了對.SF文件的簽名驗證。
Android市場目前嚴峻形勢
1. 最權威的市場也可能存在仿冒的應用
作為Android手機最權威的官方應用市場，Google Play一直以來都是Android應用市場中最安全的市場之一。但本次被黑應用上架的市場正是谷歌市場，可見其在審核開發者信息的過程也存在漏洞。據此前阿里移動安全的研究分析，被黑和仿冒應用的風險普遍存在，有超過80%的熱門應用都存在仿冒，且平均仿冒數量高達13個。若再將開發者信息的仿冒包含在內，仿冒應用的風險形式必將更加嚴峻。
在國內部分應用市場上，應用的開發者信息在應用查看，下載和安裝的過程都不進行顯示。且Android手機上是否允許非官方應用市場來源的應用的選項往往是打開的。國內Android的整體安全性更讓人擔憂。
2. 應用不可信？用戶應該如何是好？
雖然本次事件不一定會造成嚴重風險，但因為Android應用安裝的漏洞和Android應用市場的不規范，導致不可信應用非常普遍，用戶還是需要引起注意，阿里錢盾專家提醒大家：
(1)涉及賬戶，資金的應用如淘寶，支付寶，微信等 盡量在官方網站進行應用下載。
(2)謹慎選擇應用，并在手機上安裝安全軟件，防止自身信息的泄露。
(3)用戶可以通過安裝阿里錢盾，獲得最重要的網購和資金安全保護。