Thursday, November 16, 2017


Working with Department13, Kismet now supports the DroneID UAV telemetry extensions!

What is DroneID?

Drone ID is a set of records created by DJI (the drone/UAV company) for identifying UAVs.
DJI intends to release drone ID as a public standard, but have preemptively enabled it across much of their hardware line. Through the efforts of several firmware reverse engineers (Freek van Tienen and Jan Dumon), we have the structure of the data being sent; more info is available in Freek's repository at github
A device with Drone ID enabled broadcasts the serial number, current location, height, horizontal and vertical speeds, pitch, roll, yaw, and the home location of the drone (where it took off from, and where it will return after a go-home command or loss of control.

Deep-diving into Drone ID

For more info about the Drone ID packet format and how it's used, check out the D13 white paper Anatomy of DJI Drone Identification Implementation.

Drone ID in Kismet

For Wi-Fi devices, the DroneID is attached to the beacon frame as a Vendor IE tag (tag 221); Kismet decodes this with a Kaitai parser and attaches it to the packet decoding records.
Kismet defines a new, generic phy, which it attaches to device records; A Wi-Fi device beaconing DroneID packets will contain both dot11.device and uav.device records:
"dot11.device": {
    "dot11.device.typeset": 1,
    "dot11.device.client_map": {},
    "dot11.device.advertised_ssid_map": {
        "447349704": {
            "dot11.advertisedssid.ssid": "Mavic-380000",
            "dot11.advertisedssid.ssidlen": 12,
            "dot11.advertisedssid.beacon": 1,
"uav.device": {
    "uav.manufacturer": "",
    "uav.serialnumber": "08RDE150010000",
    "uav.last_telemetry": {
        "uav.telemetry.location": {
            "": 40.000000,
            "kismet.common.location.lon": -83.00000,
            "kismet.common.location.alt": 273,
            "kismet.common.location.speed": 0,

Kismet tracks the serial number, home location, most recent telemetry location, and the past 128 telemetry locations.

Finding drones via the Kismet API

Devices which include DroneID records will have a 'UAV / Drone' category in the device details, but it's also possible to automate using the Kismet API.
The regex API in the Kismet REST interface allows for easy matching against drones, for example from the rest_examples/ script:
def per_device(d):
    print d['kismet.device.base.macaddr'],
    print d['dot11.device']['dot11.device.last_beaconed_ssid'],
    print d['uav.device']['uav.serialnumber'],
    print d['uav.device']['uav.last_telemetry']['uav.telemetry.location'][''],
    print d['uav.device']['uav.last_telemetry']['uav.telemetry.location']['kismet.common.location.lon']


kr = KismetRest.KismetConnector(uri)

regex = [
    [ "uav.device/uav.serialnumber", ".+" ]

kr.smart_device_list(callback = per_device, regex = regex)

Monday, October 16, 2017

WPA, the Krack Attack, and Kismet

The Krack Attack

[ Edited on 2017-10-17 to include definitive information about the ESP chip, additional commentary on TKIP mode, device scanning, and commentary on who it impacts]

[ Edited on 2017-10-19 to include additional info about Kismet alerts and clarification on what Krack is /not/ ]

Of course you've heard about the Krack attack by this point:

I strongly recommend reading the krackattack site, if not the full paper, too: They do an excellent job describing the attack and the real-world impacts. 

Definitely everyone should read the Q&A section first!

What it is

  • A collection of vulnerabilities that impact both access points and clients.
  • A method to decrypt some traffic, and on some specific clients, all traffic.
  • The largest vulnerability in the WPA suite to date, by a wide margin.
  • A very significant attack against Linux, Android, and OpenBSD clients.
  • Something to be concerned about and patch for.

What it isn't

  • A method to expose the WPA key.
  • A method to compromise encrypted communications (VPN, HTTPS, SSH, etc)
  • A method to compromise corporate credentials via EAP (assuming proper client configuration)
  • The end of the world.

How it works

There are many other breakdowns of the attack, including the excellent one on the Krack website itself, but at a 1000-foot-view:

WPA establishes a per-session key via 4-way handshake system which passes a public component of the unique session key (the Nonce).  By creating a fake access point and manipulating the handshakes, it is possible to fool a device into re-using a keystream; given two packets encrypted with the same keystream, it's possible to derive that keystream and decrypt them (but NOT the passphrase, remember).

Some devices have additional vulnerabilities (those using wpa_supplicant from Linux, including Android) which cause them to essentially disable encryption completely - resetting the key to all zeroes.

Detecting Krack with Kismet

The git-master version of Kismet is introducing alerts to attempt to detect a Krack-style attack underway.  To accomplish this, Kismet tracks several things used by the attack:
  1. Spoofed AP/Multichannel AP detection.  Kismet has had a long-standing alert for access points changing channels.  Currently, to manipulate the handshakes, the Krack vulnerabilities clone an access points MAC, but on a different channel.  Kismet will generate CHANCHANGE or BSSTIMESTAMP alerts for the two conflicting access points.  This is likely the most obvious indication that an attack is ongoing, however as the attack is refined in the future it may no longer be obvious.
  2. Key removal/degradation.  This variant of the attack is used against OpenBSD clients, and transmits a handshake with a zero-length key and zero nonce.  Kismet detects this by a fingerprint and raises the NONCEDEGRADE alert.
  3. Nonce retransmission.  Nearly all of the attacks in the Krack suite retransmit a previously used Nonce value, either as the 3rd handshake Nonce, or the first handshake ANonce value.  Kismet tracks the previous 128 Nonce and ANonce handshakes seen, and if a repeated Nonce is spotted, raises the NONCEREUSE alert.
Currently, most of the described Krack attacks - replaying a Nonce against a traditional supplicant - require spoofing the access point.  This should, in almost all cases, cause Kismet to be very noisy regarding the CHANCHANGE or BSSTIMESTAMP alerts.

In the future it may be possible to optimize these attacks so that there is no visible duplicate AP, but the current state of those attacks should be very obvious.

The 802.11r FT injection appears to be much more subtle - and much more difficult to detect, as different vendors implement the IV reset process differently.  Additional research will be needed to create an alert for those attacks.

Weaknesses in detecting Krack with Kismet

To detect the Nonce re-use, Kismet needs to actually observe the handshake packets.  Typically, Kismet channel hops across all channels supported by a card; this reduces the chance that Kismet will see the handshake.

Kismet supports multiple data sources simultaneously - this increases the chance of capturing the nonce, but also can introduce some false positives if two cards see the same packet.  Kismet now has packet de-duplication, which is turned on by default, which attempts to detect identical packets seen by multiple sources; in practice, this system still needs tuning.

The 802.11 protocol allows for automatic retransmit of data frames which are not acknowledged - and EAPOL exchanges are data frames.  This leads to multiple, different copies of the same EAPOL frame potentially being seen - this is exacerbated by the fact that Kismet may see the original, while the receiver may not!  To combat false-positives on EAPOL Nonce replays, Kismet now uses the timestamp of the packet - multiple Nonce or Anonce injects (Frame 1 or Frame 3 of the handshake), with the 'Retransmit' bit set in the dot11 frame control, in a very short period of time (0.1s) will be treated as valid.

Once the proof-of-concept code is release (or alternate proof-of-concept code is developed), the logic of the alerts will need to be tested.

How do I fix it

Generally speaking, the only fix is to upgrade your devices - you'll need upgrades for your access point firmware as well as upgrades to all of your client devices.

If you are using Linux or OpenBSD, fixes for wpa_supplicant should already be available.  Similar fixes are available for Windows 10 and OSX.

If your access point runs OpenWRT or LEDE there may be updated packages available, either through the package repository or by compiling new firmware.

Fixes for Android will depend on the security schedule for your device.  Typically, Google devices get patches monthly, devices from other manufacturers may take longer to get patched.

Kristopher Tate has created a Github repo tracking the update status of various vendors at

Can I just disable TKIP?

While parts of the Krack attack impact CCMP (WPA2), the worst impacts appear to be against TKIP (WPA1).  Many access points support WPA1 and WPA2 simultaneously, which leads to using TKIP as a group cipher (required for clients to send broadcast packets to other clients, regardless of WPA association type).  This has led some people to recommend disabling TKIP as a group cipher in your access point; it is unclear if this is actually successful.  From the FAQ of the Krack documentation:
I'm using WPA2 with only AES. That's also vulnerable?
Yes, that network configuration is also vulnerable. The attack works against both WPA1 and WPA2, against personal and enterprise networks, and against any cipher suite being used (WPA-TKIP, AES-CCMP, and GCMP). So everyone should update their devices to prevent the attack!
This would imply that simply disabling TKIP isn't a silver bullet against the attack, unfortunately.  It may also cause problems with large installations / corporate networks with multiple devices.

Should you care?

This is a significant breach of the WPA security model.  You should care - but only to a point.

If you are responsible for a financial, high-profile corporate, or government Wi-Fi install, you need to care, and be able to explain the risk.  Fortunately, in these situations, you'll also likely have vendors to talk to directly as well as management of the devices on your network.

If you're a home user - probably not.  The chances are, there won't be roving gangs of hooded youths cracking all the WPA networks in the neighborhood. 

In either case: patching is important, and should be done as soon as possible, but the chance that a new WPA vulnerability with no (currently) released code is the weakest point in your network is pretty slim.  Update immediately.  Update your users and customers immediately.  Pressure your vendors to update if they haven't already.  Find the devices on your network which have not gotten updates.

Scanning for vulnerable devices

At this time, there is no simple way to determine if devices are vulnerable, however there should be tools available in the future from the Krack developer which can perform some active probing to determine if a stack is vulnerable.

Currently, the Kismet detections only detect the replay of nonces, and cannot passively detect vulnerable devices; if a method to do so becomes available, it will be included in Kismet.

Detecting vulnerable devices will be a particular problem for anyone who has to manage a BYOD network, where users may continue to bring outdated, vulnerable devices onto the network for the foreseeable future (such as unpatched Android devices).

The risk in the future

When WEP was first shown to be vulnerable, it required the collection of millions of packets over the course of hours or days before it could be attacked.  Once the method was refined, the network could be cracked in a matter of minutes or even seconds.

There is always the chance that this attack, or ones derived from it, will be refined into a much more significant, automated, or wide-ranging attack.  Patching as soon as possible is the panacea against this.

The largest risk in the future is likely to be devices for which no patch is available:  abandoned mobile devices which no longer receive patches from the carrier or manufacturer, appliances and vehicles with Wi-Fi included, and embedded and IOT devices which use a Linux or Android Wi-Fi stack including wpa_supplicant.  As bad, fully embedded systems based on chips like the ESP8266 may also be vulnerable.

The inability to update many devices in the wireless ecosystem means these flaws will persist and remain as potential jumping-off points for more advanced attacks against networks for a long, long time.

Thursday, July 27, 2017

Remote Capture

Kismet once again supports remote capture in git-master!

Remote packet capture allows multiple systems to report packets back to a single, central Kismet server.  This makes it simple to use light-weight, and usually cheap, embedded devices as remote sensors to expand physical coverage or logical channel coverage.

Remote capture uses the same binaries Kismet uses locally to capture from data sources - for instance, 'kismet_cap_linux_wifi'.  These super-lightweight capture drivers can run on almost any openwrt/lede supported system; the latest version is a 64Kb package, making it plausible to install on almost any device, including limited devices with 4MB of flash.

Remote capture binaries use a fixed amount of RAM - buffers are allocated at the start and are not dynamically adjusted - which means each radio capture uses approximately 4MB of RAM.

Remote capture sources use the same protocol as local, traditional sources - instead of an IPC channel the communication is piped over a TCP socket.  Kismet is able to track what source saw a packet, per-source GPS, using per-source or centralized timestamps, and is able to distribute channels and control channel hopping and other behaviors of remote sources.

More info is in the README:

xx. Remote Packet Capture

    Kismet can capture from a remote source over a TCP connection.

    Kismet remote packet feeds are initiated by the same tools that Kismet uses to
    configure a local source; for example if Kismet is running on a host on IP, to capture from a Linux Wi-Fi device on another device you could

        $ /usr/local/bin/kismet_capture_tools/kismet_cap_linux_wifi \
            --connect --source=wlan1

    Specifically, this uses the kismet_cap_linux_wifi tool, which is by default 
    installed in `/usr/local/bin/kismet_capture_tools/`, to connect to the IP port 3501.

    The --source=... parameter is the same as you would use in a `source=' Kismet
    configuration file entry, or as `-c' to Kismet itself.

    By default, Kismet only allows remote packet connections from the localhost IP; 
    you must either:

    1.  Set up a tunnel, for example using SSH port forwarding, to connect the remote 
        device to the host Kismet is running on.  This is very simple to do, and adds
        security to the remote packet connection:

        $ ssh someuser@ -L 3501:localhost:3501

        Then in another terminal:

        $ /usr/local/bin/kismet_capture_tools/kismet_cap_linux_wifi \
            --connect localhost:3501 --source=wlan1

        The `ssh' command places SSH in the background (using `-f'), connects to 
        the host Kismet is running on, and tunnels port 3501.

        The kismet_cap_linux_wifi command is the same as the first example, but
        connects to localhost:3501 to use the SSH port forwarding.

        Other, more elegant solutions exist for building the SSH tunnel, such 
        as `autossh'.

    2.  Kismet can be configured to accept connections on a specific interface,
        or from all IP addresses, by changing the `remote_capture_listen=' line in


        would enable listening on all interfaces, while


        would enable listening only on the given IP (again using the above example 
        of Kismet running on

        Remote capture *should only be enabled on interfaces on a protected LAN*.

    Additional remote capture arguments

    Kismet capture tools supporting remote capture also support the following options:


        Connects to a remote Kismet server on [host] and port [port].  When using
        `--connect=...' you MUST specify a `--source=...' options

    --source=[source definition]

        Define a source; this is used only in remote connection mode.  The source
        definition is the same as defining a local source for Kismet via `-c' or
        the `source=' config file option.


        By default, a remote source will attempt to reconnect if the connection
        to the Kismet server is lost.


        Places the capture tool in the background and daemonizes it.

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

Tuesday, June 6, 2017

Kismet Plugins - Web-only Plugins

The new Kismet plugin architecture is beginning to solidify, and as part of that, the ability to create plugins which only affect the Web UI is now in place.

If your plugin idea doesn't require any changes to how Kismet itself functions, and only modifies or adds to the Web UI, you can now do it as a runtime-loaded add-in with no C++ coding at all, and only minimal modification of the example Makefile.

The example code is in Kismet git under plugin-demo-webonly; you can browse it at .

All plugins, regardless of if they use C++ native code or only extend the web UI, have 2 files which must be present:
  1. Makefile, which tells the build system how to compile.  For web-only plugins this file is very simple, and the only change that needs to be made is changing the name of the plugin on the first line (PLUGIN_NAME ?= ...).  This plugin name is used to control the directory the plugin is installed into.
  2. manifest.conf, which tells Kismet about the plugin.  This is a simple config file that is very similar to the Kismet config files; it contains the name, description, author information, version information, and module information.
For a web-only plugin, the manifest only needs to define the name, version, description, and author fields.  To tell Kismet to load a JS object when the web UI is loaded, there also needs to be a 'js' parameter.

Plugins are automatically mapped into the Kismet webserver, serving content from [plugindir]/[pluginname]/httpd/ on the filesystem to the URL /plugin/[pluginname]/.  The plugin directory is automatically determined and mapped, regardless if it is installed system-wide or in a user directory; This means you can serve full content from your plugins httpd/ directory.

To dynamically load JS modules, Kismet expects a few standard conventions - the demo JS file in the example plugin shows the minimal basics, but for more information about how to automatically interface with the Kismet web UI framework, check out some of the developer docs:

  • explains how to use various endpoints in Kismet to get additional data
  • explains the format of Javascript modules and how to hook into existing functions in the Kismet UI, like adding settings panels, sidebar triggers, tabbed frames, etc
  • explains how to add additional details to the Kismet device details windows, which are shown when you click on a device.

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

Monday, May 22, 2017

Eliminating default passwords from Kismet

Kismet no longer uses a default password distributed in the kismet_httpd.conf config file; it will now auto-generate a random password and store it in ~/.kismet/kismet_httpd.conf

As part of this process, there are some new onboarding screens for Kismet:

Kismet will now show a local-only text alert (not sent to the browser or other message bus clients) showing the new password which has been generated.

Kismet will also show an alert that a new password has been generated, and warning existing users of the git-master code that the old config option is no longer used.

The first time you visit Kismet with your browser (or the first time for a particular browser - the setting is stored in HTML5 local storage so it is specific per browser), you'll get a welcome screen asking to take you to the settings panel.

The settings panel now describes the need to change the login.

Subsequent visits to the Kismet page will warn you if the password is invalid, and offer to take you to the settings panel.  If you're a guest on a server, or don't want to log in for some reason, these alerts can be silenced with the "Don't warn again" option.

Finally, the new settings handler can confirm the validity of the login and warn if it is not valid.

While these add a few extra steps, the added security of not having default logins potentially exposed to the Internet definitely outweighs it.

Installation-time passwords can still be set by using the httpd_username= and httpd_password= options in /usr/local/etc/kismet_httpd.conf, or in the per-user ~/.kismet/kismet_httpd.conf, and the random generated password can be changed by editing ~/.kismet/kismet_httpd.conf as well.

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

Monday, May 15, 2017

Fun with a new toy - Kismet on the Alftel Airbud

Alftel ( were very kind and sent me the production rev of their Airbud platform to get Kismet running on it.

Anyone who swung by the NOC at Shmoocon might have seen the pre-production Airbud running a demo there:

The final rev is a lot more elegant!

It's an Intel platform - which means it will happily run Ubuntu, Fedora, Pentoo, and so on - with an ungodly number of mpci-e slots for radios (8x on this model):

This one is stocked with Atheros 11n 2x2 which have been the most stable so far in testing - I've had nothing but misery with the ath10k reporting bogus packets in a HT data environment, and the Intel cards can get into monitor mode but seem to have firmware issues which cause the interface to reset during tuning.

Happily, Kismet's new datasource code handles the multiple interfaces just fine, and I think it's going to ultimately be a lot more stable than the older style code.  Previously, Kismet multiplexed all the sources into a single IPC channel and controlled them from a single process; under the new model, Kismet spawns a process per interface for capture.

Some interesting things happen with this many devices - even scanning both bands and all HT channels, the coverage graph stays pretty flat - we're able to cover enough channels simultaneously that Kismet can maintain a fairly constant view of the devices:

With an estimated coverage map (which is a lot more interesting when it's live and animated) of:

With the new data source REST API it should be possible in the future, with fairly minimal coding effort, to also assign a source to lock on to specific channels when a device is highlighted  - making sure to capture as much information as possible about a specific device or AP while the rest of the interfaces continue channel hopping.

If you're interested in the Airbud HW, check out the Alftel website at for more info.

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

Wednesday, May 10, 2017

Pcap over HTTP and other fun

Pcap over HTTP!

Kismet git-master now supports fetching pcap logs over the HTTP REST interface!

$ curl -s  http://kismet:kismet@localhost:2501/datasource/pcap/all_sources.pcapng | tshark -r -
    1   0.000000              → ImpathNe_a2:76:f2 (00:03:d8:a2:76:f2) (RA) 802.11 50 Acknowledgement, Flags=...P....C
    2   0.133960 06:18:d6:9d:0d:ac → Broadcast    802.11 252 Beacon frame, SN=1654, FN=0, Flags=........C, BI=100, SSID=UESC
    3   0.184984 16:18:d6:9d:0d:ac → Broadcast    802.11 254 Beacon frame, SN=2266, FN=0, Flags=........C, BI=100, SSID=UESC-N
    4   0.236459 06:18:d6:9d:0d:ac → Broadcast    802.11 252 Beacon frame, SN=1655, FN=0, Flags=........C, BI=100, SSID=UESC
    5   0.273332 D&MHoldi_a0:8f:26 → Broadcast    802.11 142 Probe Request, SN=9, FN=0, Flags=........C, SSID=                                

Not only that, but Kismet now supports the pcap-ng file format; this new format allows for multiple interfaces in a single capture file, as well as conflicting linktypes in a single capture.

There are a few trade-offs:  Programs written using traditional libpcap (tcpdump, many other utilities, and Kismet itself) can handle pcap-ng files with a single link type, but cannot currently handle mixed link types in the same capture file - so for instance mixing Wi-Fi and future non-Wi-Fi packets may cause a problem.

No worries - you can also capture packets from a single specific interface, by UUID:

$ curl -s http://kismet:kismet@localhost:2501/datasource/pcap/by-uuid/5fe308bd-0000-0000-0000-a0f3c10cbf1c/packets.pcapng | tcpdump -r -
reading from file -, link-type IEEE802_11_RADIO (802.11 plus radiotap header)
13:55:38.239867 913824498us tsft 24.0 Mb/s 2437 MHz 11g -86dBm signal -86dBm signal antenna 0 Acknowledgment RA:00:03:d8:a2:76:f2 (oui Unknown) 
13:55:38.263293 913845355us tsft 24.0 Mb/s 2437 MHz 11g -86dBm signal -86dBm signal antenna 0 Acknowledgment RA:00:03:d8:a2:76:f2 (oui Unknown) 
13:55:38.265179 913847499us tsft 1.0 Mb/s 2437 MHz 11b -95dBm signal -93dBm signal antenna 0 Beacon (A276EC) [1.0* 2.0* 5.5* 11.0* 6.0* 9.0 12.0* 18.0 Mbit] ESS CH: 6, PRIVACY
13:55:38.303905 913886656us tsft 1.0 Mb/s 2437 MHz 11b -89dBm signal -89dBm signal antenna 0 Beacon (UESC) [1.0* 2.0* 5.5* 11.0* 18.0 24.0* 36.0 54.0 Mbit] ESS CH: 6, PRIVACY

Saving pcaps dynamically

Pcap logs are sent as a constant HTTP stream, streaming the live packet data out of Kismet.  If you have configured your Kismet instance to use HTTPS, they'll be encrypted of course.  They can be send directly to tools via pipes as in the above examples, or they can be sent to a file:

$ wget --auth-no-challenge http://kismet:kismet@localhost:2501/data/all_packets.pcapng -O packets.pcapng
--2017-05-10 13:58:28--  http://kismet:*password*@localhost:2501/data/all_packets.pcapng
Resolving localhost (localhost)...
Connecting to localhost (localhost)||:2501... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified
Saving to: ‘packets.pcapng’

packets.pcapng             [       <=>                 ]  15.41K  2.16KB/s

Better data!

Because pcap-ng allows us to retain the original link types, Kismet now logs the original radiotap data instead of converting it to PPI.  This preserves the entirety of the radiotap header - the MCS encoding data, the per-antenna signal data, everything held in the original record is now present in the output:

More coming soon...

Expect additional built-in pcap filtering endpoints coming soon - per-phy, per-bssid, and multi-bssid are on the list, as well as options in the UI to link to downloading pcaps directly.

As the new logging infrastructure evolves in Kismet pcapng will become the standard logging format for constant logging as well, with the option to split into multiple files recording a stream per source, or a single file combining all the sources.

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