An Android application package (APK) can include multiple modules; one or more of these modules may be an advertisement SDK. That’s pretty normal nowadays, as many Android developers currently use such modules to compensate for providing their products to users for free. So what happens if the app is clean, but the ad module is fishy?
When the user accepts and grants permission for the main app to install (assuming they really understood or care about the permissions requested), the user is also by extension allowing the ad modules to use those same permissions. Sometimes, the permissions are only used by the ad module, not the main application.
Currently, Android apps don’t differentiate between permissions used by the main app, and those used by the ad modules. And when it comes to security, that’s still a gray area, both for users and analysts. As an example, here is a screenshot of the Permissions tab of an ad-supported app downloaded from the official Android Market, with a very generic description of the permissions:
Wouldn’t it be clearer to the user if the Permissions tab indicated how the permissions were used by both the main app and the ad module? Or better still, there was a separate permissions tab for the ad module? This would give the user with a clearer idea of what the main app/ad module will do, and they would be in a better position to chose whether they want to proceed with the installation.
We had a recent case that illustrated this – Spyware:Android/AdBoo.A, where the main app was clean, but the ad module was the problem: it collected confidential user information and sent it out to a remote server.
Now, most advertising services need some info from the phone in order to serve ‘targeted’ advertisements, but for AdBoo, we considered that the module was asking for rather too much info. And since the ad module basically shared the permissions of its host main app, there’s no way to block the ad module and leave the main app.
Once the permissions are granted to the app, the ad module can proceed. If it only displays legitimate ads, that’s fine. If the module includes a questionable routine, that’s not so fine. In ABoo’s case, the module collects details from the phone, some of which are highlighted in the screenshot below:
And here are the corresponding Smali codes where these information were actually collected before serving the advertisement banners:
On a related note, currently there is no clear indication whether the app will include ads, or what kind of ads will be displayed, before or during installation. Some developers will clearly state in their documentation that an app will include ads, but not all developers are that thorough. Wouldn’t it be clearer for the users if the apps were clearly designated as ‘ad-supported’ or ‘ad-free’?
And a final issue – not all developers control the type of ads being displayed in their products. Ad modules usually pull materials from third-party advertisement providers, sometimes from multiple services, which makes it trickier all around to control the type of ads being displayed. At worst, that seems to have led to some cases of adult ads being displayed in apps meant for children.
ThreatSolutions post by Jessie
Leave a reply