Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Mobile users at risk from lack of HTTPS use by mobile ad libraries, security researchers say

Lucian Constantin | Feb. 3, 2014
Researchers from security firm FireEye recently reported that many ad libraries expose sensitive functionality to JavaScript code over insecure connections, making apps using them vulnerable to man-in-the-middle attacks.

Google even put a security note in the official Android developer documentation for addJavascriptInterface. "Use of this method in a WebView containing untrusted content could allow an attacker to manipulate the host application in unintended ways, executing Java code with the permissions of the host application," the note reads. "Use extreme care when using this method in a WebView which could contain untrusted content."

In order to limit the security risks, starting with Android 4.2, Google added an annotation called @JavascriptInterface that developers can use to define exactly what Java methods they want to expose to JavaScript code running in a WebView. This is essentially a whitelisting mechanism that forces developers to decide what functionality they want to allow.

However, according to the FireEye researchers, while @JavascriptInterface annotation is theoretically an improvement, its effectiveness actually depends on how developers use it. Developers can also add code so that any actions triggered from JavaScript through the exposed methods require consent.

One popular ad library called InMobi SDK started using @JavascriptInterface since version 3.6.2, the FireEye researchers said. The Java methods that InMobi exposed in versions 3.6.2 and 3.7.0 included: createCalendarEvent, makeCall, postToSocial, sendMail, sendSMS, takeCameraPicture, getGalleryImage and registerMicListener.

The FireEye researchers claim that InMobi requested user consent for actions through these methods, except for the makeCall one. "If an app has the Android permission CALL_PHONE, and is using InMobi versions 3.6.2 to 4.0.2, an attacker over the network (for example, using Wi-Fi or DNS hijacking) could abuse the makeCall annotation in the app to make phone calls on the device without a user's consent -- including to premium numbers," the FireEye researchers said.

The researchers named this type of vulnerability a JavaScript sidedoor, or JS sidedoor.

InMobi added a consent requirement for makeCall actions in version 4.0.4 after FireEye notified the company of the issue, the researchers said. However, there are still many apps on Google Play that use older and vulnerable versions of this ad library, they said.

"We have identified more than 3,000 apps on Google Play that contain versions 2.5.0 to 4.0.2 of InMobi -- and which have over 100,000 downloads each as of December, 2013," the researchers said. "Currently, the total download count for these affected apps is greater than 3.7 billion."

Even with the consent requirement, exposing Java methods to JavaScript while the WebView connection with the server is not encrypted is still dangerous, according to the FireEye researchers. Attackers could use social engineering methods to trick users into giving their consent for a malicious action, they said.

A fake lottery-related message, a free coupon or some other kind of offer injected into the WebView could be used to mislead users into clicking the consent button, Tao Wei, senior staff research scientist at FireEye, said via email. HTTPS with correct certificate verification would provide better protection than HTTP, he said.

 

Previous Page  1  2  3  4  Next Page 

Sign up for CIO Asia eNewsletters.