For more information, see: http://mobile.51cto.com/aprogram-382057.htm Android as an excellent open-source mobile platform, its application scope and attention has become greater and greater. Therefore, security issues have become the focus of the industry and users. How to correctly understand its security problems and adopt corresponding policies to enhance users' Security usage is a critical issue. This article will introduce general security issues of the Android platform, and provides corresponding security policies.
I. Root Cause of Android security issues BKJIA: researchers have found that popular Android software has common security traps and security vulnerabilities. There may be many causes for frequent vulnerabilities, there are mainly the following types:
- Compared with IOS, which is centrally managed, Android provides an open environment that provides flexibility and meets various customization requirements, while also compromising some security.
- The development team usually focuses on product design, function implementation, user experience, and systems, but seldom considers security issues.
- Android provides complicated security mechanisms. developers need to understand them and understand their attack ideas and methods to effectively protect the software.
- On the one hand, there are few large-scale targeted attacks against specific mobile software security vulnerabilities. Many people do not pay much attention to this attack before actual attacks emerge. On the other hand, it is not difficult to exploit these vulnerabilities to launch attacks, many attack methods and tools are mature. Once such attacks occur, users' personal privacy data may be leaked and account information may be collected. If they are combined with phishing attacks, it may even cause economic losses. The product team may face a crisis of trust and legal risks.
The following is a simple example of security-less phenomena, which are easily overlooked by our Android development team. 650) this. width = 650; "class = fit-image border =" 0 "alt =" "src =" http://images.51cto.com/files/uploadimg/20130227/1632530.jpg "Width =" 480 "height =" 360 "/> 2. Data Storage Security Issues: storage areas available for Android software are divided into external SD cards) and internal nand flash memory, apart from the differences in size and location, the two are also very different in terms of security permissions. Files in external storage are not managed with read/write permissions. All applications can create, read, modify, and delete any files in external storage at will, android applications only need to declare the READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permissions. In internal storage, each software is assigned a private region with basic Linux File Permission control. The owner ID of each file is a user ID set up by the software, other software has no permission to read or write these files. Possible problems with data storage include: privacy data is stored in external storage, for example, chat software or social software stores chat records, friend information, social information, and other information on the SD card. The backup software backs up communication records, text messages, and other information to the SD card, if the data is directly stored in plain text, including the text format, XML format, and SQLite database format, the software written by the attacker can read the data and upload it to the specified server, this vulnerability may cause leakage of privacy information. It is better to encrypt the data. The password is stored in the internal storage and is managed by the system or entered by the user. Store system data in external storage, for example, backup software and system support to back up user data to other SD cards for flash or recovery after upgrade; you can also cache some system data on the SD card for subsequent use. Similarly, the data is stored in plaintext, and malware can read them, which may be used for further attacks. Store the data that the software depends on during running on external storage if the software stores the configuration file on the SD card, then read the configuration files during running, and the data in the configuration files determines how to work, problems may also occur. Attackers can modify these configuration files to control the running of the software. For example, the list of servers used for logon is stored in the SD card. After modification, the logon connection is sent to the server specified by the attacker, which may cause account leakage or session hijacking (man-in-the-middle attack ). A safer way for this configuration file is to save it to internal storage. If it must be stored on the SD card, check whether it is tampered with before each use, compare with the hash value of the file pre-stored in the internal. The software installation package or binary code is stored in external storage. Many software users are recommended to download and install other software. After you click it, the APK file of another software is downloaded online, save it to the SD card and install it. Some software also chooses to dynamically load and execute binary code to achieve function expansion. For example, download the DEX file or JRA file that contains the extended function, save it to the SD card, and then use dalvik when the software is running. system. dexClassLoader class or java. lang. the ClassLoader class loads these files and then uses Java reflection to execute the code. If the software does not verify the integrity of the SD card files before installation or loading, and determines whether the files may be tampered or forged, security issues may occur. Here, attackers can use the re-packaging method. Currently, a large number of Android malicious code has adopted this technology. The basic principle of re-packaging is, decomassembles the APK file to obtain the smali syntax representation of the Dalivik command. Then, add, modify, delete, and modify the command sequence, and modify the Manifest file as appropriate. Finally, re-assemble these commands and package them into a new APK file, and re-sign them to install them on other mobile phones. Through re-packaging, attackers can add malicious code and change data or commands, however, the original functions and interfaces of the software are basically unaffected, making it hard for users to notice. If attackers repackage the APK files to be installed in the software or load DEX and JAR files, implant malicious code, or modify the code, and then replace the original files with the files on the SD card, or copy to the path to be executed or loaded. When the software does not verify the validity of these files, it will run the attacker's code attack. There are many possible results, such as sending fee deduction text messages directly, sending user-entered account passwords to the specified server, or popping up the phishing interface. Therefore, the software should verify its integrity before installing or loading any file on the SD card, and determine whether it is stored in the internal storage or downloaded from the server) whether the hash value is consistent. Global writable internal files if the developer uses the openFileOutPut (String name, int mode) method to create an internal file, set the second parameter to Context. MODE_WORLD_READABLE or Context. MODE_WORLD_WRITEABLE will make this file globally readable or writable. Developers do this to achieve data sharing between different software, but this problem is that they cannot control which software can read and write, so attackers can also have this permission for malware. If you want to implement a Content Provider component across applications, provide the data read/write interface and set a custom permission for the read/write operations. The internal sensitive file is read and written by the root permission software. If the attacker's software has obtained the root permission, the attacker can naturally read and write the internal files of other software at will, which is not uncommon. 1) a large number of third-party custom ROM provides root permission management tools, if the software constructed by attackers forge into some powerful tools. You can trick a user into granting it root permissions. 2) even if the mobile phone is pre-installed with the official system, most domestic users are willing to unlock it, that is, recovery and click the toot management tool. 3) There are some vulnerabilities in Android2.2 and 2.3 that can be used to obtain root permissions, and the exploitation of such vulnerabilities does not require user confirmation. 4) Therefore, we cannot assume that other software cannot obtain the root permission. Even internal data may still be read or modified. 5) As mentioned above, important, sensitive, and private data should be stored in internal storage, and the root user may still be read. My opinion on this issue is that, if an attacker attempts to obtain root permissions and the risks discovered by the user or the security software, then theoretically he has full control over the system, you can directly obtain contact information, text message records, and even account passwords, session creden。, and account data. For example, in the early days, Google Wallet stored users' credit card data in plain text. After attackers acquired the data, they could pretend to be a cardholder to perform further attacks to obtain the account's right to use the data. This type of data is "important data managed by other software ". 6) There is no common solution to this problem. Developers may need to find a solution based on the actual situation and make appropriate choices before availability and security.
This article from the "excellence begins with the foot" blog, please be sure to keep this source http://patterson.blog.51cto.com/1060257/1162020
