GAINING ACCESS (HACKING 802.11)

Following the proven Hacking Exposed attack methodology, "gaining access" is the stage of the assessment in which the attacker or auditor , depending on the situation, leverages the information gathered during the initial phases of the assessment. The goal for just about all system assessments or acquired targets is to gain administrator or root-level access to the system. However, for this to occur, the attacker must know certain types of detailed system, application, and configuration information.

In the realm of wireless and 802.11, gaining system access is significantly different when compared to "wired" systems. In most cases, this is due to a lack of strong WEPenforced encryption, thereby allowing the attacker to crack weak keys and obtain pertinent transmitted data. If the attacker has gained access to the AP's WEP key, the WLAN is all but penetrated. The small amount of communication information that is still required to effectively gain access should be considered ridiculously elementary when compared to the skill-set required to configure and utilize a wireless-cracking-capable system. As you will notice, a variety of methods is available to gain access to systems, covering a wide range of effort levels.

SSID

Once you have the SSID, you'll need to reconfigure your wireless interface to use it. On Windows operating systems, the card vendor will usually provide a utility to reconfigure card settings or an interface in the driver itself to reconfigure the SSID. Shown next is the configuration screen for an SMC wireless card and its driver settings. The network name has been changed to "Linksys," the SSID of the network we wish to connect to.

For Linux, most drivers will support the iwconfig interface. iwconfig is a wireless version of the ifconfig command used to configure basic 802.11 network parameters such as the SSID. To change the SSID with iwconfig, use the following command, where "sigma" is the network name and "eth1" is the wireless interface:

 [root@localhost root]#  iwconfig eth1 essid sigma  

BSD systems such as OpenBSD and FreeBSD use the wicontrol command, which is used to change parameters of cards that use the wi (Wavelan) driver and handle the 802.11-specific network configuration parameters. To change the SSID using wicontrol, use the following example, where the interface we want to change is "wi0" and the target network name is "Lucent":

 #  wicontrol -I wi0 -n Lucent  

MAC Access Control

Once you've gathered a list of usable MAC addresses, you will need to reconfigure your system to use a new MAC. For Windows systems, this may be driver dependent. Some older drivers allow you to reconfigure the MAC address in the interface properties, but many vendors have since disabled this capability. A few utilities are available to help with this problemone of them is Bwmachak, created by BlackWave. Bwmachak will change the MAC address of an Orinoco wireless card to one you specify. To use Bwmachak, remove the card first, then run Bwmachak as shown next (00:09:E8:B4CB:E8 is the MAC we want to use):

 E:\>  BWMACHAK.exe 0009E8B4CBE8  

After the command has run, insert your card and run an ipconfig /all to verify the MAC address has changed.

Linux systems can use the ifconfig command to change the MAC. You'll need to bring down the interface first, then issue the new hardware Ethernet address, and finally bring the interface back up and check the results. Here is a sample command sequence to use. As you can see, the wireless interface is eth1 and the MAC we wish to use is 00:02:2D:07:E1:FF.

 [root@localhost root]#  ifconfig eth1 down  [root@localhost root]#  ifconfig eth1 hw ether 00:02:2D:07:E1:FF  [root@localhost root]#  ifconfig eth1 up  [root@localhost root]#  ifconfig eth1  eth1      Link encap:Ethernet HWaddr 00:02:2D:07:E1:FF           UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1           RX packets:15 errors:2388 dropped:0 overruns:0 frame:2388           TX packets:10 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:100           RX bytes:720 (720.0 b) TX bytes:3300 (3.2 Kb)           Interrupt:3 Base address:0x100 

FreeBSD systems use the ifconfig command as well, but with a slightly different context. Bring down the interface before applying changes, just as in Linux, but omit the "hw" and colons in the address itself:

 #  ifconfig fxp0 ether 00022d07e1ff  

Then bring the interface up and check it to make sure the changes have taken effect.

OpenBSD users can use the sea utility to change the MAC address because the supplied version of ifconfig does not support that capability. sea does not have an official download location, so the easiest way to find it is with a Google search for "openbsd" and "sea.c". Sea's operation is very straightforward and works in the following manner. In this example, wi0 is the wireless interface and 00:02:2D:07:E1:FF is the MAC address we want to use:

 #  sea -v wi0 00:02:2D:07:E1:FF  

WEP

Wired Equivalent Privacy (WEP) is a standard derived by the IEEE to provide an OSI Layer 2 protection schema for 802.11 wireless networks. The goal of WEP is not to completely secure the network but rather to protect the data from others passively and unknowingly eavesdropping on the WLAN. Many people mistake the WEP algorithm for a security solution that encompasses secure authentication and encryption, a goal that the 802.11 standard did not intend to address.

The WEP algorithm relies on a secret key that is shared between the AP and the client node, most commonly a wireless card on a laptop. WEP then uses that shared secret to encrypt all data between the nodes. The common misconception is that WEP provides network authentication via the use of a shared secret. If a WLAN is enforcing WEP, then any party that does not obtain that shared secret may not join that network. Therefore, the network is thought to be secure. The WEP algorithm does not encrypt the 802.11 header, nor does it encrypt the Initialization Vector (IV) or ID portions of the packet (see Figure 8-15).

