1. What Mobile Ads know about mobile users
Authors - Sooel Son, Daehyeok Kim, and Vitaly Schmatikov (2016)
Presented by - Aditya Walanj

2. Motivation Advertising is an important part of the mobile ecosystem.
Mobile advertising helps app developers obtain revenue.
Mobile advertising is integrated in mobile apps through an advertising library known as AdSDK.
Over 41% of apps in Google play store include at least one mobile advertising library.
Malicious advertising is a serious issue in the mobile advertising ecosystem.

3. Background
AdSDK is a library to fetch and display ads as app is running.
Creatives displayed on devices are called impressions.
Service provider place trackers into creatives.
WebView instances don’t share cookies or state across app
Service providers rely on device identifiers. e.g GAID, Android ID
HTTP Requests (GET/POST)
Advertising creatives (HTML, JSON, XML)
Impressions displayed as WebView Instances.

4. Problem
Apps on users device and AdSDK are benign but advertisers are not.
Impressions undergo auctions, brokers, and exchanges before reaching device.
Trusted ad service providers – AdMob, MoPub, AirPush, AirMarvel
Service providers serve ads over HTTP --> man in the middle attack possible!
Malicious mobile ads can cause leakage of location
Access to location required for geotargeted advertising
Malicious mobile ads can Infer sensitive information about users
Ads cache images and file so require external storage access
After Android 4.4, write permission to external storage automatically grants the read permission
Same Origin Policy in WebView prevents malicious ads to read external storage files, but not prevent from learning file names!

5. Experiment
Used a proxy server to intercept creatives sent by the advertising network and add a script element to it.
Each exploit requires two apps:
A Target app which creates the local files on devices external storage whose presence leaks sensitive information.
An Attack-vector app which is an ad supported app that shows a malicious creative using one of the AdSDK.
Any app using the same AdSDK can be exploited by an attack vector.

6. Results
Both use same AdSDK
Local files created by these apps

7. Summary
Target app caches HTML files or images in external storage to improve user experience
Names of cached file are predictable regardless of Android version or device
An attacker can precompute an offline database of file names, use local resource oracle in his ads, and check presence of file on users device.
E.g. Bookmark functionality in GoodRX

8. Defences App Developers cannot do much:
Business logic of AdSDK and configuration setting of WebView instances are opaque to developers.
Developers have no mechanism to restrict the privileges of the AdSDK they include.
AdSDK providers can do a few things:
Scan advertising creatives  can be evaded by attackers
Ban scripts in creatives  Impractical
Jail the WebView instance used to show impressions so it only accesses a dedicated subspace of external storage  More feasible but difficult to implement.
Mobile OS designers can do useful things:
Provide an inbuilt “Jail” functionality that can be invoked by an API call
iOS-each app’s files are located under a file path with a 128-bit unique ID

9. Issues and Improvements
Only location and external storage permissions explored.
Assumption that other apps on users device are benign - not necessarily
Not much on what users can do.
Look into camera and microphone permissions too
Investigation taking into account other apps on device are not benign.
What can users do – AdBlockers efficient?
Checksum-type logic?

10. Thank you for listening