Jul 11

Wireless Privacy Loss++; Amazon Kindle

Kindle DX

Kindle DX

Fellow hacker and all-around rock-star Sherri Davidoff and I have been chatting lately about a new form of privacy loss from Amazon in the form of the Kindle.

I’m a big Kindle user, and I love having a good deal of my tech library with me on the Kindle DX when I travel. When I’m on-site with a customer and want to reference something from the Database Hacker’s Handbook, for example, I can buy and download it in a minute. The alternative is to find a Border’s, drive there, buy the book, drive somewhere else because the first store didn’t have it, drive back to the customer and waste precious on-site engagement time. With the ability to read full 8.5×11 PDF’s as well (the ZigBee-2007 PDF is keeping me busy at the moment), it’s well worth the cost of the unit.

However, it turns out that the Kindle keeps track of what you read. Presumably, this is just for synchronizing your last-read page across e-readers, but I suspect a company that recognizes the value of customer information such as Amazon wouldn’t let this be the only thing they collect about their e-book users.

Check out Sherri’s post on this topic on philosecurity.com.

Privacy loss often comes in convenient forms; TiVO cataloging each second of TV you watch and skip, the Nike+iPod leaving a RF breadcrumb trail for where you go and who you associate with and many other examples. If anyone knows what Amazon’s policy is on the information they collect about Kindle users, I’d love to hear it.

Also check out my presentation from SANS 2009 titled “Privacy Loss in a Pervasive Wireless World.”

-Josh

Jul 09

802.11 Pocket Reference Guide

802.11 Pocket Reference Guide Sample

802.11 Pocket Reference Guide Sample

I’ve posted my IEEE 802.11 pocket reference guide to the Projects Section. This legal-sized guide provides some quick-reference resources for wireless analysis including common acronyms, Wireshark display filters, Kismet shortcuts and a breakdown of several of the IEEE 802.11 header fields. This will be especially helpful to my SANS SEC617 Ethical Hacking Wireless students!

-Josh

Jul 03

Cowpatty 4.6 (with less teh suck)

As it turns out, there was a pretty significant bug in cowpatty 4.5 and earlier when built on systems with a more modern version of OpenSSL than what I was testing against:

        typedef struct {
            unsigned char k_ipad[65];
            unsigned char k_opad[65];
            unsigned char k_ipad_set;
            unsigned char k_opad_set;
        } SHA1_CACHE;

        struct SHA1_CACHE cached;
        SHA1_CTX context;

        /* ... */

        if (usecached) {
            /* Cache the context value */
            memcpy(&cached.k_ipad, &context, sizeof(context));
            cached.k_ipad_set = 1;
        }

When I looked at this I realized what the problem was right away: I was stupid when I wrote this code.

One of the ways we can accelerate WPA2-PSK cracking is to cache values that are computed each time during SHA1 rounds; namely the inner and outer pad hashes (ipad, opad). I implemented this in cowpatty and created a data structure SHA1_CACHE to store the hashed value with a field to indicate if it was currently cached or not.

At the time, OpenSSL’s SHA1_CACHE structure was 64 bytes; I created my structure members at 65 bytes (why not 64 bytes? Because I was stupid when I wrote this code). Perfect!

All worked well until I recently discovered that the SHA1_CTX structure is now 96 bytes, which did not fit so well in my 65 byte data structure.

The lesson here: don’t try to recreate the wheel. This is how I fixed the problem, and how I should have done it back in 2005:

        typedef struct {
            SHA1_CTX k_ipad;
            SHA1_CTX k_opad;
            unsigned char k_ipad_set;
            unsigned char k_opad_set;
        } SHA1_CACHE;

Instead of relying on a static byte length that once characterized the size of SHA1_CTX, I should have just used the real thing. I’ll remember this lesson in the future, and hopefully you won’t make the same mistake I did.

You can snag the latest version of cowpatty here. Special thanks to Kevin Kestinggolrer, Philipp Schroedel, Max Moser and Nathan Grennan, Jason Franks and Michal Knobel for hitting me with their various clue-sticks.

-Josh

Jun 04

Cowpatty 4.5

After too much time I have posted coWPAtty 4.5 with several fixes and a couple of new features:

  • Fewer restrictions on collecting the data needed to mount an attack.  The default behavior requires all 4 frames of the 4-way handshake to mount an attack.  If you specify “-2” on the command-line, coWPAtty will only require frames 1 and 2 of the 4-way handshake to mount an attack.  More on this below.
  • Validate that the needed information is present to mount an attack, without launching the attack (the “-c” option).  This was requested by Pure Hate for an awesome project he gave me a preview on.  I’m hoping details of this project will be public soon.

The “-2” option also includes fewer restrictions for validating the content of the packet capture.  This was implemented by a patch submitted by Nathan Grennan, accommodating some AP’s that do not strictly adhere to the IEEE 802.11i/IEEE 802.11-2007 specification.

