Shulou(Shulou.com)05/31 Report--

Today I will show you how to analyze APK security and automation audit. The content of the article is good. Now I would like to share it with you. Friends who feel in need can understand it. I hope it will be helpful to you. Let's read it along with the editor's ideas.

1. Small talk

When it comes to mobile security, we may be relatively unfamiliar, because the research in this area is only gradually popular in recent years. So what is mobile security? First of all, we know that mobile security is nothing more than some security issues on the ios platform and Android platform, including some problems in the platform system itself and at the application level. Of course, some communication protocols need to be involved in the interaction between the client and the server, mainly http and https protocols, as well as some other protocols, such as websocket and so on. We do not pay too much attention to the shortcomings of these protocols. We need to pay attention to whether data packets are encrypted in the process of transmission, whether the server controls the user's operation rights, whether there are defects in some business logic processing of the server, and so on. The idea in this aspect is basically similar to that of web penetration, but there are also some differences.

Second, Trojan horse attack

When it comes to mobile security, of course, there are virus and Trojan attacks, common remote control Trojans such as droidjack, SpyNote and so on, as well as lock software springing up some time ago.

Figure 1Droidjack

Fig. 2 locking software

Attackers can use software like Droidjack to generate Trojans, which are malicious Trojans that generally exist in some third-rate apk markets. Generally speaking, attackers will put some seductive information in these apk, such as watching so-and-so beauty video for free, ad-free video client, so-and-so Shuangtu browser, and so on. After the attacker publishes these apk with seductive information to the network, he will set up a server program on the remote server. once the user installs and runs the malicious program, the hacker can manipulate the user's mobile phone on the remote server, monitor the user's behavior, and then steal the user's privacy information.

In the final analysis, these Trojan attacks are mainly due to the weak security awareness of users, so they are not the main object of discussion. We mainly discuss the security of Android at the application level.

Third, App server vulnerability mining

So how do we dig app vulnerabilities? First of all, for security workers who move from web security to mobile vulnerability mining, they certainly want to dig loopholes that are similar to their own field, and the server of app is basically similar to that of web security, except that the client of web program is more browser, while mobile applications generally have an app program that can be installed on mobile devices. Therefore, for the mining of app server vulnerabilities, we can still rely on previous web experience to mine some vulnerabilities such as xss,ssrf,sql injection, arbitrary file reading and so on.

When mining vulnerabilities in web applications, we can capture and analyze our web applications by configuring agents in the browser, so how should we analyze data packets in mobile applications?

In fact, the packet analysis of Android applications is also based on proxies, but the configuration of proxies is relatively complicated. After we configure the corresponding proxies in burptsuit or fiddler, we can use them for packet interception and replay. The specific steps will not be described in detail here. There are tutorials on the Internet, which you can consult by yourself.

Here, I will not say more about some classic loopholes such as xss,sql injection, and there is nothing to say. Here, I will mainly talk about the ultra vires vulnerabilities of mobile applications. We know that in web security, ultra vires vulnerabilities are generally caused by the fact that the server does not verify the user's request and only relies on the user id to execute the user's request. So what kind of process is the correct authentication method? It is briefly described in words: after the user has successfully logged in and authenticated, the server will write the identity user rights into cookie and then return to the browser. The browser retains the cookie; user to bring the cookie in the subsequent request packet, and the server verifies the cookie in the packet, so as to identify the user rights and perform the corresponding permission operations.

Figure 3 cookie authentication process

Of course, another authentication method is session authentication. Both Session authentication and cookie authentication can authenticate the identity of a user, so what is the difference between Session authentication and cookie authentication?

Simply put, cookie is stored on the client side, while session is stored on the server side. From a security point of view, cookie is relatively insecure, while session is relatively secure, because the cookie is stored on the client side, and the attacker can obtain the cookie on the client side. If the fields used to identify the user are not encrypted and are easily enumerated, then the attacker can forge the cookie and then exceed its authority. If session authentication is enabled, the client only gets the id of the corresponding session after successful login. This id is an encrypted string that cannot be traversed.

