A thesis submitted to the Graduate Faculty of the University of Colorado at Colorado Springs in partial fulfillment of the requirements for the degree of Master of Science
Department of Computer Science

Mobile devices, such as smartphones or PDAs, have become increasingly popular with consumers and often provide essential functionality in their everyday life. Usually these mobile devices contain a great deal of sensitive information such as addresses, contacts, ingoing/outgoing call logs, SMS messages and, on the latest models, a calendar, emails and potentially the user’s current location. A smartphone or mobile device today can be as powerful as a desktop or laptop in some respects and, while the latest models feature a complete OS, for many users these devices are “just phones” so there is an underestimation of the risk connected to mobile device privacy. There is a currently existing privacy problem associated with user and hardware tracking in mobile devices. Users can be tracked without their knowledge and consent and have rich profiles built about them using their hardware interface address regarding their location and preferences. This information can be potentially cross correlated to other existing datasets to build advertising profiles for these users. The mitigation to this problem using a framework to support randomly generated, disposable hardware addresses.

To perform this audit, the author launched one application at a time and used WireShark to capture and analyze packets. The experiment was performed on an open network that the author created. The access point was a Cisco Small Business router (WAP4410N) and was configured using a hidden SSID and MAC address authentication to prevent outside users from associating with the access point and introducing outside, extra packets. While the author realizes that hidden SSIDs and MAC address authentication are easily defeated mechanisms, it was used to prevent casual users from using the access point. The mobile devices used were an Apple iPod Touch 4G, an Apple iPad 1G and an iPhone 4, configured with iOS 5.0.1.

For reasons of classification, the authors created several different levels of potential security breaches. The levels are defined as:

None: This level is defined as having no potential security breaches and no exposure of confidential information.

Low: This level is defined as having a few potential security breaches or exposure of confidential information that could not directly affect the user, such as device IDs that could be used in tracking users (in iOS, these are called UUIDs).

Medium: This level is defined as having several potential security breaches or exposure of confidential information that is potentially serious or if information is exposed such that an attacker would be able to identify the user on an individual basis, such as addresses, latitudes or longitudes, etc.

High: This level is defined as having multiple potential security breaches or exposure of extremely confidential information, such as account numbers, PINs, and username/password combinations.

For more information on the specific application, including the version number of the application with the vulnerability, see Appendix A for a full listing.

Application

Level

Risks Found

GrubHub

Low

UUID

The Weather Channel

Low

Geocoded location

Path

Low

UUID

Handmade

Low

UUID

iHeartRadio

Low

Reverse Geocoded location

TabbedOut

Low

UUID, Platform

Priceline

Low

UUID, Geocoded location, “Search” API is unencrypted

Free WiFi

Low

Geocoded location

Coupious

Medium

Geocoded location, UUID, coupon redemption codes

Delivery Status

Medium

UPS transmits reverse geocoded locations and tracking numbers.

Color

Medium

Reverse geocoded location and photos taken and shared by users

Cloudette

Medium

Username in plaintext and password, hashed with MD5

Gas Buddy

Medium

Username and password, hashed with MD5

Ness

Medium

Reverse geocoded location

Southwest Airlines

High

Username and password in plaintext

Minus

High

Username and password in plaintext

WordPress

High

Username and password in plaintext

Foodspotting

High

Username and password, Geocoded location

ustream

High

Username and password, UUID, geocoded location

Labelbox

High

Username and password, geocoded location

The majority of the applications that were surveyed encrypted the exchanges of confidential or sensitive information, such as usernames, passwords and account numbers via SSL/TLS.

However, many applications performed some sort of tracking or storing of analytic information, such as passing the UUID in a call to a web service. In some of the instances, this identifying information was not encrypted. While not potentially dangerous in the sense that an attacker could use this information to “identify” a particular person, none of the applications let users know that their information such as UUID, phone OS and model, was being used or recorded, nor did they let the user “opt-out.”

The largest single potential security breach was with the Southwest Airlines application. Due to the fact that the username and password were submitted to a web server via a POST operation in plaintext, an attacker could simply sniff for this data. If an example was captured, one could use those credentials to log into a particular account and book travel, use award miles and possibly change information in the victims profile. This not only obviously worrisome from the standpoint of a potential attacker fraudulently using a victims account and credit card information, but also due to the possibility of a terrorists threats in air travel.

For example, consider the possibility of a person who is currently (and rightfully) on the Department of Homeland Security’s “No-Fly” list. If this person were able to capture a victim’s credentials and create a fake ID, he could pass through TSA security without being stopped.

Of the 253 applications surveyed, 91.7% had no risk found, 3.1% had a low risk, 2.3% had a medium risk and 2.3% had a high risk. While it would be desirable to have no applications in the “Medium” or “High” category, the number of applications the authors found presented a security risk was both surprising and far too numerous. There are over 500,000 applications on the iOS App Store, so extrapolating the results, there could be at least 15,500 applications in the “Low” risk category and 11,500 applications in the “Medium” and “High” risk category.

Overall, the number of applications with some sort of security risk is low. This is not very surprising to the authors as many of these applications are in the “Top” applications list and any potential security flaws would have already been found.

Due to the fact that iOS does not have a robust privilege system, there is no way that a user could know their information was being used in a dangerous or insecure way. While there is support for showing users there is network traffic by using a spinning “network activity indicator”, it is certainly not mandatory for them to do so. In fact, a legitimate or malware application could access the network interfaces, sending and receiving information and never alert the user on iOS.

Developers typically do not follow the principle of least privilege. If an application needs a set of privileges for functionality, they will request them up front, not just when they are needed. This is particularly dangerous because this could be an entry point for an attacker to compromise the application.

[19] performed research where they surveyed 940 Android applications and found that more than 50% required 1 extra unnecessary permission and 6% required more than 4 unnecessary permissions. The reasons that developers may request more permissions than are necessary could be because 1) they don’t understand the importance of security and least privilege, 2) they are planning on future releases that will require these privileges and 3) they don’t fully understand how to work with the platform and make the code function correctly.

Since mobile devices and smartphones are unique in that they have a built-in billing system, there must be ongoing education of developers with emphasis on security and privacy or additional built-in measures in the OS to enforce security over code the developers write or the permissions for which they ask.

By David Stites and Anitha Tadimalla {dstites, atadimalla}@uccs.edu
University of Colorado at Colorado Springs

