"Never forget the past, never forget the future"
[opening: lessons from the past]
With the development of mobile Internet, many security problems of PC end appear gradually. For example, the Chrome browser using the WebKit kernel has appeared various general-purpose XSS (i.e. uxss, see the note at the end of the article) [see Figure 1], and now there are similar vulnerabilities on Android. Google transplanted WebKit to Android and encapsulated it in the SDK as a WebView component, but the official forgot the "lesson from the past", resulting in the vulnerability that once appeared in WebKit and reappeared on Android system, even though the vulnerability has been fixed on the PC version of chrome.
Figure 1: chrome uxss vulnerability list
At present, many Android applications directly use the WebView provided by the system, which may cause various applications installed on the system to be affected by the WebView vulnerability, which further expands the scope of the impact of the vulnerability, so that all mainstream applications are affected by it, and a bloodbath without smoke sales is launched.
[Part 2: bloodbath]
Since 2011, the bug list of Google's Chromium project has been reported that there are some uxss vulnerabilities in WebKit. For example, cve-2011-3881 webkithtmlobjectelement uxss vulnerability, its corresponding POC code [figure 2]:
Figure 2: cve-2011-3881 POC code
The vulnerability is mainly due to cross domain problems caused by insufficient verification of JavaScript URL address in htmlpluginimageelement:: allowedtoloadframeurl function. Check the code comparison before and after the repair (as shown in Figure 3). It can be found that the repair code adds security detection to the URL using JavaScript pseudo protocol. Only the current domain and the sericityorigin security information (such as protocol, domain, host, port, etc.) embedded in the ifame domain can access each other within the scope of permission, that is, the browser's "homology policy".
Figure 3: patch code comparison
The patch code is to call securityorigin:: canaccess to check whether the source is the same. The corresponding code is shown in Figure 4. This function mainly performs the following operations:
1. First, judge whether the two securityorigin information are the same and unique. If they are the same, return true. If they are not the same, different tests will be performed according to whether document.domain is set;
2. When document.domain is not set for both, check whether scheme, host and port in the URL are the same, and return true if they are the same;
3. When document.domain is set, check whether the domain and scheme of URL are the same, and return true if they are the same;
4. If you open a local file, perform other file security checks.
Figure 4: securityorigin:: canaccess function code
Many other uxss vulnerabilities are also cross domain problems caused by incomplete source detection. Although they were fixed on Chrome browser, the same set of WebKit was referenced by Android system, resulting in the re occurrence of the previously fixed vulnerabilities.
At the end of 2013, domestic security personnel began to expose this kind of Android uxss on the Internet in succession, and many people also swipe points on the dark cloud platform. After that, a variety of mainstream IT information sites, vulnerability platforms, and self-Media have been able to see the scenes of various frames on Android, especially hot.
Before that, the terminal security team of Tencent security center also studied the vulnerability of Android uxss, and found that this kind of vulnerability is still relatively harmful, and affects many mainstream Android applications, especially those involving sensitive functions such as financial transactions and personal communication, which is easy to cause fund theft, account theft or privacy disclosure. In this regard, TSRC students made a demo, by providing a QR code or URL to send to others, when using chat tools or shopping applications to scan QR code or open the link, then you can steal other people's personal data [figure 5].
Figure 5: stealing user data by using uxss vulnerability
At the same time, students of TSRC also developed a uxss automatic detection tool [as shown in Figure 6], which not only supports batch testing, but also supports the detection of PC and Android browsers. It is also found that some browsers under Android in China are also affected by uxss vulnerabilities, and browsers on individual PC terminals are also affected.
Figure 6: browser uxss automatic detection tool
Android uxss is mainly a security problem left by Android system itself, but if all major application manufacturers rely on Google to fix it, it seems too passive. And even if Google fixes it, most users won't necessarily upgrade in time. In this way, many users may still be affected by uxss vulnerabilities. Therefore, it is necessary for application manufacturers to build their own city defense by hand.
[Part 2: wall reinforcement]
In the webviewclient object of Android, there is an event method called onpagestarted (as shown in Figure 7), which is the earliest event for WebView to inject code. Therefore, we can execute our own detection code before attackers inject JS code with uxss, and judge whether there is cross domain operation.
Figure 7: onpagestarted event method
At the same time, you can also use js hook to dynamically create dangerous elements, such as iframe, object and other elements, and then track the event behavior inside to see whether there is cross domain. If there is, filter all the dangerous elements and refuse to load.
At present, the terminal security team of Tencent security center has completed the development of the defense scheme. Its test effect [as shown in Figure 8] can prevent uxss vulnerability on Android without damaging the stability of the program.
Figure 8: Android uxss defense tool demo
These uxss vulnerabilities mentioned above have been fixed in the latest version of Android 4.4. At the same time, it also provides the function of automatically upgrading WebKit to fix the vulnerabilities in time. Therefore, it is recommended that users try to use the latest version of Android system.
For manufacturers, in addition to the onpagestarted + JS hook method, they can also pack the latest WebKit kernel for their own products to call, but this will greatly increase the volume of the application package, and they need to follow the official update of Google WebKit, which is relatively troublesome. Each manufacturer can choose according to their own situation.
[postscript: a long way to go and a long way to go]
Android uxss is just the tip of the iceberg on Android vulnerabilities. In addition, there are addjavascriptinterface execution vulnerabilities, fakeid vulnerabilities and so on. In the future, there may be other vulnerabilities that will be exposed. In the face of such security problems, how to better defend it, we have many ways to go.
How to seek a breakthrough in the unity of opposites between attack and defense is an eternal topic for security personnel.
[Note: what is uxss]
Universal cross site scripting (uxss) mainly uses vulnerabilities of browsers and plug-ins (such as the same origin policy bypass, which causes the scripts of station a to access various private properties of station B, such as cookies, etc.) to construct cross site conditions to execute malicious code. The difference between XSS and ordinary XSS lies in the difference of vulnerability object and scope, as shown in Table 1.
Table 1: comparison between uxss and ordinary XSS
It is because uxss can affect all sites accessed in the browser that it is called universal cross site.