When it comes to mobile security, you may be unfamiliar with it, because research in this area has only become 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 issues in the platform system itself and issues at the application level. Of course, some communication protocols need to be involved when the client and server interact, mainly http and https protocols, and of course some other protocols, such as websocket and so on. We won’t pay too much attention to the flaws of these protocols themselves. What we need to pay attention to is whether the data packets are encrypted when necessary during transmission, whether the server controls the user’s operating permissions, and some services on the server. Whether there are flaws in logical processing, etc. The idea in this aspect is basically the same as web penetration, but there are some differences.
Speaking of mobile security, of course, viruses and Trojan attacks are indispensable. Common remote control Trojans include droidjack, SpyNote, etc., and some time ago, such as Locking software is springing up like mushrooms after the rain.
Figure 1Droidjack
Figure 2 Locking software
Attackers can use Droidjack type Software generates Trojan horse programs. This kind of malicious Trojan horse program generally exists in some third-rate APK markets. Generally speaking, attackers will put some tempting information in these apks, such as free viewing of so-and-so beauty videos, ad-free client for so-and-so videos, so-and-so cool picture browser, etc. After the attacker publishes these APKs with tempting information on the Internet, they will start a server program on the remote server. Once the user installs and runs this malicious program, the hacker can control the user's mobile phone on the remote server. Monitor users' various behaviors and steal users' private information.
In the final analysis, these Trojan virus level attacks are mainly due to the weak security awareness of users, so they are not the main subject of discussion. We mainly discuss the security of Android application level.
So how do we mine app vulnerabilities? First of all, for security workers who have switched from web security to mobile vulnerability mining, of course they want to dig for vulnerabilities that are similar to their own field. The server side of the app is basically the same as the server side in the web security field, except that it is a web program. Its client is more of a browser, while mobile applications generally have an app program that can be installed on a mobile device. Therefore, for the mining of app server vulnerabilities, we can still use our past web experience to mine some of the vulnerabilities such as xss, ssrf, sql injection, arbitrary file reading, etc.
When digging for vulnerabilities in web applications, we can configure the proxy in the browser to capture packets and analyze our web applications. So how should we perform packet analysis on mobile applications?
In fact, the data packet analysis of Android applications is also based on proxy, but the proxy configuration is relatively complicated. After we configure the corresponding agents in burptsuit or fiddler, we can use them to intercept and replay data packets. The specific steps will not be explained in detail here. There are tutorials online, you can check them out by yourself.
Here, I won’t go into details about some classic vulnerabilities such as xss and sql injection. There is nothing much to say. Here I will mainly talk about the unauthorized vulnerabilities of mobile applications. We know that in web security, unauthorized access vulnerabilities are usually caused by the server not performing permission verification on user requests and executing user requests based only on user IDs. So what is the correct authentication process? A brief description in text is: after the user successfully logs in and is authenticated, the server will write the user's permissions into the cookie, and then return it to the browser. The browser will retain this cookie; the user will bring this cookie in subsequent request packets. , the server verifies the cookie in the data packet to identify user permissions and perform operations with corresponding permissions.
Figure 3 cookie authentication process
Of course, there is another authentication method which is session authentication. Both session authentication and cookie authentication can authenticate the user's identity. So, what is the difference between session authentication and cookie authentication?
To put it simply, the cookie is stored on the client side, and the session is stored on the server side. From a security perspective, cookies are relatively unsafe, while sessions are relatively secure, because cookies are stored on the client side, and attackers can obtain cookies on the client side. If the fields used to identify the user's identity are not encrypted, they can easily be Enumeration, then the attacker can forge cookies and perform unauthorized operations. And if session authentication is enabled, the client will only obtain the corresponding session id after successful login. This id is an encrypted string and cannot be traversed.
So what is its certification process like? First of all, we need to know that session authentication also relies on cookies. After the user successfully logs in, the server will write the user's corresponding session into the server's database. The session contains some identity information of the user, and then the server The ID corresponding to this session will be sent to the client, so the content of the cookie in the client is generally only a string of sessionid=xxxxxx. The user needs to bring this sessionid in subsequent requests. The server identifies the sessionid, then queries the database to obtain the corresponding user permission information, and then determines whether the user has permission to perform the response operation.
Obviously, the session mechanism is relatively safer, but the other side of security also requires paying a price. Compared with cookies, the session mechanism will consume more server performance.
Figure 4 Session authentication process
However, on the mobile side, user identity authentication does not use cookies, but is based on token identification. So what kind of authentication method is it? To express it in brief words, its authentication process is generally like this. After the client login verification is successful, the server will return a token string. This string is the session credential of the user. The user will then interact with the server. You must bring this token with you so that the user's identity can be identified.
Figure 5 Token authentication process
If we analyze the data packet and find that there is a request without a token, then this data packet is very There may be an ultra-privilege vulnerability. Of course, it must be analyzed based on specific scenarios to determine whether it affects the business logic. This is our general posture for digging out unauthorized vulnerabilities on the mobile terminal. However, this posture is too mentally retarded. There is no threshold. Basically anyone who encounters it can dig it.
There is another way of digging for unauthorized access vulnerabilities, which seems rather strange. The root cause of this unauthorized access vulnerability is the error in the authentication strategy itself. I remember that a long time ago, I conducted a protocol analysis on a live broadcast software and found that its authentication logic is as follows: after the user login verification is successful, the server returns the user ID, and then locally produces the user token. In subsequent requests, Bring this token as proof of user identity. This is obviously buggy, because the user ID can be traversed, and the token generation algorithm is local, so the attacker can calculate the token by himself as long as he obtains the IDs of other users and extracts the local token generation algorithm. , and then the fake user logged in.
Of course, it is still relatively difficult to discover such unauthorized vulnerabilities, which requires vulnerability diggers to have relatively deep reverse analysis capabilities and coding capabilities. However, as a developer, you must not relax the reinforcement of application security because of this difficulty. Especially for user authentication, a very important functional module, you must take good security protection.
As for client vulnerabilities, the main method is to decompile the app client through decompilation tools to obtain Source code, and then conduct static source code audit based on some experience and security knowledge. Common decompilation tools include apkide, jeb, apktools, etc. Let me take a screenshot for you to understand:
The Android application platform is mainly divided into native layer and java layer. For the Java layer, we can use the above tools for analysis, and for the 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 the apk through ida, and then use its f5 function to convert the arm assembly code into c pseudo code and analyze the logical algorithm. It also supports dynamic debugging and can remotely debug apk applications. We can use ida dynamic debugging to bypass some verifications in the so layer, such as secondary packaging verification, or perform dynamic debugging and shelling.
Speaking of application shelling, this is very necessary during the apk analysis process. Before talking about unpacking, let’s first understand what packing is. Packing means to first obtain control of the program before the application is run, and then transfer control of the program to the original program. The packing implementation on the Android platform is to encrypt and hide the original dex file, and then obtain the original dex file through the shell program and then restore it back; another method is to extract the function instructions and use hooks to respond when running. The class loading function fills the instructions back.
For packed applications, the logic of the original program is basically unrecognizable, and we cannot conduct security analysis through the packed program. Therefore, we need to unpack the application. Common automated unpacking tools include drizzledump and dexhunter. Dexhunter is easy to use, but it requires flashing, and many encryption vendors have checked it, so it won't work if you use it directly. You need to make some modifications and bypass some detection. As for the detailed usage, you can find tutorials online, so I won’t go into details here. If the tool doesn't work, you'll have to go to ida in the end.
Let’s take a detailed look at the issues that need to be paid attention to when it comes to security detection at the source code level.
Component security
The first is the security issue of components. We know that Android applications have four major components, namely: activity, service, content provider, and broadcast receiver. If these components are not very necessary, their export attribute, exported, should be set to false, that is, exporting is prohibited. If set to true, it will be called by external applications, which may cause information leakage, permission bypass and other vulnerabilities. In addition, when using Intent.getXXXExtra() to obtain or process data, if try...catch is not used for exception handling, a denial of service vulnerability may occur. These exceptions include but are not limited to: null pointer exception, type conversion exception, array Out-of-bounds access exception, undefined class exception, serialization and deserialization exception.
Like the component security mentioned above, we usually judge it by analyzing Android’s androidManifest.xml file. AndroidManifest.xml is the entry file for Android applications. It describes the components exposed in the package (activities, services, etc.), their respective implementation classes, various data that can be processed, and the startup location. In addition to declaring Activities, ContentProviders, Services, and Intent Receivers in the program, permissions and instrumentation (security control and testing) can also be specified. By analyzing this manifest.xml file, we can also discover vulnerabilities such as application data backup and application tunability. Of course, these vulnerabilities are generally relatively low-risk vulnerabilities, that is, they will not have much impact on the business logic of the program. Moreover, due to the vulnerability of application debuggability, even if debuggable is set to prohibit attackers from debugging the application, it will not prevent attackers from debugging the application, because developers can only control the application itself from 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 to be debugged. However, it is still necessary to make this setting to disable debugging here, because not all reverse analysts know that this setting can be bypassed.
webview security issues
If we want to talk about the more serious vulnerabilities in Android client applications, they must be webview vulnerabilities. Many apps now have built-in web pages, such as many e-commerce platforms, Taobao, JD.com, Juhuasuan, etc., as shown below:
Figure 9 webview display
In fact, these are implemented by webview, a component in android. WebView is a control based on the webkit engine that displays web pages. Its function is to display and render web pages. It directly uses HTML files for layout and calls interactively with javascript. Webview can be used alone or in combination with other subclasses. The most commonly used subclasses of Webview are WebSettings class, WebViewClient class, and WebChromeClient class. I won’t introduce too much here. If you are interested in Android programming, you can find more information on Baidu.
The Webview component can be described as a two-sided sword. On the one hand, its appearance can reduce the burden of client development and put the main logic of the program on the server for implementation. Locally, you only need to use webview to load the corresponding web page. However, if configured improperly, remote command execution vulnerabilities may exist. The relevant CVEs include CVE-2012-6636, CVE-2014-1939, and CVE-2014-7224.
cve-2012-6636 This vulnerability is caused by the program not correctly restricting the use of the WebView.addJavascriptInterface method. A remote attacker could exploit this vulnerability to execute arbitrary Java object methods by using the Java Reflection API.
cve-2014-1939 This vulnerability is due to java/android/webkit/BrowserFrame.java using the addJavascriptInterface API and creating an object of the SearchBoxImpl class. An attacker can exploit this vulnerability to execute arbitrary Java code by accessing the searchBoxJavaBridge_ interface.
cve-2014-7224 The attacker mainly uses the two Java Bridges of accessibility and accessibilityTraversal to execute remote attack code.
The generation of Webview remote command execution also relies on Java's reflection mechanism. The addJavascriptInterface method in Webview can inject a Java Object into WebView, and the methods of this Java Object can be accessed by Javascript. The reason why addJavascriptInterface is provided is so that Javascript in WebView can communicate with the local App. This is indeed a very powerful function. The advantage of this is that when the local App logic remains unchanged, the program can be updated without upgrading the App and the corresponding Web page can be modified. However, in the early versions of Android, there were no restrictions on the accessible methods. Using Java's reflection mechanism, you can call any method of any object. This is the fundamental cause of the WebView vulnerability.
apk update package attack (man-in-the-middle attack)
The vulnerabilities mentioned above are relatively common vulnerabilities in Android applications and have a relatively large impact. There are also some vulnerabilities The relative impact is relatively light, but if used properly, its harm is still relatively serious. For example, a man-in-the-middle attack requires the attacker and the victim to be on the same LAN, and the victim's traffic is controlled by the attacker. What can a man-in-the-middle attack do? Play xss? Get user cookie? Of course, it is obviously useless to obtain the user cookie here, it should be the token information. In mobile attacks, properly exploited man-in-the-middle attacks can even lead to remote command execution. For example, the update package downloaded when the application is updated is controlled and replaced with a malicious attack data packet. The application executes the update program in the return package modified by the attacker without performing necessary signature verification on the update package. This is May cause malicious programs to be executed.
There is currently no good scanning engine for client-side vulnerability detection. Some time ago, I investigated a certain digital company, a certain Bang, and a certain encrypted APK security scanning tool. The results were average and basically similar. They were all based on simple vulnerability verification based on the decompiled source code. So can we also write an automated detection tool ourselves? I also wrote an apk automated missing scanning tool before.
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 two are compiled binary files. We need to reverse them. Compile it. The tool needed to decompile AndroidManifest.xml is AXMLPrinter.jar, and the file needed to decompile dex files is baksmali.jar. In fact, these two jar packages are also commonly used by some reverse engineering tools. Let’s take a look at the program directory of the android reverse assistant decompilation tool:
Figure 10 Android reverse assistant program directory
This is called android reverse assistant The reverse engineering tool mainly uses these two tools to decompile AndroidManifest and dex files.
As long as we write the corresponding logic in our automated leak scanning tool and call these two tools to decompile the AndroidManifest and dex files, we can detect the vulnerability by matching some vulnerability characteristics.
The following is a brief introduction to the project directory structure:
Figure 11 Apk vulnerability scanning project directory and introduction
First we need the package name of the application, and then detect some settings of the application, such as whether backup is allowed, whether it is adjustable, etc.; then we obtain some configuration information of the four components acvitiy, service, content provider, broadcast receiver, Determine whether it can be exported; then obtain the permissions applied by the application to determine whether it is too sensitive; obtain the permissions created by the application itself to determine whether it has permission restrictions.
Next, perform vulnerability feature detection on the decompiled smali file. This mainly relies on the vulnerability characteristics we have collected in advance. Here I write the vulnerability characteristics into an xml file, and when starting the vulnerability scan, load it into the memory for the program to call. We can customize these vulnerability characteristics so that our program can scan more vulnerabilities. Currently, the definition of vulnerability characteristics supports string and regular forms. This project is still under maintenance, but the basic functions have been implemented and can meet daily scanning and detection. Just make some troubleshooting on the scanning results.
1. Arbitrary file reading and writing vulnerabilities
2. Key hard-coding vulnerabilities
3. Forced type conversion local denial of service vulnerability
4. System component local denial of service vulnerability
5. Intent Schema URL vulnerability
6. Content Provider component local SQL injection vulnerability
7. Code dynamic loading security detection
8. Certificate weak verification
9. Host name weak verification
10.HTTPS sensitive data hijacking Vulnerability
11, Hash algorithm is unsafe
12, AES weak encryption
13, Locat leaks private information
14, Log leakage risk
15. Risk of misuse of PendingIntent
16. Implicit call of Intent
17. Arbitrary reading and writing of database files
18. WebView system hidden interface vulnerability detection
19. WebView component remote code execution vulnerability detection
20. WebView ignores SSL certificate error detection
21. WebView plain text storage password
22. SharedPreferences can be read at will Writing
23. Reading and writing arbitrary files
24. It is unsafe to use random numbers
25. Component permission check
26. Check whether the application is adjustable
27. Application permission check
28. Application custom permission check
30. Application backup vulnerability check
1. Place the apk file that needs to be scanned in the workspace/apk directory
2. Click AndroidCodeCheck.exe or execute python AndroidCodeCheck.py to perform vulnerability scanning
The report output path is under report
1) txt format
It can be regarded as the running log of the program. It can also be used as a reference for scan results.
2) HTML format The report in
html format has a directory. Click on the vulnerability name in the directory to jump to the corresponding vulnerability type description. In the type description, you can click Return to Directory to return to the vulnerability directory list to facilitate vulnerability review.
Finally, I will give you a screenshot of the vulnerability scanning report. It is a bit crude and will be gradually improved later.
Apk static source code leakage scanning tool project address: 
https://github.com/zsdlove/ApkVulCheck
The above is the detailed content of How to analyze APK security and automate auditing. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