Removing the restriction of needing all 4 frames of the 4-way handshake to mount an attack has some interesting implications.  First, packet captures taken while channel hopping often miss parts of the 4-way handshake, since they can hop in the middle of the 4-way handshake exchange.  Relying on only frames 1 and 2 gives you a better chance of catching the needed data even if you are channel hopping.

coWPAtty "-2" utilization example

coWPAtty "-2" utilization example

Second, it provides the ability for an attacker to mount an attack against a client even if they aren’t within range of their target network (for example, a WPA2-PSK user is at the airport).    Consider the following illustration:

Cowpatty Attack Scenarios

Cowpatty Attack Scenarios

On the left is an example of what I consider a traditional WPA2-PSK attack.  The attacker gets within physical proximity of the target network and waits for (or coerces) the 4-way handshake between an AP and a valid client system.

On the right, however, is a less-understood attack scenario.  In the 4-way handshake, the client system authenticates first, sending a HMAC-MIC of frame 2 to the AP.  If an attacker impersonates the legitimate SSID of the network, they are able to send Frame 1 of the 4-way handshake (no authentication) and observe the HMAC-MIC of frame 2.  At frame 2, the attacker has everything they need to recover the PSK (now with cowpatty’s “-2” option).  Frame 3 fails validation by the client, but by that point, it’s too late.

In practice, I’m testing this using HostAP running on my attack workstation, but that’s not even necessary.  Simply take any SOHO AP, configure the SSID to reflect that of your vistim with any pre-shared key and observe the exchange between the victim and the imposter AP, supplying the packet capture to coWPAtty with the “-2” option.

My transition to work for InGuardians has given me a chance to spend more time on penetration tests. As a result, I’ve started to change my mind about the value of “weaponized” attack tools. If the tool isn’t reliable, works under many circumstances and flexible enough to withstand an error or two, it takes much longer to be useful, and that costs your customer more. I’m using this as a motivator to make tools more effective, capable of demonstrating a point, and thereby allowing you to providing greater value to your customer.

I’d love to hear comments and questions. Please add a comment below, or send me a note.

-Josh

May 26

Kismet Newcore RC1 Released

Just a little while ago, dragorn released RC1 of Kismet-Newcore, the much-awaited next-generation of Kismet. From the release news:

After 5+ years of development, this staging release is to work out any final minor issues before a full release. Kismet-2009-05-RC1 is expected to be fully functional, so please report problems on the forums or via email. Please read the new README and replace your configuration files, as just about everything about configuring Kismet has changed (for the better!) The old Kismet tree also sees a new release as Kismet-old-2009-05-R1, which incorporates minor fixes and support for some of the newer Intel and Ralink cards/driver names. Both are available from the download page.

Kismet-Newcore Screenshot

Kismet-Newcore Screenshot

I’ve been moving away from using Kismet-Stable to the Kismet-Newcore architecture. On my short-list of awesome-new-features in newcore are:

  • Plugin architecture makes it easy to add new functionality (passive and active) which promises to introduce significant new features on a more regular basis, not the least of which are support for DECT sniffing, live Aircrack-PTW WEP cracking and (coming soon?) ZigBee sniffing;
  • Improved security model using suid-root group-exec-only interfaces;
  • Lots of greater functionality in capture sources including improved channel hopping controls and graceful interface termination with dynamic interface adding (no more exiting Kismet to add or remove an interface from use);
  • Save state feature where you can resume a previous capture state by running “kismet -r” on the runstate file;
  • New menu-driver Kismet client interface which shows you the interesting information at a glance;
  • Lots of new alerts and informational events help you in analyzing and assessing networks.

The development leading up to this release has been long in coming, and cheers to dragorn for continuing the introduce awesome new features that push the edge of what this powerful tool can do.

Take a look at the new Kismet-Newcore and enjoy this gem of the open source community.

-Josh

May 13

Wlan2eth 1.2 Release

Wlan2eth is a tool I wrote to convert 802.11 packet captures into Ethernet-style captures; I find this useful when working with various sundry tools that don’t properly handle 802.11 frames.

Adrian Crenshaw sent in a bug report for wlan2eth where he was getting the following output:


$ ./wlan2eth ../forjosh.pcap out.dump
Converted 0 packets.

Turns out I didn’t have support for other 802.11 packet capture link types (Adrian was using PRISM_AVS). I’ve updated wlan2eth to fix this issue, while adding support for Ad-hoc network captures as well.

Questions/Comments/Concerns?

Thanks,

-Josh

May 11

Locating ZigBee Devices

ZigBee Device Finder

ZigBee Device Finder

Since the introduction of the ZigBee-2004 specification, the ZigBee Alliance has made significant improvements in the security of sensor-based wireless networks. Despite improvements introduced in later amendments including the ZigBee-Pro specification, the security is not bullet-proof, due to the significant constraints of CPU, flash and memory availability in low-cost devices. Designing around these constraints, the ZigBee Alliance has made reasonable security options available to vendors of ZigBee products, broadly classifying security levels into high-security mode (intended for enterprise applications) and low-security mode (intended for residential applications). Looking at the available offerings for ZigBee stacks from vendors such as Atmel, Microchip and TI, it is apparent that high-security mode costs more, not necessarily in software costs but in terms of memory, flash and CPU requirements.

