InMobi: Another Vulnaggressive Adware Opens Billions of JavaScript Sidedoors on Android Devices

Summary. FireEye mobile security researchers identified another new mobile threat, which we call “JavaScript Sidedoors” (“JS Sidedoors” in short), which we discovered in the popular InMobi ad library. InMobi exposes dangerous behaviors such as making phone calls without user consent through JavaScript interfaces, which creates a “sidedoor” for attackers to exploit by injecting malicious JavaScript through hijacking InMobi’s HTTP traffic. After receiving our security notification, InMobi released new SDK versions that partially solved the problem. However, there are still 2.56 billion downloads of apps using old versions of InMobi SDK which remain vulnerable. We recommend ad library vendors like InMobi to carefully ensure the security of their libraries and actively advise app developers about the underlying security and privacy risks so that app developers can make informed decisions.
Following our previous discovery of Ad Vulna [1,2,3], FireEye mobile security researchers recently discovered another new mobile threat from a popular ad library that has not been previously reported. Mobile ad libraries are third-party software included by host apps in order to display ads. As shown in our previous blogs, some ad libraries are vulnaggressive: they are aggressive at collecting sensitive data, embedding functionalities and capabilities to perform dangerous operations such as downloading and running new code on demand, and they are also plagued with various classes of vulnerabilities that enable attackers to turn their aggressive behaviors against users.
In this blog, we describe a new class of vulnaggressive behaviors, which we call JS Sidedoors; and we identify this behavior in an extremely widely deployed ad library, InMobi. In particular, InMobi uses the new @JavaScriptInterface annotation to deliberately expose interfaces that allow aggressive behaviors such as making phone calls without user consent, thus opening a sidedoor for JavaScript loaded by this app’s WebView. Furthermore, InMobi is vulnerable to man-in-the-middle attacks because it loads content in its WebView using HTTP. Thus, an attacker on the network could inject malicious code to abuse the sidedoor embedded in InMobi to conduct attacks. We name this class of vulnaggressive threat JS Sidedoors.
We have identified more than 2,000 apps on Google Play that contain the vulnerable versions of InMobi and have over 100,000 downloads each. The total download count for these affected apps is greater than 2.56 billion. We have informed both Google and InMobi of our findings, and they are actively working to address it.
Background: JavaScript Can Control Android App
Older versions of Android use the JavaScript binding method addJavascriptInterface to enable JavaScript code running inside a WebView to access the app’s Java methods. However, as widely known, this method is dangerous as it allows untrusted content in the WebView to manipulate the host application in arbitrary ways, executing attacker’s code with the permissions of the host application.
To mitigate this risk, starting with Android API level JELLY_BEAN_MR1, Google introduced @JavascriptInterface annotation to explicitly designate and limit which public methods in Java objects are accessible from JavaScript. It is the developer’s responsibility to minimize use of the JS binding interface annotation to reduce the power of untrusted code in WebViews. However, note that @JavascriptInterface doesn’t provide any protection for devices using Android API level lower than JELLY_BEAN_MR1, i.e., Android 4.1 and below, which is still occupying more than 80 percent of the market worldwide.
InMobi Opens JS Sidedoors
InMobi began using addJavascriptInterface since version 2.5.0. Starting with version 3.6.2, InMobi added @JavascriptInterface. However, it used this mechanism to expose aggressive features to JavaScript in WebViews. The list of exposed methods include:

• createCalendarEvent
• makeCall
• postToSocial
• sendMail
• sendSMS
• takeCameraPicture
• getGalleryImage
• registerMicListener

Essentially, InMobi builds a sidedoor in host apps with these aggressive features to endow content in WebViews with these capabilities. InMobi also provides JavaScript wrappers to these methods on their ad servers, as shown in the Appendix B.
What Attackers Can Do With InMobi Sidedoors
Unfortunately, InMobi is vulnerable to man-in-the-middle attacks because it loads content in WebViews using HTTP. By hijacking the HTTP traffic of the app containing InMobi, e.g., via WiFi hijacking or DNS hijacking, attackers can inject malicious JavaScript code to take advantage of the sidedoors that InMobi embeds into host apps for malicious activities.
For example, by leveraging the sidedoors, if the app has the right permission (CALL_PHONE), an attacker could make phone calls, including to premium numbers, on the device without user consent.
With this vulnerability, attackers can also launch telephony distributed denial-of-service (T-DDoS) attacks targeting certain phone numbers, so that they can effectively paralyze the phone service of a given organization.
By leveraging the sidedoor, without requiring special permissions in the host app, attackers could also

• Post to user’s social network from the device
• Send SMS to premium numbers
• Create calendar events on the device
• Take pictures and access the photo gallery on the device

These activities would need the user to click on certain consent buttons to complete. However, as well known, users are vulnerable to social engineering attacks. The built-in sidedoor in InMobi gives the attacker the opportunity to perform these malicious activities by misguiding users to consent.
InMobi also has other sensitive behaviors. For example, through the sidedoor, attackers can use InMobi to start recording audio on the device without user consent. Luckily InMobi only uses this feature to adjust volume for its own contents instead of saving or uploading recorded audio. InMobi can also receive input from the app about user’s private information including gender, income, ethnicity, and so forth. After receiving such information, InMobi uploads them in plain text through HTTP, where an eavesdropper over the network can hijack and harvest the private information.
New InMobi Update
After we notified InMobi about these vulnaggressive behaviors, they released new SDK versions 4.0.3 and 4.0.4. The 4.0.3 SDK, marked as “Internal release”, was superseded by 4.0.4 after one day. The 4.0.4 SDK made the following changes:

