AN INVESTIGATIVE STUDYINTO THE PRIVACY OF IOS

APPLICATIONS

MICHAEL SILVERBLATTMENTOR: MING CHOWTUFTS UNIVERSITY

1. Abstract

This paper looks to address the many pri-vacy concerns that accompany the vast mo-bile application usage in todays world. Manyusers are often not even aware that an appcan access their personal information, let aloneshare it with others and use it for its ownbenefit. However, despite the increase inscrutiny that apps must go through just toappear in the Apple App Store following thenegative publicity surrounding the revelationthat a popular app, Path, had been upload-ing users address books without permissionto use for marketing purposes, many popu-lar applications still post information aboutusers to their servers with no immediatelyapparent purpose. Some of the apps areproperly granted permission to use such in-formation; others have found ways aroundApples enforcement of its policies. In thispaper I discuss the implications of applica-tion privacy violation, the current di�cul-ties in determining leakage of private infor-mation from iOS devices, and introduce aPython script to aid in the monitoring of ap-plications, called iosscan, which uses mitm-proxy to decode SSL tra�c and presents asummary to the user. The paper concludeswith preliminary findings in tra�c from cer-tain popular applications and a note about

the importance of remaining vigilant whenusing the web or any web-connected device.

2. Introduction

Mobile applications are prime targets formalicious applications for many reasons. Theyare widely used by people with every levelof technical sophistication, which leaves formany unsuspecting victims. An exciting newgame that may have slipped through the cracksof the testing process could go viral beforethe developer removes the code snippet thatposts GPS locations of users. Mobile com-puting by nature comes with computationaland network limitations, so users have grownaccustomed to quirky behavior such as lag-ging or freezing, which allows time for ma-licious code to run before a user thinks tostop it.

3. To the Community

Privacy of mobile applications should beof great concern to anyone who uses a cel-lular device. If all of the information thatis logged about you could be gathered inone place, one could likely track your everymovement, down to every time you not onlycheck your phone, but switch between ap-plications, as well as every person or thingyou ever come into contact with. It can bedangerous for so much information about anindividual to be in the open; one is left vul-nerable to anything from physical assault toidentity theft or e-ransoms.

3.1. Usage Logs/Analytics Frameworks.Mobile analytics platforms undoubtedly pro-vide developers with useful information forthe purposes of debugging and improvingsoftware, but the extent to which usage is

1

2 MICHAEL SILVERBLATT MENTOR: MING CHOW TUFTS UNIVERSITY

logged is too extreme to be necessary. Luck-ily, some of the platforms allow a user toopt-out of the logging frameworks by provid-ing your iPhones Unique Device IDentifier(UDID), but most people would not knowwhere to find that even if they somehow dis-covered their usage was being logged. In the-ory, these logs are anonymous and pose noimmediate threat, but as I discuss later on,this may not be the case.

3.2. Marketing Agencies. Marketing frame-works work similarly to analytics logs, ex-cept they attempt to associate personal datato a device to target advertising content ratherthan debug an application. Apart from theobvious concerns about being publically linkedto information gathered from things like websearches, we also run the risk of amassing alargely false body of information. There isoften more than one person who regularlyuses a device, yet all of their information islikely bundled together and tied to a singleidentity. Not only could a user not changethis information if it is incorrect, they wouldhave no way of knowing it was wrong in thefirst place. This can be damaging if it wereever to leak to future employers or other per-sons of interest.

3.3. NSA/Government. Protecting ones pri-vacy from the government is of comparableconcern to protecting it from corporationsand malicious users. As recently leaked con-fidential documents have revealed, the gov-ernment, and in particular the NSA, attemptto store and file away any information theycan get their hands on. It is far from a boldassumption to think they could potentiallyaccess not only your marketing portfolios,but your usage records as well.

4. How We Stop Applications FromAccessing Personal Data

