Android FakeID arbitrary code injection vulnerability analysis

Android FakeID arbitrary code injection vulnerability analysis

UVulnerability background
 

On April 9, July 30, 2014, BlueBox, a security agency outside China, announced the APK signature vulnerability-FakeID. Attackers can exploit this vulnerability to inject code and execute malicious operations.
 

UHazards
 

1) affected system versions: Some Android 4.4 and all versions earlier than Android 4.4;

2) typical attack scenarios: applications using the Android webview component can be maliciously monitored or private data stolen, which may pose a threat to GoogleWallet payment applications, obtain the control permissions of NFC (short-range wireless communication) devices;

 

UVulnerability Principle
 

1) APK Signature
 

Android applications need to sign before release, the signature information in the apk compressed package/META-INF directory (. RSA), the system will check the signature in the following scenarios:
 

L verify the integrity of the file data in the apk before installation;

L identify the apk. If an apk has a system signature, it has higher permissions. If the two apk signatures are consistent, the two applications can share data;

L in some specific scenarios, some applications will verify that other applications have a specific signature. For example, webkit will verify that a plug-in program is issued by Adobe.
 

The self-signed certificate of the Android app is as follows:
 

 

2) Problem
 

The Android system does not verify the sub-certificate when verifying the certificate chain, as shown in. The root certificate only verifies whether the issuer name of the sub-certificate is the same as its own subject name, it does not verify whether they are signed with the same public key. As a result, malicious applications can perform malicious operations by forging certificates.
 

 

 

 

The vulnerability code is located in the findCert method of the JarUtils class. The Code comparison before and after fixing is as follows:
 

 

 

UVulnerability Exploitation
 

The exploitation process of the FakeID vulnerability includes certificate forgery, malicious application signature, certificate tampering, and application installation to the client. This article describes how to reproduce a vulnerability and forge a malicious Adobe Flash Player Plug-in. The vulnerability is verified as follows:
 

A) When WebKit accesses the page requesting flash, it will call the Adobe flash Player Plug-in;

B) The basis for WebKit authentication of Adobe Flash Player Plug-in is that the bottom-layer certificate in the APK certificate chain is Adobe's signature certificate;

C) malicious applications should meet the Adobe Flash Player Plug-in authentication requirements, and put a compliant so file in the APK for Webkit to call.

Therefore, if a malicious application is forged and its root certificate is tampered with as a real Adobe certificate, authentication can be passed. When you access the page requesting flash, malicious code in the so library is automatically called and executed.

 

1) forged certificate
 

L modify the openssl. cnf configuration and set the policy attribute to policy_anything;

L use openssl to generate a CA self-Signed root certificate (set to Adobe Certificate Name)

L use the root certificate to issue a subcertificate

L import the root certificate to the keystore

L import the sub-certificate to the keystore
 

After the operation is complete, the forged sub-certificate contains two certificate nodes, authentication 1 for itself, authentication 2 for CA root certificate (forged false Adobe certificate), two certificates constitute a certificate chain, as follows:
 

 

 

 

 

 

2) construct malicious applications that meet the requirements
 

L comply with Adobe Flash Player Plug-in specifications

In addition to using Adobe signature, you must also meet the following requirements: APK applied for android. webkit. permission. PLUGIN permission; APK declares a service, and Intent is android. webkit. PLUGIN, where the meta information is type and the type value must be native;
 

L compliant with webkit Plug-in development specifications

 

3) use the sub-certificate to sign the malicious apk
 

In this case, the signature of the malicious application contains two certificates. The Adobe certificate is false (with the same name), as shown below:
 

 

 

 

4) tamper with the apk certificate to make a valid Adobe certificate as the issuer
 

By using automated script [1], combine the RSA signature file in the/META-INF directory of the malicious application apk with the signature file of the real Adobe application, generate an RSA signature file with a real Adobe certificate and replace it with the original signature file. The contents of the tampered signature file are as follows:
 

 

 

 

 

 

5) install malicious applications on the client

Install the malicious plug-in application constructed above to the client.

 

UVulnerability exploits
 

Combined with the Android FakeID and LaunchAnyWhere vulnerabilities, the system can inject APP processes and remotely listen to the logon password of apps.

1) when a user opens a malicious app, the malicious app automatically calls the webview to access a webpage containing flash, so that the so file is injected into the process and the user enters the password silently;
 

 

Malicious app

 

 

 

Malicious apps automatically open web pages

 

 

So library injection successful

 

2) After the user enters the password in, the malicious app will send the password entered by the user to the remote server

 

User input password

 

 

Remote Server receiving Password

 

 

UVulnerability Solution
 

Upgrade the android system to the latest version or install an apk Patch [3] provided by a third party under the XPOSED framework to temporarily fix this vulnerability.

 

 

URefer:

[1] https://github.com/retme7/FakeID_poc_by_retme_bug_13678484/

[2] http://bluebox.com/technical/android-fake-id-vulnerability/

[3] http://repo.xposed.info/module/tungstwenty.xposed.fakeidfix