Over the past week there have been a few big stories on iOS apps transmitting users’ address books as a convenience feature. Apple has even found themselves on the congressional hot seat this week about their device’s address book privacy. AllThingsD reports that Apple, faced with growing criticism that they have given iOS developers far too much access to private data without requiring a user prompt, has pledged that apps dumping address book data will soon require explicit user permission to do so.

Dieter Bohn at The Verge states the problem best: "Any iOS app has complete access to a large amount of data stored on your iPhone, including your address book and calendar. Any iOS app can, without asking for your permission, upload all of the information stored in your address book to its servers. From there, the app developer can either use it to help find your friends, store it in perpetuity, or do any number of other things with it."

Introducing AdiOS

To find out how many of my iPhone apps were dumping the address book, I put together a utility called AdiOS (Addressbook Detector for iOS) that lets Mac users scan the iOS apps in your iTunes directory to see if they have the potential to dump your phone book externally. AdiOS detects apps that access your entire address book, by using a binary grep to look for use of the ABAddressBookCopyArrayOfAllPeople API call. AdiOS quickly and easily finds all the apps that have the potential to violate your privacy. It could also be used to see if your apps are complying with the new policies Apple is rolling out around protection of Address book information.

Using AdiOS to Audit Your Privacy

AdiOS allows Mac users to see what apps have potential privacy problems. Using AdiOS is easy. Just download AdiOS, unzip, double click on AdiOS.app, and let it run. If you have a few hundred apps, it'll take a couple minutes to complete.

Output will look something like this:

What We Discovered

A few of us in Veracode just tested AdiOS on our own machines. Of the roughly 450 iOS apps on my Mac, 50 of them appear to call ABAddressBookCopyArrayOfAllPeople. That by itself doesn't mean the app is transmitting any data, or doing so behind your back, but it does raise questions. Angry Birds does it. Citibank does it. Several Google apps do it. A number of lesser-known games do it, too. Why do all of these apps need to dump my entire address book? The quantity of apps with this ability really caught us off guard.

Most apps that have email functionality (e.g. "send this to a friend") wouldn't ever need to use ABAddressBookCopyArrayOfAllPeople. They could just use the standard view controller for contact info, the ABPeoplePickerNavigationController. If they wanted a custom UI for the picker, then they have no choice but to dump the address book.

In order to check whether the app is actually transmitting the address book information, you'd need to perform a full static analysis, or a manual test using a tool such as mitmproxy.

Don't Panic!

Lots of apps access your whole contact list for legitimate reasons! Social networking apps do it so you can make connections. Maps/directions/GPS apps do it for convenient access to all of your friends' addresses. Many games do it so that you can "share your highscores", etc. But still, it's interesting to see which apps have the potential to do what with your personal address book data.

Should We Really Be Surprised?

Talking to the Veracode Research team about this iOS address book madness, the consensus was that none of this should come to a surprise to anyone who’s been following mobile development or security research for mobile platforms.

At Veracode, we've already detected this issue in some of the mobile applications that we've scanned for our customers. More importantly, we can automatically determine if the app is actually transmitting the address book information once it has been retrieved. Obviously that requires much deeper analysis than this quick binary grep tool can provide! The deep static binary analysis service that we offer our customers uses data flow graphs to connect the output of ABAddressBookCopyArrayOfAllPeople with downstream network APIs in order to confirm a privacy leak.

Along with running AdiOS, consumers of mobile apps should ask their providers to perform binary static analysis on the apps they offer.

About Mark Kriegsman

Mark Kriegsman, Director of Engineering, is responsible for leading the development of Veracode’s flagship static binary analysis system. In addition to providing direct technical leadership, he also works closely with Veracode’s Research and Product Management teams to refine and improve Veracode’s product offerings. Mark is a lifelong innovator and entrepreneur, with over twenty-five years experience in advanced software and systems development.

Comments (15)

fG! | February 16, 2012 12:54 pm

It's very probable that someone already asked for this, but a final summary about the total number of each type would be great!

Nice app :-)

DB | February 16, 2012 1:31 pm

Any explanation for the Indiv/All column entries? If it's an I, does that mean the app is not accessing all your address book entries? Or what?

Stephen Wilson (@Steve_Lockstep) | February 16, 2012 1:34 pm

