Android App Secure Problem Part 1

Security is important for applications involving direct money transactions or personal privacy concerns. Android system due to its open source properties, the market for open-source custom ROM vary, in the system level security and vulnerability are not the same, Android application market app review relatively iOS is also relatively broad, Many vulnerabilities provide an opportunity. Some mainstream app on the market although some have done some security precautions, but because most of the app does not involve financial security, so the importance of security is not enough; and because security is a door system disciplines, most of the app layer developers lack security Technology accumulation, measures are relatively limited.

This article will focus on analysis of Android APP facing security issues, preventive measures and a series of security technology program implementation.

The security issues facing

virus

Android virus is a mobile phone Trojans, mainly malicious applications. Such as last year, CCTV exposure of a “bank ruthless” mobile phone banking Trojan, imitate the real mobile banking software, through phishing access to user input phone number, ID number, bank account number, password and other information, and these Information uploaded to the hacker specified server. Steal bank account password, the user account in the funds immediately transferred away. Some of the independent existence of mobile phone Trojans, while others are disguised as a picture file attached to the genuine App, hidden very strong, some viruses will appear variants, and more powerful generation than generation.
These viruses have some general characteristics:

  • Mother packet + malicious sub-packet operating mechanism.

  • Through technical means to prevent users through the normal way to uninstall.

  • To steal the user account funds for the purpose.

  • To SMS as a command channel.

  • Critical Information Disclosure

Although the java code to do the general confusion, but several major components of Android is dependent on the way to create the injection, it can not be confused, and some commonly used anti-compiler tools such as apktool can be effortless to restore java in the clear text information , Native library information can also be obtained through objdump or IDA. So once java or native code in the existence of expressly sensitive information, basically there is no security in terms of.

APP re-packaged

That is, decompile and re-join the malicious code logic, a new package APK file. The purpose of re-packaging are generally mentioned above and the virus, the genuine apk to unpack, insert the malicious virus re-packaged and released, so a strong camouflage. Intercepted app re-packaged to a certain extent to prevent the spread of the virus.

Process was hijacked

This is almost the most targeted attack a way, usually through the process of injection or debugging process to hook the process to change the logic and order of running the program to obtain the memory information to run the program, that is, all the user behavior Was monitored, this is the most commonly used account password theft a way. Of course, hook behavior is not necessarily entirely malicious, such as some security software will use the hook function to do proactive defense (such as LBE and our mobile security laboratory latest apkprotect online reinforcement products). In general, hook need to get root privileges or the same process with the hook authority, so if your phone is not root, but is genuine apk, was injected is still very difficult.

Data is hijacked during transmission

The most common hijacking in the transmission process is a man-in-the-middle attack. Many of the more secure applications require that all business requests go through https, but the middleman attack on https is getting more and more, and we find that in practice, certificate exchange and authentication are in some cottage phones or non-mainstream ROMs There are some problems, so that the use of https encounter obstacles.

Keyboard input security risks

Payment password is generally entered through the keyboard, keyboard input directly affects the security of the security of the password. The security risks of the keyboard come from three aspects:

The use of third-party input method, all the click events are technically can be trilateral input method interception, if you are not careful to use some illegal input method, or input method to upload information and leaked, the consequences are unimaginable.

Screenshot, the method requires mobile phone with root privileges to run screenshots software

Getevent, by reading the system driver layer dev / input / event1 in the information to obtain the location of the phone touch screen coordinates, combined with the keyboard layout, you can figure out the incident with the specific number of mapping, which is currently more commonly used attacks the way.

Before doing a set of security keyboard program, that is, custom keyboard + digital layout randomization. But the randomization of the keyboard is very inconsistent with the operating habits of human nature. So after the random words have also been removed.

Also need to explain, there is a more secure way is now trustzone standard has GlobalPlatform_Trusted_User_Inteface, that is to say in the trustzone security interface in a set of standards, if the security keyboard in the trustzone in the pop-up, the hacker regardless of the means through the Sha Can not get the password, is the most secure way, but trustzone depends on the underlying equipment to achieve, if the device does not support trustzone, or trustzone does not support GlobalPlatform_Trusted_User_Inteface standard, we can not do anything. *

Webview vulnerability

