亚洲日本免费-啊轻点灬太粗太长了三男一女-麻豆av电影在线观看-日韩一级片毛片|www.grbbt.com

　　近期在國內(nèi)網(wǎng)易，雷鋒網(wǎng)等網(wǎng)站爆出谷歌市場上的索尼官方的備份與恢復(fù)應(yīng)用“Backup and Restore”被黑的消息。新聞顯示：目前索尼官方的備份與恢復(fù)應(yīng)用“Backup and Restore”已經(jīng)被黑客徹底破解；甚至在Google Play商店里該應(yīng)用的所有權(quán)都被黑客修改；目前仍不清楚使用破解修改版本的應(yīng)用，會否對用戶造成損害；建議用戶盡量避免使用，刪除已下載的應(yīng)用；目前在 Google Play上應(yīng)用管理權(quán)都?xì)w于“HeArt HaCkEr Group”，開發(fā)者信息顯示“Nirav Patel Kanudo”。

　　阿里錢盾專家分析認(rèn)為，Android證書驗(yàn)證機(jī)制存在漏洞，開發(fā)者身份信息可以任意篡改，而不會影響應(yīng)用APK的安裝、升級、運(yùn)行等操作。針對這一情況，阿里錢盾(qd.alibaba.com)團(tuán)隊(duì)也專門進(jìn)行了研究和提出了相應(yīng)的解決措施。

　　Android證書驗(yàn)證機(jī)制

　　首先，詳細(xì)說明Android應(yīng)用程序安裝文件APK的證書驗(yàn)證機(jī)制。

　　1. 基本算法

　　(1)消息摘要 -Message Digest

　　簡稱摘要，在消息數(shù)據(jù)上，執(zhí)行一個(gè)單向的Hash函數(shù)，生成一個(gè)固定長度的Hash值，也稱為數(shù)字指紋，消息摘要有以下特點(diǎn)：

　　1. 通過摘要無法推算得出消息本身。

　　2. 如果修改了消息，那么摘要一定會變化(除開碰撞情況)。

　　3. 消息摘要只能保證消息的完整性，并不能保證消息的不可篡改性。

　　在Android證書里，一般采用SHA-1算法來生成摘要值。

　　(2)數(shù)字簽名 – Signature

　　消息的發(fā)送者用自己的私鑰對消息摘要進(jìn)行加密，產(chǎn)生一個(gè)加密后的字符串，稱為數(shù)字簽名。因?yàn)榘l(fā)送者的私鑰保密，可以確保別人無法偽造生成數(shù)字簽名，也是對信息的發(fā)送者發(fā)送信息真實(shí)性的一個(gè)有效證明。數(shù)字簽名是 非對稱密鑰加密技術(shù) + 數(shù)字摘要技術(shù) 的結(jié)合。

　　數(shù)字簽名技術(shù)是將信息摘要用發(fā)送者的私鑰加密，與原文一起傳送給接收者。接收者只有用發(fā)送者的公鑰才能解密被加密的信息摘要，然后接收者用相同的Hash函數(shù)對收到的原文產(chǎn)生一個(gè)信息摘要，與解密的信息摘要做比對。如果相同，則說明收到的信息是完整的，并且是由該發(fā)送者生成的(因?yàn)橹挥邪l(fā)送者才擁有對應(yīng)的私鑰)。

　　(3)數(shù)字證書 – Certificate

　　數(shù)字證書是一個(gè)經(jīng)證書授權(quán)中心數(shù)字簽名的包含公開密鑰擁有者信息以及公開密鑰的文件。

　　證書包含的有效信息有：證書版本、證書序號、證書頒發(fā)機(jī)構(gòu)、證書有效期、證書擁有者和擁有者公鑰，以及證書頒發(fā)機(jī)構(gòu)對該證書的簽名。

　　需要注意的是Android APK中的CERT.RSA證書可以是自簽名的，并不需要這個(gè)證書是第三方權(quán)威機(jī)構(gòu)發(fā)布或者認(rèn)證的，用戶可以在本地機(jī)器自行生成這個(gè)自簽名證書。

　　當(dāng)使用某證書時(shí)，需要驗(yàn)證該證書的合法性：使用證書頒發(fā)者的公鑰，然后對整個(gè)證書(除了證書數(shù)字簽名以外)采用給定的證書簽名算法計(jì)算，然后將計(jì)算結(jié)果同證書數(shù)字簽名對比，相同則可以證明該證書確實(shí)由證書頒發(fā)者頒發(fā)的合法證書；不同則說明有篡改存在，證書不合法。