Abstract— Mobile devices, such as smartphones and PDAs have become increasingly popular with consumers and often provide essential functionality in our everyday life. Usually these mobile devices contain lots of sensitive information, such as addresses, contacts, ingoing/outgoing call logs, SMS messages, and on latest models, a calendar, emails and potentially our current position. A smartphone or mobile device today is as powerful as a desktop or laptop and while the latest models feature a complete OS, for many users these devices are “just phones”, so there is a underestimation of the risk connected to mobile device security. This makes mobile devices an interesting target for malicious users. Damages that a user can sustain are financial loss, privacy and confidentiality, slowdown of processing speed, battery life.

Index Terms—mobile, security, malware, defense

INTRODUCTION

Mobile devices, especially cellphones, have changed a great deal from their counterparts from the 1990s. Gone are the days of brick-sized phones, with a 1-line displays, 9 analog buttons and several KB of memory. In recent years there has been an explosion [2] of powerful mobile computing devices. These new smartphones and tablets, small enough to fit in your pocket or backpack, hold an immense amount of computing power. Information is available at a simple touch or finger flick and many users use these devices to access all sorts of data or services such as email, personal contacts, websites and even performing tasks normally reserved for a desktop system, such as video conferencing, watching movies or listening to music.

These devices are able to access the internet, download additional software from the internet, send and receive email, browse websites and send and receive SMS messages from other users. In addition to these capabilities, many subscribers use their cell phone as a primary method of communication, storing their personal contacts information (which include address, email addresses, phone numbers, etc.) as well as photographs they have taken. Additionally, many of these devices have a built-in GPS that allows the user to “geo-tag” photographs and use Location Based Services, such as FourSquare, Twitter and Facebook in addition to the basic mapping and GPS functionality.

Devices that run iOS (iPhone, iPad and iPod Touch), Android and Windows Mobile (which represent the majority of the market share) present a brand new computing paradigm in terms of availability, user interface and security. These devices are being targeted as never before by attackers [1]. Today more than 300 kinds of malware – among them worms, Trojan horses and other viruses and spyware have been unleashed against the devices [1]. Although desktop systems remain the most widely targeted platform, as mobile computing become more ubiquitous and powerful, the lines between a traditional desktop system and a mobile system will become blurred and these devices will gradually enter the virtual battlefield.

Clearly, these new capabilities mixed with the fact that users store personal information on the devices make it a prime target for attackers. There are three different basic categories of attacks that can be carried out against mobile devices and they include:

These three categories represent a wide spectrum of security issues and there are many different attacks that an attacker could carry out. Any of the aforementioned attacks could range in severity from “low” to “high”, which makes this particular research area a wide open problem.

2. Survey Organization

This research paper is organized in the following manner: section III discusses some notable previous work that has been in this particular field, section IV discusses threats, vulnerabilities and defenses of mobile device security and sections V and VI presents some original work of the authors that show current and potential security threats to security from mobile device applications.

3. Previous Work

There has been a significant amount of previous work done in the area of mobile security. In [2], the authors show that since many of the mobile devices are based on similar codebases as their desktop counterparts (as in the case of Windows Mobile and iOS), rootkits, or stealthy malware that affects system programs and files, can equally affect the mobile version of these systems. In addition to showing that the systems can be exploited, they also show the implications of being able to compromise these devices.

In [4], the authors demonstrated the ability to deploy “a Trojan with few and innocuous permissions, that can extract a small amount of targeted private information from the audio sensor of the phone. Using targeted profiles for context-aware analysis, Soundcomber intelligently pulls out sensitive data such as credit card and PIN numbers from both tone- and speech-based inter- action with phone menu systems.”

In [5], the authors show that even though Android has an advanced permissions system with a sandboxed execution environment, a “genuine application [can be] exploited at runtime or a malicious application can escalate granted permissions and imply that Android’s security model cannot deal with a transitive permission usage attack and Android’s sandbox model fails as a last resort against malware and sophisticated runtime attacks.”

In [3], the author shows many of the attacks that occur on iOS have to do with theft or procurement of personal or private information. For example, iOS applications would have access to a user’s address book that includes phone numbers, addresses and email addresses. Additionally, an application can also access other data such as call history, carrier information and photographs.

4. Threats, Vulnerabilities and Defenses to Mobile Device Security

A) Attacks and Vulnerabilities

Since there has been explosive growth in the mobile device market and the demand for smartphones, tablets and other integrated devices have increased dramatically. According to Nielsen [5], “in the third quarter of 2009, smartphones accounted for 40% of new phones sold in the period, up from 25% in the prior quarter. And in the third quarter, for the first time, more people accessed the Internet from smartphones than regular phones. Assuming that 150 million people will be using smartphones by mid-2011, that means 120 million will be on the mobile Internet and 90 million, or 60%, will be watching video” according to Nielsen projections based on current data trends.

In addition to a enormous user base, people are spending more time on their mobile devices than ever before. “As of the second quarter, Nielsen has previously reported that some 15 million U.S. mobile subscribers watch video on their phones for an average of three hours, 15 minutes each month” [5].

Previously attacks such as the ones detailed later in this section haven’t been seen until now. Securing mobile devices present unique challenges to researchers, attackers, defenders and users. This “uniqueness” is due to the fact that computers don’t typically have some the interfaces that mobile devices do, such as GPS hardware, or similar data storage paradigms, such as storage in the cloud. Several potential reasons mobile malware and attacks are becoming more popular is because people are using their mobile devices for more day-to-day tasks such as banking, email and web surfing. This might cause users to store more “valuable” information on these devices and this represents a prime target for attackers due to the wealth of information they could obtain. In addition, while users may have good security habits when it comes to more traditional systems, they may not realize that their mobile device could be just as vulnerable as their servers, desktops and laptops.

I) History and Current Day Data

The first known cell phone virus, Cabir (EPOC.cabir and Symbian/Cabir), occurred in 2004, written by the group 29A [1, 8]. It affected devices that had Bluetooth modules and spread using Bluetooth via OBEX (object exchange). While it was originally designed as a proof-of-concept that would affect Symbian OS devices, it could spread to any Bluetooth enabled device such as desktop computers and printers.

The virus would activate each time the phone was turned on and immediately start looking for other hosts to infect. However, Cabir required the victim user to accept the transfer before any transfer could start. If an attacker were able to masquerade as someone the victim trusted, then they could easily socially engineer their way into infecting the victim’s phone.

Since the virus was released as a proof-of-concept to shock the security community into focusing on the importance of mobile malware, it did nothing other than drain the battery of the infected device while it constantly scanned for new targets to which to send the virus. A variant of Cabir, Mabir, was released that infected phones not only via Bluetooth but also by SMS, so it could use the carrier as an attack vector. This increased the infection potential of this virus exponentially since you didn’t have to be within the 10 meter range of Bluetooth to be infected.

