Wednesday, September 25, 2013

Drive-by Wi-Fi Attacks Against Android + The Beginning of Defense

Drive-by command execution in short just posted information about a significant vulnerability in Android applications using common ad networks.  To summarize,

The Android WebView API implements a miniature browser inside an app - not only does it render HTML, it can execute javascript.

In an attempt to make it simpler for developers to include rich web environments which can interact with the standard Android UI of the application, the WebView can provide a Javascript Bridge, which allows Java methods to be executed by Javascript calls.

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:

Smarter Wi-Fi Manager for Android

[ Update - A more in-depth description of the problem & the tool in this post ]

I've been working on this for a while, but the recently announced vulnerabilities in android ad networks which allow for shell command execution via hijacked traffic pushed me to release a working version before getting all the features I wanted done:

Intelligently manage your wireless on android - SWM automatically learns where you use Wi-Fi, and will turn it on when you're in one of those locations and automatically turn it off when you're not.  You can also control Wi-Fi by Bluetooth association - automatically turn off Wi-Fi when you're connected to your car stereo, for example.

This is a bit of an experiment in funding open source - the app is paid in the marketplace, but also open source.  If you can't, or don't wish to, buy it from the market place, you can compile it from source using Android Studio.

Thursday, September 12, 2013

A guest post from Renderman

This decision is of a court that does not seem to understand the technology nor that trying to make new technologies fit in the definitions of old tech is not going to fit. Under this judgement, the entire 802.11 specification is technically in violation. With Google and their famous motto of 'Don't Be Evil', every judge looking to make a name is hoping to be the one to make them 'be evil'

An interesting part of this case was that results of the Canadian privacy commissioners report on the issue: which, in short comes down to; "Delete the data, setup controls and processes to prevent it happening again, don't do it again". A fairly levelheaded and sane approach.

We are in an era where technology is rapidly evolving, and the generation gap between the creators and the legislators is larger than ever. Often the courts are dealing with things they have no understanding of and that no apt analogy exists (or, even worse, they use a bad analogy, as in this case).

I wonder if the judge or his family use Wi-Fi at home and realize they are breaking the same judgement?

You can see more from Renderman at @ihackedwhat on Twitter, and at

Wi-Fi isn't radio!?

So, this happened.  #$&^@#.