　　2. Android證書組成

　　APK文件實(shí)際上是一個(gè)壓縮文件包，我們將文件后綴.APK修改為.zip，可以使用解壓縮軟件直接打開。如weixin.APK

　　(1) MANIFEST.MF

　　遍歷APK包中除了META-INF 文件夾以外的所有文件，利用SHA1算法生成這些文件的消息摘要，然后轉(zhuǎn)化為對應(yīng)的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為使用者證書的自定義別名，默認(rèn)為CERT，即CERT.SF)，保存的是MANIFEST.MF的摘要值， 以及MANIFEST.MF中每一個(gè)摘要項(xiàng)的摘要值，然后轉(zhuǎn)化成對應(yīng)的base64編碼。雖然該文件的后綴名.sf(SignatureFile)看起來是簽名文件，但是并沒有私鑰參與運(yùn)算，也不保存任何簽名內(nèi)容。

　　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使用的是數(shù)字簽名算法DSA，目前APK主要使用的是這兩種算法)，保存的是第二項(xiàng).SF文件的數(shù)字簽名，同時(shí)還會包括簽名采用的數(shù)字證書(公鑰)。特別說明，當(dāng)使用多重證書簽名時(shí)，每一個(gè).sf文件必須有一個(gè).RSA/.DSA文件與之對應(yīng)，也就是說使用證書CERT1簽名時(shí)有CERT1.SF和CERT1.RSA，同時(shí)采用證書CERT2簽名時(shí)又會生成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個(gè)部分，其中證書里面也有一個(gè)簽名，是證書頒發(fā)者對該證書的簽名。

　　對APK的證書簽名具體原理和算法，可以參考

　　https：//Android.googlesource.com … ignAPK/SignAPK.java

　　3. Android證書驗(yàn)證機(jī)制

　　Android 系統(tǒng)不允許安裝沒有任何數(shù)字簽名的應(yīng)用APK程序，所有應(yīng)用程序必須使用某個(gè)證書進(jìn)行簽名(一般為應(yīng)用開發(fā)者自簽名證書)：

　　APK源文件，首先由應(yīng)用開發(fā)者使用自己的私鑰，對整個(gè)文件進(jìn)行簽名，生成上述的三個(gè)文件，然后打包成簽名后的APK文件；然后發(fā)布到市場，圖示是Google市場。

　　用戶從市場下載APK安裝文件，在真正安裝APK前，會首先驗(yàn)證數(shù)字簽名。具體步驟：

　　(1) 首先計(jì)算除META-INF 文件夾以外所有文件的SHA1摘要值，同MANIFEST.MF文件中的摘要值做比對。如果不同，則證明源文件被篡改，驗(yàn)證不通過，拒絕安裝。

　　(2) 計(jì)算MANIFEST.MF的摘要值， 以及MANIFEST.MF中每一個(gè)摘要項(xiàng)的摘要值，同.SF文件中的摘要值做比對。如果不同，則證明.SF被篡改，驗(yàn)證不通過，拒絕安裝。

　　(3) 從.RSA 文件中取出開發(fā)者證書，然后從證書中提取開發(fā)者公鑰，用該公鑰對.SF文件做數(shù)字簽名，并將結(jié)果同.RSA文件中的.SF簽名進(jìn)行比對。如果不同，則驗(yàn)證不通過，拒絕安裝。

　　存在的問題

　　2014年報(bào)出來的Fake ID漏洞，是對證書鏈的驗(yàn)證方法存在漏洞，沒有對證書本身的簽名進(jìn)行驗(yàn)證(不同于.SF簽名)，場景：證書頒發(fā)者A對證書B進(jìn)行簽名，然后使用證書B對APK的.SF文件簽名，而安裝APK時(shí)僅僅驗(yàn)證了證書B對.SF文件的數(shù)字簽名，而沒有驗(yàn)證頒發(fā)者A對該證書B本身的數(shù)字簽名。目前，GOOGLE已經(jīng)對該漏洞進(jìn)行了修復(fù)，但筆者認(rèn)為，該修復(fù)并不完全：僅僅修復(fù)了證書鏈的認(rèn)證方法，沒有對自簽名證書中的證書數(shù)字簽名進(jìn)行驗(yàn)證，存在著一定的問題。

　　代碼段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 }

