How hackers are remotely compromised by your Android phone

"You go into a coffee shop and sit down." When you wait for coffee, you take out your smartphone and start playing a game that you downloaded some days ago. Then, you continue to work and collect mail in the elevator. Without your knowledge, an attacker gets the address of the corporate network and constantly infects all of your colleagues ' smartphones.

Wait, what?

Although privilege-boosting techniques are common on Android (and form the convention of "Root" devices), remote code execution is a rare and much more dangerous vulnerability. It allows an attacker to execute specific code on the user's device without authorization. This bug is especially interesting because, even after it has been repaired for 18 months, it can still be exploited on the latest Android device with all the patches installed. Think about it, if that's true, how much effort is needed to exploit this vulnerability.

We have used two different methods to study this bug. First, take advantage of it in a public WiFi-like environment, where you might encounter an environment in a coffee shop. We launched some Android devices and cheap network devices to start attacking. The second step is to estimate how large the average user is likely to encounter this worst case scenario. To do this, we used statistical analysis techniques to see how many vulnerable apps and devices were available.

Before you begin the details, learn the background of this bug:

Background knowledge

It started in 2012 with JavaScript in the Addjavascriptinterface API for remote code execution bug,cve-2012-6636. This bug allows JavaScript code to gain greater access to the system, which is not what the developer intended. So bad at this point. A few months later, MWR's researchers showed that a large number of apps used the ad vendor's framework programs, which were often affected by the bug and downloaded JavaScript code while it was running.

These factors combine to mean that a large number of apps use unsafe ways to download JavaScript code from the Internet, so it is not difficult for a malicious attacker to hijack an attack that downloads and launches remote code execution.

Not fixed yet?

Android 4.2 Fixes this potential JavaScript vulnerability. Unfortunately, because of backwards compatibility, remediation only means that the vulnerability is closed in a particular scenario. The reality of the Android version fragmentation and the advertising business model on Android means that these scenarios are not common. We checked the 100,000 APK files on Google Play and found that about 12% were still at risk even though running on the latest Android devices.

APK analysis results: Half of the vulnerability risk, because their target SDK version is greater than or equal to 17, the remaining 31% is not using the vulnerability of api;7% due to apk confusion or analysis error without analysis.

In addition, more than 50% of Android devices still use versions below 4.2, regardless of whether the vulnerability is fixed. For these devices, there is no fix, and they still risk the vulnerability.

Technical points

To fix the success, the program calling Addjavascriptinterface must be compiled to API 17 and above, meaning that your target Android version must be 4.2 and later. To be compatible with more devices, apps and framework programs are often compiled with the lowest possible API version. The point is that even if you run a patch on Android 4.2, 4.3 or 4.4, the app still has the risk of a vulnerability attack.

The advertising business model is popular in Android: The app is free, and developers earn revenue by showing ads to users. In Android, there are more than 50 different ad framework programs, which makes it easy for developers to implement ad functions, and in fact they often use more than one AD framework program in the app. There are 20 of apps found using more than one. Most of these framework programs have this behavior-they download JavaScript libraries over HTTP when the app first runs. This means that the app is often unsafe to download unauthenticated JavaScript code that runs in an environment that can execute arbitrary code.

Code execution means unrestricted access to the device

So far, the vulnerability has only allowed an attacker to execute code in an Android application environment. This is bad, but it is still restricted by the Android privilege system to access the data in a separate application. However, once an attacker has a foothold in the system, this is similar to the additional privileges they might gain. Taking the Futex vulnerability as an example, it affects every version of the Linux kernel currently in use, including the Android system and the Galaxy S5, the first successful root. Although they are not equivalent, we should develop the habit of "Remote Code Execution" and "root privilege" on a severity level, because sooner or later a determined hacker will be able to jump from one place to another and gain full control of the device.

Exploit in the real world

We talked about how exploits and vulnerabilities are so serious. Now let's put aside the analysis and verify how easy it is to exploit the vulnerability.

We randomly downloaded 102,189 free appsfrom Playstore and found 12.8% of them with a potential vulnerability risk through statistical analysis. These apk also use the too low target API version and the Addjavascriptinterface API. The vulnerabilities of these apk calls to Addjavascriptinterface can in fact be exploited in the form of a man-in-the-middle attack, which can be initiated when JavaScript scripts are downloaded from the Internet insecure.

We will test the hijacking of non-secure JavaScript downloads through a man-in-the-middle attack and inject some JavaScript scripts to probe the Addjavascriptinterface vulnerability.

Test your app's vulnerabilities

