What makes Android apps vulnerable to cyberattacks?

What makes Android apps vulnerable to cyberattacks?

July 30, 2020
Green Alert
Last Update posted on
February 3, 2024
Ensure your mobile applications are safe and sound.

Ensure the safety and integrity of your mobile applications with CloudSEK BeVigil Enterprise Mobile App Scanner module.

Schedule a Demo
Table of Contents
Author(s)
No items found.

 

An Android app is a software that runs on devices powered by the Android operating system. Android apps are commonly written in Java programming language and compiled to bytecode. These applications are basically Android Package Kits (APK files) that enable the distribution and installation of Android applications. This is similar to how .exe files are used in Windows OS. The second quarter of 2020 registered 2.96 million Android apps in total compared to 2.6 million in 2018 (on Google Play). And in 2018, high risk vulnerabilities were found in 43% Android applications.

An APK file contains the following components:

  • AndroidManifest.xml: which inturn contains details such as the name of the package, description of access rights, as well as that of the API components.
  • res /: A folder that contains app resources, which does not include precompiled application resources.
  • classes.dex: Application code compiled in dex format that are executable by Dalvik virtual machine. 
  • META-INF/: A folder that contains the hashes and signatures of all files. 

 

Application sandboxing

Unlike Windows, Android runs each of its applications in a sandbox environment. Application sandboxing or containerization limits the environment in which a code can be executed. It intends to protect the app from interacting with external malicious elements. 

The Android operating system is based on the Linux system which uses the Linux kernel. But unlike the Linux system, each Android application is assigned a unique user ID. The system then sets permissions for a particular user ID, permitting that app alone to access certain features. 

Typically, all Android apps have to request permission to access sensitive data such as contacts, SMSs, and cameras . All these system features are restricted with the help of the Permissions API. The application is permitted to access system features only if the user grants access. 

 

Applications and processes

Although Android applications are written in Java, the class files that contain Java virtual machine instructions (Java bytecode) are converted to Dalvik executable files (.dex files) that contain Dalvik bytecodes, before they are installed.

The kernel that is used by Android OS manages the working of each application on the device, where Dalvik virtual machine runs independent processes or applications under different user IDs.

Android app Kernel

  

Sandbox escape

Web applications have universal links to interact with other applications, unlike Android apps. 

Android app-to-app communications are limited, however, it is achieved through the following methods:

 

  • Intents/ Deeplinks

 

An intent is used to request action from a different application component. It helps to coordinate the activities carried out by different applications. For example, selecting a photo from your gallery to set your WhatsApp display picture. 

Deeplinks are links that direct you to a specific destination from an application. 

Deeplinks is what makes it possible for users to share the link to a Medium article on Twitter. 

 

  • Binder IPC 

 

A Binder enables inter-process communication (IPC) within a kernel. It allows processes to manage shared data. Object Linking and Embedding (OLE) by Microsoft is an example of an IPC.

 

  • Content Providers

 

Content providers manage the access to the central repository of data. They provide data to external applications. For instance, content providers grant access to applications to use the contacts and SMSs on a device. 

Even though Android applications are typically sandboxed and isolated, limiting app-to-app communications, they can still be abused. 

 

What goes wrong?

App misconfiguration or the developer’s bad coding practices make Android applications vulnerable to cyber attacks. Listed below are the most common Android application security issues that developers and users come across.

 

Hardcoded credentials

Hardcoded credentials are basically plain text passwords, API keys, tokens, etc. in the source code. Although it is quite common for Android applications to integrate third party APIs, they may not necessarily be for client-side API calls. When such credentials are exposed in plain text, they form easy targets for password guessing exploits.  

Recently, CSC BHIM app suffered a data breach, exposing 70 lakh user records, due to an unsecured AWS database. Developers had allegedly coded AWS credentials into the app itself. In such cases, a static code analysis can debug the source code before the program is executed.  It exposes any vulnerability within the static source code. This process is also automatable. However, there can be too many false positives. 

 

Weak Cryptography

Broken cryptography in Android applications uses weak algorithms for encryption and decryption, or implements a strong algorithm in an insecure way. 

The widely used cryptographic hash function MD5 has been found to be vulnerable. Stream cipher RC4 is known for its simplicity and yet was discovered to have multiple vulnerabilities. 

Finding weaker/vulnerable cryptography could be automated through static analysis.

 

Using a static analyser in APK

Java decompilers decompile the Java bytecode into source Java code. Using such tools, we convert the APK to produce the source code. Even though they might not be the exact code the developer had written, the classes, methods, and the logic would be the same. This reveals hardcoded credentials or other flaws in the code that the developer may have used. 

Most common developer bad coding practice involves custom cryptography which can be broken quite easily.

 

HTTPS Issues