As the prevalence of hybrid app now, Webview in the use of the app is more and more, Android system Webview there are some loopholes, resulting in js right to mention. The most famous is the legendary js injection vulnerabilities and webkit xss vulnerabilities, the following section we will detail.

The server did not deal with, was infiltration attacks

This is the most anti-replay attacks and injection attacks, this is not discussed in the context of this article.
Android APP security architecture

Familiarity with Https

In essence, https is a two-way authentication process, but because too many Android devices too messy, Android device certificate is not uniform, generally only client authentication server-side certificate, and the server-side in the https layer will not verify the customer End certificate, so the actual application scenario is a one-way authentication process.
SchemeRegistry.register (new Scheme ( “https”, SSLSocketFactory.getSocketFactory (), 443));

This is the use of google API to https for verification, the main check four aspects:

  • Whether the signature CA is legal

  • Domain names match

  • Is not a self-signed certificate

  • Whether the certificate has expired

If the root certificate used by the server is self-signed or if the signing authority is not in the list of trusted certificates for the appliance, then http connections using httpclient will fail. There are several ways to solve this problem:

The simplest approach is that httpclient does not open certificate validation, trust all the way the certificate. This approach is relatively simple, but the security is equivalent to http as bad, hackers can easily falsify the certificate for man-in-the-middle attacks, resulting in user transaction data and other sensitive information disclosure. Now most of the mobile browser in order to be compatible with the various certificates of the site is to take such a way, but also some mainstream browsers on the non-root certificate, only check the host and validity, if failed, to the user prompts, but also Can continue to browse or interrupt the prompt to ensure that the user experience at the same time to enhance security.

Using the default certificate covering google checking mechanism (X509TrustManager) way, before initiating https connections the server certificate is added to the list of trusted certificates httpclient, this is relatively complex, error-prone, and since each site The definition of certificates are not the same, it is difficult to find a unified approach to all non-root certificate for certificate inspection.

Payment Password Security

Payment password is only a representative of the data, it is actually representative of the client some sensitive data, such as bank card number, mobile phone number, password, cvv, expiration date. Especially against strong passwords and cvv such sensitive data, in order to improve the performance of applications and to prevent others from cracking.

We use RSA and AES encryption of these two sets of encryption methods, as shown below:

Anti-debug module

Debugging refers to the current app by other programs using a specific method (debugger, ptrace, etc.) tracking hijacking, after debugging all the behavior of the app can be viewed and modified by other programs, we can think of the next usually through gdb debugger. Anti-debugging function in two steps: first test whether the current app is being debugged. If the app is being debugged, it returns the process name of the process the debugger is in. If the app is not debugged, protecting the app is no longer debugged by other programs. There are two ways to protect the app from being debugged: - One is the debug option in the kernel that has a debugger turned off, but we can not change the kernel state as an app. - The other is a dual process anti-debugging. We know that a process allows only one debugger, so in the process up at the same time, will fork a daemon (daemon), and ptrace protected app process, the daemon will intercept the debugger entry to ensure that other programs can not debug The current app. Once the daemon is activated, it will remain until the current application exits, if the forced shutdown of the daemon, the current App will be closed. Here we should pay attention to signal processing.

Anti-injection module

Injection is the current App process by other programs using specific methods (ptrace, dlopen, etc.) into the module does not belong to the current App. In general, the injection is not an end, just means, so after the injection module generally has a special behavior, such as the collection of App’s privacy data, the use of methods such as Hook hijack App normal operation process. Which Hook is the most important security risks. From the technical means, the premise is the need to debug the injection. So if the current App has been protected for not being debugged, then theoretically there is no risk of being injected. However, if the anti-debug module is activated later, then before the activation, App still there is the possibility of being injected. Anti-injection function is to detect the current App which modules are injected and hijacked (Hook) the. Android Hook and Hook methods are divided into two categories: Java Hook and So Hook. Java Hook which is divided into static members Hook and function hook, you can check the vm dex memory fields and method field to determine whether there are java injection. So Hook is all linux system hook mode, divided into GOT Hook, Symbol Hook and Inline Hook. Inline Hook is generally compiled by way of injection, Symbol Hook is generally used LD_PRELOAD way to the function plus hook, the two injection are currently Not to prevent, the main anti-or GOT hook. I have been in a number of years ago through the GOT hook principle in the brush machine, no root privileges in the system implanted su program, the system to force a root. GOT Hook principle is simply to say that through cat / proc / pid / maps get the app process so the load address, and then through the analysis of the GOT table so that the offset function of each address, calculate the function of the absolute address of the entrance, And then replace the address function with the injection function. So anti-native injection method is: through the app process space, see the loaded library is not in / system or / data / data / app under, if not, then there must be injected.

