Mobile Application and Device Security

Published in

Trendyol Tech

9 min readJan 11, 2021

Hello, as Trendyol Security team, today we will talk about security measures that can be taken in mobile applications and mobile devices.

Mobile Apps and Security Perspective

Mobile applications allow an organization to reach more customers, which is positive for the organization, but from a security perspective, it can be interpreted as a possible attack vector or a new risk factor.

After web apps, mobile apps are one of the most popular applications for bounty hunters or malicious attackers.

Security Measures for Mobile Applications

The top 10 security risks of mobile applications shared by OWASP, the open source web application security project, are as follows.

1. Improper Platform Usage

One of the most important issues for mobile application developers is the “AndroidManifest.xml” file. In this file, the necessary permissions are requested for the application. The application developer needs to add the necessary permissions to the AndroidManifest.xml file to get them from the user. When the old versions of Android were analyzed, the “exported” property was returned as true. This deficit means that if the developer does not change the exported property, it remains active. To give a short example, imagine that you downloaded a storage application; if the developer did not change exported to false, your storage can be accessed.

2. Insecure Data Storage

If unencrypted data is stored in the phone, it can be easily accessed. If an attacker physically obtains the mobile device, the attacker can connect the mobile device to the computer and access the victim’s personally identifiable data or other sensitive information with various software. An attacker can also develop malware to obtain this information.

3. Insecure Communication

If the APIs used in the application do not use an encryption method during communication, an attacker monitoring the traffic can obtain communication data.

4. Insecure authentication

The authentication steps on applications need to be implemented correctly. Authentication is usually provided by username and password. This data can be accessed with an automated attack. For example, a 4-digit password can be captured with a bruteforce attack. In order to prevent this situation, measures such as using captcha, 2-factor authentication, special characters in the password, etc. can be taken.

5. Insufficient Cryptography

If the data used on the application is not encrypted with strong encryption methods, attackers can obtain user data or the code of the application. To avoid such an attack, the application must be encrypted with strong encryption methods.

6. Insecure Authorization

Authorization steps in applications are very critical. Authorization can be used to restrict which user can access which screens or edit which screens. For example, a lack of authorization can cause an attacker to see the targeted user’s profile page when he replaces his own profile ID sent to the application with the profile ID of the targeted user.

7. Client Code Quality

3rd party libraries used in the application should be analyzed before they are used. Even if there is no vulnerability in the code you write, the 3rd party libraries you use may contain vulnerabilities.

8. Code Tampering

If no security measures are in place for code tampering on the application, the attacker can directly modify the application code, dynamically change the memory content used by the application, change the APIs used, or modify application data and resources. To prevent this attack, a root/jailbreak check should be performed on the mobile device and the application should be coded in such a way that it can detect when code integrity is compromised.

9. Reverse Engineering

An attacker can access the source code of the application and obtain sensitive data in the source code by running the application in its own environment and analyzing it with the help of various tools. Obfuscation techniques can be used to protect against these attacks.

10. Extraneous Functionality

Developers can turn on functions such as debug mode to make their work easier in code development environments. When these functions are turned on in live environments, attackers can use them for malicious purposes. It is an important step to turn off these functions before applications go live.

Apart from these measures, one of the other security measures that can be taken is MTD (Mobile Threat Defense). MTD applications can be integrated into mobile devices or mobile applications. In this way, the security of mobile devices can be increased.

Mobile Threat Defense(MTD) Applications

When used on mobile devices, MTD applications can identify vulnerabilities in OS versions, system parameters, hardware and device configurations. It can also continuously scan the device for suspicious activity.

When used on mobile applications, the application grayware and malware detection.

When used on a network, it can also detect and stop man-in-the-middle (MiTM) attacks, monitor network traffic for suspicious activity, and detect invalid or spoofed certificates.

What are the Security Measures Taken by Google on Android Devices?

1. Location Restrictions

In versions prior to Android 10, you can choose whether or not apps that are installed by the user or come pre-installed on the device use device location tracking. In Android 10 and later, it is possible for apps to track location only when they are in use, so that apps cannot track the user’s location when not in use, but these apps can also ask the user if they need background location access and, depending on the answer, ask for the necessary permissions — if the user grants these permissions — the apps can also track location in the background.

2. Device monitoring protection

In Android 10, apps cannot access sensitive device information such as IMEI and serial number information. In addition, to prevent the transfer of sensitive device information to remote servers, when the device is connected to a Wi-Fi network, the MAC address of the device is automatically transmitted to the devices included in the network as a random MAC address.

3. Restricting applications’ access to external storage

Google restricts apps to access only their own folders. This means that an app cannot access other folders stored on the SD card. It also prevents apps from launching foreground activities.

4. Keystore

Keystore In Java, a keystore is a repository of security certificates, which are either authorization certificates or public key certificates.

