HB Blog 114: System Permissions In Android.

Android is a privilege-separated operating system, in which each application runs with a distinct system identity (Linux user ID and group ID). Parts of the system are also separated into distinct identities. Linux thereby isolates applications from each other and from the system.

Additional finer-grained security features are provided through a "permission" mechanism that enforces restrictions on the specific operations that a particular process can perform, and per-URI permissions for granting ad hoc access to specific pieces of data.

A central design point of the Android security architecture is that no application, by default, has permission to perform any operations that would adversely impact other applications, the operating system, or the user. This includes reading or writing the user's private data (such as contacts or emails), reading or writing another application's files, performing network access, keeping the device awake, and so on.

Because each Android application operates in a process sandbox, applications must explicitly share resources and data. They do this by declaring the permissions they need for additional capabilities not provided by the basic sandbox. Applications statically declare the permissions they require, and the Android system prompts the user for consent.

All APKs (.apk files) must be signed with a certificate whose private key is held by their developer. This certificate identifies the author of the application. The certificate does not need to be signed by a certificate authority; it is perfectly allowable, and typical, for Android applications to use self-signed certificates. The purpose of certificates in Android is to distinguish application authors. This allows the system to grant or deny applications access to signature-level permissions and to grant or deny an application's request to be given the same Linux identity as another application.

A basic Android application has no permissions associated with it by default, meaning it cannot do anything that would adversely impact the user experience or any data on the device. To make use of protected features of the device, you must include one or more <uses-permission> tags in your app manifest.

System permissions are divided into several protection levels. The two most important protection levels to know about are normal and dangerous permissions:

1. Normal permissions cover areas where your app needs to access data or resources outside the app's sandbox, but where there's very little risk to the user's privacy or the operation of other apps. For example, permission to set the time zone is a normal permission. If an app declares that it needs a normal permission, the system automatically grants the permission to the app. For a full listing of the current normal permissions, see Normal permissions.
2. Dangerous permissions cover areas where the app wants data or resources that involve the user's private information, or could potentially affect the user's stored data or the operation of other apps. For example, the ability to read the user's contacts is a dangerous permission. If an app declares that it needs a dangerous permission, the user has to explicitly grant the permission to the app.

 Apps can define their own custom permissions and request custom permissions from other apps by defining <uses-permission> elements. However, you should carefully assess whether it is necessary for your app to do so.

• If you are designing a suite of apps that expose functionality to one another, try to design the apps so that each permission is defined only once. You must do this if the apps are not all signed with the same certificate. Even if the apps are all signed with the same certificate, it's a best practice to define each permission once only.
• If the functionality is only available to apps signed with the same signature as the providing app, you may be able to avoid defining custom permissions by using signature checks. When one of your apps makes a request of another of your apps, the second app can verify that both apps are signed with the same certificate before complying with the request.
• If you are developing a suite of apps runs only on your own devices, you should develop and install a package that manages permissions for all the apps in the suite. This package does not need to provide any services itself. It just declares all the permissions, and the other apps in the suite request those permissions with the <uses-permission> element.

HB Blog 87: Android Root Equivalent Vulnerabilities Detected And Fixed.

In computer security, a vulnerability is a weakness which allows an attacker to reduce a system's information assurance. Vulnerability is the intersection of three elements: a system susceptibility or flaw, attacker access to the flaw, and attacker capability to exploit the flaw. To exploit a vulnerability, an attacker must have at least one applicable tool or technique that can connect to a system weakness. In this frame, vulnerability is also known as the attack surface.

Many root equivalent vulnerabilities are found in Android which could exploit an application. This means vulnerabilities which allow an application (malicious or compromised) to either directly gain root or gain privileges which can then be used to obtain root. Below, I have listed few android vulnerabilities that are detected and fixed with there basic descriptions,

Name:- dhcpd buffer overrun.
Root Category:- Network.
Description:- The specific flaw exists within the parsing of the DHCP options in a DHCP ACK packet. The vulnerability is triggered when the LENGTH of an option, when added to the current read position, exceeds the actual length of the DHCP options buffer. An attacker can leverage this vulnerability to execute code on the device. This remote code execution vulnerability executes code as the dhcp user which limit's its severity.

Name:- TowelRoot.
Root Category:- Network.
Description:- The futex_requeue function in kernel/futex.c in the Linux kernel through 3.14.5 does not ensure that calls have two different futex addresses, which allows local users to gain privileges via a crafted FUTEX_REQUEUE command that facilitates unsafe waiter modification.