The 9th Circuit Court of Appeals has ruled that Google can be prosecuted for the capturing of wireless data by Street view cars.  (Disclaimer: Reports indicate that this software was Kismet; having never been a Google employee I have no position on that; it's open source software, I expect it to show up all over the place).

There are some very odd aspects to the ruling - the full text of which can be found here:

The most controversial aspect of the ruling is the declaration that Wi-Fi isn't radio.

Data Transmitted over a Wi-Fi Network Is Not a “Radio Communication” under the Wiretap Act.

From a technical standpoint this is obviously, blatantly, wrong - of course Wi-Fi is radio.  From a legal standpoint, this appears to be drawn from previous interpretations by Congress and exact terminology:

Congress does not use “radio” or “radio communication” to reference all of the myriad forms of communication that use the radio spectrum. Rather, it uses “radio” to refer to traditional radio technologies, and then separately describes other modes of communication that are not ordinarily thought of as radio, but that nevertheless use the radio spectrum.

One of the cited examples is the specification of "radio" as a separate concept from "television" or "communications".  So how did they decide this?  It's tied to the phrase "common meaning", in other words, the non-technical belief that "radio" is for AM and FM audio, and not a whole lot else.  Specifically, the ruling references previous statements, in utterly unrelated cases:

"..Not surprisingly, Congress has not typically assumed that the term “radio” encompasses the term “television.” See, e.g., 18 U.S.C. § 1343 (imposing liability for “[f]raud by wire, radio, or television”) (emphasis added); 18 U.S.C. § 2101 (imposing liability for inciting a riot by means of “mail, telegraph, radio, or television”) (emphasis added); 7 U.S.C. § 2156 (defining an “instrumentality of interstate commerce” as “any written, wire, radio, television or other form of communication);

Which leads to the surprisingly clear statement:

2. A “radio communication” is a predominantly auditory broadcast, which excludes payload data transmitted over Wi-Fi networks


The payload data transmitted over unencrypted Wi-Fi networks that was captured by Google included emails, usernames, passwords, images, and documents that cannot be classified as predominantly auditory. They therefore fall outside of the definition of a “radio communication” as the phrase is used in 18 U.S.C. § 2510(16).

So under this ruling, Wi-Fi isn't broadcast - but what about when it is?  For example, literally, broadcast packets, which are transmitted indiscriminately and define the actual presence of the network?

Technical impacts - This is bad.  Absurdly bad.

It all depends how this ruling is interpreted and enforced.  For law enforcement agencies, there are two types of snooping on data. [* more info here]

  1. Pen/Tap registers and Tap and Trace.  On phone lines, these are essentially the metadata of the call - when a call takes place, the source and destination, duration of the call, etc.  For email, this type of trace can capture header data, sender and recipient emails, and subject lines, but not the content of emails.  These are simpler to get.
  2. Traditional wiretaps, which can contain the content of messages, full packet logs, the content of emails, etc.  These are harder to get and require (in theory) more oversight.
This gets extremely sticky because the statutes interpret a wiretap as anything which receives the information - for a packet-based capture system, this means the copy stored in RAM in the system buffers prior to filtering.  Even if you filter the based on headers and discard the data, it counts as a wiretap.

A researcher, pen-tester, or someone running a WIDS system, or anyone running an access point in Linux (which uses a monitor-mode interface), is going to be capturing all packets on the channel.  Despite the ruling explicitly stating:

But “radio hobbyists” do not mistakenly use packet sniffers to intercept payload data transmitted on Wi-Fi networks. Lending “radio communication” a broad definition that encompasses data transmitted on Wi-Fi networks would obliterate Congress’s compromise and create absurd applications of the exemption for intercepting unencrypted radio communications.

Under the actual limitations of wiretap law, this is exactly what happens under every WIDS system - even if the packets which are not part of the target network, or even if the data packets, are immediately discarded (such as Kismet running under "don't be evil" mode, with "hidedata=true" set in the config), a copy is still made and kept in RAM as part of the kernel packet buffers or in the Kismet (or whatever) buffers.

This seems to be a fundamental failure to understand the nature of shared media:  If you're transmitting on a channel, ALL users of that channel will see your transmissions.  They might ignore them, but they're going to see them.  That's how it works.

By not taking any precaution to encrypt data, a user on an unencrypted network is voluntarily transmitting their traffic for anyone to monitor.

Is this a particularly desirable situation for a user to be in?  No - but the last time I checked, being foolish wasn't against the law.  People do things all the time that aren't particularly safe, secure, or smart.

Critically, the ruling seems to think it's difficult to monitor Wi-Fi:

First, Wi-Fi transmissions are not “readily” available because they are geographically limited and fail to travel far beyond the walls of the home or office where the access point
is located.
Second, the payload data transmitted over unencrypted Wi-Fi networks is only “accessible” with some difficulty. Unlike traditional radio broadcasts, a Wi-Fi access point cannot associate or communicate with a wireless device until it has been authenticated.

Considering the vast majority of Wi-Fi reaches far beyond the property lines of the owners - which causes problems in urban settings, and which many users deliberately attempt by boosting the power or adding after-market antennas, I'm not too confident about that assertion.  Plus, Google only monitored from the street - that means the networks were broadcasting beyond private property into public space.  Seems like that's a pretty clear-cut broadcast.

The second assertion is a major misunderstanding of how Wi-Fi, and Wi-Fi monitoring, operates.  Unencrypted networks are received by everyone in range of them, they're just deliberately discarded if they're not originating from a network a client is connected to.  Broadcast management packets are specifically designed to be received by every device in the area, as are the traffic flow control packets.  Wi-Fi has been specifically designed to co-exist with additional Wi-Fi networks in the same space because it's impossible to not receive packets from other networks!

While Google did take deliberate action to record all the packets seen, it's definitely not difficult to receive them in the first place.  Just because a user may choose to not be aware of how things work under the cover doesn't mean it's not trivial.

But what about the FCC?

What indeed!  The FCC - the regulatory body concerned with radio communications.  Like Wi-Fi.  Which uses radio - already examined this case and declared that Google was not infringing:

In it the FCC specifically addresses the fact that Wi-Fi networks have broadcast transmissions to all receivers, and that Wi-Fi networks can have extended coverage reaching into public areas.

Additionally, Wi-Fi networks fall under Part 15 of the FCC rules.  The extremely exciting (by which I mean not exciting at all) rules, by which all devices in the frequency ranges used by Wi-Fi must abide by, can be found here:

The two relevant aspects of the document that I could find is the statement that cordless phones operating under Part 15 must contain a sticker explicitly notifying the user that privacy is not guaranteed when using the device, and the following admonition about monitoring:

Except for the operations of law enforcement officers conducted under lawful authority, no person shall use, either directly or indirectly, a device operated pursuant to the provisions of this part for the purpose of overhearing or recording the private conversations.

What constitutes a "private conversation"?  Surely using encryption should fit that - it demonstrates an explicit desire to obfuscate.  Conversely, shouting into the street would not constitute a private conversation.  Person-to-person email might be assumed to be a private conversation - except the US government has already made it clear that it doesn't consider any email on a remote server to be protected by any expectation of privacy.

So it's all the users fault, right?

I wouldn't be comfortable saying it's all the users fault they're engaged in insecure behavior - while huge inroads have been made into educating users about Wi-Fi security (and in the past decade I've seen adoption of some form of encryption jump from around 10% of networks to around 70%), responsibility also lies on the manufacturers to ship more devices with secure default settings.  This is slowly becoming more common, but needs to continue this trend.