Prior to Android 6.0, Android devices had a simple, hardware-supported cryptographic services API provided by versions 0.2 and 0.3 of the Keymaster Hardware Abstraction Layer (HAL). Keystore digital signing and verification operations enabled the generation and import of key pairs for asymmetric signing.

In Android 6.0, Keystore added the basics of symmetric encryption, AES and HMAC, and an access control system for hardware-backed keys. Access controls are specified during key creation and applied throughout the lifetime of the key. Keys can be used only after user authentication and only for specified purposes or with specified encryption parameters.

In addition to expanding the range of cryptographic primitives, Keystore in Android 6.0 adds the following:

Ensuring that key usage is restricted to reduce the risk of security compromise due to misuse of keys.
An access control scheme that allows keys to be restricted to specified users, clients and within a specified time interval

In Android 7.0, Keymaster 2 added support for key validation and version binding. Key validation provides public key certificates with a detailed description of the key and access controls to make the key’s presence and configuration on secure hardware remotely verifiable. Version binding binds keys to the operating system and patch version. This ensures that an attacker who detects a weakness in an older system version or TEE software cannot roll back a device to the vulnerable version and use keys generated with the new version.

In Android 8.0, Keymaster 3 switched from the old-style C-Architecture Hardware Abstraction Layer (HAL) to a C++ HAL interface generated from a definition in the new Hardware Interface Definition Language (HIDL). In addition to this interface overhaul, Android 8.0 extends Keymaster 2’s attestation feature to support ID authentication.

Updates in Android 9 include the following:

Keymaster 4 update
Embedded Secure Elements support
Support for secure key import
3DES encryption support
Changes in version binding

5. Trusted Execution Environment

The Trusted Execution Environment (TEE) is a secure area of the main processor. It guarantees the code and data loaded into it to be protected in terms of confidentiality and integrity. As an isolated execution environment, a TEE provides security features such as isolated execution, integrity of applications executing with the TEE, and confidentiality of its assets. In general terms, TEE offers an application domain that provides higher security than a rich operating system and more functionality than a secure element (SE). TEE is used in premium content protection/digital rights management, mobile financial services, authentication, secure modular programming, enterprise, government and cloud.

Mobile wallets, peer-to-peer payments, contactless payments or the use of a mobile device as a point-of-sale (POS) terminal often have well-defined security requirements. TEEs can often be used in combination with near field communication (NFC), secure elements and trusted backend systems to provide the security needed to enable financial transactions to take place.

In some scenarios, there is a need for interaction with the end-user, which may require the user to reveal sensitive information such as a PIN, password or biometric identifier to the mobile operating system to verify their identity. TEE provides a trusted user interface that can optionally be used to establish user authentication on a mobile device.

TEE helps protect the code and data loaded into it in a secure environment and only allows Trusted Applications to execute.

Apart from these security measures,

Restrict access to /proc/net file system
Restriction on non-resettable device identifiers
Limited access to dashboard data
Restricted access to camera details and metadata
Restriction to enable and disable Wi-Fi
Restrictions on direct access to configured Wi-Fi networks
Limited access to screen content

security measures have also been taken.

However, despite all these precautions, vulnerabilities can still occur. In the link below, you can see the Android versions, which version contains how many vulnerabilities, and you can visit the relevant link to see what these vulnerabilities are.

Vulnerabilities by Android Versions

https://www.cvedetails.com/version-list/1224/19997/1/Google-Android.html

What are the Security Measures Taken by Apple on IOS Devices?

1. Data Security

Apple devices have a processor that encrypts user data using the AES-256 encryption method. Data security at the file level is provided by encryption keys derived from strong passwords set by the user. At the same time, information such as the user’s account information, credit card information, etc. is stored on the device encrypted with Triple DES using the key specified by the user thanks to the keychain.

2. Application Security

Apple verifies the identity of developers before they join the Apple developer program. Apps available in the App Store are reviewed by Apple to ensure that they are free of important bugs, do not compromise user privacy, and comply with the rules. In-house apps must include a certificate signed by the Apple Enterprise Developer Program. iOS has built-in runtime protection and sandbox protections.

In the link below, you can see the iOS versions, which version contains how many vulnerabilities, and you can click on the relevant link to see what these vulnerabilities are.

Vulnerabilities by IOS Versions

https://www.cvedetails.com/version-list/49/15556/1/Apple-Iphone-Os.html

What Mobile Device Versions Should Be Supported?

With all this information in mind, supporting older android/iOS versions of a mobile application allows it to appeal to more users, but user information may be compromised due to vulnerabilities in older android/iOS versions that are no longer supported. Since unsupported versions will no longer be updated by manufacturers, the vulnerabilities on them will not be closed. For this reason, it would be correct from a security point of view not to support Android 6.0/iOS 10.3.3 and earlier versions whenever possible.