Other historic, notable mobile malware include Duts (a virus for the PocketPC platform), Skulls (a trojan horse that infects all applications, including SMS/MMSes) and Commwarrior (a worm that used MMS messages and Bluetooth to spread to other devices). A more complete list of mobile viruses, trojan horses, worms and malware exist at [1, 7, 8].

Clearly, since mobile devices represent the future of computing, the fact that mobile malware is becoming more prolific shouldn’t be a surprise. In fact, F-Secure reported an almost 400% increase in mobile malware within a two year period from 2005-2007 [2].

Additionally, [9] reports that the amount of Android malware jumped 37% in the third quarter of 2011 and that Android is now the “exclusive platform for all new mobile malware. While the Symbian OS remains the platform with the all-time greatest number of malware, Android is clearly today’s target.” Today, there are currently over 1,200 known malware samples [9].

In [10], the authors performed a survey of mobile malware in the wild. They determined, that between 2009 and 2011, there were 46 pieces of malware released, including 4 for iOS, 24 for Symbian and 18 for Android. They also determined that the most common malicious activities were confidentiality attacks (collecting user information, 61%) and integrity attacks (sending premium-rate SMS messages, 52%).

I) Reasons for an increase in attacks

There are a number of reasons that the community is now experiencing an increase in malware including:

Increased computing power and storage capabilities: While many consumers may not recognize mobile devices as being equivalent in power to their larger counterparts (laptops and desktop PCs) due to their size, many smartphones, tablet devices and other PDA type devices have a rich set of hardware interfaces. Many smart phones, such as iPhones, Android-based phones, have powerful dual-core processors and a large amount of storage space to accommodate music, movies, documents and other types of media that can be consumed on the go.

In addition, the available software applications that come pre-installed on the device by the device manufacturer, such as web browsers, email clients, messaging applications allow the user to interact much more with the physical and virtual world than previous mobile devices. Furthermore, additional software applications can be downloaded, installed from the Internet and run by the user. These third-party applications are able to access this advanced hardware as well as GPS and network interfaces (3G, WiFi and Bluetooth).

This provides mobile malware and crimeware authors a much larger array of possibilities to carry out their attacks. In addition, more sophisticated hardware and software could make it easier for these attackers to “hide” their attack by ensuring that it only consumes a small portion of the resources, thereby modeling a legitimate application.

Increased network connectivity: There is a widespread availability of 802.11 WLANs and high-speed broadband data access (3G, WiMAX). These services allow users to stay constantly connected to services such as email and messaging at home, at work and in foreign places, such as coffee shops. In addition, many applications utilize network connections to either request or send data. For example, a game application might transmit a user’s high score to a web server for storage.

Additionally, some applications rely on the fact that the phone will have a network connection to receive and send data, such as the Amazon.com shopping application. Lastly, many recent applications utilize location-based services, such as Facebook, Twitter, and FourSquare. These applications provide additional functionality if they are able to access the network and a user’s current location.

Lastly, many applications can make use of social data, such as the friends one might have on Facebook. This Facebook data could be stored within the application. While Facebook might maintain rigorous security standards on who and what can access the user’s data, other third party applications might not be so careful with the user’s data.

Standardization of OS and interfaces: The OS is consistent on all the same family of devices, so malware applications would have more effect, being able to exploit the same security vulnerability across many devices. In addition, many manufacturers give third party developers access to the system to write applications for the platform. For example, one can freely download the Android and iOS SDK. Using this provided SDK, one could craft a virus or some other piece of malware and then submit it for inclusion in the respective application storefronts.

Enterprise integration: Many mobile devices, such as Android, iOS and Blackberry, support standards to be integrated into an enterprise environment. For example, many of the same devices have support for Virtual Private Networks (VPNs) as well as Exchange server integration. Thieves and malware authors recognize that this will greatly enhance the infection potential if a mobile virus, trojan horse or worm is able to spread from a mobile device to a corporate environment.

Consider the case of an employee with a mobile device becoming infected while at a coffee shop and taking that device back to the corporate environment where it could spread throughout the organization. Where previously an attack might have only stolen information pertaining to the particular victim, now the attacker could have potentially obtained information on many different people as well as corporate information.

Other reasons, social engineering and hacktivism: The number of socially-engineered attacks are becoming more prevalent and more sophisticated. [9] reports “that targeting content works based on cultural and sociological differences between geographic regions. Hacktivism have become part of the mainstream in 2011 due to groups such as Anonymous and LulzSec.”

I) Attack Vectors, Motivations and Types of Attacks

There are a number of attack vectors that exist for compromising confidentiality, integrity or availability. In fact, many of the attack vectors are the same ones that are available to desktop applications. Mobile attack vectors often spread via interfaces and services as well as interfaces unique to smart phones, including SMS and MMS.

While the motivation behind such attacks can be varied and numerous, as well as being outside the scope of this paper, [10] identifies some current and future incentives including:

Novelty and amusement

Financial Gain

Political Gain

Damage resources

In addition to numerous attack vectors and motivations, there are many different types of attacks that a malicious individual could attempt to carry out. [10] defined three main categories of attacks including 1) malware attacks 2) grayware attacks and 3) spyware attacks.

Malware attacks: “Malware attacks are attacks that gain access to a device for the purpose of stealing data, damaging the device, annoying the user, etc. The attacker defrauds the user into installing the malicious application or gains unauthorized remote access by taking advantage of device vulnerabilities. These particular types of threats provide no notice to the user and typically includes worms, Trojan horses and viruses [10].”

RF attacks: In this particular type of attack, an attacker could compromise confidentiality, integrity and availability. For example, if an attacker were to have the correct equipment, the attacker could sniff the air (WLAN and RF) for user data that the attacker could steal if it were unencrypted, such as usernames, passwords and account numbers. This particular type of attack is made easy if: 1) the network the user is on doesn’t utilize encryption and, 2) the application transmits confidential information in plaintext.

As we’ll see later on in section V, there are a number of iOS applications today that transmit private information without encryption. Additionally, if an attacker were able to successfully carry out a “mis-association” attack where the mobile device joins the wrong access point, the attacker could attack the integrity of communications by performing a “man-in-the-middle” attack, if the data were not validated or signed. Consider an example where a victim user sent a SMS message that said “Transfer $1000 to account X.” The attacker could alter the SMS to say “Transfer $10,000 to account Y”, where Y was his account.

