Learning Pentesting for Android Devices (2014)

Chapter 7. Lesser-known Android Attacks

In this chapter, we will read about lesser-known Android attack vectors, which might be useful during Android penetration tests. We will also be covering some topics like vulnerabilities in Android ad libraries and vulnerabilities in WebView implementations. As a penetration tester, this chapter will help you audit Android applications in a more effective manner, and discover some uncommon flaws.

Android WebView vulnerability

WebView is an Android view that is used in order to display web content in an application. It uses the WebKit rendering engine in order to display web pages and other content with the file:// and data:// protocols, which could be used to load files and data content from the filesystem.WebView is used in various Android applications as well, which display the web content in the application, such as applications offering signup and login, by framing their mobile website in the application's layout. We will be discussing more about WebKit and its rendering engine in the next chapter. For this chapter, we will only be concerned about those applications that use WebKit.

Using WebView in the application

The use of WebView in an application is quite simple and straightforward. Let's say we would like our entire activity to be a WebView component, loading content from http://examplewebsite.com.

Here is the code sample to implement WebView in an Android application:

WebView webview = new WebView(this);

setContentView(webview);

webview.loadUrl("http://vulnerable-website.com");

Another important thing that most developers end up doing in order to enhance the functionality of the application, is enabling JavaScript (which is set to False by default) within the WebView implementation using the following command:

setJavascriptEnabled(true);

The preceding command will ensure that JavaScript can be executed within the application and take advantage of the registered interfaces.

Identifying the vulnerability

