Further Android Vulnerabilities Disclosed

IBM X-Force have disclosed a serious security vulnerability in Google Android, the popular smartphone operating system. The flaw was disclosed in their research paper and presented at the USENIX Woot ’15 conference in Washington D.C.

The flaw known as the Android serialization vulnerability affected Android versions 4.3 (codenamed Jelly Bean) to 5.1 (Lollipop) and the upcoming version of Android currently codenamed M Preview 1. It affects approximately 55% of current Android phones in use. It allows the execution of code of an attacker’s choice but can only be exploited if malware was installed on the victim’s device.

How this does flaw work?
To demonstrate the issue, the security researchers replaced a genuine app with a fake one which would allow them to obtain any sensitive data that was entered into that app. The fake app was designed to target the privileged system_server process of Android in order to use it’s SELinux profile to allow the app to carry out privileged actions.

The researchers scanned a large number of Android app classes (see “Aside” at the end of this post for a definition), one was found that met of the following criteria:

  1. Is serializable;
  2. Contains a finalize method;
  3. Contains an attacker-controlled field.

This class, known as OpenSSLX509Certificate contained a controllable pointer (which points to code (tasks or actions) next to be carried out). Using this pointer the researchers were able to control which address in Androids memory to point at. They were then able to change the contents of this memory space to contain code of their choice.

Next, they bypassed ASLR (defined) by using the fact that all apps and some services including this fake app inherit the same memory layout (the very thing that ASLR is designed to prevent) since the fake app is also forked from the Zygote process (an app launcher process).

Moreover, the researchers managed to have their app execute (carry out their intended actions) as follows:

Overwriting the callback function pointer and then triggering a call to that pointer. This allows control of the program counter (PC)(The program counter is a register within your CPU which always holds the memory location of the next instruction to be executed).

Pointing the PC to a ROP (return oriented programming) gadget (both defined) and employs a stack pivoting technique. This ROP chain changes the memory space (mentioned above) to enable it to have the ability to run/execute code. The intended code is then placed within the memory space and executed.

Why Should This Issue Be Considered Important?
With the code of their choice placed in a location in memory that allows code to execute (carry out a set of actions); this allows the researchers to carry out any or all of the following actions:

  • Load arbitrary kernel modules in devices with kernel compiled with CONFIG_MODULES (kernel modules run with the highest level of privilege and can carry out any action they choose);
  • Steal data from any apps (e.g., by exploiting Android KeyChain app, which is allowed to run shell commands and access data);
  • Change SELinux policy rules;
  • Replace the code (APKs) of arbitrary apps.

How Can I Protect Myself From This Issue?
Sophos provides easy to use advice to protect yourself from this issue. In short, your Android smartphone should receive a patch to resolve this issue. The IBM researchers worked with Google to develop a fix for this issue.

Please note that the IBM researchers also found security issues in numerous Software Development its (SDKs) used to create Android apps. They also worked with the creators of such SDKs to develop fixes for the issues found. Further information on these flaws are provided in their detailed blog post.

My thanks to these researchers for providing an in-depth explanation of both the serialization and SDK issues.
=======================

Google Admin App Sandbox Bypass
The Android serialization issue was not the only issue recently disclosed by security researchers. The Google Admin app which allows users to access their Google for Work accounts was also found to contain an issue that allows attackers access to the files being used by the Google Admin app.

How this does flaw work?
Apologies but this explanation is as short as I can make it while explaining what’s happening as we go along:

The Google Admin app does not handle file URLs (examples of a URL would file://test.txt) correctly. The Google Admin app like other apps on Android is sandboxed (isolated within a protected container with no direct means of communicating with other apps) from other apps. To enable apps to communicate for useful and legitimate purposes Android uses inter process communication (IPC).

One such app interface is called setup_url. This can be used by another app to create an intent (a description of the action that an app wishes to perform, full definition here). Using this intent the attacker sets the URI (Uniform Resource Identifier) to a file on the device with the setup_url (mentioned above) to a file that the attacker can write to (has write access to).

A function (see Aside below for a definition) with the Google Admin app will then load this file (which the attacker can write to) with the same permissions the Google app possesses while the Google app renders (draws) the file/page in its WebView class (which enables it to display webpages, unsurprisingly!). The attacker can then add HTML code to this file and will then use an iframe (an HTML code tag used to embed one file within a currently in use HTML file) to load the file again.

The penultimate action for the attack is to delete the file that they can write to and replace it with a symbolic link (a means of representing a link to a file or a folder in a simpler way, an example is given at the end of this forum thread and a further explanation in this Sophos blog post) to a file of the same name within the Google App’s protected sandbox.

Finally, after one second has passed WebView will load the file within the sandbox. Since both the WebView and the WebView with the inserted iframe have the same URL (Uniform Resource Locator) the Same Origin Policy (a policy/rule that prevents code usually JavaScript from site A accessing private data belonging to site B) allows the WebView to query the contents of the WebView with the iframe (since the URLs are the same, the Same Origin Policy is not broken). Thus the HTML code added by the attacker can read the files within the iframe.

Why Should This Issue Be Considered Important?
A malicious app installed on your Android device could be able to read any data within any file contained in the normally inaccessible sandbox (protected storage area) of the Google Admin app.

How Can I Protect Myself From This Issue?
Please ensure that you have the latest version of the Google Admin app as described in this Sophos blog post since Google has addressed the above issue in this update.

=======================
Aside:
What is a class?

In the context of computer programming a class is set of variables (containers that store single values). The variables can be of different types e.g. integer and float (to represent floating point numbers e.g. 1.25). A class also contains one or more functions.

Functions allow a class to do something e.g. a class named Car would contains functions for accelerate, brake, park etc. A class allows a programmer to create an object which contains all of these variables and functions ready to use.
=======================

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s