Lastly, an attacker could also compromise the availability of RF services. Consider an example where an aircraft was WiFi enabled (passengers could access the WiFi during flight). An attacker could carry out a “disassociation” attack, where he transmits 802.11 management frames that cause the wireless clients to disassociate from the access point. The denial-of-service would continue until the attacker stopped transmitting the packets.

Bluetooth attacks: This particular class of attack has many different possible different attacks, similar to RF attacks, that can compromise confidentiality and integrity of data. In “blue-jacking”, an attacker’s malware application could insert contacts or SMS messages into a victim user’s mobile device. Additionally, in “blue-snarfing”, a user’s data is again under attack by allowing the attacker to steal or transfer the victim’s data. Yet another type of bluetooth attack is “blue-tracking” where an attacker could follow the victim’s movements. Lastly in “blue-bugging”, an attacker could listen in on conversations by activating the attack software and having the phone call them back. When the attacker answers the call back, the attacker would then be able to listen in to a conversation.

SMS attacks: “SMS spam is used for commercial advertising and spreading phishing links. Commercial spammers are incentivized to use malware to send SMS spam because sending SMS spam is illegal in most countries” [10]. In addition to sending and receiving regular-rate SMS messages, SMS can also be used as an attack vector by exploiting vulnerabilities in the software stack, such as performing SMS fuzzing.

GPS/Location attacks: In this type of attack, the attacker can access the GPS hardware to monitor the user’s movement and current location. This data can be used to create a profile of a particular user. In addition, this information could be sold to to other companies for purposes of marketing and sending advertisements to the user. A more insidious use of a GPS/location attack would allow a criminal to track when a victim leaves their residence and then the attacker could rob the person while they are gone.

Application masquerading and personal data attacks: This particular type of attack is as simple as accessing a user’s private data and saving, sending or using it in an unauthorized manner. For example, in [3], the author shows multiple examples of information that an application could access that could potentially be sensitive or confidential, such as a user’s phonebook, keyboard and location cache and photo albums.

In addition, [3] also showed that it would be relatively trivial for an application to traverse the file system of a mobile device, recording information that it could find valuable. This can all occur in the background and the user would never know that it is happening. This data could be sent off to a server and stored for later misuse.

Phone “Jailbreaking” and 3rd party application stores: While not encouraged by the manufacturer, (and in some cases against the carrier terms and agreements), many users prefer to “jailbreak” their mobile devices. Jailbreaking is the process of removing the security limitations that are imposed by the operating system, such as the ability to only run signed applications and install additional extensions and themes. This also allows the user to bypass application sandboxing mechanism and install applications from unofficial application stores. Users find this desirable because they can add functionality that didn’t previously exist or could get from any existing application on the application stores. However, users may not realize that this could potentially be a problem if they were to install a malicious application that would normally be killed by the OS on an un-jailbroken device. For example, one of the available exploits for iOS is when a user jailbreaks their iDevice, installs the OpenSSH package and doesn’t change the root password for the device, which is “alpine”. This would allow a hacker to login to their device as the root user and exploit the system because they would have full access to read, write and execute any command.

Premium-rate attacks: Premium rate services can deliver valuable content to a user’s mobile device. When used in a legitimate manner, a user could receive financial information, technical support or even adult services. These services can cost as much as several dollars per message or minute. In [10], they identified 24 of the 46 pieces of malware surveyed as sending premium-rate SMS messages. In one piece of malware, [10] found that applications purporting to be a Russian adult video player sent premium-rate SMS to an adult service.

Another piece of malware, Geinimi, sent premium SMS messages to numbers specified by the remote command servers. This is potentially a very large security concern, because these premium SMS messages don’t require a user’s permission to send, so they potentially could go unnoticed until an attacker has racked up hundreds or even thousands of dollars on a victim user’s phone bill. In addition to premium-rate SMS message attacks, [10] also found that 2 of the 46 malicious applications contained premium-rate phone call attacks.

Power management attacks: [11] describes three different classes of power management attacks. A power management attack is a form of a denial-of-service attack that affects the availability of the mobile device by draining the battery more quickly than it would under normal operation. The attacker’s goal is to maximize the difference in power consumption between active and sleep states and keep the device from sleeping.

The three classes of attacks include 1) service request attacks 2) benign power attacks 3) malignant power attacks. In service request attacks, repeated requests are made to the victim for services, typically over a network. Even if the request is ultimately not granted, the power must be expended by the device to determine whether or not to grant the service request. In benign power attacks, the mobile system executes valid, but power hungry tasks (such as displaying a hidden animated gif or executing a JavaScript). In malignant power attacks, attackers create or modify binary executables that force the mobile system to consume more power than it normally would. For example, consider an application that plays a silent audio track in the background while the application is running. This type of attack might be difficult for the user to detect because they may think that their battery can no longer hold a charge.

Time-activated and location-activated attacks: An attacker may choose to activate attacks at certainly locations or at a pre-determined or random time in the future. When the victim arrives at the location and uses the software, it could activate whatever is the intended malignant function. This would be fairly easy to do as many applications have access to the GPS. This type of attack may also sneak by any analysis of the application as it wouldn’t run every time the application was launched, but rather only under certain conditions.

In addition to malware attacks, [10] also defines several other types of “attacks” including:

Grayware attacks: In [10], the authors classified grayware attacks as “some legitimate applications collect user data for the purpose of marketing or user profiling. Grayware spies on users, but the companies that distribute grayware do not aim to harm users. Pieces of grayware provide real functionality and value to the users. The companies that distribute grayware may disclose their collection habits in their privacy policies, with varying degrees of clarity. Grayware sits at the edge of legality; its behavior may be legal or illegal depending on the jurisdiction of the complaint and the wording of its privacy policy. Unlike malware or personal spyware, illegal grayware is punished with corporate fines rather than personal sentences. Even when the activity of grayware is legal, users may object to the data collection if they discover it. Application markets may choose to remove or allow grayware when detected on a case-by-case basis.”

For example, in 2009, bloggers raised concern over the PinchMedia LLC analytics framework. This framework provided third party application developers usage information about their users. The users were not informed and they were not given an option to opt-out [3]. In addition, Storm8 and MogoRoad also faced legal issues when it was discovered that they were collecting users’ contact information without informing them and then transmitting the collected information in plaintext [3].

Spyware attacks: The last category that [10] detailed was “Spyware attacks.” “Spyware collects personal information such as location or text message history over a period of time. With personal spyware, the attacker has physical access to the device and installs the software without the user’s knowledge. Personal spyware sends the victim’s information to the person who installed the application onto the victim’s device, rather than to the author of the application. For example, a person might install personal spyware onto a spouse’s phone. It is legal to sell personal spyware in the U.S. because it does not defraud the purchaser (i.e., the attacker). Personal spyware is honest about its purpose to the person who purchases and installs the application. However, it may be illegal to install personal spyware on another person’s smartphone without his or her authorization [10].”

