Friday, December 31, 2010

Happy New Years All!

I'm sitting here and am not believing that 2010 is over. But it is. So let's just lay it out there and say Goodbye to 2010 and hello to 2011. And let's work for a great 2011. One that brings more resolutions than problems (that would be a first if that were true).

I was always taken by the account that I heard way back that the world was to end at the close of the first millennium. I guess the prevailing wisdom was that it was the dark ages equivalent of the year 2000 bug, but in this case the "master plan" was for the powers that be to call it quits after year 1000. The response from the church was to stop building (and hence there's a gap in the architectural record around the year 1000). I suppose that part made sense--just what was the point if the world was going to come to a screeching halt?

Hopefully we've progressed a bit since then and our insight in moving the human condition forward will show a bit more foresight with less reliance on blind faith.

Now getting back to this blog, I'm not much on resolutions and the whole, but I will state that my goal for this blog is to drop technical tidbits (that I find interesting and think might be useful to others) on a weekly basis--but just to be clear that's a goal. And not a promise. Sometimes there are bound to be bigger gaps, especially as I get busier...

Take care all, and let's ring in a great 2011.

Wednesday, December 29, 2010

Perl command line emulator (an exercise in using remote API calls for command completion/execution)

OK--that's an awkward title. The real deal is this...

This was an exercise in seeing if a command line interface could be built using a remote source (meaning accessing an REST API via http) for command completion and execution. The remote API used was the Vyatta router remote access API (REST based https configuration API). I choose PERL as the language so that this little prototype could run on any system (windows, mac, linux etc.). Sure the language could have been something else, but what the heck I picked Perl--plus it has pretty good JSON support (which is the response body format for the remote service).

Sunday, December 19, 2010

Browser session management, authentication and breaking with RESTful principals

REST is a series of general guidelines for simple, compact and effect remote procedure calls over some transport (generally HTTP). And the guidelines are very useful limitations that can help shape a cohesive API.

One major tenant of REST is sessionlessness or statelessness of a request. In other words no client state should be stored on the server. Sticking to this approach generally allows for a simpler API and simpler coding exercise in building the backend behavior. This tenant also facilitates load-balancing of requests or robustness (i.e. server failures)--meaning that with no client state on the server it is much easier to distribute requests among server clusters.

Thursday, December 16, 2010

Survey of Wireless Vulnerabilities

Network security vulnerabilities are ubiquitous within a Wi-Fi network, the best one can do is keep abreast of current threats.

Below is an article I wrote in 2005-2006 but never ended up publishing it. So, the material could be "freshened" especially since most access points have moved away from WEP as an encryption solution. And undoubtedly routers have gotten a bit smarter against some of these attacks too. I'll follow up this with a "part II" when I get a chance.

Threat/What threat?
Exactly, what threat? Well, since the birth of Wi-Fi devilish minds have been busy exploring vulnerabilities and releasing new exploits. It can be an enormous task to keep abreast of all these threats. But, if you rely on Wi-Fi for critical functions it is important to remain familiar with new security breaches as they occur.

So, given that should you be worried? Perhaps. It probably all depends on whether you stand to lose money if your wireless network goes down or if you are concerned about keeping your encrypted data encrypted. The goal of this article is to introduce an awareness of the classes and threats found within the Wi-Fi realm.

First, a little background on Wi-Fi
In order to deconstruct attacks we need to drop down to the packet level. There are three general classes of Wi-Fi packets (or frames): control, data, and management frames. Control frames (i.e. Ready to Send, Clear to Send) allow packets to be exchanged efficiently and are mainly used to facilitate layer 2 packet transmission within the wireless media, management frames (i.e. beacon, association, authentication) control access to the network, and data frames are the workhorse carrying data above the Wi-Fi protocol.

Figure 1 is a sample beacon (management) frame that exposes a typical 802.11 header. Wi-Fi headers contain a number of data elements including source and destination MAC addresses (in this case a destination broadcast address of ff:ff:ff:ff:ff:ff), identity of the associated Access Point (BSSID)—note that the BSSID is usually the same as the AccessPoints (AP) MAC address, identity of the network as defined by the SSID (or extended SSID--ESSID), the frame type/subtype, sequence number. For management frames additional tagged data lives at the tail end of the header where a header can tuck optional parameters such as supported data rates (you can see that this example only supports 802.11b data rates of 5.5 and 11Mbit/sec), response code, packet sequence number and can also contain vendor specific data. Formats of the header vary with the Wi-Fi frame type and carry differing sets of data. For example (in figure 1) the second section (IEEE 802.11 wireless LAN management frame) only shows up with management frames. Data frames carry data at the end of the 802.11 header. For an in-depth treatment of the Wi-Fi packet header format please refer to an excellent reference “802.11 Wireless Networks” by Matthew S. Gast.

IEEE 802.11
     Type/Subtype: Beacon frame (8)
     Frame Control: 0x0080 (Normal)
          Version: 0
          Type: Management frame (0)
          Subtype: 8
          Flags: 0x0
               DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0  From DS: 0) (0x00)
               .... ...0 = To DS: Frame is not entering DS
               .... ..0. = From DS: Frame is not exiting DS
               .... .0.. = More Fragments: This is the last fragment
               .... 0... = Retry: Frame is not being retransmitted
               ...0 .... = PWR MGT: STA will stay up
               ..0. .... = More Data: No data buffered
               .0.. .... = WEP flag: WEP is disabled
               0... .... = Order flag: Not strictly ordered
     Duration: 0
     Destination address: ff:ff:ff:ff:ff:ff
     Source address: 00:40:96:54:32:5f
     Source or Destination address: ff:ff:ff:ff:ff:ff
     Source or Destination address: 00:40:96:54:32:5f
     BSS Id: 00:40:96:54:32:5f
     Fragment number: 0
     Sequence number: 1392