If you read up on ZigBee, you’ll quickly identify the Achilles’ heel plaguing the security of any low-cost wireless technology:

“… due to the low-cost nature of ad hoc network devices, one cannot generally assume the availability of tamper resistant hardware. Hence, physical access to a device may yield access to secret keying material and other privileged information, as well as access to the security software and hardware.”
ZigBee Specification 053474r17, Jan. 2008; available from www.zigbee.org
ZigBee CC2420

ZigBee CC2420

Effectively, if you use sensor-based networks, and an adversary is able to steal a device, they can extract key information from the hardware which can be used to exploit the rest of the network. This style of attack has been demonstrated by my neighborly colleague Travis Goodspeed on multiple occasions, snagging encryption keys, dumping device firmware and many other interesting hacks with hardware in hand.

Following Travis’ article, a few people submitted posts indicating that while his attack is interesting, it requires hardware to be effective. Today, we’re a little bit closer to making that reality.
.

Introducing zbfind – ZigBee Location Tracking

Following my previous work on reversing the Microchip Zena ZigBee sniffer, I put together a quick Linux tool to passively sniff for the presence of ZigBee/802.15.4 devices and display some summary information about the identified devices. When a device is selected in the GTK UI, a speedometer needle and histogram will record the relative signal strength of the selected device with a relative distance estimate in feet using the free-space path loss formula. A screen-shot is displayed at the top of this post.

Readers from my SANS Ethical Hacking Wireless course will recognize this UI; it’s based on a tool Mike Kershaw and I wrote for Bluetooth analysis (that has yet to be released, but we have big plans for it, stay tuned). This initial code is a little rough around the edges, but provides a simple interface to track down and identify ZigBee and other 802.15.4 devices in the area.

I’m holding off on releasing this tool until I iron out a few more bugs, but am happy to share the code individually if folks 1. have a Microchip Zena Sniffer and 2. have experience with Linux and Python. Drop me a note if you are interested and meet these conditions (I don’t mean to be unfair, but I want to spend my time working on the code to add features and fix bugs instead of helping users, at the moment; thanks for understanding).

My Goals

My goal in releasing this tool is simple: provide administrators with the firepower to justify the added cost of enterprise-security ZigBee technology with hardware tamper-proof security features. If the tools don’t exist publicly, many people disregard the threat. By making this tool available, I’m hoping people will be able to use it as an argument to justify more expensive ZigBee hardware deployments where warranted by security policy.

-Josh

May 10

Reversing the Microchip Zena ZigBee Sniffer

Microchip Zena Network Analyzer

Microchip Zena Network Analyzer

A few days ago I bought a Microchip Zena ZigBee sniffer. This USB HID device comes with simple software for Windows that captures and decodes 2.4 GHz 802.15.4, ZigBee, MiWi (Microchip stack) and MiWi-P2P traffic. It’s $150, which is a little steep considering that it is a PIC18LF with USB and a MRF24J40 radio, but I’ve had fun playing with it all the same.

The Zena 3.0 sniffer software provides a basic per-packet view of frames. I guess we are all spoiled by Wireshark, but I was hoping for more detail and a better UI. The Zena sniffer can save a capture in a proprietary file format, and can export selected frames (to the clipboard) in space-delimited hex bytes.

A cool accompanying feature is the network configuration display interface where Zena will identify all the parent/child relationships observed. You can specify a BMP background as a floorplan and move the nodes to their physical locations as well.

Zena Packet Capture Tool

Zena Packet Capture Tool

Zena Sniffer Network Configuration Display

Zena Sniffer Network Configuration Display

SnoopyPro Capture of Zena USB Traffic

SnoopyPro Capture of Zena USB Traffic

With no Linux support, I decided to write my own user space Linux driver to capture packets with the goal of integrating it into libpcap captures and other tools including Kismet Newcore. Plugging into a Linux box, it was clear that the device was using the USB HID, which was good news for me since it would be simpler to reverse the configuration details. Using the SnoopyPro USB sniffer, I was able to look at the USB packets, observing data from frames shown by the sniffer, as well as recording the configuration activity based on the channel I specified to capture on.

With this information, it was straightforward to identify the USB endpoint 0x01 as the control channel (for setting the channel) and USB endpoint 0x81 as the data endpoint (for delivering frames). Using PyUSB with the excellent Pymissle project by Scott Weston as an example, I quickly put together a tool that can set the channel number and capture frames from the Zena device, dumping the hex bytes to stdout.

Linux Microchip Zena data, isn't it beautiful?

Linux Microchip Zena data, isn't it beautiful?

The Python script is available here. It’s hack, but it was enough to get me started on what will be my next post: zbfind, a location tracking and identification tool for ZigBee and 802.15.4 networks.

-Josh