1. Changed its methods for making phone calls to require user’s consent
2. Added a new storePicture interface to download and save specified files from the Internet to the user’s Downloads folder. Despite the name, it can be used for any file, not just images.

Comparing with InMobi’s earlier versions, we consider change #1 as an improvement that addresses the issue of an attacker making phone calls without users’ consent. We are glad to see that InMobi made this change after our notification. However, the new change still leaves the users vulnerable to social engineering attacks where attackers could misguide users into making premium calls. Unfortunately, change #2 gives attackers more opportunity for social engineering attacks, as it allows the attacker to leverage the storePicture interface to download and save arbitrary files onto the device.
Moving Forward: Pay Attention to Third-party Libraries
InMobi is another example of a vulnaggressive ad library. Comparing with Ad Vulna in our previous report, InMobi explicitly exposes aggressive features using @JavascriptInterface and builds a sidedoor exploitable through hijacked HTTP traffic.
It’s hard for app developers to understand the underlying security risks because 1) InMobi is closed-source and 2) InMobi doesn’t disclose any of these vulnaggressive features explicitly in its privacy policy or app developer SDK guide. We understand that library vendors like InMobi have the incentive to add rich functionality, however, it is important for the vendors to advise app developers about such features and functionality that cause sensitive security and privacy risks, so that app developers can make informed decisions. Customers may have different requirements regarding security and privacy. Apps with sidedoors can introduce serious threats to security sensitive environments such as enterprise networks. FireEye Mobile Threat Prevention protects our customers from such threats.
Acknowledgement
We thank our team member Adrian Mettler for his help on writing this blog.
Appendix A: Privacy Collection Claimed in InMobi Privacy Policy
We may collect some or all of the following information about your device: device type (e.g., smartphone, tablet, etc.), operating system (e.g., iOS, Android, Windows, Blackberry), network provider, Internet (IP) address, which mobile browser you use (e.g., Safari, Internet Explorer, etc.), the carrier user ID (a number uniquely allocated to you by your network provider), platform, SDK version, timestamp, API key (identifier for application), application version, iOS Identifier for Advertising, iOS Identifier for Vendors, Media Access Control (MAC) address, International Mobile Equipment Identity (IMEI), Model, manufacture and OS version of device, session start/stop time, locale (specific location where a given language is spoken), time zone, and network status such as WiFi, the geo-location of your device (using GPS or other geo-location data) and the unique device identifier of your mobile device (a number uniquely allocated to your device by your device manufacturer).
We also collect some or all of the following information about the ad you have viewed: (i) the content type of the ad (what the ad is about, e.g., games, finance, entertainment, news); (ii) the ad type (e.g., whether the ad is a text, image, or video based ad); (iii) where the ad is being served (e.g., the address of the website on which the ad appears); and (iv) certain information about post-click activity in relation to the ad (e.g., whether you proceed to purchase the product or service advertised). On occasion, our partnering mobile publishers or app developers may also disclose to us information they have separately collected about you so that we can improve the relevance of the ads we serve on their behalf.
The InMobi Audience Platform also provides information to publishers and developers about how you use and engage with their app as well as how sites or apps are performing across different handsets, including but not limited to tracking conversions across multiple advertising networks.
Appendix B: JavaScript Code Snippets from InMobi Ad Servers

a.takeCameraPicture = function () {
    utilityController.takeCameraPicture()
};

a.getGalleryImage = function () {
    utilityController.getGalleryImage()
};

a.makeCall = function (f) {
    try {
        utilityController.makeCall(f)
    } catch (d) {
        a.showAlert("makeCall: " + d)
    }
};

a.sendMail = function (f, d, b) {
    try {
        utilityController.sendMail(f, d, b)
    } catch (c) {
        a.showAlert("sendMail: " + c)
    }
};

a.sendSMS = function (f, d) {
    try {
        utilityController.sendSMS(f, d)
    } catch (b) {
        a.showAlert("sendSMS: " + b)
    }
};

a.postToSocial = function (a, c, b, e) {
    a = parseInt(a);
    isNaN(a) && window.mraid.broadcastEvent("error", 
        "socialType must be an integer", "postToSocial");
    "string" != typeof c && (c = "");
    "string" != typeof b && (b = "");
    "string" != typeof e && (e = "");
    utilityController.postToSocial(a, c, b, e)
};

a.createCalendarEvent = function (a) {
    "object" != typeof a && window.mraid.broadcastEvent("error", 
        "createCalendarEvent method expects parameter", "createCalendarEvent");
    "string" != typeof a.start || "string" != typeof a.end ? 
        window.mraid.broadcastEvent("error", 
            "createCalendarEvent method expects string parameters for start and end dates",
            "createCalendarEvent") : 
        ("string" != typeof a.location && (a.location = ""),
             "string" != typeof a.description && (a.description = ""), 
             utilityController.createCalendarEvent(a.start, a.end, a.location, a.description))
};

a.registerMicListener=function() {
    utilityController.registerMicListener()
};