IEEE 802.11 wireless LAN management frame
     Fixed parameters (12 bytes)
          Timestamp: 0x00000015B6327408
          Beacon Interval: 0.102400 [Seconds]
          Capability Information: 0x0031
     Tagged parameters (65 bytes)
          Tag Number: 0 (SSID parameter set)
          Tag length: 18
          Tag interpretation:
          Tag Number: 1 (Supported Rates)
          Tag length: 2
          Tag interpretation: Supported rates: 5.5(B) 11.0(B) [Mbit/sec]
          Tag Number: 3 (DS Parameter set)
          Tag length: 1
          Tag interpretation: Current Channel: 6
          Tag Number: 5 ((TIM) Traffic Indication Map)
          TIM length: 4
          DTIM count: 1
          DTIM period: 2
          Bitmap Control: 0x00 (mcast:0, bitmap offset 0)
          Tag Number: 133 (Cisco Unknown 1 + Device Name)
          Tag length: 30
          Tag interpretation: Unknown + Name: AP350-54325f

Figure 1: Anatomy of a single 802.11 (beacon) packet header.

Different security models are provided for encrypting the payload within the data frame. Provided encryptions are WEP, WPA and WPA2 (in the forthcoming 802.11i spec). WEP came first and is pretty much insecure, WPA is a big improvement over WEP, but is not immune to attacks, while the forthcoming WPA2 builds on the WPA model. WPA2 requires hardware support on the AP (Access Point) and client, and therefore will be slower to gain acceptance. It is important to remember that protection by encryption only protects the payload part of data frames and does not apply to the Wi-Fi headers.

