KisBee status

Latest status on the KisBee zigbee sniffer project:

* Version 2 of the boards is done, and looks like it will be the final rev:

It uses the Microchip MRF24J40 integrated radio board, which puts all the RF on the radio module and doesn't require a quad-layer PCB.  This makes assembly a lot simpler.

* Prototype build of V2 boards done and tested, except for battery charger circuit:

It will work with either a case/chassis-mount antenna jack, or a PCB edge connected SMA adapter and a RF jumper cable.

* Firmware is based on the microbuilder lpc1343 library and is largely done; radio packet reception works, bluetooth link works, usb link works.

* Battery pack will be Li/Poly and should provide a reasonable run time; the majority of the power will be drawn by the zigbee and bluetooth radios.

Assuming all goes well, hopefully the firmware will be finished soon, emulating a zigbee-serialdev, then the fun of getting proper zigbee decoders in Kismet starts, the current zigbee code isn't written for phy-neutral and isn't very good right now.

As long as the battery charger circuit works out (waiting on some connectors) then the board is ready for larger-scale fab and hopefully I can think about offering kits soon for those who are interested.

More info at:
https://www.kismetwireless.net/kisbee/

Android hidden AP weirdness

@jduck1337 brought this to my attention:

http://seclists.org/bugtraq/2012/Mar/50

It was too long-form to continue the discussion on Twitter, so here we go:

The bug is, basically, that when looking for a hidden AP, Android doesn't care what the BSSID of the response is, ie, it doesn't cache the BSSID of known hidden SSID APs.

This actually doesn't seem, to me, like a bug at all.  The BSSID is not relevant to association, the SSID defines the network.  On a multi-AP roaming network any number of BSSIDs could reply to a probe request for a hidden network.

The assumption that being able to reply as the hidden network leads to loss of credentials doesn't make any sense either:  Sure, the client will try to talk to you to do a WPA handshake, but if you don't know the key, it won't succeed, and it trying to associate won't give you insight into the key.  Also this doesn't give you anything that setting up a generic rogue wouldn't give you.

So unless there's something I don't understand going on, I don't see the threat.  I don't even see the bug - when you send out a probe to see who is out there, you have to expect any number of responses, and the whole mechanism of roaming is to go to a new BSSID.  From the bugtraq post:

5. Turn off the first AP
6. Turn on the other AP
7. See your Android device automatically connect to the second AP

This is exactly how roaming is SUPPOSED to work, this 

doesn't seem like a bug to me.

Anyone see something I don't? 

Android Kismet progress