What happens now

Taken at it's most literal, this ruling effectively makes standard modes of Wi-Fi operation illegal:  By failing to recognize the broadcast nature of Wi-Fi control packets, it makes it impossible for normal CSMA/CA collision avoidance (detecting flow control packets from any network overlapping the current channel), or even building lists of networks in the area (receiving and processing all packets until a beacon is seen).

This will also impact all WIDS systems - which by design capture all the packets in the channel and look for unauthorized networks, while ignoring or discarding packets from other networks - after capturing them and discarding them.

Would they prosecute basic operational methods?  Probably not.  Could they?  Probably yes.  Would it be tacked on as another 100 charges to inflate public outrage, force a plea bargain, or push for excessive sentencing?  I'd certainly expect so.

Security through Legislation

What's worse than security through obscurity: I won't tell you how it works so of course you could never figure it out?  Security through legislation:  It's secure because I say you can't look at it.

Security by Legislation has been applied to several wireless communications standards already - analog cell phones and digital pagers offer no security and no protection, but are considered "secure" because it's illegal to look at them being insecure.  This sort of "protection" provides two things:  A club to beat offenders with, should they ever be caught, and a limit on the above-board products which might otherwise violate ("see all pages in your neighborhood!").  What it does not prevent is any behavior by individuals already inclined to break the law, nor does it offer any incentive for manufacturers to develop more secure devices.  Pager networks are still heavily used today.  By hospitals, EMS, fire departments, alarm networks, and traditional alert systems like email forwarders for company network monitoring.  They're still unencrypted, and they still offer no protection against message spoofing.

By contrast, Wi-Fi is barely over a decade old (in any modern implementation with widespread adoption).  In that timeframe, extensive work has been done by security researchers, many many tools exist for testing and protecting networks, and major improvements have been made to providing users with actual, working security.  If they can be bothered to turn it on.

Thanks to Amanda, Renderman, Mister X, and folks who know who they are, for reviewing, fact checking, and telling me I needed to get this written.

Feel free to post in the comments or @KismetWireless on Twitter