Imagine a situation where the application is used within an insecure network, allowing an attacker to do a man-in-the-middle attack (read more about man-in-the-middle attacks on the OWASP website https://www.owasp.org/index.php/Man-in-the-middle_attack) on the network. If the attacker has access to the network, they can modify the request and the response to and from the device. This indicates that they will be able to modify the response data and will have full control over the JavaScript content, if it's being loaded from a website.

In fact, using this, an attacker can even use JavaScript to invoke certain methods on the phone, such as sending an SMS to another number, making a call, or even getting a remote shell using tools such as Drozer.

Let's take a quick example of what is possible using the WebView vulnerability. Here, we will be using the proof of concept created by Joshua Drake, which is hosted on his GitHub repo (https://github.com/jduck/VulnWebView/). This POC will simply load a URL in the application using WebView and load a web page located at http://droidsec.org/addjsif.html (in case this link doesn't work, you could go to http://attify.com/lpfa/addjsif.html).

The following is a screenshot of the code sample in Eclipse, in which a JavaScript interface is created with the name Android:

We could also create the apk file from the source code by simply right-clicking on the project and then selecting Export as an Android Application. Once we run the application and monitor the traffic in the Burp proxy, we will see a request to the URL specified in the application, as shown in the following screenshot:

Now, when the response comes from the server, we can modify the response data and use it to exploit the vulnerability, as shown in the following screenshot:

Let's say the attacker needs to exploit this vulnerable application in order to send an SMS to a number using the victim's device. The following screenshot shows how the modified response should look:

Once we hit the Forward button, the message will be sent from the victim's device to the number specified by the attacker.

The preceding content simply calls SMSManager() in order to send the SMS to a predefined number containing the text pwned.

This is a simple example of how to exploit a vulnerable WebView application. You could, in fact, go ahead and try calling different methods or use Drozer to get a remote shell from the device. You could also read more about exploiting WebViews via Drozer athttps://labs.mwrinfosecurity.com/blog/2013/09/24/webview-addjavascriptinterface-remote-code-execution/.

Infecting legitimate APKs

Due to the not-so-strict policy of Google, when uploading applications to the Play Store, many developers upload malicious applications and malware, with intentions to steal private data from a user's device. Most of the malware that exists in Google Play is simply an infected version of the legitimate application. The malware authors simply take a genuine application, decompile it, insert their own malicious components, and then recompile it in order to distribute it on app stores and infect the users. This might sound complicated at first, but in reality, this is a really simple thing to do.

Let's try to analyze how a malware author modifies a legitimate application in order to create an infected version of it. One of the easiest ways to do this is to write a simple malicious application and place all of its malicious activities in a service. Furthermore, we will add a broadcast receiver in the AndroidManifest.xml file so that a specified event such as the receiving of an SMS triggers our service.

So here's a quick breakdown of how to create an infected version of the legitimate application:

1. Decompile the application using apktool, shown as follows:

apktool d [appname].apk

2. Decompile the malicious application to generate the smali files of the Java classes. Here, we need to put all the malicious activities in the service. Also, if you are experienced with the smali language, you could directly create the service from scratch in smali itself. Let's say the name of the malicious service is malware.smali.

3. Next, we need to copy the malware.smali file to the smali folder inside the folder in which we have decompiled the legitimate application.

4. We will change all the references of the package name in malware.smali to the package name of the legitimate application.

5. Register the service in AndroidManifest.xml.

6. Here, we need to add another line in the AndroidManifest.xml file, as follows:

an<service droid:name = "malware.java"/>

7. Also, we need to register a broadcast receiver to trigger the service. In this case, we will choose SMS to be the trigger, as shown in the following code:

8. <receiver android:name="com.legitimate.application.service">

9. <intent-filter>

10. <action

11.android:name="android.provider.Telephony.SMS_RECEIVED" />

12. </intent-filter>

</receiver>

8. Recompile the application using apktool, as shown here:

apktool b appname/

Once the app is recompiled using apktool, the new apk will be the infected version of the legitimate one. Sending a message to the phone could automatically trigger this malware. In case the malware service needs more permissions than the legitimate applications, we will also need to manually add the missing permissions in the AndroidManifest.xml file.

Vulnerabilities in ad libraries

Most of the free Android applications available on Google Play use advertisements in order to generate revenue. However, often, the ad libraries themselves are vulnerable, making the entire application vulnerable to some kind of serious threat.

In order to identify an ad library present in a particular application, we could simply decompile the application using dex2jar/apktool and analyze the created folders. You could also find some of the most popular Android ad libraries and the applications that use them athttp://www.appbrain.com/stats/libraries/ad. An ad library could have numerous vulnerabilities such as the WebView vulnerability discussed in the previous section, insecure file permissions, or any other vulnerability, which may lead an attacker to compromise an entire application, get a reverse shell, or even create a backdoor.

Cross-Application Scripting in Android

The Cross-Application Scripting vulnerability is a kind of Android application vulnerability in which the attacker can bypass the same-origin policy and access the sensitive files stored on the Android filesystem in the application's location. This means that the attacker will be able to access all the content located in the /data/data/[application package name] location. The underlying cause of the vulnerability is that the application allows content to be executed in an untrusted zone with privileges to access trusted zones as well.

The attack becomes even more severe if the vulnerable application is a web browser, in which the attacker will be able to silently steal all the cookies and other information stored by the browser and send it to the attacker.

Even some of the famous applications such as Skype, Dropbox, Dolphin Browser, and so on, were vulnerable to Cross Application Scripting in the earlier versions.

Let's take the vulnerability in Dolphin browser HD, for example, discovered by Roee Hay and Yair Amit. The vulnerable Dolphin Browser HD application used in this example is 6.0.0 and was patched in the later versions.

Dolphin Browser HD has a vulnerable activity called BrowserActivity, which could be invoked by other applications as well, along with other parameters. An attacker could use this to invoke Dolphin Browser HD and open a particular web page, along with a malicious JavaScript. The following screenshot shows the POC code, available along with the advisory (http://packetstormsecurity.com/files/view/105258/dolphin-xas.txt):

Here, with the preceding code in the screenshot, we will open the website http://adityagupta.net along with the JavaScript function, alert(document.domain), which will simply pop out the domain name in an alert box. Once we open this malicious application on our phone, this will invoke the Dolphin Browser HD, opening the URL along with our specified JavaScript code, as shown in the following screenshot:

Summary

In this chapter, we learned about different attack vectors in Android, which could be useful from a penetration tester's point of view. This chapter should serve as a quick walkthrough of different attack vectors; however, you are advised to experiment with these attack vectors and try to modify them, and use them in real-life penetration tests.

In the next chapter, we will be moving away from the application layer and we will focus on ARM-based exploitation for the Android platform.