So what is its authentication process like? First of all, we need to know that session authentication also depends on cookie. After the user has successfully logged in, the server will write the corresponding session of the user into the database of the server. The session contains some information such as the user's identity, and then the server will send the id corresponding to the session to the client, so the content of the cookie in the client usually only has a string such as sessionid=xxxxxx. The user needs to wear this sessionid in the subsequent request. The server identifies the sessionid, then queries the database, obtains the corresponding user permission information, and then determines whether the user has the authority to perform the response operation.

Obviously, the session mechanism is relatively secure, but the other side of security also comes at a price. Compared with cookie, session mechanism will consume more server performance.

Figure 4 Session authentication process

However, on the mobile side, user authentication is not based on cookie, but based on token. So what kind of authentication is it? In brief words, its authentication process usually goes like this. After the client login verification is successful, the server will return a token string, which is the user's session credential. The user must bring this token to interact with the server later, so that the user can identify the user.

Figure 5 Token authentication process

If we analyze a packet and find that there is a request without token, then the packet is likely to have ultra vires loopholes. Of course, we have to analyze it in combination with specific scenarios to determine whether it has an impact on business logic. This is our general posture of digging ultra vires holes on the mobile side. However, this posture is too retarded, there is no threshold, basically anyone can dig.

In view of the ultra vires loophole, there is also a mining posture, which feels strange. The root cause of this ultra vires loophole is the failure of the authentication strategy itself. I remember that a long time ago, I analyzed the protocol of an LVB software and found that the authentication logic was as follows: after the user logged in and verified, the server returned the user id, and then the local production user token. In the subsequent request, take this token as the user's identity certificate. This obviously has bug, because the user id can be traversed, and the token generation algorithm is local, so as long as the attacker gets the id of other users and scratches out the local token generation algorithm, he can calculate the token himself, and then fake the user login.

Of course, the mining of this kind of ultra vires loophole is still relatively difficult, which requires that the loophole excavator has a relatively deep reverse analysis ability and coding ability. However, as a developer, we must not relax the reinforcement of application security because of this difficulty, especially the very important functional module of user authentication, we must do a good job in security protection.

Fourth, Apk client vulnerability mining 1. Introduction of common tools

As for the vulnerability of the client, it mainly decompiles the app client through decompilation tools to obtain the source code, and then combines some experience and security knowledge to conduct static source code audit. Common anti-translators include apkide,jeb,apktools and so on. Let's take a picture and learn about it:

Fig. 6 the reason for the change

Figure 7 Jeb

Of course, my favorite is the android reverse assistant, which is very practical.

Figure 8android reverse Assistant

Combined with the use of jeb, it can basically meet the daily reverse analysis.

Android application platform is mainly divided into native layer and java layer. For Java layer, we can use the above tools for analysis, while for native layer, we need to use ida for analysis. Ida is a very easy to use disassembly tool, we can disassemble the so file of apk through ida, and then use its f5 function to transform the arm assembly code into C++ pseudocode and analyze the logic algorithm. It also supports dynamic debugging and can debug apk applications remotely. We can use ida dynamic debugging, bypass to drop some checks in the so layer, such as secondary packaging check, or dynamic debugging and shelling.

2. Brief introduction of shelling application

When it comes to application shelling, it is necessary in the process of apk analysis. Before we talk about shelling, let's take a look at what shelling is. To shell is to give priority to the control of the program before the application runs, and then hand over the control of the program to the original program. The shell implementation on the Android platform is to encrypt and hide the original dex file, and then get the original dex file through the shell program and restore it back; another is to extract the function instruction and, at run time, load the instruction back through the corresponding class load function of hook.

For the application after the shell, the logic of the original program has changed beyond recognition, and we can not carry out security analysis through the program after the shell. Therefore, we need to shell the application. Common automatic shelling tools are drizzledump and dexhunter. Dexhunter is easy to use, but it needs to be brushed, and many encryption vendors have checked it, so it doesn't work to use it directly, so it needs to be modified and tested by bypass. As for the detailed usage, you can look for tutorials on the Internet, so I won't repeat them here. If the tool doesn't work, you'll end up on ida.

3. Static source code audit

Let's take a closer look at the issues that need to be paid attention to in security detection at the source code level.

Component security

