The first layer that we are going to talk is the Linux Kernel which is the basic layer. The whole Android Operating System is built on top of the Linux 2.6 Kernel with some architectural changes made by Google. This Linux is the one who interacts with the hardware and contains all the essential hardware drivers. These drivers are programs that control and communicate with the hardware. The Linux Kernel also acts as an abstraction layer between the hardware and other software layers. Android uses the Linux also for all its core functionality such as memory management, process management, network stack, security settings and driver model.
The next layer is the Android’s native libraries. The Android includes a set of C/C++ libraries used by the various components of the Android system in order to enable the device to handle different types of data and each one is specific for a particular hardware. Bellow we list some of the core libraries:
The Android Runtime consists in Core Java libraries and of Dalvik Virtual Machine.
These are the blocks that our applications directly interact with. By providing an open development platform, Android offers developers the ability to build extremely rich and innovative applications. Developers are free to take advantage of the device hardware, access location information, run background services, set alarms, add notifications to the status bar, and much, much more.
Developers have full access to the same framework APIs used by the core applications. The application architecture is designed to simplify the reuse of components. Any application can publish its capabilities and any other application may then make use of those capabilities (subject to security constrains enforced by the framework). This same mechanism allows components to be replaced by the user.
Underlying all applications is a set of services and systems, including:
Applications are the top layer in the Android architecture and this is where our applications are going to fit. Several standard applications come pre-installed with every device, such as:
The developers are able to write an application (written using Java programming language) which can replace an existing system application. That is, they are not limited in accessing any particular feature. You are practically limitless and can do whatever you want to do with the android (as long as the users of the application permit it). Thus Android is opening endless opportunities to the developer, but at the same time can create serious issues from the security point of view, and that is what we are going to talk more ahead.
The rapid growth in smartphone adoption also produced rapid changes in application world where they’ve been changing and moving to mobiles and with these changes private and sensitive information is being pushed to the new device perimeter at an alarming rate. The smartphone mobile device is quickly becoming ubiquitous. While there is much overlap with common operating system models, the mobile device code security model has some distinct points of differentiation.
The mobile code security stack can be broken up into four distinct layers. The lowest layer of the stack is the infrastructure layer, followed upward by the hardware, operating system and application layers. These security stack layers each define a separate section of the security model of a smartphone or mobile device.
Each layer of the Mobile Code Security model is responsible for the security of its defined components. The upper layers of the stack rely on all lower layers to ensure that their components are appropriately safe. This abstraction based model allows the design of a particular mobile security mechanism to focus on a single specific area of concern without expending the resources required to analyze all layers that support its current location within the stack.
This layer is the foundation that supports all of the other tiers of the model. The majority of the functional components at this layer are owned and operated by a mobile carrier or infrastructure provider, however integration into the handset occurs as data is transmitted from this tier upward. Cellular voice and data carriers operate the infrastructure that carries all data and voice communications from end point to end point. The security components at this level typically encompass the protocols in use by the carriers and infrastructure providers themselves. Examples of such protocols include code division multiple access protocol (CDMA), global system for mobile communications (GSM), global positions system (GPS), short messaging systems (SMS), and multimedia messaging systems (MMS). Due to the low foundational nature of this security tier, flaws or vulnerabilities discovered at this tier are generally effective across multiple platforms, multiple carriers, and multiple handset set providers.
As we move to the second tier of the mobile code security stack, we are moving into the realm of a physical unit that is typically under direct control of an end user. The hardware layer is identified by the individual end user premise equipment, generally in the form of a smartphone or tablet style mobile device. The hardware layer is accessible to the operating system allowing for direct control of the physical components. This hardware is generally called the “firmware” and is upgraded by the physical manufacturer of the handset. Security flaws or vulnerabilities discovered at this layer typically affect all end users who use a particular piece of hardware or individual hardware component. If a hardware flaw is discovered in a single manufacturer’s device, it is more than likely that all hardware revisions using that similar design and/or chip will be effected as well.
This layer corresponds to the software running on a device that allows communications between the hardware and the application tiers. The operating system is periodically updated with feature enhancements, patches, and security fixes which may or may not coincide with the patches made to the firmware by the physical handset manufacturer. The operating system provides access to its resources via the publishing of application programming interfaces. These resources are available to be consumed by the application layer as it is the only layer higher in the stack than the operating system itself. Simultaneously, the operating system communicates with the hardware/firmware to run processes and pass data to and from the device
Operating Systems flaws are a very common flaw type and currently tend to be the target of choice for attackers that wish to have a high impact. If an operating flaw is discovered, the entire install base of that particular operating system revision will likely be vulnerable. It is at this layer, and above, where software is the overriding enforcement mechanism for security. Specifically due to the fact that software is relied upon, the operating system, and the application layer above, is the most common location where security flaws are discovered.
The application tier resides at the top of the mobile security stack and is the layer that the end user directly interfaces with. The application layer is identified by running processes that utilize application programming interfaces provided by the operating system layer as an entry point into the rest of the stack.
Application layer security flaws generally result from coding flaws in applications that are either shipped with or installed onto a mobile device after deployment. These flaws come in classes that are similar to the personal computing area. Buffer overflows, insecure storage of sensitive data, improper cryptographic algorithms, hardcoded passwords, and backdoored applications are only a sample set of application layer flaw classes. The result of exploitation of application layer security flaws can range from elevated operating system privilege to exfiltration of sensitive data.
On part two we will look at setting up a security testing environment for android apps and look at how to analyze them.