Name:- Defy republic init_runit.
Root Category:- Permissions.
Description:- A certain configuration of Android 2.3.7 on the Motorola Defy XT phone for Republic Wireless uses init to create a /dev/socket/init_runit socket that listens for shell commands, which allows local users to gain privileges by interacting with a LocalSocket object. Stack-based buffer overflow in the sub_E110 function in init in a certain configuration of Android 2.3.7 on the Motorola Defy XT phone for Republic Wireless allows local users to gain privileges or cause a denial of service (memory corruption) by writing a long string to the /dev/socket/init_runit socket that is inconsistent with a certain length value that was previously written to this socket.

Name:- Qualcomm chown init scripts.
Root Category:- Permissions.
Description:- Insecure owner/permission changes in init shell scripts: During the device start-up phase, several init shell scripts are executed with root privileges to configure various aspects of the system. During this process, standard toolchain commands such as chown or chmod are used to, e.g., change the owner of the sensor settings file to the system user. As these commands follow symbolic links (symlinks), an attacker with write access to these resources is able to conduct symlink attacks and thus change for example the owner of an arbitrary file to system. This flaw can be used to, e.g., elevate privileges.

Name:- APK duplicate file.
Root Category:- Signature.
Description:- Android does not properly check cryptographic signatures for applications, which allows attackers to execute arbitrary code via an application package file (APK) that is modified in a way that does not violate the cryptographic signature.

Name:- Fake ID.
Root Category:- Signature.
Description:- The software does not properly validate an application's certificate chain. An application can supply a specially crafted application identity certificate to impersonate a privileged application and gain access to vendor-specific device administration extensions. The vulnerability resides in the createChain() and findCert() functions of the Android JarUtils class.
Name:- RageAgainstTheCage adb.
Root Category:- System.
Description:- adb fails to check setuid return code and this can be caused to fail by the shell user already having RLIMIT_NPROC processes.

Name:- keystore buffer.
Root Category:- System.
Description:- Stack-based buffer overflow in the encode_key function in /system/bin/keystore in the KeyStore service in Android 4.3 allows attackers to execute arbitrary code, and consequently obtain sensitive key information or bypass intended restrictions on cryptographic operations, via a long key name.

Name:- Qualcomm Gandalf camera driver..
Root Category:- Kernel.
Description:- The camera driver provides several interfaces to user space clients. The user space clients communicate to the kernel via syscalls such as ioctl or mmap. The camera driver provides an uncontrolled mmap interface that allows an application with access to the device file to map physical memory exceeding the camera driver's memory into user space. A locally installed, unprivileged application can use this flaw to escalate privileges.

Name:- Qualcomm out of bounds camera.
Root Category:- Kernel.
Description:- The camera driver provides an ioctl system call interface to user space clients for communication. When processing this communication, the msm_ioctl_server, msm_server_send_ctrl, and msm_ctrl_cmd_done functions use a user-supplied value as an index to the server_queue array for read and write operations without any boundary checks. A local application with access to the camera device nodes can use this flaw to, e.g., elevate privileges.

HB Blog 62: Firewall And Its Types.

Firewall is a hardware or software that protects from intrusions from attackers. It examine all the data packets passing through them to see if they neet the rules defined by the ACL(Access Control List) made by the administration of the network. Firewall also maintain a log of important activities in the network. The log can be configure as per required. It also filters contents on the basis of address, protocol, packet attributes and state.

The types of firewall are as follows:-
Packet filtering firewall
Circuit level gateway firewall
Application level gateway firewall
Stateful multilayer inspection firewall

Packet filtering firewall:-
Packet filtering firewalls are deployed on routers which connect the Internet network to Internet. It can be only be implemented on network layer of osi model. It works on the basis of rules defines by Access Control Lists. They check all the packets and screens them against the rules as per the ACL. If the packet is not match the criteria then that packet is dropped and logs are updated. The ACL are created on the basis of address, protocol, packet attributes and state.

Circuit level gateway firewall:-
Circuit level gateways are deployed at the session layer of OSIodel and they monitor sessions like TCP three way and handshake to see whether a requested connection is legitimate or not. Major screening happens before the connection is established. Information sent to a computer is secure and appears to be sent from the gateway.

Application level gateway firewall:-
Application level gateways works on the application layer of OSI model and provide protection for specific Application layer protocol. It only works for configured protocols. It can also be configured as Caching servers which in turn increase the network performance and makes it easier to log traffic.

Stateful multilayer inspection firewall:-
Stateful multilayer inspection firewall is combination of all firewalls. They can filter packets at network layer using ACL, check for legitimate sessions on the session layer and thry also evaluate packets on the application layer. They can work on a transparent mode allowing direct connections between the client and the server. It can also implement algorithms and complex security models which are protocol specific, making the connection and data transfer more secure.