When defending against mobile phone security threats and mobile malware, there are two main categories: prevention and detection and recovery. The majority of the work that has been already implemented falls into the class of prevention. However, detection and recovery is becoming a more popular research topic. We discuss some of the major defenses below:

Code analysis (static and dynamic): There are two main techniques of determining an application’s characteristics: statically and dynamically. Both have certain advantages and disadvantages.

In static analysis, many techniques may be used to determine how the program works, such as decompilation, decryption, pattern matching and static system call analysis. The central idea behind static analysis is finding signatures of malicious code in a fast and easy manner. In [3], the author describes part of the App Store review process for applications and detail that using static analysis, one can dump the strings in a binary file and check them against a black list of forbidden classes, method names and file paths. However, static analysis can be circumvented with obfuscation techniques. Additionally, some languages, such as Objective-C allow developers to lookup classes and methods by name at runtime. This feature of the language adds additional opportunity to “hide” malware functionality.

The primary disadvantage of static code analysis is that malicious code patterns have to be known in advance, making it impossible to automatically detect new malware or malicious polymorphic code without an intervention of a human expert [23].

Dynamic analysis is a set of techniques which involve running an application in a controlled environment and monitoring its behavior. Various heuristics can be used to capture behavior of the application such as monitoring file changes, network activity, processes, threads and system call tracing [23].

One large difference between the iOS App Store and the Android Marketplace is that applications that are released to the iOS App Store are reviewed by a human. This accomplishes an important goal in that it rejects applications that are in a “legal gray zone such as casino gambling or collecting personal data.” The Android Marketplace allows an author to post apps without needing any a priori review but rather it relies on “crowd-sourcing” to review the applications and post comments, either positive or negative.

ASLR and DEP: ASLR (address space layout randomization) is a computer security method that involves re-arranging the positions of key data areas, including the position of libraries, the heap and the stack in the process’ address space. This technique makes it more difficult for an attacker to predict target addresses [21]. For example, an attacker who is attempting to overflow the stack, would first have to locate the address of the stack before they could overflow it. If an attacker were to guess incorrectly and the program terminated, the next time the program were launched, the stack address will have moved again and the attacker would have to start all over again in their attempt to find it. While the full description of how ASLR is implemented and its effectiveness is outside the scope of this paper, the reader may learn more at [21].

In addition to ASLR, DEP (data execution prevention) is another security feature that prevents an application or service from executing code from a non-executable memory-region. This protection can be enforced in hardware and/or software. Again, while the full description of how DEP is implemented and its effectiveness is outside the scope of this paper, the reader may learn more at [22].

The platforms that support ALSR and DEP include iOS and Windows Mobile. Android has plans to support ASLR but the Blackberry platform has neither.

Application sandboxing: “Sandboxing consists of running mobile code in a restricted environment called a sandbox [17].” A sandbox can be characterized by two different mechanisms: 1) confining code, either through type checking, language properties or the use of protection domains to prevent the subversion of trusted code and 2) enforcing a fixed policy for the execution of code [17].

When applied to the real world, each application will have its own environment. Other applications should not be able to interfere with another applications environment nor should that particular application be able to interfere with other applications’ environments. Both iOS and Android implement application sandboxes. In the iOS model, each application only has read-write access to a few directories (the application’s own directory and a temporary directory) and applications cannot read or write to any other directories (including other applications and system directories) than for which it is authorized.

In the iOS sandbox, all applications share the same sandbox rules and they’re allowed any action any application could ever need [18]. Compared to the Android sandbox, “applications must explicitly share resources and data and do this by declaring permissions they need for additional capabilities not provided by the basic sandbox. These additional permissions are granted or denied by the user at install time only. [13]”

Permission systems: In Android, there is the additional protection of a permission system. This permission system “treats all applications as potentially buggy or malicious so they are assigned a low-privilege ID that can only access their own files [19].” Depending on what the application wants to do, it can request an elevation of permissions from the user, at install-time, which the user will ultimately grant or deny.

For example, there are several different levels of permissions including Normal (permissions that protect access that could annoy but not harm the user, such as setting the wallpaper), Dangerous (permissions that protect access that potentially harm the user such as gathering private information), and System (permissions that need access to the most dangerous privileges, such as deleting applications).

In addition to the permissions system, Android also has the Intents system. Intents are typed interprocess messages that are directed to particular applications or systems services, or broadcast to applications subscribing to a particular intent type [20]. Access to the Intents system is funneled through ActivityManagerService which restricts intents only being sent by applications with the appropriate permissions and processes with a UID that match the systems [19].

iOS does have a rudimentary concept of a permissions system but not one that is as in depth as the Android model. For example, when an application attempts to access the user’s location via the GPS hardware, the application will confirm with the user that this is an acceptable action, which the user can confirm or deny. However, for the most part, Apple relies on a number of other techniques to handle security issues, such as Sandboxing, ASLR/DEP and code analysis.

ACLs and capability lists: Both iOS and Android implement standard UNIX type permissions with users and groups. This allows the systems to implement the concept of “least privilege” where accounts and users are only able access data to which they are properly privileged to access. In iOS, files have permissions and third party applications runs as the user “mobile”, instead of root. In addition, certain operations on Android require the proper permissions, such as accessing as network interfaces. Typically, when a user “roots” or “jailbreaks” their device, they are elevating the permissions of the application to that of a more privileged account to bypass certain security features such as sandboxing.

Code signing: Code signing is a process where executable binaries are signed digitally by software authors to guarantee that the code that has not been altered or corrupted [15]. This is an important part of the defense systems in both the Android, Blackberry, Windows Mobile and iOS security model and it is used extensively in both models for validating third party applications. An important distinction between the two is that with iOS code signing, the code must be signed with a certificate validated by a certificate authority or CA (in this case, Apple), whereas with Android, self-signed certificates are acceptable [13, 14]

In addition to validating applications, iOS also uses code signing when booting up. When a device running iOS boots up, the first significant piece of code that runs on a device running iOS is the BootROM or the “SecureROM”, which is read-only [16]. Within this BootROM, an Apple root certificate is embedded such that the firmware can be validated as being official and secure. Once the RSA signature has been checked, control is passed to the low level bootloader or the “LLB.” This module runs several setup routines and checks the signature of iBoot, which is a stage 2 bootloader for all devices running iOS. Once iBoot starts, it allows the device to go into a “recovery” or “DFU” mode that allows devices to be restored from any state. Firmware images from Apple are signed and checked when the upgrade or downgrade occurs. If the device boots normally instead of going into DFU mode, control is passed to Launchd, CommCenter, and Springboard [11].