We set up a WiFi wireless access point (AP) that acts as a transparent Web proxy broker. It is set to inject malicious code into any device that accesses this AP when it requests any script over HTTP. The AP sets a password in case someone is misused, but this method can be used for publicly accessible APS. Even when the AP is not controlled, techniques such as DNS poisoning or ARP cache spoofing can also be used to implement a broker-in-the-middle. Or you can install a fake AP that mimics a legitimate AP. In other words, there are various ways to implement a man-in-the-middle agent, and anyone using WiFi will access the network through our agents.

The dynamic nature of JavaScript means that we do not need to detect a particular application or AD framework program as a target. When run, malicious code scans the entire JavaScript namespace for objects, looks for objects that use the Addjavascriptinterface API incorrectly, and then tests each for vulnerabilities. If the vulnerability is not found, it silently exits without affecting the operation of the app. If it succeeds, it will run a shell command to launch the Calculator app (which is a tradition of vulnerability disclosure that shows that you have finished running the code-how you can start the calculator and you prove that you can execute any code).

injected JavaScript Fragment

function Findvulnerableobject () {
For (var prop in window) {
try {
If getclass () doesn ' t throw, the object is vulnerable Window[prop].getclass ();
return Window[prop];

}

}

After I set up the AP, I randomly selected some of the 13,119 apps labeled as potentially vulnerable, installing them to a Nexus 5 (running 4.4.3) and a Samsung xe700t (running AOSP 4.2 x86 tablet) connected to the AP. We are simply launching each app and doing some simple interaction to successfully trigger remote code execution in more than half of the applications, which load the malicious code injected through a man-in-the-middle agent.

It's all advertising.

By looking at the trajectory of the TCP/IP package, it was soon discovered that the AD framework program was the culprit for federated use of Addjavascriptinterface and unsecured HTTP downloads. None of the framework programs we investigate use HTTPS, which means that any app that uses these framework programs is also vulnerable to downloading JavaScript in an unsecured manner. Previous research has shown that 17% of apps use HTTPS, but this is another matter.

We examined some of the apps carefully to see which ad frameworks were used. AdMob is the most used (and often the most frequently updated), but we find that many of the frameworks used are still unsafe to use addjavascriptinterface. More than 80% of non-paid apps include at least one ad frame in the app you're checking. Overall, there are 4,190 ad frames in the 2,140 apps identified.

How serious is the problem?

Google posted an approximate amount of downloads for all apps on Playstore. There are more than 150 million downloads for the only small number of use cases that we manually identified as being vulnerable. This is not to say that there will be 150,000,000 vulnerable devices, as one device may install several different vulnerable applications. But given the potential risk of the--10% app we found in the analysis, 50% of risky apps are being tested on the ground-and there are a lot of vulnerable devices.

Also, don't forget that 57% of Android devices are running on versions below 4.2. So even if tomorrow all the vulnerable apps and frameworks are patched on a 4.2 patch, more than half of Android devices will not be able to fix the vulnerability.

Once you've implemented remote code execution, it's not much of a leap forward in the disaster scenario described in the coffee shop before the end. Initializing a matching root permission, a compromised device becomes some sort of middleman, which then goes into any network. As a result, attacks begin to spread, for example, in a world of mobile devices, where a common Wi-Fi network is so popular.

Data for the Merge Device Analyzer (analyser)

Device analyser is another source of data used to count Android devices. One of the features is that it tracks how frequently users start different applications. They use enough patience to cross-reference the data on the list of potential defect applications, giving the following results:

Average number of potential defect apps per user open per day

Over the past year or so, the device analyser data display device's users have an average of 0.4-0.5 potential vulnerabilities open every day. Or, in other words, the average number of times a week has been a (vulnerability) attack. We cannot assume that the version of the app is newer than the one we have analyzed, so when our sample data is no longer the latest version, the corresponding graph also shows a sharp drop. If we re-performed our analysis of the latest APK version, we would probably see it still at 0.4 points. The data for DA (Device Analyzer: Deviceanalyser) is a fairly small sample that allows it to guide more of the conclusions about Android devices, which is generally difficult.

Conclusion

We found that by using a relatively simple man-in-the-middle proxy technology, there is no need for a specific application or device to remotely run a compromised application even if the Android device has a full patch installed. Using static analysis we found that a significant percentage of applications are likely to remain fragile, and we have confirmed that more than half of the applications that have been randomized tested are indeed less resistant.

Therefore, we recommend that you do not use any Android app to display ads when connecting to an untrusted Wi-Fi network. The vulnerability of Android app is the first goal of hackers, so we should use the vulnerability Detection Tool Safe.ijiami to detect, and according to the vulnerability of the corresponding repair or protection, using the Android app security platform Ijiami encrypt the app to protect your personal interests!

How hackers are remotely compromised by your Android phone