Preface
Before that, some people counted the products with the most vulnerabilities in 2015, and Apple's OS X and IOS systems ranked first and second respectively. Although some people suspected that the statistics might be inaccurate, they believed that the general trend would not change.
In 2015, there were many security events on IOS platform, such as "xcodeghost" event, IOS 9 jailbreak, "ibackdoor" and "youmi" event, etc., especially xcodeghost, which had a great impact, was destined to leave a lot in IOS security history.
According to the statistics of IOS system vulnerabilities on cvedetails [figure 1], the overall trend is on the rise, especially the rapid growth in 2015, which is more than three times that of 2014. Therefore, it can also be predicted that the security vulnerabilities on the IOS platform are growing rapidly, as well as IOS applications.
Figure 1: IOS system vulnerability statistics over the years
Tencent also has a lot of IOS application products, which are basically available on Android, and the corresponding same app will also be available on IOS. At present, the audit technology of Android application is relatively mature in the industry, while the IOS application vulnerability audit system is still relatively deficient in China. Some companies may have internal development, but it is not disclosed.
Before that, Tencent's IOS products also failed to conduct effective pre online audit, leaving some security risks, so we specially developed an automatic audit system for IOS applications. In addition to daily application audit, it is also hoped that it can play an auxiliary role in security emergency. This article is mainly to carry on some superficial exploration to this part of technology, in order to hope that it can play the effect of casting bricks and attracting jade.
development environment
• Mac OS X 10.11 • Python development environment: pycharm5 • Objective-C development environment: xcode7 + IOS opendev • support IOS 8.1 and above jailbreak system
system architecture
The whole IOS application audit system is mainly divided into two parts: static audit and dynamic audit [figure 2]. Static audit includes bin file vulnerability audit, third-party library detection, private API static detection and other functions; dynamic audit mainly monitors network packets, SSL middleman detection through hook, and realizes the dynamic installation and operation of IPA, file upload and download and other basic functions.
Figure 2: IOS Application Audit System Architecture
Basic audit function
The basic file information is extracted through static audit and output to the report page with good display effect [figure 3], which is also convenient for subsequent secondary scanning and identification of different IPA files.
Figure 3: file information and vulnerability statistics
In static audit, the most important function is bin file vulnerability detection function [figure 4], such as compilation options and function information, which can be easily detected with the help of otool.
Application vulnerability detection is mainly used to detect the open vulnerabilities / malicious backdoors, such as xcodeghost, ibackdoor, afnetworking, etc. firstly, static detection rules are made by analyzing samples, most of which can be detected through key strings. For afnetworking SSL man in the middle vulnerability, the author uses arm instructions related to vulnerability detection.
Figure 4: Bin static audit function
The following is the arm instruction of a vulnerability version of afnetworking [figure 5]. There will be some differences between different versions, so it is still necessary to compare multiple different versions and extract the general detection rules (ARM instruction with red icon will be misreported if it is detected only). In addition, we also need to compare the repaired version of the code to avoid false positives.
Figure 5: afnetworking SSL man in the middle vulnerability code
Because IOS applications include 32-bit and 64 bit programs for compatibility, rarely only 64 bit compiled applications are used, so 64 bit problems can not be considered during detection.
In addition to the application vulnerability in Figure 4, the user-defined audit function [figure 6] is also supported. This is mainly to make rules in time for batch scanning in case of emergency [figure 7]. We have also added some rules specifically for the business situation of the company, which will not be covered here.
Figure 6: example of custom audit rules (not applicable)
Figure 7: apply batch scan
The above [figure 6] is just an example rule, which is not actually used in the system, but is just for demonstration. It supports binary, database and file scanning, in which Linux command can be used to assist detection. Of course, you can also call it "backdoor".
In addition, data storage security and network transmission security are completed in the dynamic audit part, and the audit rules are defined in the custom rules. Among them, the network real-time detection function is mainly implemented based on hook, which monitors the contract function, such as nsurlconnection: sendsynchronousrequest or uiapplication: OpenURL [figure 8].
Figure 8: monitoring through hook network related API
The program will listen to HTTP, HTTPS and even the request of custom pseudo protocol in real time, and record the cookie value for the convenience of subsequent test, and then output it to the report completely [figure 9], later it can also be imported into the scanner for web vulnerability scanning.
Figure 9: real time monitoring of network requests
As the famous third-party library afnetwork is often used, it also increases its network monitoring.
UI interface traversal
In order to trigger more program logic and increase code coverage, it is necessary to traverse various UI interfaces during dynamic detection. In this case, we use the app crawler tool for UI traversal, which supports Android and IOS applications at the same time. In the config.json configuration file provided by it, we can flexibly configure it according to our own needs, such as the depth of traversal, matching text box keywords for input (such as login account). These rules need to be tested by ourselves to improve it. [figure 10] is the partial screenshot effect of traversing wechat UI. Since it only traverses for 10 minutes, the screenshots are relatively few, and the overall effect is good.
Figure 10: partial screenshot of traversing wechat UI
SSL intermediary detection
In mobile app, no matter Android or IOS platform, SSL man in the middle attack is a common vulnerability, which is often caused by lax certificate verification. Although it is man in the middle attack, it can also cause great harm in a certain scenario, especially in the financial scenario of public WiFi.
For SSL man in the middle vulnerability, if static code detection is adopted, the false alarm rate may be higher. Here, the author makes static detection through hook, injects the request of certificate exception site at runtime, and then checks whether the access is successful [figure 11].
Figure 11: SSL middleman dynamic detection principle
Taking QQ Browser HD as an example, a prompt in [figure 12] will pop up after injecting an abnormal site, indicating that this site will not be automatically connected, so there is no SSL man in the middle vulnerability.
Figure 12: detection effect
However, applications using the third-party SSL library may fail to report. Another alternative is to use the certificate replacement detection method. However, this will lead to access exceptions, and eventually the application may not be able to use normally, and subsequent audit actions will be suspended. Each has its own disadvantages, which can be used separately for the time being. If you have better detection methods, please reply and discuss below.
Private API detection
Although calling private API is not a vulnerability, but because of Apple's strict audit mechanism, once it is found that calling private API will directly off the shelf application, which has a great impact on the business.
In addition, from the security point of view, if the bug fix version of the application needs to be released, but the private API call is also rejected by Apple official many times, it will lead to the bug can not be fixed in time.
The difficulty of detecting private API mainly lies in that Apple does not disclose the list of private API, so it can only extract it by itself during detection, but it will also lead to some false positives and false positives.
There is a formula for extracting private API on the network: private API = (API in the header file generated by the Library under the class dump framework - (API in the header file under the framework = API with documents + API without documents)) + API under the privateframework
In fact, this is not completely correct. If you simply extract it according to this method, there will be a high level of false positives and false positives. Because there are public APIs in private classes and private APIs in public classes. But the above formula is the first step to extract the private API. After that, many extraction rules need to be improved step by step. For example, some pure lowercase API, mostly some C library functions, can filter a large number of them.
This kind of method is not particularly good. It can only scan applications and optimize rules according to the results.
GitHub also has open source projects for testing private APIs, but basically none of them can meet the testing requirements. The false positive rate and false negative rate are too high, and the IOS version is low. In IOS 9 SDK or above, you can't directly use classdump to extract the header file, because the symbol table of the application has been removed, and the author uses nm to solve this problem.
At first, the author intended to do the dynamic detection of private API, but later considered that the audit system is mainly internal, so there is no malicious behavior to bypass the detection of private API, and then commented out half of the dynamic detection function.
If readers want to do dynamic detection of private APIs, then false positives and performance are the primary concerns. If the hook is too deep, there will be too many messages and too much time consumption. Moreover, if some private APIs are called by the system itself, it is impossible to distinguish whether they are application or system calls. If the hook is too shallow and fails to achieve the effect, it is impossible to monitor the behavior of private APIs. Here is a screenshot of the semi-finished product of dynamic detection [figure 13], you can continue to play.
Figure 13: hook log for dynamic detection of private API (semi-finished product)
In order to improve the accuracy of static detection, the author also supports [Figure 14] in the case of static splicing of API strings, because normally, the two strings are adjacent, and the combination can be compared with the private API library.
Figure 14: String splicing bypasses private API detection
Well, I've said so much, and I'll go straight to the actual picture. The following [figure 15] is a test for tinyv, an IOS virus exposed last year (thanks for the sample shared by claudxiao). You can see that it calls the private API in lsapplicationworkspace and mobileinstallation to view the list of installers, install and uninstall applications.
Figure 15: private API test results of IOS virus tinyv
Third party library detection
Sometimes the outside world will expose some vulnerabilities of the third-party open source library, and the impact is often cross platform, including IOS applications. Therefore, we collect hundreds of commonly used third-party database information as the detection content. During the daily audit application, we can maintain a copy of the information about which company's products are used and which third-party database are used [figure 16]. After the vulnerability is exposed externally, we can quickly locate the affected products and the scope of harm.
However, there is a lack of corresponding version information at present, because some libraries are compiled without version string, so fingerprint library detection is needed for different versions, which is also a lot of work. If there are good people in the industry willing to benefit the masses, you can try to make a fingerprint Library of a third-party library.
Figure 16: third party library detection
Open port detection
The function of open port detection is mainly based on the previously exposed "wormhole" vulnerability. There have been many cases in Android applications, which can be found by searching dark cloud.
It's enough to check the open port with one command, and then rotate it regularly: lsof - I | grep '"+ appName +"' | awk '{print $1, $8, $9, $10}'
Directly on the rendering, as shown in [figure 17]:
Figure 17: open port audit
Audit effect
We randomly selected 60 IOS applications of the company, and found 10 products with medium and high-risk vulnerabilities after audit [figure 18], among which most are SSL middleman vulnerabilities and authorization key disclosure vulnerabilities.
Figure 18: audit results
Epilogue
This paper mainly aims at the author in the development of IOS application automatic audit system to use some of the technology to share, hoping to play a role in the introduction. The system itself also has some areas to be improved. Welcome to discuss with colleagues in the industry.