Drive-by command execution in short
mwrinfosecurity.com just posted information about a significant vulnerability in Android applications using common ad networks. To summarize,
Unfortunately, the bridge code can allow for execution of arbitrary code through the use of reflection, Java's implementation of introspection. Introspection / reflection allows running code to examine itself, and dynamically call methods by signatures based on method name, argument types, and so on.
There's plenty of interesting function calls to run, but the one leveraged by MWR Labs is to get the runtime environment of the webview, and then find the exec() function. Runtime.exec() in Java is basically what you'd expect - the equivalent of exec() or popen() in libc.
In other words, anyone able to hijack the traffic between your phone and the ad network can execute system commands at the privilege level of the vulnerable application.
Any entity able to intercept traffic from the Android device should be able to trigger exploitation against any vulnerable applications.
Let's leave aside cell data - yes, a state actor could almost definitely interfere with traffic at this level, as could a spoofed GSM tower running something like OpenBTS, but neither is likely to be the prime vector. Instead, let's look at Wi-Fi, my favorite frenemy technology.
Partly as a function of the user interface, and partly due to being consumer technology, phones aren't generally all that good at giving the user intelligent choices when it comes to Wi-Fi. You get a list of networks you've seen before and connected to, and you get an icon saying you're associated to Wi-Fi (or that you're not).
Additionally, there isn't a whole lot in the UI for configuring WPA-EAP networks securely. Until recently there was very very little support for this, and it's still under development. By happily accepting a default situation where the device doesn't validate server certificates, PEAP support is nearly worthless.
So what's the wireless attack surface?
1. Any previously configured open network. This includes 'linksys' and 'attwifi' for those keeping score at home.
2. Any WPA-EAP network without proper certificate backing
The second is certainly juicy, but lets assume any device we're looking at is going to send out a bunch of probes for open networks it's talked to in the past. This lets us do:
1. Simple evil twin attack; clone the SSID of the access point and control outbound traffic
2. Karma; grab any network the device is looking for and spoof it. The Wi-Fi Pineapple is a great tool for this.
3. Wait for them to join any open access point and hijack them via TCP session hijacking. MSF-Airpwn is my (somewhat obvious) favorite here.
Juicy, juicy mobility
Mobile devices (not just Android) are especially vulnerable to Wi-Fi hijacking attacks because they will promiscuously roam to anything that looks like an access point they know, even when the user isn't paying attention.
On Android, official apps like Google Maps and Google Now even suggest you always leave Wi-Fi enabled, so that Wi-Fi based positioning will work more accurately. This means the device is constantly looking to join networks, and constantly at risk for random hijackers.
The one glimmer here is that most ad-driven applications are required to only show ads when the user is actually looking - they probably won't be loading new ads constantly while the screen is off, though who knows for sure. Unfortunately this won't prevent users who have their devices on - doing whatever users do, connecting to random Wi-Fi networks.
As mentioned by the MWR Labs guys, this lets an attacker run anything they want at the privilege level of the application which was hijacked. Since it's using a WebView natively hosted in the app, it has network access permissions as a start. Most Android devices are not configured to block read-only access to the external storage (either a SD card or flash partition on the internal storage) where bulk app data, photos, downloads, etc are stored, so it would be fairly simple to scrape all of that.
Depending on the other permissions the app has, it may be possible to place phone calls or send text messages, being either an annoyance or a significant revenue source.
Installing applications typically requires user interaction, so while it's possible to download entirely new APKs, it would require the user have out-of-market installs enabled, and to click accept.
Depending on the device settings there's a chance it could be possible to install new APKs via the android debug bridge locally - this opens up a whole new set of problems, if the user has ADB enabled and the application is able to install via local ADB privilege escalation would be simple. Combined with the Android Master Key vulnerability, a full take-over of the system could be possible, but I haven't investigated leveraging ADB locally.
The gold crown of course goes to simply rooting the device - Android has had a history of local vulnerabilities which can gain root, and while newer releases have significantly improved device security, not all devices are running newer releases. Vendors keep putting in fantastic backdoors all on their own - shell execution combines wonderfully with CVE 2013-447, which allows any user to execute commands as root on older Motorola devices such as the Defy.
The beginning of defense (or pushing my own product)
There aren't a lot of solutions which don't require modifying the phone; either with a custom ROM or by gaining root.
I'm personally terrified of running anything from the marketplace (or anywhere else) that requires root on Android. The controls are just too coarse: Once you allow an application to run as root, you lose all control of the entire system. It becomes impossible to determine if something has installed backdoors, altered the system, etc.
If you DO have root, you can implement traditional firewalls (Android can run iptables), and you can even implement per-application firewalls (since every app on Android runs as its own user you can filter by uid). You can also block the common ad network servers with a /etc/hosts file.
You can also reduce the attack window by controlling when Wi-Fi is enabled. This can be done manually, of course, but I think there's a smarter way.
Smarter Wi-Fi Manager is a tool I've been working on to handle Wi-Fi settings intelligently. This report has given me a reason to push an initial release out to the world before the entire set of features I'm aiming for are done, but it's already an effective tool.
Smarter Wi-Fi Manager
SWM attempts to manage your Wi-Fi state while requiring as little direct care and feeding as possible. It leans the cell towers near where you use Wi-Fi automatically, then disables Wi-Fi when you are no longer connected. When you return to a learned location, it will automatically re-enable Wi-Fi for you.
To train a new location, just turn on Wi-Fi manually and connect to a network. The learning system will take over from there, and the next time you come back to the area, it will re-enable Wi-Fi automatically.
Specific SSIDs can be excluded from training - attwifi, linksys, timewarner, and so on, networks which appear all over and which you only want to connect to manually.
Wi-Fi can also be disabled when specific Bluetooth devices are connected - for instance, automatically turn off Wi-Fi when connected to a car stereo, or to a Bluetooth headset or pedometer or some other device which indicates you're somewhere other than home.
Hopefully future features will include geofencing for more precise location control, time-range based control of Wi-Fi and Bluetooth (turn off between 9 and 5 for example), and control of the preferred network list so that the device attempts to connect to the proper network.
SWM is also a bit of an experiment in funding open source development - while the Google marketplace version is a for-pay app, it is fully open source, which is available from the SWM page as a Git repository. It was built using Android Studio, the all-in-one Google tool. There is no difference between the released versions and the version found in Git.
You can find more about SWM on the Kismet page:
And on the Google Play market link:
And remember to read the full MWR Labs report at: