Thursday, March 23, 2017

Scripting Against The Web Interface, Part 1

New Server Model

Recently I've seen several questions about connecting to the Kismet server with scripting tools - while possible with the stable/old Kismet, it's so much easier under the git-master code that I strongly recommend anyone developing something new that draws from Kismet look at runnign the git-master version instead.

The new Kismet code uses an embedded webserver (libmicrohttpd) to serve data as a collection of REST-like endpoints.

Object Data

Data is now stored in Kismet in introspectable (meaning they can be processed by the code automatically without having to know what they contain beforehand) dictionary-like (meaning they're usually structured as a collection of "key" = "value" records) objects.

The upshot of this is that they can be converted into interchange formats like JSON and exported as complete objects; Unlike the old Kismet protocol which was line-based and generally operated like a relational database:  Nested data had to be represented with multiple different server sentences, with a common key to correlate them.

By exporting complete objects, we are able to use a single request to represent an entire complex, nested entity.  By using introspectable objects, we're able to add new data to it without having to change the export code, which means plugins (and future Kismet code itself) can easily expand the data tracked for a device (or add whole new types of data), and by using a REST-like interface we can organize it simply and use common, standard protocols to access it.

Basic Interfaces

Currently Kismet data can be exported as JSON or binary Msgpack.  The format and field names on both should be identical - you can pick which you prefer by requesting a '.json' or a '.msgpack' field.  In the future, XML export may be possible, but JSON solves nearly all the problems XML would, and has simpler parsers in most languages.

Kismet also has a few special interfaces which export other data - notably the /system/tracked_fields.html interface which shows a HTML-formatted table of every named field Kismet knows about & their descriptions (great for looking up how a field is used without digging into the code), and the /phy/phy80211/handshake/[device]/[device]-handshake.pcap interface, which allows downloading a dynamically-created PCAP file.

Available Interfaces

All the currently available interfaces are defined in the webui_rest document:

which documents how to reach them, what they do, and what parameters they take.

There is a python class for handling interacting with Kismet and a collection of code doing interesting things with it at:

Part 2

Part 2 will focus on some of the specifics and provide some examples for doing interesting things, stay tuned!

A huge thanks to all who support Kismet on Patreon - if you'd like to help, you can become a patron here!

Monday, March 20, 2017

Discord (the good kind)

I've brought up a Discord server for chatting about Kismet related things: Kismet Discord

We're also on in #kismet for those who prefer IRC!

Tuesday, March 14, 2017

WPA Handshake Collection (Kismet git-master)

Another new feature in Kismet git-master:  WPA handshake collection!

Thanks to the new data format Kismet uses, it's possible to add additional complex fields to network records, trivially.  One of the fields we can add:  WPA packets!

This lets Kismet collect WPA handshakes and provide them as pcap files directly over the web ui.

Let's look for a network with captured handshakes

Kismet will highlight networks with a complete WPA handshake (or what appears to be a complete handshake) automatically.

For fun, you can also change the color of the highlighted network in the settings...

Look at the network details

The network details will show the handshake and offer a PCAP download if there is a complete handshake.  To be crackable, the handshake needs at least packets 1 and 2 or 2 and 3, and preferably all four packets of the handshake.  If you have insufficient packets, Kismet will warn you:

Internally this is stored as a bitset (where packet sequences 1, 2, 3, and 4 are bits 0, 1, 2, and 3 respectively) so scripts can easily check to see which handshake components a network has; rest_examples/ shows a quick use of this:

        if ((d['dot11.device.wpa_present_handshake'] & 0x06) == 0x06 or
                (d['dot11.device.wpa_present_handshake'] & 0x0C) == 0x0C):
            pkts = []
            for i in range(1, 5):
                if d['dot11.device.wpa_present_handshake'] & i:

Download the pcap

Download the pcap file.  You'll be prompted for your username and password you configured in kismet_httpd.conf - you did change the default password, right?

Take a look in Wireshark

You can open the pcap in Wireshark to take a look - you'll see that Kismet saves the handshake packets only, making a very small pcap file.  This is similar to trimming a much larger pcap file, only the packets required by Aircrack (or similar tools) are included.

Run Aircrack-NG

Or whatever tool you like; for Aircrack the syntax would be:

aircrack-ng -w wordlist -e UESC-N -b 0E-18-D6-9D-0D-AC 0E-18-D6-9D-0D-AC-handshake.pcap

Note that we provide the wordlist (-w), the ESSID (-e), and the BSSID (-b), and the PCAP we downloaded from Kismet.  You need all these parameters for Aircrack to detect the handshakes properly from the PCAP Kismet generates.

Let the magic happen 

Obviously this (also obviously doctored) screenshot took no time because we populated the wordlist with only one entry:  The known PSK for this network. 

Where to get it

This is in the Kismet git-master code, located at or at the Github mirror at if you want to live on the edge, and it will show up in the next major Kismet release including the web-ui and all the other new code.

Monday, March 13, 2017

Lots of new code in Kismet

Updates have been going to Twitter (@KismetWireless) but there's been a lack of content here:  Lets try to fix that!

Lots of new stuff:

  1. New object storage model.  
    Kismet now uses which is basically an introspectable dictionary structure to store all it's data internally.  Basically this means that instead of storing the data and then having to write custom output code for every type of interaction (logging, kismet client, etc), there is now a common data "blob" which can be turned into different things.
    This makes it tremendously simpler to add new features, new tracked elements, and non Wi-Fi data to Kismet.
    Even better, all the fields are documented on creation - every field in the hierarchy has a description and a human-readable name.
  2. Embedded webserver and web-ui.  Kismet now uses microhttpd to provide a built-in webserver capable of serving static (ie JS/HTML/etc content for the webui) and dynamic (REST-style endpoints with JSON data) content.
    The web-ui will be exposed to plugins so that they will be able to provide their own content to render custom data.
  3. Easily scriptable REST-style data.Instead of a custom TCP network protocol, Kismet now provides all the data via a REST-style web interface.
    This means scripts can pull data like network lists, packet rate, GPS location, battery status, everything Kismet knows, as standard JSON.

  4. Much simpler interface for non Wi-Fi dataThere is initial support already in Kismet now for some simple non-dot11 devices; wireless thermometers, weather stations, and other devices detected by the rtl433 tool for the RTLSDR, and Z-Wave home automation devices detected by KillerZee and a RFCat compatible tool, such as the Yardstick One.
    The new data structure allows new phy-handling code to plug into the existing device record and append new, arbitrary data structures, such as weather records, Z-Wave identifiers, etc
    Low-data-rate sources can even use the REST interface to submit data, which is how the RTL433 and KillerZee interfaces currently work.

More on the Web UI

The new web-ui allows much more data to be presented, as well as a huge amount of flexibility for displaying the information.  The web-ui is built on top of jquery and common open source jquery and js modules.

Using the seamless paging interface in jquery-datatables lets Kismet handle tens of thousands of devices with server-side sorting, filtering, and searching, while still being able to display reasonably on low-power devices, including mobile.

More coming

Development is going quickly on a number of new features & restoring currently broken functionality; coming soon will be the new packet capture framework, etc.  Keep an eye out for future posts with more info about new features.

What's broken

The new code is under heavy development so there's a number of things which don't currently work:  Text logging (text/netxml) and GPS logging (gpsxml) currently are disabled, filtering doesn't work, most plugins are unlikely to be happy or even compile, and various other subsystems have issues and quirks.

All of these are being addressed, of course.

Jumping in

If you want to jump in on the latest dev code, it's available from the git-master branch at either or 

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