　　當(dāng)采用自簽名證書時(shí)，Android直接跳過驗(yàn)證，將證書加入了合法證書列表。這導(dǎo)致攻擊者拿到.RSA / .DSA文件后，可以對其中的證書(除了證書擁有者公鑰之外)隨意篡改，包括證書序號、證書有效期、證書擁有者名字等等。而Android在安裝APK時(shí)，僅僅使用了證書中的公鑰，其它信息未使用也未作任何驗(yàn)證，只要使用公鑰驗(yàn)證.SF文件的數(shù)字簽名通過就可以正常安裝使用。

　　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

　　……

　　很明顯的證書有效期錯誤，結(jié)束時(shí)間比開始時(shí)間還早，但是修改后的APK依然可以正常安裝、運(yùn)行，因?yàn)镃OM_TENC.RSA文件里的公鑰(證書的一部分)和.SF文件都沒有修改，可以通過Android證書驗(yàn)證機(jī)制。

　　聯(lián)想開來，某個(gè)已過期的證書依然可以使用，假如某個(gè)擁有高權(quán)限的證書已經(jīng)過期，危害會很大。例如Adobe頒發(fā)過某個(gè)證書C(使用Adobe公鑰簽名該證書)，然后證書C過期了，但是由于用Adobe的公鑰驗(yàn)證該證書仍然可以通過(修復(fù)過的證書鏈認(rèn)證可以通過，除非Adobe吊銷它自己的證書)，而Android并沒有驗(yàn)證證書有效性，所以用證書C簽過名的APK依然擁有Adobe的高權(quán)限。

　　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

　　……

　　將開發(fā)者信息修改為了abcdefg，但是修改后的APK依然可以正常安裝、運(yùn)行，因?yàn)镃OM_TENC.RSA文件里的公鑰(證書的一部分)和.SF文件都沒有修改，可以通過Android證書驗(yàn)證機(jī)制。

　　聯(lián)想開來，開發(fā)者主體信息很容易修改，造成知識版權(quán)問題，例如可以把Google開發(fā)的APK的開發(fā)者證書信息修改成我自己的名字，擴(kuò)大影響力；或者，把自己開發(fā)的惡意APK冠上Google的名字。

　　3. 證書吊銷CRL

　　Android證書機(jī)制并沒有引入CRL吊銷機(jī)制，已經(jīng)吊銷但擁有合法簽名的證書依然可以使用，和第一項(xiàng)證書過期類似(證書過期，也是吊銷的一種方法)。

　　但是，證書吊銷還有另外一個(gè)應(yīng)用，當(dāng)發(fā)現(xiàn)某個(gè)證書的私鑰有泄露或是被破解時(shí)，業(yè)界常用的手法是吊銷該證書，加入CRL列表，例如2012年發(fā)生的Yahoo Axis私鑰泄露事件。在Android系統(tǒng)里，并沒有采用證書吊銷機(jī)制，設(shè)想場景：Adobe頒發(fā)過某個(gè)證書D(使用Adobe公鑰簽名該證書)，然后證書D在使用過程中發(fā)生了私鑰泄露，那么此時(shí)只有吊銷Adobe自己的根證書才能真正使證書D失效，成本大而且會影響其他Adobe簽過名的證書。

　　Google的態(tài)度

　　筆者就上述問題上報(bào)過Google Security。Google回復(fù)，證書機(jī)制只是用來認(rèn)證開發(fā)者擁有該證書的私鑰，并不驗(yàn)證證書本身的合法性(因?yàn)樽院灻到y(tǒng)，每個(gè)人都可以成為自己的證書頒發(fā)者)。而證書有效期問題，Google Play自己的市場有驗(yàn)證，但在Android系統(tǒng)里沒有引進(jìn)(為什么？)，對其它第三方市場不保證。然后，證書吊銷CRL機(jī)制，因?yàn)闆]有好的方法實(shí)現(xiàn)，所以沒做。

　　筆者認(rèn)為，目前可以加強(qiáng)的是自簽名證書的驗(yàn)證機(jī)制(增加一行驗(yàn)證代碼即可)，對自簽名證書的數(shù)字簽名也使用自簽名證書的公鑰進(jìn)行驗(yàn)證，可以杜絕對.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官方系統(tǒng)應(yīng)用偽造的原因分析

