Mobile Security Evangelos Markatos FORTH-ICS and University of Crete Full Professor, head of DCS http://www.ics.forth.gr/dcs/ Institute of Computer Science (ICS) Foundation for Research and Technology – Hellas (FORTH) Ack: This project has received funding from the European Union’s Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No 690972 and from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement No. 786669

Roadmap Overall area The problem Methodology Results Summary

Roadmap Overall area The problem Methodology Results Summary

Let us start with a question: Are smartphones secure? Smartphones seem to be secure! Apps are downloaded from Google Store or Apple Store and thus are probably safe Apps do not have malware Someone checked them before they are published Smartphones are a “closed” environment Which leaves little room for attackers So: Smartphones do not seem to have malware and thus they seem to be secure

The issue with smartphones Smartphone security is different from traditional desktop/laptop security In desktops attackers are interested in the device! Desktops/laptops (devices) are being compromised to be used as bots (in botnets) In smartphones “attackers” are interested not so much in the device as in Data Tracking information Personal information User preferences

How do attackers get data from smartphones? Choice 1: they may compromise a smartphone It may be difficult It may be illegal Choice 2: use Apps! Create a popular app Convince people to install it Collect data through the app Choice 3: use cookies! Third-party cookies, tracking cookies In this line of research we focus on choices “2” and “3”

Roadmap Overall area The problem Methodology Results Summary

As people use their smartphones Overall Problem As people use their smartphones to browse the web or execute apps, what kind information is collected about them?? We do not assume compromised devices Just regular devices Using regular web browsers Using ordinary apps

Relevant Publications P. Papadopoulos, N. Kourtellis, E. P. Markatos: Cookie Synchronization: Everything You Always Wanted to Know But Were Afraid to Ask. WWW 2019 P. Papadopoulos, N. Kourtellis, E. P. Markatos: The Cost of Digital Advertisement: Comparing User and Advertiser Views. WWW 2018. E. P. Papadopoulos, M. Diamantaris, P. Papadopoulos, T. Petsas, S. Ioannidis, E. P. Markatos: The Long-Standing Privacy Debate: Mobile Websites vs Mobile Apps. WWW 2017. Best Paper Honorable Mention.

Suppose that you would like to access a service such as facebook. Problem Definition Suppose that you would like to access a service such as facebook. There are two options to do it A: use the facebook app B: use a browser and go to www.facebook.com Question: What information do the two options leak? Which option leaks the most?

Which is the entity that leaks the information? Third Party Trackers Collect users’ data to provide Personalized Advertisement Web sites have Cookies! Mobile apps have Third party libraries! For Ads, Analytics, etc.

Third-party Libraries Third-party libraries Inherit all the apps’ permissions If the app can access the camera So does the third party library If the app can access the user’s contacts If the app can access the SIM card

What kinds of data can be leaked? An online service may leak Personal Data E.g. birthdate, email, gender, age, etc. Device-specific data e.g. identifiers The android identifier The SIM card identifier The apps installed in the smartphone, etc.

Methodology: How did we measure it? Went to Alexa (ranks web sites) Collected the top 300 services Chose those that had an app (116 services) For each of the 116 services We accessed them through the app Through the web browser And found what information they leak

Roadmap Overall area The problem Methodology Results Summary

Our Dataset

Roadmap Overall area The problem Methodology Results Summary

First experiment: Are there third party libraries in apps? 56.67% of apps contain at least one analytics- or ad-related library 9 in-app libraries!

Second experiment: What do they leak? Nexus 6 running Android 6.0.1 Capture traffic: Raspberry Pi  mitmproxy SSL-capable monitoring proxy Run each service for 20 mins: through web (Firefox browser) through app Filter possible leaked identifiers using pattern matching

Privacy Leaks: What we found 58% of the apps leak the Android ID identifier not accessible by websites unique for each device Allows for tracking (even between different apps!) 9.5% of the apps leak at least one SIM Card ID 3.5% of the apps leak the list of installed apps can be used to find the user’s interests 4.3% of the apps leak Nearby Access Points

Roadmap Overall area The problem Methodology Results Summary

In Summary... Question: Results: What kinds of information do smartphones leak? Do apps or browsers leak more? Results: Both apps and browsers leak information Apps leak significantly more (device identifiers, installed apps, nearby APs, etc.)  allowing trackers to infer user interests, gender, even behavioral patterns

Mobile Security Evangelos Markatos FORTH-ICS and University of Crete Full Professor, head of DCS http://www.ics.forth.gr/dcs/ Institute of Computer Science (ICS) Foundation for Research and Technology – Hellas (FORTH) Ack: This project has received funding from the European Union’s Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No 690972 and from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement No. 786669

Our approach: antiTrackDroid Blocks outgoing requests to third-parties Core design principles: app-independent no additional infrastructure (VPN, proxy) by leveraging Xposed framework: intercepts every outgoing request  checks destination’s domain name against a blacklist of mobile trackers

antiTrackDroid – Privacy Performance Run the 30 top leaking apps in with and without antiTrackDroid antiTrackDroid Reduce the number of leaked identifiers by 27.41% on the average Functionality across apps remains the same

antiTrackDroid – Latency Overhead < 1ms antiTrackDroid: adds overhead in benign requests < 1ms/request reduces overall latency in case of blocked requests