Wi-Fi relies on expected packet sequences or handshakes in order to validate state. Consider the captured association packet exchange shown in Figure 2 between an AP (00:13:60:00:53:d0) and client (00:0b:7d:1f:09:02). The AP dispatches beacons at regular intervals broadcasting the availability of a network. The AP transmitting the beacon in this example does not broadcast its SSID. The client, wanting to join the network sends Probe Request packets (2 through 6) containing the SSID of the network (“foobar”). In this case the SSID was not retrieved from the Beacon, but set by the user wishing to join the network. Starting with frame 8 the client initiates a request to join the AP, first through an authentication, and then an association sequence. The authentication sequence may contain a number of exchanges depending on the authentication algorithm in use (such as shared-key authentication). Following a successful association response (frame 15) the client now is able to exchange data with the AP. Clear to send (CTS) messages are used to reserve the wireless media for a requested period of time.

Frame   Type            Source                  Dest                    Additional

1       Beacon frame    00:13:60:00:53:d0       ff:ff:ff:ff:ff:ff       ("")
2       Probe request   00:0b:7d:1f:09:02       00:13:60:00:53:d0       ("foobar")
3       Probe request   00:0b:7d:1f:09:02       00:13:60:00:53:d0       ("foobar")
4       Probe request   00:0b:7d:1f:09:02       00:13:1a:57:66:e0       ("foobar")
5       Probe request   00:0b:7d:1f:09:02       00:13:60:00:53:d0       ("foobar")
6       Probe request   00:0b:7d:1f:09:02       00:13:60:00:53:d0       ("foobar")
7       Beacon frame    00:13:60:00:53:d0       ff:ff:ff:ff:ff:ff       ("")
8       Authentication  00:0b:7d:1f:09:02       00:13:60:00:53:d0       
9       Acknowledgement                         00:0b:7d:1f:09:02
10      Authentication  00:13:60:00:53:d0       00:0b:7d:1f:09:02
11      Acknowledgement                         00:13:60:00:53:d0
12      Association Request 00:0b:7d:1f:09:02   00:13:60:00:53:d0
13      Acknowledgement                         00:0b:7d:1f:09:02
14      Clear-to-send                           00:13:60:00:53:d0
15      Association Response 00:13:60:00:53:d0  00:0b:7d:1f:09:02
16      Acknowledgement                         00:13:60:00:53:d0
17      Clear-to-send                           00:13:60:00:53:d0
18      Beacon frame    00:13:1a:57:66:e0       00:13:1a:57:66:e0       ("")
19      Beacon frame    00:13:1a:57:66:e0       00:13:1a:57:66:e0       ("")

Figure 2: Sample of a normal authenticaton/assocation 802.11 packet sequence.

Information (and source code) on attacks are pretty easy to come by. The thinking being that the less obscure the attack the more responsive vendors will be in plugging security holes as they appear (which works sometimes). One such location for obtaining information on the latest wireless exploit is:, which is a community supported site dedicated to cataloging known wireless defects as they emerge in the wild.

There are different approaches to categorizing threats. As a software developer I prefer to group attacks by complexity of packet behavior. I find this to be more descriptive of the mechanics at a packet level. Attacks can then be broken down into the following groups:

  1. Singular
  2. Triggered
  3. Multi-phased

A Wi-Fi attack in its most basic form is the "Singular" attack which usually involves transmitting prodigious amounts of a single packet type—it’s goal being Denial of Service (DoS). “Triggered” is the second category of attack and has the same goal, but requires a more intricate implementation. This group generally monitors Wi-Fi packets and sends a packet in response to a specific received packet.

The third attack type, "Multi-phased" attack builds upon the previous two. These attacks can be very complex and may send different packets as states are transitioned during a Wi-Fi communication sequence. Often these attacks aim to gain access to privileged network information.

It is worth noting that one could consider "evesdropping" as a degenerate case, where packets are simply recorded for offline analysis. The downside of this attack is that it is virtually undetectable. We will not consider this type of threat in this article.

There are many singular attack types, below are a few examples that have been identified in the wild:

  • Void11
  • Fata-Jack
  • Omerta
  • Storm attacks
  • Duration attack