4.1. Privacy Policy. Apple has a strict pol-icy regarding user information that can beaccessed within an application. Unlike An-droid applications, which request all permis-sions prior to installation, iOS applicationsrequest permissions at runtime. Since a re-quest for permissions can come at any time,this can both be confusing to users and makeit more di�cult for Apple to deny unautho-rized requests. Thus, Apple must rely on acombination of static and dynamic analysisto determine if an application is fit for salein the App Store, and these analyses are notalways accurate.

4.2. Binary Analysis. Tools for determin-ing how secure an application is with yourprivate data are far less advanced for mobileplatforms than full-fledged desktops. Datacan be accessed with a single function call.Developers have discovered clever ways aroundbinary static analysis of their code, allowingthem to execute functions that are forbid-den. Analyzers like Veracodes AdiOS do agood job of detecting information leakage,but they are not perfect. As shown in aBlackHat presentation by Nicolas Seriot, thefollowing code should not be allowed by aniOS application, but would pass many staticanalyzers.

- (NSString *)stringMinus1:(NSString

*)s {

NSMutableString *s2 =

[NSMutableString string];

for(int i = 0; i < [s length];

i++) {

unichar c = [s

characterAtIndex:i];

[s2 appendFormat:@"%C",

c-1];

}

AN INVESTIGATIVE STUDY INTO THE PRIVACY OF IOS APPLICATIONS 3

return s2;

}

- (void)viewDidAppear:(BOOL)animated {

NSString *pathPlus1 =

@"0wbs0npcjmf0Mjcsbsz0Qsfgfsfodft0dpn

/bqqmf/bddpvoutfuujoht/qmjtu";

// @"/var/mobile/Library/Preferences/

// com.apple.accountsettings.plist"

NSString *path = [self

stringMinus1:pathPlus1];

NSDictionary *d = [NSDictionary

dictionaryWithContentsOfFile:path];

// ...

}

4.3. Dynamic Analysis. Dynamic analy-sis presents a whole di↵erent set of issues.In certain cases, it is obvious that an HTTPrequest is sending data it should not have,such as a request to a URL along the linesof store all contacts. A request from a gameto set highscore, on the other hand, wouldappear to be benign at first glance. How-ever, further inspection may reveal that thepayload not only includes the score from thelast game played, but a copy of the users en-tire address book. Other than by looking,it is nearly impossible to detect that such arequest would be malicious. To be e�cientwhile dynamically analyzing an application,it is necessary to find a reliable heuristic forwhich requests are worthwhile to track fur-ther.

4.4. How can we do better? A paper fromthe University of California, San Diego ti-tled ProtectMyPrivacy: Detecting and Mit-igating Privacy Leaks on iOS Devices Us-ing Crowdsourcing introduces a novel ap-proach to assessing privacy risks. It detailsa method of crowdsourcing application datafrom a large user base, and using said datato recommend privacy settings for an arrayof di↵erent software. Recognizing both that

trustworthy and malicious requests can oftenbe indistinguishable without enough extrainformation, and that access to personal in-formation is not always immediately appar-ent from source code, Agarwal and Hall over-come these obstacles by attempting to de-termine which applications should have ac-cess to certain information, rather than de-termining which actually do. Unfortunately,their application, ProtectMyPrivacy, was onlymade available to users with jailbroken iOSdevices, as it monitors system processes otherthan its own. This limits its use consider-ably, since the act of jailbreaking a deviceinvites a litany of other security issues, andthus is not the focus of this paper.

5. iosscan

5.1. A New Way To Scan iOS Tra�c.I looked to create a tool to aid an end userin monitoring the behavior of their iOS de-vices and the applications that run on them.Building on top of Aldo Cortesis mitmproxyproject, using mitmdump in particular, I wrotea script in Python which gives context to thetra�c in and out of an iOS device. Mitm-dump and mitmproxy are man-in-the-middleproxies for decoding SSL and reading HTTP/Stra�c. Mitmdump runs similarly to the morecommon tcpdump, while mitmproxy runs witha nice interactive interface. Rather than recre-ate the wheel, I looked to build somethingthat would enhance the use of an existingtool.