Android process management sucks.  It's almost as if they don't want you to exec a native binary sanely (hint - they don't.)  This made it impossible to clean up a Kismet server process if a new apk was deployed, or the thread crashed, or whatever.

Ended up porting Kismet to run as a NDK shared library by adding a small wrapper that turns a jstring into an argc/argv[] pair and wraps main(), then runs the whole show in a java thread as a JNI call.

Tossed together a ridiculously basic Kismet client in java to get a display back on the main window; previously it scraped stdout from a kismet_server binary running via Runtime.exec.  All the client does right now is turn off *TIME and turn on *STATUS


(full-size)

Everything but the UI runs in a service which stays running in the background.  Because currently kismet runs in a sharedlib with effectively no mods (added an ifdef to not build tuntap), it isn't killable as a thread.  A future mod would be to add a jni call that clobbers globalreg->fatal-condition to cause a kismet shutdown.

Right now Kismet throws some spurious errors because it isn't configured  to have any writeable directories to store tags, etc.  I don't care right now.

Thanks to Laen and Dorkbot, got some USB power injector boards being made as well:



Super simple board to pull 5v from a battery pack, and prevent VCC from the phone from being connected to the radio.

Kismet on Android

So it's super unstable, but Kismet can run on android now:



Requires Android 4.x for USB host, does NOT require root.

Packets are captured with userspace rtl8187 driver written in java, sent to a kismet-drone work-alike also written in java, which allows an unmodified kismet_server to read them.

Output is kluged into a textview to at least be able to see what's going on.

Currently the code doesn't channel hop, though that should be possible without too much trouble.  The process.exec thread doesn't kill off kismet_server when the background service ends, there's usb init timing problems, etc, but it's a major step forwards.

Ultimately, kismet_server will be hidden completely and the Java UI will tap the kismet client protocol for a native display.

Still... progress!  Code and test apk to come in the future.

Capturing raw 802.11 on android

Short answer: It's not really possible, definitely not on an unrooted device, if you're using the built-in nic.  The drivers and firmware aren't monitor mode friendly, and you'd need to root the device (and give the app root) to be able to even attempt.

Giving android apps root terrifies me - it places 100% trust in the developer to not be malicious, and the market to have not presented you with a cloned project that IS malicious, and in the developers systems to make sure no-one can ever push an update using their keys that becomes malicious... it's bad news all around.

Fortunately, in Honeycomb and in ICS, they've added USB host mode.  Unfortunately, in honeycomb something seems to not be quite right with it (but honeycomb is a dead end anyhow, most devices with it should be seeing an ICS update very soon), and there's only one official ICS phone right now.

The android USB API is very similar to libusb.  It's possible to compile libusb on android in the NDK.  Unfortunately, claiming a device via the android USB api does NOT make the endpoints directly writeable to the app uid.  There is a method to shunt the USB file descriptor to a native segment, which may prove useful in the future.

Even without using native code, it's possible to bit-bang a USB device directly using the Android java API; a simple example is the Wi-Spy, which has a pleasantly simple hardware interface...



There's nothing innately special about a wifi device, in USB terms, other than general complexity.  Having crazy ideas sometimes, I took chunks of the Serialmonkey rtl8187 driver, the macusbwifi port of it to mac userspace, and the linux kernel driver for rtl8187, and mangled them into a 2500 line pure-java implementation of the driver, with IO shunted through the android USB API:

I/ActivityManager(  206): Start proc net.kismetwireless.android.rtl8187 for activity net.kismetwireless.android.rtl8187/.Rtl8187Activity: pid=1965 uid=10072 gids={}
D/rtl8187card( 1965): device interface count: 1
D/rtl8187card( 1965): open SUCCESS
D/rtl8187card( 1965): hwaddr 0:c0:ca:21:9d:ef RTL8187BvB V1+RTL8225
E/rtl8187card( 1965): 8187z2 rf calibration failed: e6
D/rtl8187card( 1965): rtl8225z2 set tx power
D/rtl8187card( 1965): Initialized card hardware
D/rtl8187card( 1965): Started rtl8187
D/rtl8187card( 1965): Successfully calibrated & started hw
D/rtl8187card( 1965): Set channel 11
D/rtl8187card( 1965): Initializing URB request for max 512

I'm honestly not sure at the moment why the rf calibration code is getting a failure bit set, that will be a problem to look at in the future.

The result?

D/rtl8187card( 1965): Packetdata 2...
  Data 80 00 00 00 ff ff ff ff ff ff 00 24 6c a7 87 70     ...........$l..p
  Data 00 24 6c a7 87 70 b0 11 81 d1 fb 01 00 00 00 00     .$l..p..........
  Data 64 00 31 04 00 10 65 74 68 65 72 73 70 68 65 72     d.1...etherspher
  Data 65 2d 77 70 61 32 01 08 82 84 0b 16 0c 12 18 24     e-wpa2.........$
  Data 03 01 0b 05 04 00 01 00 00 2a 01 00 32 04 30 48     .........*..2.0H
  Data 60 6c 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04     `l0.............
  Data 01 00 00 0f ac 01 00 00 dd 18 00 50 f2 02 01 01     ...........P....

The post mangles the formatting a little, but it's clearly a beacon packet (0x80), the SSID is visible, we're in good shape!

The code currently needs a lot of care and feeding before a release, though hopefully by Shmoocon I can show some basic results.

In theory there shouldn't be much trouble porting the Kismet core over to the phone and shunting the packets through the JNI interface to that, and letting the existing code to the decoding and logging, but I haven't started on that yet.

The battery drain on the phone is pretty significant - I'm kind of amazed it can handle it at all, considering some netbooks can't drive these Alfa nics.  A hard-drive power Y cable offsets it to some extent, someone suggested making a custom cable which severs VCC from the device and uses the aux connector exclusively, this seems like a pretty good idea to me.

Reaver / WPS Brute Force IDS

Thanks to Render and Dutch for pushing on this and contributing pcaps.

Kismet-SVN now detects a WPS brute force attack underway via tools such as Reaver.

Reaver exploits a weakness in WPS which reduces the potential keyspace to 11,000 PINs, exploitable in a matter of hours.

Kismet WPS brute-force detection alerts on an access point which is doing an unusual amount of WPS traffic, specifically by monitoring for the M3 exchange of the WPS handshake.  An access point should only perform a WPS exchange with new clients, excessive WPS communications indicate a likely attack.

The WPS detector is implemented in the newly minted phy-neutral tracking layer of Kismet, which will become the primary tracking code in the next release of Kismet.  As such, alerts are available from the client protocol under the standard *ALERT sentence, but will not be attached to the network list in the Kismet UI due to pending changes to code.

Further enhancements to WPS brute force detection may be forthcoming soon depending on development.

To be most effective, Kismet should be locked onto the channel of the AP being monitored, however depending on the frequency of the attack, a channel-hopping instance should also detect it.

[Update] When testing, don't forget to enable the WPABRUTE alert in your kismet.conf!

[Update #2] Also included in Kismet-SVN by popular demand is a basic Ruby client which bridges Kismet alerts to syslog:

Jan 10 11:15:27 drd1812 kismet: WPSBRUTE server-ts=1326212106 bssid=00:14:D1:E6:8F:F8 source=00:14:D1:E6:8F:F8 dest=18:3D:A2:4A:65:80 channel=1 IEEE80211 AP 'rootsdkwlan' (00:14:D1:E6:8F:F8) sending excessive number of WPS messages which may indicate a WPS brute force attack such as Reaver

[Update #3] Kismet-SVN now includes the plugin-alertsyslog server plugin, which also logs alerts to syslog, without needing ruby or needing to run a separate client.

[Update #4] Expanded the timeline for WPS brute detection to 5 minutes to catch more during channel-hop configs.  WPS negotiation is so rare that this shouldn't be triggering false positives even with the expanded window.

Kismet SVN code is available via svn co https://www.kismetwireless.net/code/svn/trunk kismet-devel

Shmoocon

I'll be at Shmoocon again this year, running the wifi.  Drop me an email if you want to get a drink or something, or come find me, probably in the NOC.

Warning: I'm often a bit out of it at cons that I'm doing work at, so if I'm a bit scatterbrained, forgive me.