Void11 is a crude but effective attack. Void11 floods an AP with management packets--specifically association, deauthentication or with authentication (as per software configuration). The deauthentication attack is the most effective variant as it inflicts the heaviest cost on a network (by requiring clients to reassociate and reauthenticate in order to rejoin the network). This attack illustrates a key aspect of the Wi-Fi protocol—that it is a trusting protocol and assumes all packets to be sourced from a trusted/known system.

For deauth mode, Void11 takes the identity of the AP and broadcasts to all clients to reauthenticate as the previous authentication is no longer valid (see below for a partial deauth Void11 frame). An effective DoS attack occurs when Void11 sends out packets faster than clients can reassociate with the AP (which would prevent access to the AP). An auth attack is similar but uses random station addresses to request authentication thereby overloading the AP. The deauth attack is very effective as it uses the broadcast MAC address to notify all clients.

IEEE 802.11
     Type/Subtype: Deauthentication (12)
     Destination address: ff:ff:ff:ff:ff:ff
     Source address: 00:20:a6:4f:1a:90
     Source or Destination address: ff:ff:ff:ff:ff:ff
     Source or Destination address: 00:20:a6:4f:1a:90
     BSS Id: 00:20:a6:4f:1a:90
IEEE 802.11 wireless LAN management frame
     Fixed parameters (2 bytes)
          Reason code: Previous authentication no longer valid (0x0002) 

The Fata-Jack attack is another simple attack. This attack works by sending an Authentication packet with a bogus (meaning out of bounds) status code (2) from the client to the AP being attacked. When the AP receives the bogus packet the AP responds with a reply that states "Received an Authentication frame with authentication transaction sequence number out of expected sequence". Upon receipt of this message the client is required to deauthenticate from the AP and again we have set up a simple and effective DoS attack. The packet below shows a bogus authentication packet sent from a rogue in a Fata-jack packet capture.

IEEE 802.11
     Type/Subtype: Authentication (11)
     Destination address: 00:0e:35:60:9f:6f
     Source address: 00:0f:8f:da:47:8a
     Source or Destination address: 00:0e:35:60:9f:6f
     Source or Destination address: 00:0f:8f:da:47:8a
     BSS Id: 00:0f:8f:da:47:8a
IEEE 802.11 wireless LAN management frame
     Fixed parameters (6 bytes)
          Authentication Algorithm: Unknown (2)
[Malformed Packet: IEEE 802.11]

Moving up the food chain we have “Triggered” attacks, ones that dispatch packets in response to a captured packet (these essentially rely on timing). Triggered attacks generally include a passive monitoring mode and an active transmit mode. This attack type is more interesting than “Singular” attacks in that it demonstrates a bit more "awareness" of the 802.11 protocol. These attacks monitor for certain Wi-Fi communication patterns in order to dispatch a disruptive packet(s) onto the network. Again the goal is (usually) to achieve a DoS style attack. Some examples of "Triggered" attacks are:

  • 802.11 Association redirect
  • Data rate downgrade
  • AirJack (essid_jack)
  • airpwn

Take the 802.11 Association redirect exploit. This attack monitors for an association request from a client to an AP. What normally occurs when a client associates with an AP is that a client receives the association response from the AP with the identity of the AP (BSSID). However, the attacking system sends an association response (before the “real” AP has a chance to respond) with a different MAC, thereby requiring the system to association with the attacking system on the new MAC address. The response from the “real” AP is then discarded. Figure 3 shows a timed sequence chart of this type of behavior. Once the first association response is received the client becomes associated with the rogue AP.

Figure 3: Association redirect sequence diagram.

Another interesting attack is a variant of AirJack (essid jack), the essid jack option allows the attacker to fool the AP into revealing the SSID of networks where the SSID is not included in beacon packets. This is accomplished by deauthenticating one or more clients, which subsequently attempts to reestablish a session with the AP by dispatching a Probe Request with the SSID of the network. AirJack then captures the SSID of the system.

OK, so now we've seen a couple examples of how a network is vulnerable to attacks, whether by brute force, or by a timed packet, it is time to consider more complex variants, ones that build of the previous examples. These attacks either focus on gaining access to a network, or are DoS attack. There are no limits to these attack types except in their complexity.

  • Aireplay
  • WEPWedgie
  • Hotspotter
  • coWPAatty
  • chopchop

KARMA, is a recent exploit that mimics an AP. The Rogue AP in this case listens for Probe Requests from clients requesting to join a network. KARMA, upon capturing a Probe Request, sends a Probe Response with the SSID used in the Probe Response. Where do the SSIDs come from in this case? Even in the absence of a network both Windows XP and MacOS X systems insert SSIDs from their list of preferred/trusted networks into their Probe Request packets. Once a Probe Response is sent KARMA proceeds with an authentication/association sequence in order to join the client to its bogus network. Kind of a rogue honey pot in a sense. The KARMA attack is entirely capable of sucking down all unassociated wireless clients within range.

The Hotspotter attack is similar to the KARMA attack in that it builds and extends upon the basic Hotspotter exploit. The Hotspotter identifies probe requests, masks itself as an AP, and then proceeds to now mimic an authentication and association sequence. Once the client has associated (joined) the rogue Hotspotter AP, this attack can be configured to run other layer 2 and above attacks. It might be set up to provide an IP via DHCP, the perform port scanning (probing for access), ARP poisoning, etc.

WEP has several known cracking exploits that, with the right knowledge and software allows one to quickly gain access to encrypted communication. Fortunately, WPA is more secure. But WPA is not immune to wireless attacks. Consider coWPAtty, which really is a dictionary attack on the password used to seed the system. Fortunately, this attack is still on the slow side, allowing a maximum of roughly 100 tries per second. However a data set of commonly used passwords is available to aid in cracking simple passwords.

WPA does provide for some level of security from a dictionary style attack. The weakness with WPA lies in the fact that the user chooses the password, and that the encryption authentication sequence can be reproduced. The encryption sequence is known as EAPol which stands for Extensible Authentication Protocol Over Lan sequence—a 4 way handshake between the client, AP and an authenticator (such as a radius server). Through the use of this sequence passwords can be replayed to the authenticator. In order to crack WPA the SSID is needed along with a captured EAPol sequence. CoWPAtty is able to guess at passwords by essentially replaying the EAPol packets and computing the MIC (message authentication code) value from the last message in the EAPol handshake looking for a match with the captured MIC and the one produced by the password that was tried. On a match the password has been correctly guessed.

coWPAtty can take a really long time if a password is truly random and at least 8 characters in length. But passwords are often simple or just default values making them very easy to crack.

What you can do? (building on SecureScout):
It is important to comprehend the breadth of threats within the Wi-Fi realm, given that we've covered a smattering of threats and exploits. There are vendors (such as Network Chemistry, Air Defense and Air Magnet) that provide good solutions to monitoring and alerting of attacks.

If you are interested in rolling your own there is the SecureScout framework (DDJ article November 2004) which is a general purpose multithreaded network monitoring and response framework. As new attacks are identified components can easily be added to SecureScout. There are three types of processing blocks: Sources, Tools, and Actions. All communication between processing blocks are handled via event queues. Each module runs on its own thread in order to support efficient processing of results and management of the message queues.

Listing 1 shows the base class requirements for a tool module. The requirements are minimal with just a compute() method where the work is performed, and a finish() method. Results are posted back to the ToolManager when test results are complete (through the ToolBase::results() method). Two threads are provided for in this class in order to support efficient asynchronous processing of packets (sending and receiving threads). The Task<Test> class that ToolBase derives from provides support for threading and event queues. The template argument <Test> is the data object used in the event queues—this data object wraps test requests and results and in the main vehicle of communication between processing blocks.

