Over the past several months security researchers have found serious vulnerabilities in many mobile advertising libraries that could be exploited to abuse the permissions of Android apps or to execute unauthorized code on users’ devices. The risks resulting from those vulnerabilities would be significantly lower if those libraries would use HTTPS, security researchers said.

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. An attacker who could intercept traffic from such libraries—for example on public wireless networks, through DNS hijacking or by hacking into an Internet gateway—could inject malicious JavaScript code into the connection to perform unauthorized actions using the host app’s permissions, they said.

If, for example, an app using a vulnerable ad library has permission to access the Android device’s camera, then a remote attacker could exploit this issue to take photos or record video over the Internet without the user’s consent, the FireEye researchers said.

The vulnerability stems from an Android API (application programming interface) feature called addJavascriptInterface that allows JavaScript code running in a WebView to access the app’s native functionality. A WebView is a browser window that apps can use to display Web content.

Advertising libraries, also known as advertising SDKs (Software Development Kits), consist of third-party code that many developers include in their apps in order to earn revenue from advertising displayed in the app. These libraries commonly use the WebView feature to display ads loaded from a remote server and many of them also use the addJavascriptInterface for more advanced features. Android device users who want to keep tabs on what mobile ad networks are running in their apps can download products like Lookout’s Ad Network Detector.

The security risks appear when the addJavascriptInterface method is used and remote content is loaded in a WebView over an unencrypted HTTP connection, because plain HTTP traffic is susceptible to tampering by anyone in a position to intercept it.

“Our analysis shows that, currently, at least 47 percent of the top 40 ad libraries have this vulnerability in at least one of their versions that are in active use by popular apps on Google Play,” the FireEye researchers said.

However, the security risks associated with addJavascriptInterface have been known for a while. In September researchers from London-based security firm MWR InfoSecurity reported that the use of addJavascriptInterface, which they refer to as JavaScript bridging, combined with the lack of HTTPS, can be exploited to obtain a reverse TCP shell on a device. They too pointed out that many ad libraries are vulnerable to this attack.

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.

InMobi appears to actually be in a better position when it comes to this problem than many other ad libraries, which according to Wei, still have the more serious addJavascriptInterface vulnerability in their latest versions. Wei declined to name any of those libraries as FireEye is still in the process of notifying its developers.

InMobi was the only library found by FireEye so far that used the new @JavascriptInterface annotation but had JS sidedoor problems, he said. “We want other vendors to be aware of this issue and not repeat it.”

The Android version fragmentation is also a problem. The @JavascriptInterface mechanism only works on Android 4.2 or higher, but according to the latest statistics published by Google, around 75 percent of Android devices that visited Google Play at the beginning of January were running Android versions older than 4.2.

“The insecure usage of JS Binding and JS Binding annotations in third-party libraries exposes many apps that contain these libraries to security risks,” the FireEye researchers said. “When third-party libraries use JS Binding, we recommend using HTTPS for loading content.”

InMobi doesn’t agree with FireEye’s conclusions.

“Unfortunately, FireEye has taken industry-level concerns and applied those specifically to InMobi, making some incorrect assumptions along the way regarding our products,” said Chris Davies, InMobi’s head of privacy and its general counsel for the EMEA region, via email. “They’re making vast generalizations regarding potential industry vulnerabilities and applying those to InMobi without understanding our products and our commitment to privacy and security. We have tried to work with FireEye to discuss their claims but our attempts of opening a meaningful dialogue have been unsuccessful to date.”

“It should be understood that the required situation for a potential breach includes multiple sets of conditions that are extremely unlikely to occur at the same time and that the real potential risk is minimal, at best,” Davies said.

He agreed that using HTTPS would mitigate a potential attack, but said there are other technological methods of achieving the same result.

“While HTTPS is a standard technology for the Internet, even in the desktop world there are cases where you’d want to apply HTTPS versus cases where you wouldn’t,” he said. “HTTPS is a very CPU- and network-intensive protocol. There are many other ‘lighter’ technologies available which can provide the same benefits.”

InMobi couldn’t find any ad network in the mobile space that conducts all transactions over HTTPS, Davies said. “In the ad tech industry we are all aware of the benefits of HTTPS but still have chosen not to use it, there must be some reason for it.”

InMobi already encrypts device identifiers so that if anyone sniffs ad requests, the data they would obtain couldn’t be associated with specific device IDs, he said. “Inmobi plans to encrypt all the user information using a secret key in our SDK before requesting for an ad. This will be included in our next release of the SDK.”

The company makes significant efforts to encourage developers to use the latest version of the SDK, Davies said. “We conduct comprehensive marketing and communications campaigns when we launch products or new, improved versions of a product and this includes direct emails to developers and publishers in our database, as well as general public awareness tactics like press releases, articles, interviews, blog posts, videos, etc.”

If it believes there is a significant security risk, the company will advise app developers to upgrade immediately to a new version of the SDK, he said.

Some security experts don’t think the performance impact of implementing HTTPS should outweigh its security benefits.

“Plenty of applications such as email clients and social networking clients have already fully migrated to SSL without side effects,” said Bogdan Botezatu, a senior e-threat analyst at security firm Bitdefender. “We are talking about personal information being sent unencrypted over the network, and this is something app developers should take seriously.”

Last month researchers from Bitdefender found a vulnerability in an ad library called HomeBase SDK that would have posed less of a risk if the library had used HTTPS. They found that HomeBase was updating itself over HTTP, allowing man-in-the-middle attackers to potentially inject a rogue update package into the traffic that would then get executed on the device with the host application’s permissions.

Widdit, the Israel-based company that develops HomeBase SDK, said at the time that it plans to secure the traffic with SSL by the end of January.

“By design, mobile devices spend most of the time connected to wireless networks that the user has no control over, such as those in coffee shops, airports and so on,” Botezatu said. “More than that, anybody can set up a rogue access point with no security set in place, lure the nearby users into connecting to it and then intercept or manipulate traffic. Man-in-the-middle attacks on Wi-Fi networks are definitely a possibility that should be taken into account.”

Even if there have been no reports so far of real world attacks exploiting the addJavascriptInterface issues, it’s only a matter of time until attackers pick up on them, Robert Miller, a security consultant at MWR Infosecurity, said. “It’s a question of when, not if.”

MWR researchers built a proof-of-concept box that can be placed on any wireless network to intercept and exploit traffic from phones connected to that network, Miller said.

JavaScript bridge attacks are ridiculously easy to do, Miller said. By reading a Web page and using tools available online for free, an attacker could have it ready in half an hour, he said.

HTTPS would mitigate the man-in-the-middle attack vector, but not others like rogue ads potentially making their way into the ad network and exploiting this issue. However, adding HTTPS would massively increase the levels of security that ad library vendors offer to their customers, Miller said.

See the original post here!