People are increasingly relying on mobile devices to perform the majority of their daily tasks, leading many attackers to focus their efforts on mobile operating systems within the top-tier markets. Android has about 50% of that market, whereas Microsoft has 23% and Apple iOS has 21%. While these are different operating systems, the attack vectors to which they are vulnerable are quite similar. Nearly all smartphones allow the installation of externally supplied applications (apps). These apps, once downloaded to the phone, are the linked to messaging services capable of launching many forms of remote media. Many of the vulnerabilities associated with mobile devices were previously associated with non-mobile desktops, laptops, and tablets. The following summarizes three of these mobile platforms.
Comparison of Mobile Platforms
Many companies will carefully evaluate the security risks across mobile platforms to determine what may be the best fit for their company-sponsored mobile device deployment (if a bring-your-own-device [BYOD] policy is not implemented). In this case, an evaluation of the company’s “security model” should be performed. Security needs to be implemented and viewed as a whole, which is why it is best represented as a model or architecture.
The Apple iPhone iOS operating system is based on the Objective-C programming language and separates its platform into four key areas. Apple has a highly regulated app-development environment as compared with the Android and Windows platforms. All Apple devices have built-in hardware encryption, remote wiping, and a protocol stack that is current with the latest secure transmission standards. The area most at risk is the ability to download from an external source and install user apps. When apps are installed, they are “sandboxed” into their own separate environment and are unable to access other areas of the system. When an app is created and then distributed to and made available from, or “published,” by the app store and compiled using the Xcode platform, it must be signed using a certificate that can only be granted by Apple. Figure 17.1 illustrates how the sandbox isolation works.
Figure 17.1 How sandbox isolation works.
At the highest level, iOS acts as an intermediary between the hardware and apps you have on your phone. Apps talk through a set of defined system interfaces. This allows apps to work consistently on devices that have different hardware capabilities. The iOS technology can be viewed as a set of layers, which are shown in Figure 17.2. The OS is implemented in C and Objective-C.
The core OS layer (the bottom layer) contains low-level features on which most technologies are built. Some examples include explicitly dealing with security or communicating with an external hardware accessory.
The core services layer (one of the middle layers) contains fundamental services for apps. The key services are the core foundation frameworks, which define the basic types that all apps use. This layer also contains individual technologies to support features including iCloud, social media, and networking. It also includes SQLite, which allows you to embed a lightweight Structured Query Language (SQL) database into your app without running a separate remote database server process. This layer also includes POSIX threats and UNIX sockets.
Figure 17.2 The Apple iOS layers.
This layer (the upper middle layer) contains graphics, audio, and video that you would use to implement multimedia experiences in your apps. This layer makes it easy to build apps that look and sound ideal.
The Cocoa Touch layer (the top layer) contains key frameworks for building iOS apps. These frameworks define the appearance of your app. They also provide the basic app infrastructure and support for key components such as multitasking, touch-based input, push notifications, and other services.
Development of iOS Applications
The development of iOS apps is done in Objective-C using Apple SDK or Xcode (Figure 17.3).
Apple has four primary security focuses: system, data, app, and network security.
Apple uses touch ID and passcodes to protect a phone’s information. Users are encouraged to use strong passcodes, and to have both an expiration and maximum number of fail attempts. For data security, it provides hardware encryption, remote and local wiping of your data, encrypted configuration profiles, and encrypted iTunes backups. For security, it keeps current accepted network security protocols, such as Internet Protocol Security (IPSec), Layer 2 Tunneling Protocol (L2TP), pocket transport network (PTN), and virtual private network (VPN). PTNs are frequently associated with MPLS networks. Secure Socket Layer (SSL) VPN is available via app store apps, SSL/Transport Layer Security (TLS) with X.509 certificates, and Wi-Fi Protected Access (WPA)/WPA 2 Enterprise with 802.1x.
Figure 17.3 Apple iOS app development.
As with Apple’s iOS operating system, the Android phone is based on a Linux operating system kernel (which was derived from the standard historical UNIX kernel). The Android programming is in the C language (similar to Apple’s Objective-C language utilization). When apps are downloaded, installed, and run, they are executed by the Java platform.
In comparison to Apple iOS, Android apps can be “self-signed,” whereby the individual user is in complete control of what apps are installed. This is a point of vulnerability due to the widespread use of Android and limited education concerning the potential security risks associated with downloaded apps. Even app stores for the Android marketplace may unknowingly distribute malicious software.
Android has a similar approach to the app containment methods used by Apple iOS. Android runs each app on the device as its own user with its own permission and restrictions. Each of these apps runs in a mini virtual machine provided by Dalvik, much like Apple’s sandbox. If one app wants to access resources from another, they must communicate through the “inents” app framework.
The Android Platform Outline-Android is built on the Linux kernel and is currently developed by Google. The other layers include libraries, app frameworks, and apps. Android is open-source software and is written with C with a Java platform for running apps (Figure 17.4).
Because Android is open source, this allows for a vast amount of apps to be developed by third parties, which enhance your mobile capabilities but also can expose your phone to self-signed apps (uncertified) or permit actions on installation. When malware is downloaded in the form of an unsecure app, the malware app escalates from being a remote exploit outside the device to being installed inside the device and now having privilege escalation status on the device. Under privileged escalation, a bug—or merely a design flaw or configuration oversight in an operating system or software app—can be exploited to gain elevated access to resources that are normally protected from an app or user. The malware app, once downloaded and installed on the mobile device, then gains a privileged status for exploitation of the user’s device’s facilities.
The shift has then moved from being a remote external potential exploit to having privilege escalation status on the mobile device. This privilege escalation is essentially the exploitation of an installed bug, or of a design flaw or configuration oversight in an operating system or software app, which is used to gain elevated access to resources that are normally protected from other apps or users.
Figure 17.4 Android’s architecture diagram.
One of the key features in an Android phone is that it uses a multiuser Linux operating system. In other words, each app normally runs as a different user, preventing them from having access to one another. Communications between apps may share the same Linux user ID. If they do, they can access files from each other. Another key feature of an Android phone, although not specifically a security feature, is its battery life. Both Android designers and application developers have attempted to extend battery life by employing power conservation methods. Apps store state so they can be stopped (to save power) and restarted for power conservation purposes.
Figure 17.5 shows a chart of the app development process.
The five key components to consider when developing an app are activity, service, intents, content provider, and broadcast receiver. Activity refers to a one-user task. An example would be scrolling through your inbox. An e-mail client comprises many activities. Service refers to a Java daemon that runs in the background. An example would be an app that streams an MP3 in the background. Intents are an asynchronous messaging system. When you fire intent, you switch from one activity to another. An example would be an e-mail app that has an inbox, compose activity, viewer activity, and so on. When the user clicks on the inbox entry, an intent is fired to the viewer activity, which then allows the user to view the e-mail. A content provider looks at where and how to store and share data using a relational database interface, and a broadcast receiver looks at “mailboxes” for messages from other apps.
Figure 17.5 The app development process for mobile apps.
There are hundreds of libraries and over 500 million lines of new code with those libraries. The goal of mobile security is to prevent remote attacks and privilege escalation. One large defense is the app sandbox. A sandbox is a security mechanism for separating running programs. This provides central processing unit (CPU) and memory protection (Figure 17.6).
Each app executes as its own user identity. Android middleware has a reference monitor that mediates the establishment of intercomponent communication (ICC). Applications (apps) announce permission requirements that create a whitelist model giving users grant access.
Figure 17.6 The Android app model.
The Java sandbox is a security measure in the Java development environment. When a browser requests a web page with applets (a program designed to be executed from within another app), the applets are sent automatically and can be executed as soon as the page arrives in the browser. If the applet is allowed unlimited access to the memory and operating system resources, it can be harmful in the hands of an attacker. The sandbox creates an environment in which there are strict limitations on what system resources the applet can request or access. Sandboxes are used when executable code comes from unknown or untrusted sources, and they allow the user to run untrusted code safely.
The Java sandbox relies on a three-tiered defense. If any one of these three elements fails, the security model is completely compromised and vulnerable to attack. These three elements are
■ Byte code verifier
– This is one way that Java automatically checks untrusted outside code before it is allowed to run. When a Java source program is compiled, it only compiles down to the platform-independent Java byte code, which is verified before it can run. This helps to establish a base set of security guarantees.
■ Applet class loader
– All Java objects belong to classes, and the applet class loader determines when and how an applet can add classes to running Java environment. The applet class loader ensures that important elements of the Java run-time environment are not replaced by code that an applet tries to install.
■ Security manager
– The security manager is consulted by code in the Java library whenever a dangerous operation is about to be carried out. The security manager has the option to veto the operation by generating a security exception.
Apple iOS versus Android Operating System Comparisons
Below is a list of comparisons between the Android and Apple iOS operating systems.
App approval process: Android apps are downloaded from an open app store, while Apple iOS apps are downloaded from a vendor-controlled store of vetted apps.
App permissions: Android permissions are based on an install-time manifest, while all Apple iOS apps have the same prespecified set of sandbox privileges.
App programming language: Android apps are typically written in Java with no buffer flow, while Apple iOS apps are typically written in Objective-C.
Windows Mobile Models 7 and 8 Devices
Windows Mobile devices have been on the market far longer than either Android- or Apple iOS-based devices. Furthermore, the Windows security model is far simpler and more streamlined than its competitors, especially for the Windows Mobile 8 operating system. Figures 17.7 and 17.8 show the Model 7 and Model 8 security models.
Microsoft describes its “isolation” boundaries as “chambers,” but its isolation techniques are similar to that of its competitors. Each chamber has a preset amount of permissions and process capabilities. Memory data is completely isolated, and there is no direct communication between apps; such communication must go through cloud-based services. When an app is switched, the app is entirely shut down, which differs from the way Apple’s iOS operates.
Figure 17.7 Windows 7 phone security.
Figure 17.8 Windows 8 phone security.
Windows Phone OS 7.0 Security Model
The Windows security model has the principles of isolation and least privilege. Each app runs its own isolated chamber. Each chamber provides a security and isolation boundary and is defined and implemented using a policy system. The security policy of a chamber is that it specifies the operating system capabilities that processes in that chamber can access. The isolated chamber cannot access the memory or data of other apps, including keyboard cache. No communication channels are permitted between apps, except through the cloud. Non-Microsoft apps that are distributed via the marketplace are stopped in the background. In other words, when a user switches apps, the previous app is shut down. The reason for this is that apps cannot use critical resources or communicate with Internet-based services while the user is not using the app.
There are four chamber types. Three types have fixed permission sets, while the fourth is capabilities driven. Apps that are designed to run in the fourth chamber type have capability requirements that are honored at installation and at run time. Apps that are designated to run in the fourth chamber type have capability requirements that are honored at installation and at run time.
The four chamber types are as follows:
Chamber 1, the trusted computing base (TCB), has unrestricted access to most resources and can modify policy and enforce the security model. The kernel and kernel-mode drivers run in the TCB. Minimizing the amount of software that runs in the TCB is essential for minimizing attack surfaces in the Windows Phone 7 and 8.
Chamber 2, the elevated rights chamber (ERC), can access all resources except the security policy. It is intended for services and user-mode drivers.
Chamber 3, the standard rights chamber (SRC), is the default for preinstalled apps that do not provide device-wide services.
Chamber 4, the least privileged chamber (LPC), is the default for all non-Microsoft apps and is configured using capabilities.
The overall goal of isolation and chambers is to give apps the least amount of privilege as possible. The app should get the amount it needs but no more. Developers use the capability detection tool to create the capability list. The capability list is included in the app manifest. Capabilities are resources associated with user privacy, security, cost, or business concerns. Each app discloses its capabilities to the user. It is listed on the Windows Phone Marketplace, and there is an explicit prompt on app purchase. Lastly, there is a disclosure within the app for the first time the user is about to use the location capability.
Figure 17.9 Code requiring permission.
.NET Code Access Security That Can Be Exploited on Windows Phones
The .NET framework is a proprietary, partially open-source freeware software framework developed by Microsoft that runs primarily on Microsoft Windows. The default security policy is part of the .NET Framework. Default permission for code access is permitted to protect resources. Permissions can limit access to a system’s resources. “Deny and revert” denies access to a resource, and “revert” can cancel a previous deny command. Figure 17.9 shows an example of code requiring permission.
Figure 17.10 is an example of code denying permission because it is not needed.
The following is a summary list of Windows characteristics.
■ The approval process for apps:
– The market is both vendor controlled and open
– App signatures are also both vendor and self-signed
– User approves permissions
Figure 17.10 Code denying permission because it is not needed.
Figure 17.11 Summary chart: Differences between, Apple iOS, Android, and Windows phones.
■ The programming languages employed:
– The managed execution is in Java, .NET
– The native execution is in Objective-C
Figure 17.11 provides a summary of overall comparisons between the different platforms.
Mobile platform security is a leading topic regarding the future of information security. More often than ever, people are using their smartphones to deal with critical tasks such as banking, investing, and even health care. Knowing this, hackers and malicious coders are looking for ways to exploit present security vulnerabilities in Apple iOS, Android, and Windows Mobile platforms. Luckily, security measures have already been implemented within these operating systems to combat potential issues. However, they are certainly far from perfect. Understanding the potential risks of mobile information security is important for understanding each operating system’s current security platform.
Apple’s iOS is one of the leading mobile operating systems in the world. In fact, it is estimated that Apple has sold almost half a billion iPhones within the past seven years! Apple’s iOS is a kernel-based operating system, much like Apple’s computing operating system OS X. It is coded in the C and Objective-C programming language, which is a fairly efficient computing language. While at rest, Apple’s iOS is fairly secure. There are lock-screen passwords that enable a user to lock their phone at the simple click of a button. However, if the phone is stolen, the data integrity may be compromised by third-party apps that could rip data off the iPhone. Luckily, Apple has a remote erase feature that can wipe the iPhone of all its data if it has been stolen. However, there have been iPhone worms that have affected users. Ikee is the most famous of these iPhone worms. While it isn’t considered malicious code, Ikee changes the background to a picture of Rick Astley with text on the top screen that reads, “Ikee is never going to give you up.”
Figure 17.12 Source code for Ikee with developer comments.
While the developer had no malicious intent, it was supposed to be a commentary on the fact that users do not adequately change their passwords. In fact, this code could have been written maliciously and taken bank information from the users. Figure 17.12 shows the source code for Ikee with developer comments.
The Android phone has another vulnerable operating system. One billion Android phones were shipped in 2014 alone. Needless to say, this is a fairly popular operating system. As with iOS, Android is written in the C programming language and utilizes a Linux kernel. The apps for Android users are written in Java, which can be a security risk itself. Another glaring security flaw is the Android applications. In the Android model, users could potentially create malicious apps to be downloaded by other Android users. DroidDream is a perfect example of one of these apps. DroidDream conducted data theft on Android user’s phones by utilizing 58 bad apps. It got its name because the malicious apps would run between 11 p.m. and 8 a.m., when most users would not be utilizing their telephones. While Google has removed DroidDream, variations of it have hit the market since. Some of these variations include DroidDream Light, which hit the market in 2011.
Mobile security is the next big topic of the future regarding information security. The statistics for vulnerabilities and exploits presented in Figures 17.3 and 17.4 will corroborate this belief. Mobile operating system vulnerabilities have grown from 18 to close to 200 from 2006 to 2012, while mobile exploits have risen from near zero to 14 in the same time period.
More users need to proceed with the same caution in using their mobile devices that they use on their computers, if not more so. With this being the next frontier for hackers and malicious coders, there is no telling what the possibilities are for security threats within iOS and Android devices.
Figure 17.13 Worldwide mobile operating systems (phones) market share.
Figure 17.14 Gartner group estimate of mobile operating systems sales market share 2008–2016. (From Gartner, Forecast: Mobile devices by open operating system, worldwide, 2009–2016, 2012.)
In this section, we will further discuss mobile platforms and the potential threats they each face. Specifically, we will again focus on the Apple iOS, Android, and Windows 7 and 8 security models. Figures 17.13 and 17.14 show a graph representing the mobile phone operating system market share from 2008 to 2012.
As you can see, Android has been rapidly growing in popularity. Apple has remained steady in its market share, but Microsoft has begun growing significantly in the past 4 years. For each operating system, there are dozens of apps providing similar services. Figure 17.15 is a list of displayed icons that represents some of the Android advertised apps.
However, apps for all mobile phones can be broken down into eight broad categories (Figure 17.16).
With the rise in mobile devices and apps, more and more threats and attacks will continue to occur following the pattern of operating system vulnerabilities and exploits previously discussed.
Figure 17.15 Some Android advertised apps.
Figure 17.16 Eight broad categories of mobile apps on the market.
Attack Vectors for Mobile Devices
There are two attack vectors for mobile platforms, the web browser and installed apps, both of which are increasing in prevalence and sophistication. Phones are unique in that they have short message service (SMS) messages, identity location, and records of phone calls, and they log a certain number of your SMS messages. They are similar to desktops in that they can connect to botmasters, can steal data, and are vulnerable to phishing and malvertising. Some broad examples include DroidDream (Android), Ikee (iOS), and Zitmo (SYmbian, BlackBerry, Windows, Android). DroidDream was malware that was placed in over 58 apps and then uploaded to the Google app market. It conducts data theft, sending credentials to attackers. Ikee has worm capabilities (targeted default ssh pwd), but it only worked on jailbroken phones with ssh installed. Zitmo is malware that propagates via SMS, claiming to install a “security certificate,” but it actually captures information from the SMS. It’s aimed at defeating two-factor authentication. Zitmo works with Zeus botnet and is timed with user PC infection.
QUESTIONS
1. List the Apple iOS layers and describe each.
2. What are the five key components when developing an app?
3. What is a Java sandbox?
4. A Java sandbox relies on a three-tiered defense. What is it?