5.2. Usage and Functionality. Using mit-mdump or mitmproxy alone and manuallyinspecting the output, request by request,is an ine�cient and nearly useless practice.My script, iosscan, allows a user to see a livecount of personal information being sharedand a log of the various apis being accessedfrom the device, as well as filter tra�c by a

4 MICHAEL SILVERBLATT MENTOR: MING CHOW TUFTS UNIVERSITY

specific host api to see who is actually break-ing (or not breaking) privacy permissions.The script reads output from mitmdump lineby line, summarizing vital parts of each re-quest by searching for various keywords inthe URLs and payloads of the requests. Itis intended to help a user determine whetheror not they should be concerned about theapplications they use on a daily basis. I stillrecommend use of mitmproxy to directly in-spect any tra�c you are concerned about,as it does a very e↵ective job of detailingrequests.

6. Application Data Uncovered withiosscan

6.1. Facebook. The Facebook iOS had someof the most obviously suspicious activity thr-oughout my testing. Whenever in the back-ground, the application would sporadicallysend incredibly detailed device informationto the /mobilelogs and similar actions of theirapi, including carrier information and evenbattery state. Having noticed that it loggeddata constantly even when not in use, I im-mediately uninstalled it. A sample loggingrequest can be seen on the following page.

6.2. Snapchat. My analysis of Snapchat re-vealed multiple concerns, the most outstand-ing of which being that it posts to a log-ging framework every time the application isopened or closed. These logs are not anon-ymized by a device identifier, but actuallyinclude the username associated with the de-vice. On top of tracking exactly how andwhen each and everyone uses the applica-tion, many of the features are incredibly un-secured. For example, to prevent users fromtaking screenshots of the images only intendedto last a few seconds, upon viewing a snap,a post request is sent with the number of

screenshots as a parameter. Using mitm-proxy, it would be a trivial task to interceptthis request and modify the parameter to re-main 0.

6.3. foursquare. The foursquare app wasdi�cult to analyze, since it is a social appbased on location and thus much of the per-sonal information it transmits is authorized.However, it does submit a post request uponbeing opened with a ll parameter which ap-peared to contain a set of coordinates. Sureenough, the coordinates mapped to my GPSlocation. It appears the service logs your lo-cation whenever you use it, even if you arenot searching for nearby friends/attractionsor attempting to check-in and post your lo-cation.

7. Conclusion

Through my study of iOS network tra�c,I have become increasingly convinced thatthe aforementioned privacy concerns are farfrom eradicated, but remain on a downwardtrajectory. That said, much of the tra�cwas encrypted on top of the SSL encoding,so there is a lot going on behind that requiresmore expertise and privilege to fully inspect.Surprising to me, nearly every applicationuses some form of tracking or logging frame-work. It is important that as mobile de-vices become more and more ubiquitous thepublic remains knowledgable about the risksthat go along with them. I hope that thispaper gives a suitable overview of the con-cerns surrounding iOS application data pri-vacy and the procedures in place to mitigatethe harmful consequences of mobile comput-ing.

AN INVESTIGATIVE STUDY INTO THE PRIVACY OF IOS APPLICATIONS 5

References

[1] http://www.wired.com/gadgetlab/2012/02/path-social-media-app-uploads-ios-address-books-to-its-servers/

[2] http://mesl.ucsd.edu/yuvraj/docs/AgarwalMobiSys2013 ProtectMyPrivacy.pdf

[3] http://www.technologyreview.com/news/516416/study-shows-many-iphone-apps-defy-apples-privacy-advice/

[4] http://www.blackhat.com/presentations/bh-dc-10/Seriot Nicolas/BlackHat-DC-2010-Seriot-iPhone-Privacy-slides.pdf

[5] http://seclab.cs.ucsb.edu/media/uploads/papers/egele-ndss11.pdf

[6] http://phd.gccis.rit.edu/weile/docs/le mobs13-2.pdf

[7] http://media.blackhat.com/bh-eu-11/Nitesh Dhanjani/BlackHat EU 2011 Dhanjani Attacks Against Apples iOS-WP.pdf