SANS Penetration Testing

Mobile App Permissions and Choice

[Editors note: The inimitable Josh Wright has been working his patooties off on a brand-new SANS course, SANS Security 575, Mobile Device Security and Ethical Hacking. I have to say, this is the most excited I've been about a new SANS course in years. Josh has gone all Willie-Wonka on us for several months as he forges and polishes the course behind the scenes. I've seen some sneak previews, and the stuff rocks. In his work on the course, Josh is looking in-depth at architecture, config, vuln, attack, and defense issues for the iOS, Android, RIM, and Windows Phone platforms. Weekly, Josh and I discuss his findings and insights, all based on what he's putting into the course. It's been fascinating, and an honor for me to view this space through the eyes of Josh. This article is a small snapshot of some of the things that Josh is thinking about and working on in light of the new course. I think you'll find it quite interesting. -Ed.]

Mobile App Permissions and Choice

by Joshua Wright, jwright@willhackforsushi.com

Recently we've seen a flurry of news articles identifying a weakness in the Apple iOS architecture where application developers have unrestricted access to contact book entries on your iPhone, iTouch or iPad. This is unlike Android, Windows Phone and BlackBerry platforms where an application must declare the required application privileges for inspection and approval by the end-user prior to installation.

Any informed Apple iOS developer will tell you that there is a tremendous amount of flexibility for developers to take advantage of explicit app permissions for collecting sensitive data from the platform. Enumerating all the contacts stored in the contact book is a brief Objective-C code block, as shown below.

ABAddressBookRef addressBook = ABAddressBookCreate( );
CFArrayRef allPeople = ABAddressBookCopyArrayOfAllPeople( addressBook );
CFIndex nPeople = ABAddressBookGetPersonCount( addressBook );
for ( int i = 0; i < nPeople; i++ ) {
ABRecordRef ref = CFArrayGetValueAtIndex( allPeople, i );
/* Retrieve, modify or add new records to the iOS Address Book */
}

This is not a new problem for Apple iOS. In early 2008, Apple removed the Aurora Feint app from the App Store after learning that it retrieved contact information from devices as part of a gaming "match-up" function for social networking. Nearly four years later, Path is taking the hit for similar functionality, with their CEO declaring:

"We upload the address book to our servers in order to help the user find and connect to their friends and family on Path quickly and effeciently [sic] as well as to notify them when friends and family join Path. Nothing more."

Apple's vetting process did not catch this violation during their inspection of the Path 2 app prior to publication on the App Store, but they reacted by pulling the app, citing App Store policy violations. Shortly thereafter, Facebook and Twitter apps were also disclosed as having similar functionality. Presently, the Twitter and Facebook apps are still available in the App Store.

Apple has agreed to address this flaw in iOS that permits running apps from obtaining contact information. Reportedly, Apple will declare to the end-user anytime an app tries to enumerate contact information similar to what is done for location services today.

I believe this is a limited approach, addressing each sensitive information disclosure flaw with another popup. The contact list access issue is only one of many sensitive information access opportunities available to mobile apps including:

  • Access to your phone number
  • Access to your unique device ID
  • Access to photo gallery entries
  • Access to email account configuration information
  • Access to WiFi connection information
  • Access to the last called phone number
  • Access to your YouTube history
  • Access to Safari settings and history
  • Access to keyboard cache content (autocorrect words)
  • Access to arbitrary network access using HTTP or other network sockets (used by Path, Twitter, Facebook and other apps to obtain and then send data off-site)

Will we end up with an Apple iOS popup for each?

Reflections on Mobile Platform Permission Control

Apple iOS is commonly perceived as the more secure platform, but lately I've been thinking about the implications of their "simple is better" model. Apple does not prompt users about the privileges required for an application, I believe not from a fundamental security choice, but from an end-user simplicity and ease of use perspective. Android, for example, requires that an end-user permit declared permissions in applications when installed.

The Android model presents choices to the end-users, while Apple takes away informed choice from their users. As an informed information security professional, I prefer the Android approach, but this isn't a panacea, since only a small number of Android users will recognize and understand the implications of the combination of declared application requirements on the platform.

The bottom line is that none of the mobile phone and tablet security approaches are flawless. Before we really start to embrace mobile devices in enterprise and government networks, we need to have informed specialists in the area of mobile device security that can recognize and articulate the flaws and benefits of mobile device security. Only through this understanding can we deploy and manage mobile devices that adequately suit the needs of the business, and the end-user community.

On May 10th I will debut my new course Mobile Device Security and Ethical Hacking in beautiful downtown San Diego, CA. This six-day course is designed to help organizations struggling with the security challenges of mobile devices, looking at building effective policies and device management platforms while building skills needed for application analysis and mobile device penetration testing. Today I'm putting the finishing touches on a section contrasting the platform security models of Android, iOS, BlackBerry and Windows Phone devices, which seems fitting with recent press revelations regarding the insecurity of these platforms.

Josh Wright

Post a Comment






Captcha


* Indicates a required field.