In addition to validating system software, iOS also signs the code directory structure with SHA-1 hashes of memory pages, and a PKCS#7 signature is embedded in all binaries that are downloaded from the App Store [11]. For binaries that do not validate at run time, they are killed by the OS to prevent any binary that has been altered from running. Lastly, to provide a defense against rootkits, for system binaries, code directories hashes are cached in the kernel [11].

While regular users may not know or care whether a binary is signed properly, this particular process creates accountability and increased trust on the platform if an application can be traced back to a known source.

The astute reader will recognize that a signed binary may not necessarily contain safe or bug-free code – just code verified as coming from a particular known source and has not been subject to tampering. Also, if the system does not strictly enforce running only validated binaries, users could be tricked (through social engineering perhaps) into running code that refuses to validate. Lastly, one potential flaw with Google’s scheme is that Google does not require that a CA sign the application signing certificate – they only record the signatures for book keeping purposes. This additional level that Apple introduces could potentially reduce the amount of malware and spyware on Android.

Data encryption: Data encryption and decryption is a very CPU and power intensive activity. Battery life on a mobile device is a very precious commodity because the usage model for a mobile device is such that the devices are meant to be used out in the field where a constant power source isn’t always available. As such, there hasn’t been any commercial implementations of automatic whole disk encryption. However, certain OSes, such as iOS, encrypts particular items such as the Keychain (a password manager and storage framework) and provides the ability to encrypt individual files. Another option for third party applications is to provide their own encryption services framework, using known models, such as PKI, and known programs, such as OpenSSL.

One interesting study of mobile device encryption was done by the authors of [28]. In their research, they explored the use of Field Programmable Gate Arrays or FPGAs, processors and ASIC hardware in the context of finding a framework for encryption on hand-held communication units. They used the IDEA encryption algorithm to show the tradeoffs in the suggested technologies. They measured their results using three different metrics: 1) performance, 2) programmability and, 3) power consumption. They determined that since power consumption is directly related to frequency, FPGAs provided the highest performance (MOPS/watt).

Detection and recovery defenses: There has been a lot of notable work done in this category of mobile malware defense. For example, [24] presented various approaches for mitigating malware on mobile devices. The authors implemented and evaluated the suggested approaches on Google Android. The work is divided into the following three segments: a host-based intrusion detection framework; an implementation of SELinux in Android; and static analysis of Android application files.

[24] determined that to provide well-rounded protection, a security suite for mobile devices or smart phones (especially open-source ones such as Android) should include a collection of tools blending various capabilities that operate in synergistic fashion.

In [24], the author’s first approach was an innovative host-based intrusion detection system (IDS) for detecting malware on mobile devices. This framework relies on a lightweight agent (in terms of CPU, memory and battery consumption) that continuously samples various features on a device, analyzes collected data using machine learning and temporal reasoning methods and infers the state of the device. Features belonging to groups such as Messaging, Phone Calls and Applications belong to the Application Framework category and were extracted through APIs provided by the framework; features belonging to groups such as Keyboard, Touch Screen, Scheduling and Memory belong to the Linux Kernel category.

This study on anomaly detection was based on various detection algorithms. The purpose of this study is to understand how a detection algorithm, a particular feature selection method and number of top features can be combined to differentiate between benign and malicious applications which are not included in the training set, when training and testing are performed on different devices and to find specific features that yield maximum detection accuracy. Empirical results suggest that the proposed framework is effective in detecting malware on mobile devices in general and on Android in particular (accuracy of 87.4% with false positive rate of 12.6%).

The author’s second study examined the applicability of detecting malware instances using a light version of the Knowledge-based Temporal Abstraction (KBTA) method that can be activated on resource-limited devices. The new approach was applied for detecting malware on Google Android powered-devices. Evaluation results demonstrated the effectiveness of the new approach in detecting malicious applications on mobile devices (detection rate above 94% in most scenarios) and the feasibility of running such a system on mobile devices (CPU consumption was 3% on average).

This study also proposed the implementation of SELinux in Android in order to harden the Android system and to enforce low-level access control on critical Linux processes that run under privileged users. By choosing this route, the system can be better protected from scenarios in which an attacker exploits vulnerability in one of the high privileged processes.

The architecture of the proposed framework consists of two modules: a Dynamic Analysis Module and a Behavior Detection Module. Both modules use the API interception technique to obtain software running information. The Dynamic Analysis Module is responsible for analyzing the program’s behavior. The Behavior Detection Module monitors the process’ real time information and compares it with abehavior signature library. Once it detects a mal-behavior, it responds to the user and offers a feedback to construct new behavior model.

All the experiments were done first in Windows Mobile Emulator in PC and then verified in a real mobile phone. The Emulator is Windows Mobile 6.0 professional version and the real mobile phone is HTC PPC6800 with Windows Mobile 6.0 OS.

To test WMMD’s effectiveness towards obfuscation or packing techniques, they used UPX packer to pack five Windows Mobile viruses, and compare WMMD to six other anti-virus software packages (Windows Mobile 6.0) which included an updated virus signatures database. Testing results revealed that all of the other anti-virus products can only detect the virus before packing and they are useless when the virus was packed. However, the WMMD can detect those viruses after packing, since WMMD checks the API call in real execution which cannot be changed. For example, WinCE.Infojack.A is a trojan that binds to popular software installation files and it will extract a file named mservice.exe to the \Windows directory and create mservice.lnk file to the \Windows\StartUp directory. It then start this mservice.exe process. It is apparent that other variants of WinCE.Infojack.A have the same behavior and thus they only need to monitor the CreateFile() and CreateProcess() APIs to check whether their arguments satisfies the specific behavior.

This evaluation on real-world mobile malware shows that behavioral detection can successfully detect malware variants which have certain behavioral patterns with existing patterns in the database, while other anti-virus product cannot detect.

In [26], the authors describe that malware doesn’t always need to be physically installed on the phone to affect the mobile device as they considered defending mobile devices against “proximity malware.” The dynamics of proximity propagation inherently depend upon the mobility dynamics of a user population in a given geographic region. Unfortunately, there is no ideal methodology for modeling user mobility. Traces of mobile user contacts reflect actual behavior, but they are difficult to generalize and only capture a subset of all contacts due to a lack of geographic coverage. Analytic epidemiological models are efficient to compute and scale well, but simplify many details. Synthetic models are flexible and provide the necessary geographic coverage, but lack the full authenticity of user mobility traces.

