Android Application Security Sucks! Here’s what to do about it

Prologue: The following post was written and published by Checkmarx (link) on their website as part of a collaboration between AppSec Labs and Checkmarx. Originally published on May 26th, 2015 by Amit Ashbel.

 

Android…. It is no longer just a mobile phone.

Nowadays Android applications are running anywhere and everywhere. Home Appliances, watches, TVs, car applications and with the Internet of Things kicking in quickly, Android applications will probably become even more prevalent in our lives.

android_dudeAndroid is based on a customized Linux OS version. The main differentiation from the classic PC Linux is that the Android OS was adapted to define every Application on the device as a separate User or entity.

Each Application runs on its own Virtual environment within the  OS called a “Dalvik Machine (DVM)”*. Application code written in Java is modified to Java Byte Code and then converted to DEX (Dalvik byte code). The DVM will generate, on the fly, machine specific instructions to the ARM CPU (or other CPU in use). All Android applications are packaged as an APK (Android Application Package). The APK is a type of archived file which contains everything the android device needs in order to execute the application downloaded via the Google Play store or an alternate source.

*Dalvik is being shifted aside (Android L). Newer Android OS versions are using ART (Android Runtime) however the general idea stays the same.


As Android runs on Linux it is just natural that it will be using the Linux security mechanisms which have earned good reputation over the years.

Security wise, logically and physically separating each App allows processes and files to be protected from tampering and modification. Each App runs in its own Virtual Environment and does not (or rather should not) look into other app data or processes unless specifically allowed. This method of separation provides good basic protection even when developers are careless.

And additional security measure taken by Android is to ensure that APKs are signed. This will not allow the simple user to identify malicious behavior however will allow App integrity validation.

Most applications are installed from the formal Google Play Application store. Google do take a few basic measures to validate app integrity and security (See: Bouncer service) however there have been and will be some malicious developers who upload a malicious app to the store. These are usually detected by Google after a few or more than a  few infections have been reported. At that point Google will remove the App from the Store however by that time the App has found its way onto devices and other alternative stores. Note: Android phones do have a setting that disables downloads from sources other than google play however this can easily be disabled.

Screenshot_2015-05-26-11-41-28

So it seems that Google have taken significant steps to ensure the User’s security.

Where is the problem? What are we worried about?

Mobile Application Threats Compared to Web Application Threats

Mobile Apps threat model is different and cannot be compared to other Apps such as web apps. Although the server functionality might be very similar between Web and Android Apps, when analyzing the threat model for Android Applications there is an extra major piece to be considered. Client side security concerns.

The attack surface on Android Mobile devices or any mobile device includes a combination of server and client side security concerns. Therefore there are more problems to worry about compared to an equivalent web app.

When performing Penetration tests on regular applications (Non Mobile), testers will issue request to the server side in an attempt to manipulate requests. This does not suffice for Mobile applications. There are additional considerations to keep in mind on the client side such as reverse engineering which is a key requirement when testing Mobile Apps. The Pen tester’s skill set requirements are different.

Tools to analyze Android application security are becoming more available however they are not yet as mature as the ones available for web apps.

 

Malicious-user attack techniques

Reversing an App

Once a malicious user/hacker wants to analyze an application in order to identify vulnerability and plan an attack they will start by downloading the application on their own device. On a rooted device, the hacker can actually analyze the app very thoroughly and identify vulnerabilities within the code. In most cases, a vulnerability detected on a specific app will be exploitable on any other device running that same application.

Application Data Theft

Application data theft can be performed using standard Server side attacks which have been used for years on web applications. These can include request manipulation, DoS, SQL injections and others.

Have you ever lost a Personal Computer?

Most of us have probably experienced losing or having a mobile device stolen. If the wrong person puts their hands on your device, all data stored on the device itself and probably additional data stored on application server side or cloud is accessible. GAME OVER!

Malicious apps attack techniques:

Apps aren’t always as they seem

There have been multiple occasions of Application Phishing. The technique is actually quite simple. An App masquerading as a different App is published for download. Once it’s downloaded to user’s devices it can perform a variety of attack techniques:

  1. Capture any data the user enters. For example Masquerading as a banking App could easily get you the user’s real username and password to the online bank account.
  2. Communicate with other Apps to collect data. If incorrectly controlled, Android applications can quite easily giveaway information they did not intend to.

Android Mobile Application common vulnerabilities to look out for

