Mobile App Collusion Attack Analysis | Lucideus

Traditional methods of injecting malicious code inside Android apps are losing efficiency over time and are easily detected by Google Play Protect which is based on Machine Learning and Anti-malware apps such as Avast and many more. To counter this hackers found a new method of injecting malicious code into Android apps using Mobile App Collusion, in this attack vector hacker use multiple infected applications to extract valuable information from any Android device.

Briefly, it requires at least two apps, one app contains all permissions required and it extracts data from the device, the second app extracts all the data from the first app and sends it to a web server.

What is a Mobile App Collusion Attack
There are multiple ways to attack a target such as:

  • An attacker can split malicious code into multiple apps and communicate between apps using internal android architecture.
  • An attacker can create a Software Development Kit and distribute it in developers so multiple apps will have the malicious code and if a device contains all apps with this code, it can be compromised automatically

Attack Scenarios
There can be multiple attack scenarios in which attackers can successfully compromise a large number of devices such as:
  • If we browse app store we can find many apps which require a secondary app to function completely like a key or a plugin, an attacker can inject his permissions in the main app and modify the secondary app in such a way that it sends data to his web server.
  • Attacker can develop new apps dedicated for this attack and upload on app store and there is a good chance these apps will go unnoticed because apps are scanned and tested individually and if we look at both apps we can see that first app just requires permissions like many legit apps, some games, for example, require many permissions to function properly and users happily allow them, and the second app is just sending data from the main app to a web server, again many applications and games are server sided and frequently send data to their servers.
  • An attacker can also convert the compromised device into a slave of a botnet and carry out malicious tasks.

Generally, users cannot see what information the app is collecting and sending to its server which is a plus point for the attacker to successfully compromise a device.

Inter-App Communication
An Android app typically has several activities. Each activity displays a user interface that allows the user to perform a specific task (such as view a map or take a photo). To take the user from one activity to another, your app must use an Intent to define your app's "intent" to do something. When you pass an Intent to the system with a method such as startActivity(), the system uses the Intent to identify and start the appropriate app component. Using intents even allows your app to start an activity that is contained in a separate app.

The intent is a messaging object which can be used to request an action from app component. The three main usage are start activity, start service, and send broadcast, and there are two types of intents:
  • Explicit intents: An Application will use the intent by supplying either the target App’s package name or a fully-qualified component class name. The typical use of explicit intent is to start a component in one’s own App, because you know the class name of the component you want to start.
  • Implicit intents: You do not name a specific component, but instead declare a general action to perform, which allows a component from another app to handle it.

Content Providers
Content provider store and provide content to Applications like a relational database. They encapsulate data and provide it to Applications through the single ContentResolver interface. A content provider is only required if you need to share data between multiple Applications.

Shared Preference
Shared preference is a small collection of key - values that you’d like to save, and you should use the SharedPreferences APIs. A SharedPreferences object points to a file containing key-value pairs and provides simple methods to read and write them, and Applications can use shared preference to exchange information

Covert Channels
Covert channels take advantage of some of the APIs or features offered by the OS to enable communication between processes. There is no formal method to obtain all covert channels that may exist in a computer system.

Examples of Android covert channels include:
  • Audio Settings (they can be read and modified without permissions)
  • Broadcast events triggered by setting  changes
  • File  locks
  • Process  Enumeration
  • Unix socket  discovery
  • Amount  of  free RAM/storage space  and  CPU utilization
Android Security Mechanism
If an application wants to access a sensitive resource, it must include a permission declaration inside the AndroidManifest.xml file.

Apps in the sandbox can communicate with other apps via standard Unix mechanisms (files, sockets, etc.) or the Inter - Process communication (IPC) mechanisms provided by the Android OS.

The Android OS does not check if an app that is accessing a permission - protected resource through another app has Itself requested that permission. This task is left to the developer of the app that is exposing the access to the permission - protected resource.

Application Sandbox
The Android platform uses the Linux user-based protection as a means of identifying and isolating application resources.
Each Application has a unique user ID and runs it In a separate sandbox, it does not have access to the rest of the system’s resource unless are granted access permissions by the user. The sandbox is simple, auditable, and based on user separation of process and file permissions.

Android Permissions
Android uses permission mechanism to protect the privacy of Android user. Android Application must request permission to access sensitive user data and certain systems resources, such as camera and internet. An app must declare its permissions in its manifest file.

No comments:

Powered by Blogger.