Unsafe Android Apps

Unsafe Android Apps
Unsafe Android Apps

Whenever we upload an app to an android store( Google play store), Google checks it for unsafe android apps. Android apps are designed in such a way that they give the capability for developers to load code at runtime. Sometimes the sandbox (app checking software) doesn’t check for code loading in runtime,, which offers an advantage for malicious developers to add malware during runtime.

Introduction

The recent boost in the Android industry has given developers the to showcase their application development skills and creativity. Around 900 million android devices are currently active around the world. With advancement, there is a tradeoff as well. Suppose a hacker hacks an android device. It means that he can control 900 million users around the world.

Unsafe Android Apps
Unsafe Android Apps

In 2012 Google started their first App analyzer software known as Google Bouncer, which analyzes unsafe android apps offline. The inner working of google bouncer is still unknown, but some researchers say it uses dynamic analysis techniques.

The drawback of Google Bouncer was that it checked apps offline, so if the app was downloading a code during runtime, the unsafe android apps could pass the test easily.

Loading code during runtime is a legal reason. Some apps have regular updates, etc, so they do support code loading during runtime; this was another big issue.

Proposed Solution

Some researchers from the University of Bonn, Germany, proposed a solution by modifying the Android Dalvik Virtual machine.

Android Dalvik Virtual Machine

Unsafe Android Apps
Android Dalvik Virtual Machine

It is an android virtual machine which is optimized for mobile applications. It is optimized for performance, memory and battery life.

The working of the Android Dalvik Virtual Machine is as follows:

  • Java Compiler Converts Java Source code into java byte code.
  • The Dex Compiler convert java byte code into Dalvik bytecode.
  • The Dalvik Byte code is then converted to APK through AAPT Packaging.

Background and Threat Model

The things we need to care about in our android Device:

Android Permissions

Whenever the user wants to install an app, the app gives a list of things it needs permission for. Android enforces permissions by using high level checks in java code and common linux security concepts.

Application stores

When you install an app not from google play you have to on site loading settings which is a common thing people do and unsafe android apps get into your device.

Native code

Native code is machine-level code. In java, native code is invoked through the java native interface. Android deals with native code as data not as a code. So sometimes a malicious native code can cause destructions.

Threat Model
Threat Model

Now we will tell you about the threat model. There are basically two attack scenarios:

Evasion of offline analysis system

It is basically when the unsafe android apps downloads the malicious code during runtime.When the apps store check the app offline it contains no malicious code. The malicious code is downloaded after installation on the device thus these unsafe android apps easily pass the testing method of different app stores.

Code Injection against the benign application

Benign applications are harmless applications. But if there is a such benign application which downloads code during runtime for updating there frameworks, etc. Hackers can inject there code instead of code the benign applications want which can cause problems.

How Code is loaded

Let’s discuss the ways code is loaded in the application:

Code Injection
Code Injection

Class loaders

In this case, the particular class the app wants is loaded. The hacker can change the code of particular class which can cause malware in the system.

Package Contexts

When android loads an application, it associates it with a context object. Which gives access to application resources. Android has an API named as createPackageContext, which gives access to apps to communicate with other apps’ resources. Which also gives access to load classes( class loaders). if both the flags CONTEXT INCLUDE CODE and CONTEXT IGNORE SECURITY are specified in the call to createPackageContext, the system does not verify the developer who has created it just runs the malicious code. Package context usually works through their package names. If an attacker injects its app with the same package name as another app is communicating with, an attacker can get access to the system easily.

Native code

A great advantage for attackers is that at the native level, android deals with native code as data, not code. Thus when an app wants to load the native code of another application, it can cause problems for that app.

Runtime.exec

Java Class Runtime offers a method exec. It is a function runs at binary level. Application don’t check where binary came from so it can cause problems.

Legit reasons for Loading external Code

testing
testing

A/B testing and Beta Testing

Basically when App is in it’s testing phase the changes it need is very volatile. Thus it requires to load external code when changes something or fixes a bug.

Common Frameworks

Some applications need frameworks to run. Thus when a common framework is updated the app wants to load its code to run.

Add-ons

Some applications can be extended by add-ons that are installed as separate applications. Examples are an SMS application that loads design themes and a game that loads additional levels. When identifying and loading add-ons, applications have to ensure that the external code they execute is indeed part of a valid add-on. We found that such checks

Common Problems

Insecure Downloads

Some external code was loaded through HTTP instead of HTTPS thus, HTTP is not secured and can cause problems.

Unprotected Storage

The file location is chosen in such a way that it gives the file write access. Thus attackers can gain access to the data.

Improper use of package name

As discussed earlier the apps connect with each other through the package name. If package name is known to the attacker it can cause errors.

Automatic Detection

In University of Bonn, Germany, the researchers created a automation tool to detect the unsafe android apps. The tool was static-analysis tool for detection of code loading behaviour. Working of tool:

Limitations

  • Write an interpreter app and run the code
  • an application would just receive class and method names as strings and invoke the corresponding methods via reflection. For such an application, the detection approach outlined above would not work, because it would not contain any suspicious API calls.

Conclusion

The Above post is written based on attached research paper.

We do not intend to infringe any intellectual rights artist rights or copyright. If you feel any of the content posted here is under your ownership just contact us and we will remove that content immediately.

READ MORE

Network Security related posts Visit HERE

Python-related posts Visit HERE

Data Structures related posts visit HERE

C/C++ related posts Visit HERE

Databases related posts Visit HERE

Algorithms related posts visit HERE

Data Science related posts visit HERE

Share the Knowledge

Leave a Comment