This section discusses the most common vulnerabilities found on Android Mobile Applications however there are many more to be covered when developing or analyzing an application.

  1. Bad file permissions
    Developers can mistakenly poke holes in the OS built in security known as the sandbox. Such holes might allow file unwanted access.

    1. File creation – Make sure that you don’t allow other apps to read your files by ensuring the permissions are correctly set
    2. File Storage – If you are planning on using the device’s SD card to store data you have to make sure the data is properly encrypted. The OS sandbox does not cover the SD card and therefore all applications can access the data it stores.
  2. Sensitive client data storage (PII) – Addresses, emails, CC numbers and other IDs are used frequently for registration, authentication and for other legitimate purposes. Mobile Devices tend to get lost, forgotten or even stolen. PII data always has to be protected to avoid exposing personal data which can lead to privacy invasion or even identity theft. Do not include PII clear data within Log files, XML files, App manifest, SQL DB or even cloud.
  3. Usage of bad cryptography – Developers understand that data needs to be protected however not always is the encryption methodology used strong enough. Don’t create your own cryptography. Create separate keys per users, store keys securely and use the most up to date encryption techniques. Bad encryption is like having no encryption at all and provides a false sense of security!
  4. Bad transport level security – TLS and SSL usage is a must to secure all communication channels. SSL provides encryption to the transport layer to prevent communication sniffing and when using SSL we are authenticating the server side with the certificate to ensure we are talking with the correct server and not a fake/malicious one (Malware Command and Control servers). Developers sometimes disable certificate validation code by mistake. This means that server authentication is not present which will allow MITM (Man in the middle) attacks. MITM attacks perform interception of data and can then decrypt and re-encrypt the data allowing the criminals to read your most secret or sensitive communication. A good approach to prevent that would be SSL Pinning. This means that app will only accept a single certificate CA which is pre-defined.
  5. Weak server side controls –Regular webserver attacks such as SQL injection, CSRF etc. are no different when it comes to mobile applications. Validate you are not exposing any vulnerabilities when building your code.
  6. Authentication – Many mobile applications use hardware device identifiers to authenticate users. These can be IMEI, MAC addresses or similar. While these identifiers are not modifiable on the hardware layer, they can quite easily be controlled or tampered with on the software layer. Use strong authentication techniques when required. Some examples are 2-Factor Authentication and out of band authentication.
  7. Insecure IPC (Inter Process Communication) – Android Mobile communication is possible by using internal communication mechanism and sending intents to each other. There are two types of intents. Explicit and implicit intents. Explicit intents are usually more secure as they specifically chose which application can trigger data collection a service on a different App. Implicit intents allow any App to trigger data collection services on the attacked Application. Using implicit intents is risky. Intents can be sent by an invalid caller i.e. a malicious app, which can be abused to cause your application to perform sensitive actions without your control, delegate permissions which it is not permitted to use such as collecting GPS coordinates, or trigger a DoS (Denial of Service) attack by calling exposed components which cause CPU intensive operations. These are just some basic examples however the range of possible abuse for implicit intents is much wider.
  8. Client side injection – Malicious Apps can inject queries or code to other applications on the device and modify values of the attacked App.
  9. Hard Coded secrets – Storing user IDs and sensitive information hardcoded
  10. Secure Log exposure – Application store information about the app in Logcat or general files stored on the device or server side. This files can contains session IDs and other sensitive information. The Logs and apps should be protected. Do not store sensitive information on your logs.

How can we Analyze an App?

  1. Static analysis security Testing (SAST) – Static Analysis analyzes source code. Integrating a Static Analysis solution within your SDLC enables streamlining of vulnerability detection and mitigation as part of the development offer. That way you avoid financial and reputational damage once vulnerability is detected or abused on your live Application.
  2. Dynamic Analysis security testing (DAST) – Run the app and observe the process activity. What APIs are called, observe file access and perform App debugging.

 

Checkout Appuse. Appuse is a full blown solution for Pen testers working with Android Apps.

The post data is also available as a presentation delivered by Appsec Labs at the following link: https://www.brighttalk.com/webcast/288/116551?autoclick=true1

appseclogocheckmarx

1 reply
  1. andrew
    andrew says:

    This was a very informative blog and I really enjoyed reading it. But I also have a few points regarding it to discuss with you.

    Android application development is a fast-growing field, and as such, there are many unscrupulous mobile app developers out there who would love to steal your data. The top security measures which you can apply are:

    1. Protecting data in transit
    2. Secure The Server
    3. Use HTTPS

    To read more, please visit: https://blog.alakmalak.com/top-security-measures-for-android-application-development/?UTM-andrew-july/

    Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply to andrew Cancel reply

Your email address will not be published. Required fields are marked *