Figure 8-15: IEEE 802.11 packet structure

Bleeding-edge Tool from the Underground!

A new tool called file2air was created to inject seemingly random traffic into the air, or wireless network airspace. Written by Joshua Wright ([e-mail]), this tool leverages the Air-Jack drivers to arbitrarily write packets to the wireless network. Replayed communication tunnels such as these are excellent for overloading small wireless access points, wireless intrusion detection systems, and perimeter security systems such as AirDefense and BlueSocket. The source for file2air can be downloaded from http://home.jwu.edu/jwright/code/file2air-0.1.tar.bz2.

 

RC4, a stream cipher encryption algorithm created by RSA, constantly encrypts the data between two nodes, thereby creating a fully encrypted virtual tunnel. In relation to its common use within the wireless arena, RC4 may utilize either a 64-bit or 128-bit shared secret key as the seed for the RC4 streams. One of the issues with the shared secret key is that 24 of the bits are directly derived from the unencrypted IV; that is why 128-bit WEP is sometimes referred to as 104-bit WEP. As detailed hereafter, multiple attacks leverage the unencrypted IV field. The packet data is then encrypted with the secret key and appended with a packet checksum.

Attacks Against the WEP Algorithm

Several attacks on the WEP algorithm surfaced just shortly after its commercial introduction and implementation in wireless APs and client cards. The attacks range from passive to active, from dictionary based to key length, and one-to-one to man-in-the-middle. However, in general, most of the attacks work via brute-force techniques. Such techniques allow an attacker to test entire keysets, all the possibilities, looking for the single correct instance. The other category for attacking WEP is based on analysis of the IVs in correlation to the first RC4 output byte.

As mentioned previously, brute-force attacks are commonly used to exploit some of the key weaknesses within the WEP algorithm, particularly in determining the shared secret key. Passive attacksthat is, attacks that do not require you to send any packetsallow you to sniff 802.11 packets and perform computations on those packets locally. The goal for this type of attack is not to knock other systems off the Net or to forge packets to systems but rather to gather information about the network clients , the implemented security features, and the AP configuration, in addition to potentially cracking the WEP key. Through traffic analysis, you can potentially determine the services running, the encryption and authentication methods, whether a MAC-based authentication schema is implemented, and what the size of the key is in bits.

The only passive attacks that target the WEP algorithm are key and packet cracking. The attack starts by sniffing a large number of packets from potentially numerous clients (the more packets, the more likely the attack will be successful). Because the IV is in cleartext, you can do packet analysis based on client and corresponding IV. Once you have two packets that use the same IV, you can XOR the packets and obtain the one XOR of the packets. This can be used to infer information about the packets and further eliminate possibilities within the keyspace for brute-force attacks on the message. Once the XOR, encrypted text, and unencrypted text of a packet is determined, it's trivial to determine the shared secret because the shared secret was used to create the XOR.

The other type of attack is simply brute-forcing the shared secret key. You can attempt to decrypt the message in the same fashion that an AP would, verifying success via the checksum. By taking advantage of the IV weaknesses, you can execute dictionary attacks on WEP checks in minutes or sometimes seconds, depending on the wordlist and CPU speed. An entire 40-bit keyspace brute-force attack only takes about a few weeks when running on a single system.

Almost all the active attacks against the WEP algorithm are not focused on determining the shared secret key. The active attacks focus on injecting packets into current 802.11 streams. However, in all cases, you must first know the MAC of the AP and whether WEP is enforced, as well as the bit-strength and key if it is implemented. Now that you understand what you need, if WEP is disabled, the effort to use a packet-injection technique is insignificant. In either case, you would just forge the packet you want to write to the "wire" and send it off. The tools that use some of these techniques include Air-Jack and Libradiate.

Securing WEP

Multiple vendors, including Cisco, Orinoco, and Intel, have developed more secure implementations of the WEP algorithm, key scheduling, or product firmware. WEP-Plus was developed as a firmware upgrade for APs and wireless cards to modify the current IV-creation algorithm within WEP. WEP-Plus uses a more secure algorithm for determining and masking the IV field. PKI vendors such as Baltimore Technologies and Entrust have leveraged their PKI and VPN technologies to be compatible within the realm of wireless. In this case, wireless clients would have to authenticate to the network via a certificate server. If authentication succeeds, the user is allowed to join the network via an encrypted VPN tunnel. This type of security is not much different from a few of the smaller vendors pushing their wireless VPN solutions utilizing an SSL or IPSec tunnel on top of WEP. Granted, the data may be secured because of the additional applicationand transport-layer encryption, but the actual wireless sessions are still insecure . The IVs are still in cleartext and not properly randomized with this solution.

WEP has inherent security issues within the protocol, implementation, and overall vendor and consumer usage. Unfortunately, 802.11 offers great functionality because it allows people to work without wires, so wireless technology will never go away. The defensive solution is to layer security with multiple encryption and authentication schemas and to only use vendors that have addressed the IV and weak KSA WEP issue.