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 (http://www.alftel.com) 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 http://www.alftel.com 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)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|: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!