Anti-tampering module

App is the traditional method to determine whether piracy, the industry’s usual practice is to collect a large number of genuine application of the information prior to do white list, and then use the current App’s package name, signature and other information to do matching. The accuracy of this method depends on the size of the white list library and requires network connectivity. Anti-tampering based on re-packaged App and genuine App’s dex arrangement features to determine whether the App is repackaged, fast, high accuracy.

Android security programming

For some Android-specific syntax and design, there is also the risk of being attacked, we usually code will be released before the security scan, security scanning sweep surface is the most important point of the following: - Security log this information is relatively simple, and does not allow Print sensitive data, and then must be closed before printing the print log switch. - Intent information disclosure in order to start another one application of Activity, we often use some implicit Intent, if it contains sensitive information, so long as the third-party app to register the same Intent Filter, it is possible to intercept sensitive information, so To send an implicit Intent, you must specify the receiver and permission.
Security of security components

Android includes four components: Activitie, Service, Content Provider, Broadband Receiver, each of them can be opened outside of Intent implicit way, so long as these components are not open to the public must be indicated in the manifest inside exported to false, prohibit other Program access to our components, and external components to be interactive, you should add some access control, but also need to pass on the data for safe verification.
IPC null reference

This occurred mainly in the opening assembly, since the opening of the component can receive Intent, which will generally contain some data when we do not judge these data when empty, app usually crash, an attacker might send data is empty Intent to attack.

WebView vulnerability attack and defense

Js injection vulnerability

The problem was first documented in a paper called “Attacks on WebView in the Android System” in 2011 [http://www.cis.syr.edu/~wedu/Research/paper/webview_acsac2011.pdf] (http://www.cis.syr.edu/~wedu/Research/paper/webview_acsac2011.pdf), this article points to the way addJavascriptInterface in the function of some of the risks, such as your app to achieve a read and write files Class, and then use the addJavascriptInterface interface allows js call, then it may lead to an attacker to directly call the class to read and write files to achieve the operation. This approach is the most primitive risk and does not directly point to the use of the getClass () method. Later, Baidu security group in 2013, the official release of the loopholes in the high-risk work order: http://security.baidu.com/risk/findNewsDetail.do; jsessionid = B09405787822801D67251543B2B8C5CB.security_client-web01? Id = 336. This vulnerability is mainly through the getClass () method directly call java. Lang. Runtime interface to execute system commands, so that any js has the same app operating authority!

The solution is mainly two:

For Android 4.2 and above, Google has fixed the vulnerability, only native
Interface add @ addJavaInterface label can be.
For Android4.2 previous version, you need to rewrite addJavaInterface, js calls and native calls to achieve their mapping. This is a classic cordova design, it is worth learning about.

WebView phishing vulnerability

Fishing this thing has been the most commonly used security sector attacks, but also the most difficult to solve a class of technical problems, and fishing means is strange to prevent fishing in addition to allowing users to improve security awareness, do not click on the link from unknown sources, The technical level can do the following two points: - Check WebView to load the target URL if there is phishing and other security risks - on the webview closed scripting environment
WebView cross-domain vulnerability

Mainly due to the JS XmlHttpRequest can read the local file to read to the app data database directory webviewCookiesChromium.db, the db is usually the system where the cookie is stored, the equivalent of disguised to read the cookie opened the permissions, the specific can For Android 4.1 and above, this does not exist in the cross-domain vulnerabilities, there is no targeted modification. [/ B] [/ color] [/ url] For all versions setAllowFileAccess (false), prohibit the page from the local html load.
other

Weak encryption: a lot of Android application encryption storage methods are relatively simple, just a simple md5, it is easy to be cracked.

Signature verification direction: Each apk will have a signature, the signature only the developer has, if someone else changes the code, it must be signed to run, but the modified signature and the official signature is inconsistent, so we inside Stored application of the official signature of the hashcode value, after the application starts so will check the signature is not the official signature, if not, the application directly closed, so inside the encryption function also does not work.

reference articles: