Category Archives: Security

Dec 09

ISACA Review: Hacking Exposed Wireless 2nd Edition

Posted on by

Hacking Exposed Wireless 2nd Edition CoverA special thanks to Horst Karin for posting a great review of my new book, Hacking Exposed Wireless 2nd Edition on the ISACA website.

If you haven’t already checked it out, you can browse the book through Amazon’s Page Viewer. For the first time in print, we provided an in-depth coverage of attacking and exploiting WiFi as well as ZigBee, Bluetooth and DECT technology in the approachable and understandable Hacking Exposed style.

Be sure to check out our companion website to grab the online content and associated files for download.

-Josh

Jul 03

Cowpatty 4.6 (with less teh suck)

Posted on by

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

Posted on by

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

Posted on by

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 11

Locating ZigBee Devices

Posted on by
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 07

Follow the Bouncing Malware: Gone With the WINS

Posted on by

Tom Liston is a unique individual. Not only is he technically skilled in many areas, but he has the Kurt Vonnegut gift of being able to write a story that both delivers a message and keeps you entertained with simple sentences (oh, and teaches you a thing or two about malware analysis).

Follow the Bouncing Malware (FTBM) is a great series of articles Tom has published at the Incident Storm Center. Some are a little cheeky, but if you had met Tom you’d think they fit him perfectly. Be sure and check out the latest installment, Follow the Bouncing Malware: Gone With the WINS and pick up some tidbits on malware, Windows 2003 systems getting pwned and pr0n.

-Josh

May 03

Pen Test Perfect Storm Trilogy Slides

Posted on by

Over the last several months I had the pleasure of working with Ed Skoudis and Kevin Johnson in presenting a trilogy of webcasts titled the Pen Test Perfect Storm where we talk about techniques to combine network, web app and wireless pen testing. By combining these components of classic pen-tests, we are able to more effectively test the network for threats and dig deeper into an organization. Check out the slides and links to the webcast archives here:

Slides Webcast
The Pen Test Perfect Storm: Combining Network, Web App and Wireless Pen Test Techniques, Part I Flash Presentation with Audio
The Pen Test Perfect Storm: Client Side Mutiny, Part II Download WebEx Presentation with Audio
The Pen Test Perfect Storm: Network Reconstructive Surgery, Part III Download WebEx Presentation with Audio

Special thanks to Ed and Kevin for the chance to work with them on this series. Please drop me a note with any questions.

-Josh

Apr 11

Why Zoher Anis Rocks My Inbox

Posted on by

If you haven’t met Zoher Anis at a SANS conference or other popular venue, please make an effort to do so as soon as possible. Zoher is one of the most awesome guys I know, and humbles me with his new presentation “Why Joshua Wright loves Windows Vista ? And why you should be glad you’re not running it.”

Zoher came up to me at the SANS 2009 Orlando conference and showed me a slide deck he made for a private audience about some of the awesome wireless stuff Microsoft added to Windows Vista. In it, he applies a lot of the Vista wireless hacks I wrote about in Vista Wireless Power Tools (for the penetration tester), and adds his own excellent Vista hacks in the process.

After I begged and pleaded, he allowed me to distribute a sanitized version on my site. For your enjoyment. Thanks Zoher!

-Josh