　　Google Play市場上出現(xiàn)了偽造的Sony官方系統(tǒng)應(yīng)用，并且可以被用戶覆蓋升級本機(jī)的合法系統(tǒng)應(yīng)用。Android應(yīng)用的覆蓋升級，前提要求是應(yīng)用的覆蓋前后2個(gè)版本擁有相同的開發(fā)者公鑰(不是證書，僅僅是公鑰)，只要前后的2個(gè)公鑰相同，Android默認(rèn)前后2個(gè)開發(fā)者擁有相同的私鑰，據(jù)此認(rèn)定是同一個(gè)開發(fā)者。也就是說，偽造者和Sony使用的是相同的公鑰。

　　偽造者使用的是同Sony相同的公鑰，卻可以將應(yīng)用開發(fā)者身份信息隨意修改，將Sony Mobile Communications修改成Nirav Patel Kanudo。如果Android對自簽名證書也進(jìn)行過驗(yàn)證，則可以杜絕這種行為，因?yàn)橐坏┳C書擁有者被篡改，那么該證書的數(shù)字簽名不可能通過驗(yàn)證。

　　由于新聞信息簡短，而且偽造的APK已經(jīng)下架(沒有拿到樣本)，筆者做以下推論分析：

　　(1) Sony的Google賬號可能有泄露，攻擊者可以使用Sony賬號在Google市場上傳APK。

　　(2) Sony 私鑰沒有泄露。該APK仍然是官方出品的APK，但是被攻擊者修改了證書文件里的證書擁有者信息，將Sony Mobile Communications修改成了Nirav Patel Kanudo。應(yīng)用本身無害，用戶使用沒有問題。

　　(3) Sony私鑰有泄露。攻擊者修改了官方應(yīng)用APK(可能植入惡意代碼)，然后使用Sony的私鑰對修改后的APK重新打包簽名，而且修改了證書文件里的證書擁有者信息(將Sony Mobile Communications修改成了Nirav Patel Kanudo)，并上傳到了Google Play。應(yīng)用有害，用戶使用有風(fēng)險(xiǎn)。

　　不管是以上哪種情況，可以確認(rèn)的是自簽名證書中的開發(fā)者身份信息可以任意修改，Android系統(tǒng)缺少對自簽名證書里的數(shù)字簽名的驗(yàn)證，僅僅實(shí)現(xiàn)了對.SF文件的簽名驗(yàn)證。

　　Android市場目前嚴(yán)峻形勢

　　1. 最權(quán)威的市場也可能存在仿冒的應(yīng)用

　　作為Android手機(jī)最權(quán)威的官方應(yīng)用市場，Google Play一直以來都是Android應(yīng)用市場中最安全的市場之一。但本次被黑應(yīng)用上架的市場正是谷歌市場，可見其在審核開發(fā)者信息的過程也存在漏洞。據(jù)此前阿里移動安全的研究分析，被黑和仿冒應(yīng)用的風(fēng)險(xiǎn)普遍存在，有超過80%的熱門應(yīng)用都存在仿冒，且平均仿冒數(shù)量高達(dá)13個(gè)。若再將開發(fā)者信息的仿冒包含在內(nèi)，仿冒應(yīng)用的風(fēng)險(xiǎn)形式必將更加嚴(yán)峻。

　　在國內(nèi)部分應(yīng)用市場上，應(yīng)用的開發(fā)者信息在應(yīng)用查看，下載和安裝的過程都不進(jìn)行顯示。且Android手機(jī)上是否允許非官方應(yīng)用市場來源的應(yīng)用的選項(xiàng)往往是打開的。國內(nèi)Android的整體安全性更讓人擔(dān)憂。

　　2. 應(yīng)用不可信？用戶應(yīng)該如何是好？

　　雖然本次事件不一定會造成嚴(yán)重風(fēng)險(xiǎn)，但因?yàn)锳ndroid應(yīng)用安裝的漏洞和Android應(yīng)用市場的不規(guī)范，導(dǎo)致不可信應(yīng)用非常普遍，用戶還是需要引起注意，阿里錢盾專家提醒大家：

　　(1)涉及賬戶，資金的應(yīng)用如淘寶，支付寶，微信等 盡量在官方網(wǎng)站進(jìn)行應(yīng)用下載。

　　(2)謹(jǐn)慎選擇應(yīng)用，并在手機(jī)上安裝安全軟件，防止自身信息的泄露。

　　(3)用戶可以通過安裝阿里錢盾，獲得最重要的網(wǎng)購和資金安全保護(hù)。