UI Interference Attack

The method relies on exploiting the shared memory, meaning the memory almost all programs use to store the nuts and bolts of their work, which enables various processes running on the operating system to share data between them.

In this case, graphical user interface (GUI) frameworks that can be used to determine every UI state change , which can be accessed without special permissions.

Knowing this state change the attacker, can know when sensitive data are being photographed or typed or used in general, enabling the attacker to transmit them to the receiver application. Of course this method needs the injection of a spy application in the targeted OS and as researchers claim this attack can work on almost all current OSes. such GUI confidentiality breach is indeed possible, leading to serious security consequences.

So let’s look into the android exploit that is already published. The fundamental reason for such confidentiality breach is in the Android GUI framework design, where every UI state change can be unexpectedly observed through publicly accessible side channels. Specifically, the major enabling factor is a newly-discovered shared memory side channel , which can be used to detect window events in the target application. This side channel exists because shared memory is commonly adopted by window managers to efficiently receive window changes or updates from running applications.

Window manager is a system software that interacts with applications to draw the final pixels from all application windows to the frame buffer, which is then displayed on screen. After evolving for decades, the most recent design is called compositing window manager , which is used virtually in all modern OSes. Unlike its predecessors, which allow individual applications to draw to the frame buffer directly, a compositing window manager requires applications to draw the window content to offscreen buffers first, and use a dedicated window compositor process to combine them into a final image, which is then drawn to the frame buffer.

In Android, the UI state our attack infers is called Activity. An Activity provides a user interface (UI) for user in off-screen. Client refers to the application, and server refers to the window compositor.

Due to security concerns, by default apps cannot know which Activity is currently shown in the foreground unless they are the owners or the central Activity manager.

An Activity may display different content depending on the app state. For instance, a dictionary app may have a single “definition” Activity showing different texts for each word lookup. We call these distinct displays View States. Denoting the state of the user experience.

Activity transition

In Android, multiple Activities typically work together and transition from one to another to support the functionality of an app as a whole. An example during a typical transition, the current foreground Activity pauses and a new one is created. A Back Stack  storing the current and past Activities is maintained by Android. To prevent excessive memory usage, at any point in time, only the top Activity has its window buffer allocated. Whenever an Activity transition occurs, the off-screen buffer allocation for the new Activity window and the deallocation for the existing Activity window take place.

Activity transitions can occur in two ways: a new Activity is created (create transition), or an existing one resumes when the BACK key is pressed (resume transition), corresponding to push and pop  actions in the Back Stack.

Knowing these fundamentals we will try to explain this novel attack on our beloved smartphones and maybe all new OSes we use.

LoginActivity Attack Overview

The spy app uses Activity hijacking to determine when the state its looking for will come to focus. Let’s use a typical login screen such as facebook or maybe a PayPal login.

LoginActivity, is about to enter the foreground, the attack app simultaneously injects a pre-prepared phishing LoginActivity into the foreground. Just at the right moment so not to make a visual disruption. Thus, enabling the spy app to steal the login data but still log the user in the appropriate application so there will be no trace of the disruption.

Camera Peeking Attack Overview

Due to privacy concerns, many apps store photo images shot by the camera only in memory and never make them publicly accessible, for example by writing them to external storage. This applies to many apps such as banking apps (e.g. Chase), shopping apps (e.g. Amazon), and search apps (e.g. Google Goggles).

Such photo images contain highly-sensitive information such as the user’s life events, shopping interests, home address and signature (on the check). With Activity tracking such sensitive and well-protected camera photo images can be successfully stolen by a background spy app. Targeting at the camera photo shot by the user, instead of random ones of the environment.

This attack uses the OpenGL library many new phones and tablets use , which has very high frame rate and does not need the sound turned off cause it does not use the shutter sound.

Even though Android disallows the taking of photographs in the background that does not mean that it does not stack the camera usage requests while the camera is in use. So when the user photographs something of importance the activity tracker tells the spy app to take another photo just when the camera is released and the user returns to the application he was using.

The camera has a very low release time about 500ms,so the spy app can shoot another shot or the sensitive data milliseconds after the original which makes it very likely the user is still pointing at the document.

There will be information about defending ourselves against these attacks soon.

Image by Benjamin F. Clay CC BY-SA 3.0