Listing 2 has similar requirements for the Action processing block. Results (user derived Test objects) are posted to the Action processing block for reporting as they are captured by the tool modules. The only requirement for the development of a new Action module is to implement ActionBase::process(). Each Action similarly runs in its own thread.

A manager class for each processing blocks controls loading and registration of the modules as well as dispatching of events to specific components. In the case of the tools tests are dispatched in a round-robin fashion, while for results a copy of each test object is simultaneously passed to each result module.

Each of the attacks described above can be encoded as specific SecureScout tool modules. By developing custom Source, Tool and Action modules SecureScout can be configured to actively tune into and focus on specific threats of interest within your network.

These are but a few examples of threats within the wireless media. Given enough time and information there’s always a good reason to be paranoid, particularly when relying on a Wi-Fi. “Watch the sky’s everywhere” to borrow from the 1951 sci-fi movie “The Thing from Another Planet” seems strangely appropriate.

Listing 1:
 * Module: ToolBase
 * Description: Parent class that all tool implementations derive from. New
 * Tool implementations derive from me.
 * Author: Michael Larson
 * email:  mike(at)
 * Date:   August 2004

//header includes
#include "Task.hpp"
#include "Test.hpp"

 **            ToolBase                     **
class ToolBase : public Task
protected: //public:
    * Constructor and Destructor
   ToolBase(Task *pToolManager);
   virtual ~ToolBase();

    * Initialization
    * Thread entry point

    * Required for derived implementation to override. You
    * will usually want to call get() from here to process
    * incoming test requests.
   virtual void
   compute() = 0;
    * Requested for dervice implemenation to override. You
    * will usually want to processing received results here
    * in this thread. Results should be dispatched upwards
    * by a call to results().
   virtual void
   finish() = 0;

    * For dispatching results upwards
   results(Test *test);
    **      ToolBaseComplete                   **
   class ToolBaseComplete : public Task
       * Constructor and Destructor
      ToolBaseComplete(ToolBase *tool_base) : 
Task("ToolBaseComplete"), tool_base_(tool_base) {;}
      virtual ~ToolBaseComplete() {;}
       * Main thread entry point
      ToolBase *tool_base_; //ptr to parent

   Task *tool_manager_; //ptr to tool manager
   Task *complete_test_; //ptr to test completion thread

#endif //TOOLBASE_HPP_

listing 2:

 * Module: ActionBase
 * Description: Base class for all action implementations
 * Author: Michael Larson
 * email:  mike(at)
 * Date:   August 2004


//header includes
#include "Task.hpp"
#include "Test.hpp"
#include "ActionManager.hpp"

 **            ActionBase                   **
class ActionBase : public Task
    * Constructor
   ActionBase(string name) : Task(name) {;}
    * Destructor
   virtual ~ActionBase() {;}
    * derived class main entry point
   virtual void
   process(Test *test) = 0;
    * test dispatching method


Tuesday, December 14, 2010

Lost in (Japanese) translation

A while back I needed to support automated conversion of English text into Japanese script with some Java code. And fortunately, there was a project available that support just such a conversion. So, while not particularly difficult this did require some configuration voodoo and the usual troubleshooting to finally get a library up and running. The steps presented here are pretty simple, but it took a bit longer when setting this up initially (primarily because most of the docs/hints in working with this library were in Japanese)--so hopefully it will save somebody sometime in the future. The library used was the sen java library which is a port of the Mecab C libraries to support translation.

Starting with this page:

Thursday, December 2, 2010

Linux process management

This is a fairly pedestrian linux c problem. But one that I've been revisiting at least a half dozen times or so this past year when working on the Vyatta router, API, or webgui backend. Seems like each time with a new tweak or requirement. But posting this here is a good reference, particularly since something very close to this is shipping in several forms in the Vyatta router. And I always seem to be coming back to this reference implementation.

The goal for this snippet is to run a process and capture STDOUT and STDERR from this process to be used for later processing. The key ingredients here are pipes and a process exec method.