Android Application and system security Defense

Source: HTTP://WWW.CNBLOGS.COM/GOODHACKER/P/3864680.HTMLANDROID Application Security Defense

The security implications of Android apps include three areas: code security, data security, and component security.

1. Code Security

Code security mainly refers to the Android APK has been tampered with, piracy and other risks, the main reason for code security is that the APK is easy to decompile, re-packaging. We can protect the APK with the following methods:

1.1 Code obfuscation

Code obfuscation can increase the difficulty of the APK reverse analysis to some extent. The Android SDK has added Proguard code obfuscation from 2.3, and developers can easily confuse the code by simply configuring it.

1.2 APK Signature Check

Each software needs to be signed by the developer when it is published, and the key file that is used by the developer is unique to the developers, and it is often impossible for a cracker to have the same key file, so the APK can be protected using the signature checksum method. The Getpackageinfo () method of the Packagemanager class in the Android SDK allows for software signature detection.

1.3 Dex File Checksum

To recompile the APK is actually to recompile the Classes.dex file, after recompiling, the generated Classes.dex file hash value changed, so we can detect the installation after the Classes.dex file hash value to determine whether the APK has been re-packaged.

(1) Read the Classes.dex file in/data/app/xxx.apk in the application installation directory and compute its hash value, comparing that value to the Classes.dex hash value at the time of the software release to determine if the client has been tampered with.

(2) Read the application installation directory under/data/app/ The MANIFEST.MF file in the Meta-inf directory in xxx.apk, which details the hash value of all the files in the APK package, so that it can be read to get the hash value for the Classes.dex file, and compare that value to the Classes.dex hash when the software was published to determine Whether the client has been tampered with.

To prevent it from being cracked, the classes.dex hash at the time of the software release should be stored on the server side.

In addition, because the reverse C + + code is more difficult than the reverse Java code, so the key parts of the code should be written in native/C + +.

1.4 Reverse Tool confrontation

The most common tool for re-packaging apk is Apktool,apktool, which is processed in PNG format for files with the suffix png, and if we change the file suffix of a non-PNG format file to PNG, then use Apktool to re-package the error.

The above is the use of a number of several protection methods, single use one of the effect is not small, should be integrated use.

1.5 Debugger Detection

To prevent the apk from being dynamically debugged, you can detect if a debugger is connected. The isdebuggerconnected () method is provided in the application class to detect if there is a debugger connection, and you can exit the program directly if a debugger connection is found.

1.6 Shell Protection

Using the shell program to prevent the APK from reversing is a very effective way and a trend. Jack_jia in the article "Android APK Shell Technology" in detail the Android apk Shell principle and the implementation of several shell solutions. We can use these options to Shell apk.

However, the shell is implemented in the Java layer, and the risk of being deserialized is still very high. In order to overcome this shortcoming, we can study the following ideas to protect them in the future:

Put the core business logic code in an encrypted. jar or. apk file, and use the native C + + code to decrypt it when it needs to be called, while completing the integrity check of the decrypted file. If you need a more secure method of protection, consider adding a shell to the so file (the file compiled by the Native C + + code). Android so packers mainly need to solve two problems:

(1) Adding shells to elf files;

(2) The loading of Android so, call mechanism to do special processing.

This will be a direction for future Android application security research.

2. Data security

2.1 Storage Security Issues

Some of the issues that may arise with data storage include the following:

(1) storing sensitive data in plaintext, resulting in direct copying or tampering by the attacker.

• Keep private data clear in the external storage
• Save system data plaintext in external storage
• Save data that is dependent on the software runtime in an external storage
• Save Software installation package or binary code in external storage
• Globally writable internal file storage

(2) Improper storage of login credentials, causing attackers to use this data to steal network account privacy data.

Solution:

• The data is encrypted, stored in the internal storage, managed by the system, or entered by the user.
• The more secure way to apply a configuration file is to save to internal storage, and if it must be stored to an SD card, it should be checked for tampering before each use, compared to a pre-saved file hash value.
• Application if you need to install or load any file that is located on an SD card, you should verify its integrity and determine whether it is consistent with the hashes that are stored in the internal store (or downloaded from the server).
• If you want to share data across applications, there is a better way to implement a content Provider component that provides a read-write interface to the data and a custom permission set for read and write operations.
• For storage of login credentials, use a protocol based on credentials rather than a password to meet the needs of this resource for persistent access, such as OAuth.

2.2 Transport security issues

• Do not use encrypted transmissions

• Use encrypted transmission but ignore certificate validation links

This practice can lead to a man-in-the-middle attack if the developer does not check the validity of the server certificate in the code, or chooses to accept all certificates.

We should use SSL/TLS-based HTTPS for transmission of sensitive data. Since most mobile software only communicates with fixed servers, we can use a "certificate Lock" (certificate pinning) method to directly verify the server has a specific certificate in the code more precisely.

3. Component Security

The activity, Service, broadcast receiver and other components within the Android application are communicated through intent, Communication between components needs to be configured in the Androidmanifest.xml file, and inappropriate component configuration poses a risk.

Risks that may arise:

(1) Malicious invocation

(2) Malicious acceptance of data

(3) Phishing applications, e.g. (rogue phishing, boot login interface)

(4) maliciously send broadcast, start Application service.

(5) Calling the component to accept the data returned by the component

(6) Intercept ordered broadcasts

Workaround:

(1) Minimization of component exposure

Add the Android:exported= "false" property to a component that does not participate in cross-application calls, which indicates that it is private and that only the component of the same application or an application with the same user ID can start or bind the service.

(2) Set Component access rights

Set permissions on components that participate in cross-application calls or public broadcasts, services. Only components with this permission can call this component.

(3) Code inspection of exposed components

Android provides a variety of APIs to check, execute, Grant, and revoke permissions at run time. These APIs are part of the Android.content.Context class, which provides global information about the application environment.

In addition, there are many traditional web vulnerabilities for Android apps, such as SQL injection, XSS vulnerabilities, and code-level protection against these vulnerabilities in the same way as Web application defenses.

Android system security Defense 1. Operating system security issues

• Android Root Issue
• System vulnerability, patch update not timely
• Authentication mechanism Issues

2. System Security Solutions

2.1 Rights Management and isolation

Fine-grained management and isolation of permissions on applications running on Android systems to prevent unauthorized behavior and misuse of permissions to obtain sensitive data.

You can use Mac (Mandatory access control) to enforce access control model implementations. It is a security model for Linux security-enhanced system selinux, which means that any process that wants to do anything in the SELinux system must first give permission in the security policy configuration file. The process does not have permissions that do not appear in the security policy configuration file. Google officially launched a set of SELinux-based system security mechanisms seandroid on Android 4.4. So if we want to customize an Android system, we can use the Android 4.4 version with the seandroid security mechanism.

2.2 Kernel and Application Layer vulnerability protection

Add patch update function, if the vulnerability is found, prompt users to update the system patches.

2.3 Malicious program detection and protection

Set up a malicious code protection model to detect malicious programs running on Android systems against malicious code intrusion.

2.4 Secure storage and transfer of data:

Encryption and protection of data stored and transmitted on the Android system ensures that the data on the terminal can be used safely.

Android Application and system security Defense