[26] assumed that devices have a trusted defense software component that can examine messages and files transferred between devices, securely record persistent information about these transfers, and control device hardware when necessary (e.g., disable radio communication). These assumptions may be strong, but not unreasonable given the increasing prevalence of trusted computing modules. However, if malware has the ability to disable defense software, we can predict what the result will be: unchecked propagation through a population.

The first strategy described in [26] simply uses local evidence to detect malware and prevent further dissemination by the device, such as by disabling the Bluetooth or WiFi radio. Preventing further propagation by disabling communication may inconvenience the user, but voice and messaging with the provider network remain possible. Disabling the malware prevents further propagation but makes no attempt to notify other devices or the network about the presence of malware. It serves as a useful baseline for comparison.

The second strategy described in [26] extends local detection with an active mitigation component. In this strategy, each device maintains a table S of signatures of malware files, such as an MD5 hash over the file content. After a device X infers that it is infected, it disables the malware and warns subsequent devices about it. Device X computes a content-based signature s over the file(s) that triggered the infection recognition (e.g., the hash it has used to track file transfers in the first place). When X comes into proximity contact with another device Y, X disseminates the signature s to Y . If Y is infected, it immediately disables the malware. Y then adds s to its signature table S. Whenever another device shares a file with Y,Y will check the file against the signatures in S. The device can then either delete the file, or warn the user about the file.

The third strategy described in [26] relies upon the network provider to disseminate signatures using a broadcast mechanism. In addition to standard unicast messaging, providers are also able to send data packets over broadcast at a low cost. In this strategy, whenever a device decides that it is infected, it sends the malware content to an anti-virus server in the provider network (using MMS). The server, since it presumably contains far greater processing power than the mobile devices, can compute a better quality signature. Also, due to access to anti-virus experts, the server may also be able to compute a patch that contains information on how devices may “cure” themselves and remove the infection from the device. Manual involvement in generating patches is also a possibility.

Lastly, in [27], the authors used data mining techniques to detect malware behavior. This paper proposed a technique of ontology-based behavioral analysis to develop a detection method for smart phone malware. In this experiment, a mobile environment is constructed in the laboratory. The HTC HD2 smart phone with Windows mobile 6.5 operation system was adopted as the main test platform. Then they installed and ran their mobile malware detection system (MMDS) on an HTC HD2 smart phone. Then the other smart phones sent files or messages to the HTC HD2 through MMS or SMS. The MMDS can automatically filter all files and message by extracting their behavioral characteristics. The system will determine the degree of danger of these behaviors. When users have confirmed that this message is in danger of intrusion, the system will refuse the MMS or SMS.

As a result of the experiment in [27], the proposed FPN model can detect most of new mobile malware. However, there exist two pieces of mobile malware that cannot be detected by the FPN model. Since the collection of mobile malware is difficult, one cannot gain various types of mobile malware to test. Thus, the FPN model through the behavior analysis of mobile malware based on the ontology theory may not detect the above-mentioned mobile malware.

I) Future Defense Work

The authors would also like to explore the feasibility of implementing other security features such as:

Enhanced permissions systems: It would be worthwhile to spend time researching how one could detect over-privileged applications and adjust their privilege level for only the privileges that are needed. Additionally, research into a permission models that allow finer-grain control on application permissions would allow developers and users to control exactly what information or modules could be used or accessed. Lastly, research into dynamic analysis models to determine malicious activity would be useful as mobile platforms and applications are becoming more complicated and future attacks could possibly target push notification systems and in-application purchasing systems.

Trusted computing modules: Trusted computing is a technology that ensures that a computer will consistently behave in an expected way and that those behaviors will be strictly enforced by hardware and software. If these modules could be included as hardware on the phone, we could ensure that hackers couldn’t deploy rootkits on phones because the boot process would be verified and secure.

Encryption modules: Many desktop operating sytems implement some form of full hard drive encryption, such as Windows BitLocker and Mac OS X FileVault. Using a hardware encryption module, it would be possible to encrypt the entire hard drive without consuming a large amount of battery power. For example, the user application space could be encrypted in a separate volume that is mounted and decrypted at boot time. In addition to encrypting the entire user application space, applications could also provide their own separate encryption keys to do encryption of application specific data.

Firewall modules: Since smartphones and mobile devices are now as powerful as desktop computers, and the trend of consumers using them as a replacement to desktop and laptop systems will continue, more personal and confidential data will be stored on mobile platforms. It would be valuable to invest research time into mobile firewalls and packet filtering in attempt to possibly detect whether or not data harvesting is occuring on the device and being transferred across a network interface.

5. Applications Survey

The author surveyed over 230 applications (the full list of applications ,can be found in Appendix A), including applications in the “Top” categories on the iTunes store to determine what type of information could be extracted from auditing packet streams. The results were quite surprising.

To perform this audit, the author launched one application at a time and used WireShark to capture and analyze packets. The experiment was performed on an open network that the author created. The access point was a Cisco Small Business router (WAP4410N) and was configured using a hidden SSID and MAC address authentication to prevent outside users from associating with the access point and introducing outside, extra packets. While the author realizes that hidden SSIDs and MAC address authentication are easily defeated mechanisms, it was used to prevent casual users from using the access point. The mobile devices used were an Apple iPod Touch 4G, an Apple iPad 1G and an iPhone 4, configured with iOS 5.0.1.

For reasons of classification, the authors created several different levels of potential security breaches. The levels are defined as:

None: This level is defined as having no potential security breaches and no exposure of confidential information.

Low: This level is defined as having a few potential security breaches or exposure of confidential information that could not directly affect the user, such as device IDs that could be used in tracking users (in iOS, these are called UUIDs).

Medium: This level is defined as having several potential security breaches or exposure of confidential information that is potentially serious or if information is exposed such that an attacker would be able to identify the user on an individual basis, such as addresses, latitudes or longitudes, etc.

High: This level is defined as having multiple potential security breaches or exposure of extremely confidential information, such as account numbers, PINs, and username/password combinations.

For more information on the specific application, including the version number of the application with the vulnerability, see Appendix A for a full listing.

Application

Level

Risks Found

GrubHub

Low

UUID

The Weather Channel

Low

Geocoded location

Path

Low

UUID

Handmade

Low

UUID

iHeartRadio

Low

Reverse Geocoded location

TabbedOut

Low

UUID, Platform

Priceline

Low

UUID, Geocoded location, “Search” API is unencrypted

Free WiFi

