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.
Friday, December 31, 2010
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).
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.
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.
Note:
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.
ATTACKS
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: http://www.wirelessve.org, 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:
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 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.
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.
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:
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.
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.
Conclusion:
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:
listing 2:
Note:
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.
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.
ATTACKS
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: http://www.wirelessve.org, 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:
- Singular
- Triggered
- 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
- KARMA
- 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.
Conclusion:
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)lrlart.com * Date: August 2004 **/ #ifndef TOOLBASE_HPP_ #define TOOLBASE_HPP_ //header includes #include "Task.hpp" #include "Test.hpp" /********************************************* ** ToolBase ** *********************************************/ class ToolBase : public Task{ protected: //public: /* * Constructor and Destructor */ ToolBase(Task *pToolManager); virtual ~ToolBase(); public: /* * Initialization */ int init(); protected: /* * Thread entry point */ void run(); /* * 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 */ void results(Test *test); /********************************************* ** ToolBaseComplete ** *********************************************/ class ToolBaseComplete : public Task { public: /* * Constructor and Destructor */ ToolBaseComplete(ToolBase *tool_base) : Task ("ToolBaseComplete"), tool_base_(tool_base) {;} virtual ~ToolBaseComplete() {;} /* * Main thread entry point */ void run(); private: ToolBase *tool_base_; //ptr to parent }; private: 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)lrlart.com * Date: August 2004 **/ #ifndef ACTIONBASE_HPP_ #define ACTIONBASE_HPP_ //header includes #include#include "Task.hpp" #include "Test.hpp" #include "ActionManager.hpp" /********************************************* ** ActionBase ** *********************************************/ class ActionBase : public Task { public: /* * Constructor */ ActionBase(string name) : Task (name) {;} /* * Destructor */ virtual ~ActionBase() {;} /* * derived class main entry point */ virtual void process(Test *test) = 0; protected: /* * test dispatching method */ void run(); }; #endif //ACTIONBASE_HPP_
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:
Starting with this page:
http://ultimania.org/sen/hiki.cgi
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.
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.
Subscribe to:
Posts (Atom)