First of all, there are security issues in terms of components. We know that Android applications have four major components: activity,service,content provider,broadcast receiver. If these components are not necessary, their export property, exported, should be set to false, that is, export should be prohibited. If it is set to true, it will be called by external applications, which may cause vulnerabilities such as information disclosure and permission bypass. In addition, if you don't do try when using Intent.getXXXExtra () to get or process data. If catch handles exceptions, a denial of service vulnerability may occur, including, but not limited to, null pointer exceptions, type conversion exceptions, array out-of-bounds access exceptions, class undefined exceptions, and serialization and deserialization exceptions.

Like the component security mentioned above, we usually judge the security by analyzing the androidManifest.xml files of Android. AndroidManifest.xml is the entry file for Android applications, which describes the components exposed in package (activities, services, etc.), their respective implementation classes, various data that can be processed and startup locations. In addition to declaring Activities, ContentProviders, Services, and Intent Receivers in the program, you can also specify permissions and instrumentation (security control and testing). By analyzing this manifest.xml file, we can also find vulnerabilities such as application data backup and application tunability. Of course, these vulnerabilities generally belong to relatively low-risk vulnerabilities, that is, they will not have much impact on the business logic of the program. In fact, even if debuggable is set to prohibit attackers from debugging the application, it cannot prevent attackers from debugging the application, because developers can only control the application itself without debugging, but cannot control the user's system. An attacker can debug all applications in the system by setting a property in memory, regardless of whether the application is set or not. However, it is necessary to make this setting that forbids debugging here, because not all reverse analysts know that it can be bypassed.

Webview security issues

If there is a serious vulnerability in Android client applications, it must be a vulnerability in webview. Nowadays, many App have built-in Web pages, such as many e-commerce platforms, Taobao, JD.com, Juhuashuo and so on, as shown below:

Figure 9 webview display diagram

In fact, these are all implemented by webview, a component of android. WebView is a control that displays web pages based on webkit engine. Its function is to display and render web pages, directly use html files for layout, and call javascript interactively. Webview can be used alone or in conjunction with other subclasses. The most commonly used subclasses of Webview are WebSettings class, WebViewClient class, and WebChromeClient class. Here will not do too much introduction, if you are interested in Android programming, Baidu can find more information.

Webview is a two-sided component. On the one hand, it can lighten the burden of client development, put the main logic of the program on the server, and locally use webview to load the corresponding web pages. However, if the configuration is not appropriate, there may be remote command execution vulnerabilities. The related cve are cve-2012-6636 century cvemur2014-1939 recorder cverel 2014-7224.

The vulnerability of cve-2012-6636 is due to the fact that the program does not properly restrict the use of WebView.addJavascriptInterface methods. Remote attackers can execute arbitrary Java objects by using Java Reflection API to exploit this vulnerability.

The vulnerability of cve-2014-1939 is due to the fact that java/android/webkit/BrowserFrame.java uses addJavascriptInterface API and creates objects of the SearchBoxImpl class, which can be exploited by an attacker to execute arbitrary Java code by accessing the searchBoxJavaBridge_ interface.

Cve-2014-7224 attackers mainly make use of two Java Bridge, accessibility and accessibilityTraversal, to execute remote attack code.

The generation of Webview remote command execution also depends on the reflection mechanism of java. The addJavascriptInterface method in Webview can inject a Java Object into the WebView, and the Jave Object method can be accessed by Javascript. AddJavascriptInterface is provided so that the Javascript in WebView can communicate with the local App. This is indeed a very powerful feature, and the advantage of doing so is that if the local App logic remains the same, you can update the program without upgrading App and modify the corresponding Web page. But in the early version of Android, there are no restrictions on the methods that can be accessed. Using the reflection mechanism of Java, you can call any method of any object, which is the root cause of the WebView vulnerability.

Apk update packet attack (man-in-the-middle attack)

The vulnerabilities mentioned above are common and influential ones in Android applications, and some of them are relatively minor, but if used properly, the harm is still serious. For example, a man-in-the-middle attack requires that the attacker and the victim are in the same local area network, and the victim's traffic is controlled by the attacker. What can a man-in-the-middle attack do? Play a xss? Get user cookie? Of course, it is obviously useless to get the user cookie here, it should be the token information. In mobile attacks, man-in-the-middle attacks can even lead to remote command execution. For example, if you control the update package downloaded when the application is updated and replace it with a malicious attack packet, the application executes the update program in the modified return package without making the necessary signature verification to the update packet, which may cause the malicious program to be executed.

