Grepping for Glory : using grep to uncover Android Application Level Vulns

I've spent some time trawling through masses of Android App Sauce lately and I thought I'd share some quick tips and tricks that can help you uncover some critical vulnerabilities. In this post I'll discuss some basic bash scripting that pin points code being either in Java or Jasmin/Smali form.

A quick disclaimer, 

the screenshots below are from actual apps sourced from the play store, I've used real examples here to motivate the need to look for the mentioned vulnerabilities and detail how easy they are to find. Although I've made sure to santize them for any useable or exploitable information seeing that some of these apps have been downloaded hundreds of the thousands of times.



Before I start I should mention that I won't be covering much explanation or contributing to the understanding of the vulnerabilities I mention here, I'll post about that later, what I want to focus on his how you bash your way into some Android App 0days!

Apktool all the things!

To start off with lets assume you've downloaded a bunch of .apks and you have them in a single directory like so

 as in the screen you can use this small bash script to decompile and dump some smali formated dex bytecode into directories neatly named after every app

for file in `ls`
do
echo $file
apktool d $file
done 

or more compactly in a single line as follows

for file in `ls`; do echo $file; apktool d $file; done

Once its done running your directory should look something like this

 
Once you've got everything decompiled and smali'd you can start grepping your way to glory.

Grep for HTTP issues

Lets start with an easy one, mixed scripting and web based Man-In-The-Middle vulnerabilities or rather any form of HTTP traffic an app may generate that is not HTTPS secured.

If you've spent a lot of time swimming in Android sauce you may know that Android apps especially banking apps often act as front ends to web services and sometimes store very little information related to user but instead depend on massive amounts of HTTP requests and Web REST apis to pull the data a user needs. What this means is that whatever HTTP request happens that's not HTTPS secured can in some contexts--most actually--be intercepted and maliciously tampered with.

HTTP url references

To find some strong indication of this issue you can try firing off this command

for file in `find . -name "smali"`; 

do 

   grep $file -Rne "const-string v[0-9], \"http:\/\/\([\w_-]\)\{1,50\}.*\""; 

done

Which produces awesome output like this:

This little bash script looks for any mention of strings being loaded into registers that resemble http urls, they typically form part of HttpUrlConnection's which is usually a bad idea in an Android app and generally everywhere.

HttpUrlConnection calls

Another slightly more aggressive grep you could make is by looking for actual calls to the HttpUrlConnection api

for file in `find . -name "smali"`;
 do grep $file -Rne\ "invoke-virtual {v[1-16]}, Ljava/net/HttpURLConnection;->\(getInputStream\|\getOutputStream)"; 

done

There are other HttpUrlConnection calls that may be useful for fingerprinting the issue,  I suggest checking out the documentation and grepping for some other calls.

You could make this a little more effective by looking for mention of JavaScript, CSS, XML, PDFs or FlashScripts or any other active browser content you can think of. Although most modern browsers like Firefox and Chrome have pretty solid protection against Mixed Scripting apps can often circumvent this protection by loading content out of bounds of the Web Browsers on an Android Device by setting static immutable HTTP URLs that get fed to the browsers and WebViews in the apps, this exposes users to the very same risks as Mixed Scripting on normal desktop browsers.

Insecure active browser content

You can look for active content by using the following regex

for file in `find . -name "smali"`;
 do grep $file -Rne\

 "const-string v[1-9], \"http:\/\/\([0-9\w_-]\)\{1,50\}.*\(\.xml\|\.js\|\.css\|\.swf\)"; 
done

Insecure WebView usage

A vulnerability that's seeing a lot of media attention lately is the insecure use of the WebView API. Applications often expose themselves to remote code execution in a number of ways, here I grep my way into a lot of potential sources for the most common WebView related vulnerability, that is the addJavaScriptInterface vulnerability.

addJavascriptInterface

Looking for calls to the addJavaScriptInterface call in smali code is actually quite simple, here's how to do it

for file in `find . -name "smali"`;

 do grep $file -Rne "addJavascriptInterface"; 

done

Of course whether these are exploitable depends on whether the WebView is exposed to parsing remote content, or content attackers can intercept and maliciously modify to abuse the Javascript interface to find this out you will either need to read through the source code or write up a massive context-free grammar like regular expression to actually inpsect the source code autonomously if you're going to use grep to fully detail the vulnerability.

WebViewClient shouldOverrideUrlLoading and related calls

 

Another WebView related vuln you could look for is insecure overrides to the android.webkit.WebViewClient API method and insecure calls to the API methods, this API enables applications to control some of the behaviour of the a WebView instance, naturally developers do crazy things like feed the WebView non-HTTPS secured URLs and expose what should be a protected unexposed WebView instance to man in the middle attacks. In my most recent experience developers often feed URLs passed to these calls straight into WebView.loadUrl calls this combined with an exposed JavaScriptInterface does not bode well!

Here's a quick grep for the shouldOverrideUrlLoading call

grep $file -Rne ";->shouldOverrideUrlLoading"

although if you use the regex above you may be catching instances of methods that just happen to be named the same way, the closest you can get to picking up actual calls to the WebViewClient related method should include the method definition "(Landroid/webkit/WebView;Ljava/lang/String;)Z", so it would look like this:

grep $file -Rne ";->shouldOverrideUrlLoading(Landroid/webkit/WebView;Ljava/lang/String;)Z"

 If you're lucky will produce output as follows:

Some other WebViewClient related vulnerabilities you could look for is

onLoadResource
onPageFinished 
shouldInterceptRequest


There are a number of calls applications can override that can potentially trigger a remote code execution vulnerability depending on which URLs are sourced and how for more examples I suggest looking at the documentation.

Yet another interesting WebView related vulnerability is the use of HTTPAuthentication and how WebView instances allow developers to handle instances of HTTP Authentication requests and set usernames and passwords to submit for these authentication requests. Of course exposing these credentials inside an application is a really bad idea!

The call WebView provides for setting usernames and passwords for HTTP Authentication requests is called setHttpAuthUsernamePassword.

Here's a screenshot of an actual example of this being used in an actual app, finding this one actually made me uninstall this particular app for a while :/

Here's how you can grep for this, also bare in mind this may lead to exposure of these credentials since the need to be passed to his method.

grep $file -Rne ";->setHttpAuthUsernamePassword(Ljava\/lang\/String"

Conclusion

I think that's pretty much all of the application level flaws I wanted to mention in this post, I'll probably follow up this post with more vulnerability summaries and security bug hunting methods.