Transport security is needed when communicating with the server, this is enforced through HTTPS which uses Transport Layer Security (TLS) to encrypt the data. However, several developers inadvertly invalidate this protection. Several apps choose to trust any certificate given without verifying the trust chain. Such code makes through production when developers test the app in a local environment that may have self-signed certificates, they bypass SSL checks intentionally.

SSL verification could be disabled through code such as by establishing a non validating connection through a custom SSLSocketFactory will turn off all SSL validation.

These bypasses could easily be detected through static analysis.

 

WebView Issue 

WebView is a component powered by a browser engine that lets Android applications open web pages inside the application itself. As browsers are exposed to attacks through intents and deeplinks, it is not safe to open untrusted web pages within the application. 

For instance, a Twitter user found a WebView bug in ArogyaSetu, which exposed internal files on the local database. The WebView was callable by intent and any app installed on the phone was capable of loading the URL in the WebView. An attacker who has control over the WebView can decide what web page should be opened. If JavaScript is enabled, attackers can execute JavaScript code inside the app, to perform malicious activities. 

 

Insecure storage 

Creating files outside the Android sandbox allows users to view or alter the file content, and this could be a major security concern. Attackers exploit exposed sensitive data or app configuration data stored outside the app sandbox in a format that is readable and writable by any user. 

 

Component Misconfigurations

  • Exported services and activities: If your app has activities that are exported (meaning they can be called by other apps), and is a malicious app it can gain access to personal and sensitive data. But just because services and activities are exported, it does not mean that it poses security risks. Inspecting the code will also help detect the flaw. 
  • Misconfigured content providers: As mentioned earlier, content providers manage secure access to app data. Misconfigured content providers grant access to external applications without restrictions. 
  • Broadcast receivers: These are Android components that allow you to send and receive system or application events such as a battery low message. Scanning the source code can help you identify what the Broadcast Receiver is capable of or how it is triggered. Attackers can exploit this flaw and send unwanted messages without the users consent. 

 

Conclusion

Android core security features such as the application sandbox reduces security issues to a significant extent. But from the flaws discussed above, it should be noted that good coding practices also ensure the security of Android apps. Also:

  • Secure the communication between your app and other applications. 
  • Scan for vulnerabilities such as hardcoded credentials or weak cryptography.
  • Store sensitive information within the sandbox/ internal storage.
  • Request for credentials before providing access to the premium content within the app.
  • Use WebView carefully.
  • Scan for component misconfigurations.

Author

Predict Cyber threats against your organization

Related Posts
No items found.

Join 10,000+ subscribers

Keep up with the latest news about strains of Malware, Phishing Lures,
Indicators of Compromise, and Data Leaks.

Take action now

Secure your organisation with our Award winning Products

CloudSEK Platform is a no-code platform that powers our products with predictive threat analytic capabilities.

Emerging Threats

min read

What makes Android apps vulnerable to cyberattacks?

What makes Android apps vulnerable to cyberattacks?

Authors
Co-Authors
No items found.

 

An Android app is a software that runs on devices powered by the Android operating system. Android apps are commonly written in Java programming language and compiled to bytecode. These applications are basically Android Package Kits (APK files) that enable the distribution and installation of Android applications. This is similar to how .exe files are used in Windows OS. The second quarter of 2020 registered 2.96 million Android apps in total compared to 2.6 million in 2018 (on Google Play). And in 2018, high risk vulnerabilities were found in 43% Android applications.

An APK file contains the following components:

  • AndroidManifest.xml: which inturn contains details such as the name of the package, description of access rights, as well as that of the API components.
  • res /: A folder that contains app resources, which does not include precompiled application resources.
  • classes.dex: Application code compiled in dex format that are executable by Dalvik virtual machine. 
  • META-INF/: A folder that contains the hashes and signatures of all files. 

 

Application sandboxing

Unlike Windows, Android runs each of its applications in a sandbox environment. Application sandboxing or containerization limits the environment in which a code can be executed. It intends to protect the app from interacting with external malicious elements. 

The Android operating system is based on the Linux system which uses the Linux kernel. But unlike the Linux system, each Android application is assigned a unique user ID. The system then sets permissions for a particular user ID, permitting that app alone to access certain features. 

Typically, all Android apps have to request permission to access sensitive data such as contacts, SMSs, and cameras . All these system features are restricted with the help of the Permissions API. The application is permitted to access system features only if the user grants access. 

 

Applications and processes

Although Android applications are written in Java, the class files that contain Java virtual machine instructions (Java bytecode) are converted to Dalvik executable files (.dex files) that contain Dalvik bytecodes, before they are installed.

The kernel that is used by Android OS manages the working of each application on the device, where Dalvik virtual machine runs independent processes or applications under different user IDs.

Android app Kernel

  

Sandbox escape

Web applications have universal links to interact with other applications, unlike Android apps. 

Android app-to-app communications are limited, however, it is achieved through the following methods:

 

  • Intents/ Deeplinks

 