"Talking to the Veracode Research team about this iOS address book madness, the consensus was that none of this should come to a surprise to anyone who’s been following mobile development or security research for mobile platforms".

This could be an interesting example of the gap between software developers and the public (and policy makers) over privacy. In my view, most of the public -- even the technologically informed public -- would indeed be surprised to know any old app can (and many do) access their contact lists. So for developers to not be surprised may indicate a different way of looking at privacy.

Conversely, what probably _will_ surprise many technologists is that under black letter privacy law in Europe, Australia and other places, it would be an offence to access contact information without a good reason and/or user consent, let alone to do it without any notice at all. As suggested in the article, it's hard to imagine why many of these apps have any cause at call ABAddressBookCopyArrayOfAllPeople.

Developers sometimes seem to think that if information is accessible to them, then it's fair game. The classic example was the collection of wifi transmissions by Google Street View cars. Many at the time said that if data is in the "public domain" then it's free to be collected and used. And they were very surprised indeed to learn that their assumption is simply wrong at law. Many privacy laws are generally blind to where Personally Identifiable Information is collected. If information is identifiable, and if you have no business holding it, then you're not allowed to. It's black and white.

The offence is especially serious when the PII concerned is about thrid parties (i.e. my contacts) who have had no say at all in the way that an app is collecting it from me.

See http://lockstep.com.au/blog/2011/01/26/public-yet-still-private.html

CEng | February 16, 2012 1:46 pm

@DB: The "All" checks for API calls that dump the entire addressbook. That includes ABAddressBookCopyArrayOfAllPeople and all its variants (e.g. ABAddressBookCopyArrayOfAllPeopleInSource). The "Indiv" checks for any addressbook related API calls, that is, anything starting with ABAddressBook.

Also worth noting: a developer could use an iterator around individual addressbook lookups to effectively accomplish the same thing as ABAddressBookCopyArrayOfAllPeople without actually calling that function. Detecting that scenario would require full static analysis; AdiOS will report something like that as "Indiv".

Doug Grinbergs | February 16, 2012 8:42 pm

Somewhat surprised that running grep produces many less files than the AdiOS app shows (43):

$ cd ~/Music/iTunes/Mobile Applications; grep ABAddressBook *.ipa | nl
1Binary file AirPort Utility 1.0.ipa matches
2Binary file Apple Store 110366.ipa matches
3Binary file Classifieds.ipa matches
4Binary file Evernote 4.1.7.ipa matches
5Binary file Google 1.0.1.ipa matches
6Binary file LinkedIn 12.0.ipa matches
7Binary file Obama '08.ipa matches
8Binary file iCabMobile 5.3.ipa matches

(there are 200 apps in the directory)

just me | February 17, 2012 1:23 am

The app does not work if the iTunes library has been relocated. Please fix.

CEng | February 17, 2012 11:36 am

@Doug: Try unzipping the .ipa files before doing the grep.

Si | February 17, 2012 5:14 pm

PC users can use

C:Documents and SettingsuserMy DocumentsMy MusiciTunesiTunes MusicMobile Applications

Use Agent Ransack to search the contents of the files


James Seward | February 19, 2012 7:10 am

I used:

for i in *.ipa; do; if (unzip -p $i | grep ABAddressBookCopyArrayOfAllPeople > /dev/null); then; echo $i; fi; done

in my Mobile Applications directory to work around AdiOS not working with a relocated iTunes folder. (It also didn't work when I symlinked it back into the right place.)

James Seward | February 19, 2012 7:19 am

(That's a zsh script, by the way.)

Bob Webster | February 19, 2012 9:06 am

How do I get AdiOS to work if my iTunes library has been relocated to an external drive? Thanks kindly for the help.

Josh | February 20, 2012 8:03 am

It would be handy if there were a wiki that people could add their results to and say why they trust the app or not. Or maybe a Google Doc, or something.

Royce Eddington | February 20, 2012 11:13 am

I can confirm the app does NOT work if the iTunes directory (itunes / Mobile Applications) is on a external drive. Please fix! Thanks!!

offroadbiker | February 21, 2012 1:32 pm

@Mark Kriegsman
Doesn't work if the directory is on:

How is it possible to change the directory?

Max | May 24, 2012 5:04 am

I don´t see a list of compromised apps.
It doesn´t work unter snow leopard....:-(((

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.