Low

Geocoded location

Coupious

Medium

Geocoded location, UUID, coupon redemption codes

Delivery Status

Medium

UPS transmits reverse geocoded locations and tracking numbers.

Color

Medium

Reverse geocoded location and photos taken and shared by users

Cloudette

Medium

Username in plaintext and password, hashed with MD5

Gas Buddy

Medium

Username and password, hashed with MD5

Ness

Medium

Reverse geocoded location

Southwest Airlines

High

Username and password in plaintext

Minus

High

Username and password in plaintext

WordPress

High

Username and password in plaintext

Foodspotting

High

Username and password, Geocoded location

ustream

High

Username and password, UUID, geocoded location

Labelbox

High

Username and password, geocoded location

The majority of the applications that were surveyed encrypted the exchanges of confidential or sensitive information, such as usernames, passwords and account numbers via SSL/TLS.

However, many applications performed some sort of tracking or storing of analytic information, such as passing the UUID in a call to a web service. In some of the instances, this identifying information was not encrypted. While not potentially dangerous in the sense that an attacker could use this information to “identify” a particular person, none of the applications let users know that their information such as UUID, phone OS and model, was being used or recorded, nor did they let the user “opt-out.”

The largest single potential security breach was with the Southwest Airlines application. Due to the fact that the username and password were submitted to a web server via a POST operation in plaintext, an attacker could simply sniff for this data. If an example was captured, one could use those credentials to log into a particular account and book travel, use award miles and possibly change information in the victims profile. This not only obviously worrisome from the standpoint of a potential attacker fraudulently using a victims account and credit card information, but also due to the possibility of a terrorists threats in air travel.

For example, consider the possibility of a person who is currently (and rightfully) on the Department of Homeland Security’s “No-Fly” list. If this person were able to capture a victim’s credentials and create a fake ID, he could pass through TSA security without being stopped.

Of the 253 applications surveyed, 91.7% had no risk found, 3.1% had a low risk, 2.3% had a medium risk and 2.3% had a high risk. While it would be desirable to have no applications in the “Medium” or “High” category, the number of applications the authors found presented a security risk was both surprising and far too numerous. There are over 500,000 applications on the iOS App Store, so extrapolating the results, there could be at least 15,500 applications in the “Low” risk category and 11,500 applications in the “Medium” and “High” risk category.

Overall, the number of applications with some sort of security risk is low. This is not very surprising to the authors as many of these applications are in the “Top” applications list and any potential security flaws would have already been found.

Due to the fact that iOS does not have a robust privilege system, there is no way that a user could know their information was being used in a dangerous or insecure way. While there is support for showing users there is network traffic by using a spinning “network activity indicator”, it is certainly not mandatory for them to do so. In fact, a legitimate or malware application could access the network interfaces, sending and receiving information and never alert the user on iOS.

Developers typically do not follow the principle of least privilege. If an application needs a set of privileges for functionality, they will request them up front, not just when they are needed. This is particularly dangerous because this could be an entry point for an attacker to compromise the application.

[19] performed research where they surveyed 940 Android applications and found that more than 50% required 1 extra unnecessary permission and 6% required more than 4 unnecessary permissions. The reasons that developers may request more permissions than are necessary could be because 1) they don’t understand the importance of security and least privilege, 2) they are planning on future releases that will require these privileges and 3) they don’t fully understand how to work with the platform and make the code function correctly.

Since mobile devices and smartphones are unique in that they have a built-in billing system, there must be ongoing education of developers with emphasis on security and privacy or additional built-in measures in the OS to enforce security over code the developers write or the permissions for which they ask.

6. Using Mobile Devices as Network Monitors

We also researched the possibility of using WiFi sniffing and cracking utilities on the iPhone, as well as the feasibility of releasing a spyware application into the iTunes App Store and collecting user information. As a side note, all the techniques used here could easily be ported to other mobile platforms, such as Android, but this particular research focused on iOS devices.

To be able to perform basic packet sniffing, there are several critical elements that must be performed. The first element is to be able to put the particular interface into a “promiscuous” mode, in the case of wired network interfaces or “monitor” mode, in the case of wireless network interfaces.

In normal network interface operation, the kernel will discard any packets that are not destined to the specific node. Using this “monitor” mode, we are able to capture and further analyze these packets that would normally be discarded. This was a particularly easy piece of code (see Appendix B) to write (if one understands the BSD subsystem and C). In our particular implementation, we have a utility function to toggle the “promiscuous” or “monitor” bit (IFF_PROMISC) in the command word flag (SIOCGIFFLAGS) as well as a function to list all the interfaces that the OS knows about.

In addition to being able to manipulate the firmware of the network card, we also need to be able to access the bpf files or Berkely Packet Filter devices that are located in /dev. These bpf devices “provide a raw interface to data link layers in a protocol independent fashion. All packets, even those destined for other hosts, are accessible through this mechanism [29].”

The access to these files are restricted to root only. This presents a problem for as root access is restricted for applications that will be available in the App Store. Therefore, to install and distribute this application, one must have a jailbroken iOS device.

To give the programmer a more friendly access to the raw data from the bpf device and the packets, a user space program, libpcap (Unix or Linux) or WinPCap (Windows), is bolted onto these kernel-only devices. Interestingly, the authors discovered that the SDK for Mac OS included a pre-built library, libpcap.dylib. Unfortunately, that library is not available natively for iOS, but it can be cross-compiled for the arm architecture by downloading the source from www.tcpdump.org.

Lastly, to perform useful functions with this data, one must create an interface to analyze, extract and filter packet information at the application level. While, a .pcap file could be created for later analysis, it might not be as useful as having live analysis. This can easily be done with a user space program such as tcpdump or WireShark.

This particular research shows there could be a major potential data confidentiality problem with mobile devices. Assuming that the device is jailbroken and if we were able to release an app into the Cydia App Store that a user could download, we could silently harvest and store personal and sensitive information from that particular user, in addition to any other device that is on an open wireless network (assuming that the user was connected), without alerting the user. In addition the being able to sniff packets, since we are in the Cydia App Store, we would have full use of all APIs, including Apple private APIs to harvest personal information.

One question that the authors would like to explore in future research is if we could also use the aircrack-ng suite on mobile devices.

7. Conclusion

In this paper, we examined the history of mobile threats and vulnerabilities as well as current threats and vulnerabilities against mobile devices. We also researched and examined defense mechanisms that currently exist and proposed future research topics. Additionally, we performed two experiments, one as an audit of mobile application security and the other as the feasibility of turning a mobile device into a RF sniffing and data collection device.