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

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.

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.

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!

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.

Results Both use same AdSDK Local files created by these apps

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

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

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?

Thank you for listening