Implementation of static scanning tool for Apk vulnerabilities 1. Project introduction

For client-side vulnerability detection, there is no good scanning engine at present. Some time ago, a survey of a digital company, a bang, an encrypted apk security scanning tool, the effect is general, basically the same, are based on the decompiled source code for simple vulnerability verification. So can we also write an automated testing tool ourselves? I have also written an apk automated leak scanning tool myself.

Let me talk about my implementation ideas. First of all, we know that our main analysis objects are AndroidManifest.xml and dex files, but these are compiled binaries and we need to decompile them. The tool needed to decompile AndroidManifest.xml is AXMLPrinter.jar, while the file needed to decompile dex files is baksmali.jar. In fact, these two jar packages are also common jar packages for some reverse tools. Let's take a look at the program directory of the decompiler, the android reverse assistant:

Figure 10 Android reverse helper program directory

The reverse tool called android reverse Assistant mainly uses these two tools to decompile AndroidManifest and dex files.

As long as the corresponding logic is written in our automatic leak scanning tool, after the AndroidManifest and dex files are decompiled by calling these two tools, we can detect the vulnerability by matching some vulnerability features.

The following is a brief introduction to the project directory structure:

Figure 11 Apk vulnerability scanning project directory and introduction

First of all, we need the package name of the application, and then check some settings of application, such as whether backup is allowed, whether it is adjustable, etc.; then get some configuration information of acvitiy and service,content provider,broadcast receiver to determine whether it is exportable; then obtain the permission of the application application to determine whether it is too sensitive; obtain the permission created by the application itself, and determine whether it has made permission restrictions.

Then detect the vulnerability characteristics of the decompiled smali file. This mainly depends on the vulnerability features that we have collected in advance. Here I write the vulnerability characteristics into a xml file, which is loaded into memory for the program to call when the vulnerability scan is started. We can customize these vulnerability features so that our program can scan for more vulnerabilities. Currently, the definition of vulnerability characteristics supports strings and regular forms. The project is still under maintenance, but the basic functions have been implemented to meet the daily scan detection, as long as a little troubleshooting of the scan results can be done.

2. Types of vulnerability detection supported by software at present

1. Arbitrary file read and write vulnerabilities

2. Key hard coding loophole

3. Cast local denial of service vulnerabilities

4. Local denial of service vulnerabilities of system components

5. Intent Schema URL vulnerabilities

6. Local SQL injection vulnerabilities of Content Provider components

7. Code dynamic loading security detection

8. Weak verification of certificate

9. Weak check of hostname

10. HTTPS sensitive data hijacking vulnerability

11. Hash algorithm is not secure

12. AES weak encryption

13. Locat divulges private information

14. Risk of log leakage

15. Risk of misuse of PendingIntent

16. Intent implicitly calls

17. Read and write database files at will

18. Vulnerability detection of hidden interface in WebView system

19. Remote code execution vulnerability detection of WebView components

20. WebView ignores SSL certificate error detection

21. WebView plaintext storage password

22. SharedPreferences arbitrary read and write

23. Read and write any file

24. It is not safe to use random numbers

25. Component permission check

26. Check whether the application is adjustable or not

27. Apply permission check

28. Apply custom permission check

30. Apply backup vulnerability check

3. Usage

1. Put the apk files to be scanned into the workspace/apk directory

2. Click AndroidCodeCheck.exe or execute python AndroidCodeCheck.py to perform vulnerability scanning

4. Report output

Report output path under report

1) txt format

It can be regarded as the running log of the program, and it can also be used as a reference for the scanning results.

2) html format

The report in html format has a directory, and you can click the vulnerability name in the directory to jump to the corresponding vulnerability type description. Click the return directory at the type description to return to the vulnerability directory list to facilitate vulnerability review.

Finally, give a screenshot of a vulnerability scan report, which is a bit crude and will be gradually improved in the later stage.

Figure 12 report catalog home page

Figure 13 vulnerability details

5. Project address

Apk static source code missing scan tool project address:

Https://github.com/zsdlove/ApkVulCheck above is how to analyze the whole content of APK security and automation audit. For more information about how to analyze APK security and automation audit, you can search the previous articles or browse the following articles to learn! I believe the editor will add more knowledge to you. I hope you can support it!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.