An intent is used to request action from a different application component. It helps to coordinate the activities carried out by different applications. For example, selecting a photo from your gallery to set your WhatsApp display picture. 

Deeplinks are links that direct you to a specific destination from an application. 

Deeplinks is what makes it possible for users to share the link to a Medium article on Twitter. 

 

  • Binder IPC 

 

A Binder enables inter-process communication (IPC) within a kernel. It allows processes to manage shared data. Object Linking and Embedding (OLE) by Microsoft is an example of an IPC.

 

  • Content Providers

 

Content providers manage the access to the central repository of data. They provide data to external applications. For instance, content providers grant access to applications to use the contacts and SMSs on a device. 

Even though Android applications are typically sandboxed and isolated, limiting app-to-app communications, they can still be abused. 

 

What goes wrong?

App misconfiguration or the developer’s bad coding practices make Android applications vulnerable to cyber attacks. Listed below are the most common Android application security issues that developers and users come across.

 

Hardcoded credentials

Hardcoded credentials are basically plain text passwords, API keys, tokens, etc. in the source code. Although it is quite common for Android applications to integrate third party APIs, they may not necessarily be for client-side API calls. When such credentials are exposed in plain text, they form easy targets for password guessing exploits.  

Recently, CSC BHIM app suffered a data breach, exposing 70 lakh user records, due to an unsecured AWS database. Developers had allegedly coded AWS credentials into the app itself. In such cases, a static code analysis can debug the source code before the program is executed.  It exposes any vulnerability within the static source code. This process is also automatable. However, there can be too many false positives. 

 

Weak Cryptography

Broken cryptography in Android applications uses weak algorithms for encryption and decryption, or implements a strong algorithm in an insecure way. 

The widely used cryptographic hash function MD5 has been found to be vulnerable. Stream cipher RC4 is known for its simplicity and yet was discovered to have multiple vulnerabilities. 

Finding weaker/vulnerable cryptography could be automated through static analysis.

 

Using a static analyser in APK

Java decompilers decompile the Java bytecode into source Java code. Using such tools, we convert the APK to produce the source code. Even though they might not be the exact code the developer had written, the classes, methods, and the logic would be the same. This reveals hardcoded credentials or other flaws in the code that the developer may have used. 

Most common developer bad coding practice involves custom cryptography which can be broken quite easily.

 

HTTPS Issues

Transport security is needed when communicating with the server, this is enforced through HTTPS which uses Transport Layer Security (TLS) to encrypt the data. However, several developers inadvertly invalidate this protection. Several apps choose to trust any certificate given without verifying the trust chain. Such code makes through production when developers test the app in a local environment that may have self-signed certificates, they bypass SSL checks intentionally.

SSL verification could be disabled through code such as by establishing a non validating connection through a custom SSLSocketFactory will turn off all SSL validation.

These bypasses could easily be detected through static analysis.

 

WebView Issue 

WebView is a component powered by a browser engine that lets Android applications open web pages inside the application itself. As browsers are exposed to attacks through intents and deeplinks, it is not safe to open untrusted web pages within the application. 

For instance, a Twitter user found a WebView bug in ArogyaSetu, which exposed internal files on the local database. The WebView was callable by intent and any app installed on the phone was capable of loading the URL in the WebView. An attacker who has control over the WebView can decide what web page should be opened. If JavaScript is enabled, attackers can execute JavaScript code inside the app, to perform malicious activities. 

 

Insecure storage 

Creating files outside the Android sandbox allows users to view or alter the file content, and this could be a major security concern. Attackers exploit exposed sensitive data or app configuration data stored outside the app sandbox in a format that is readable and writable by any user. 

 

Component Misconfigurations

  • Exported services and activities: If your app has activities that are exported (meaning they can be called by other apps), and is a malicious app it can gain access to personal and sensitive data. But just because services and activities are exported, it does not mean that it poses security risks. Inspecting the code will also help detect the flaw. 
  • Misconfigured content providers: As mentioned earlier, content providers manage secure access to app data. Misconfigured content providers grant access to external applications without restrictions. 
  • Broadcast receivers: These are Android components that allow you to send and receive system or application events such as a battery low message. Scanning the source code can help you identify what the Broadcast Receiver is capable of or how it is triggered. Attackers can exploit this flaw and send unwanted messages without the users consent. 

 

Conclusion

Android core security features such as the application sandbox reduces security issues to a significant extent. But from the flaws discussed above, it should be noted that good coding practices also ensure the security of Android apps. Also:

  • Secure the communication between your app and other applications. 
  • Scan for vulnerabilities such as hardcoded credentials or weak cryptography.
  • Store sensitive information within the sandbox/ internal storage.
  • Request for credentials before providing access to the premium content within the app.
  • Use WebView carefully.
  • Scan for component misconfigurations.