Throughout my years working in various aspects of technology and security, I've come to realize one simple concept; out of sight is out of mind. Organizations habitually overlook security of wireless communications because they can't see it. If they can't see it, then I suppose their logic is that no one else can either, and it's safe. If you come across my Mom, you can ask her about the many times, as a toddler, I glided through the living room, one hand up to my head acting as a blinder. I was told, “I don't want to see you come out of your room.” I figured if I couldn't see them, they couldn't see me, and I was following the instructions given perfectly. When you're 4 years old, it seems logical. Apparently a faction of network administrators never outgrew that mindset. It's a little less excusable when you have 5 or 10 years of network management under your belt.

People have been looking for ways to visualize or materialize wireless for many decades, as evidenced by the extensive development and use of frequency monitoring tools from the early 1900s. Figure 4.2 is an example of a WWII-era frequency analyzer used by the U.S. military. We've come a long way since then, with devices like this small enough to fit in the palm of a hand and affordable enough for hobbyists. My goal in this chapter is to let everyone “see” wireless, by explaining how it works, describing types of devices that share common mediums and functionality, and offering plain English explanations of security vulnerabilities using real-world examples. The attacks included are part of the low tech hacking subgenre of wireless assaults. If, in reading these scenarios, you grasp just one new concept or think of one new way to attack (and therefore secure) a system, then I've accomplished my task.

Layer 1 in wired networking is the physical connection layer. And so too, in wireless, layer 1 is the physical (albeit unseen) layer of RF. For extra credit, I threw in a couple of extra physical, non-RF attacks here too.

Layer 2 DoS attacks occur when an evil-doer messes around with the 802.11 frames versus the RF as in layer 1. However, akin to the Queensland attack and other exploits at layer 1, most layer 2 strikes are aimed at vulnerabilities within the documented processes required for wireless networking to operate. What that means for wireless network managers is that many attacks can't be completely prevented but can be mitigated, monitored, or secured in other ways.

It's probably fair to generalize that as we move up the stack, our technical difficulty will also increase. So, as we move into our first layer 2 attacks, you may notice the Low Tech Levels hovering around 3 and 4 versus 1 and 2 found in the previous sections. Many of these attacks can be easily launched by someone only vaguely familiar with wireless technologies, using open source applications readily available on the Internet. Even though the underlying processes may be slightly higher tech, the execution is pretty low tech.

I'm giving this hack a Low Tech Level 4 rating right out of the gate. The underlying algorithms and behind-the-scenes processes are rather complex, but the application is on the Internet and readily available to hackers of all levels. Although I admire the cryptographic genius behind the attack, it loses cool points for being a relatively trite hack. Unless you've been hiding under a rock for the last few years, you already know that WEP and other PSK encryption schemes are broken. If this is your first time hearing the news, then I send my condolences and suggest maybe you skip this chapter and move on to the next one; you'll find it less disturbing.

Retract that last sentence; I just realized Chapter 5 is the Surveillance chapter. In any event, there have been a flurry of tools circulating that allow hackers to passively sniff wireless traffic, collect the data, and perform a traditional encryption crack. As we learned in WWII, the more times a password is used, the more vulnerable it is. These encryption cracking tools gather as many packets as they can from the wireless traffic passing around them to and from legitimate stations and analyze the initialization vector (IV) of each. It's estimated a hacker would need to collect about 500,000 IVs to crack a WEP key. While that may sound like a lot, remember those IVs are on every packet being sent. Still, in an enterprise environment, that could translate to days' worth of packet captures.

Hackers are not too keen on waiting, so they devise a better plan. Newer encryption cracking tools use injection attacks, usually in the form of ARP flooding, to force devices to generate more packets with more IVs, in a much shorter time. This catalyst allows hackers to capture enough IVs for a crack in a matter of minutes.

But, wait. It gets better. About a year and a half ago (at the time of writing), researcher Moxie Marlinspike launched WPA Cracker, a palpably named cloud-based service that offers a pay-per-use powerhouse of hacking. The online service has at its disposal 400 processors to check a WPA or WPA2 key against a sizable 135-million-word dictionary tailored for WPA cracking. How is it tailored? Read the side note on rainbow tables and WPA encryption. The hosted service costs just $17 and $34 per use, for use of half or all CPUs, respectively, and guarantees a response time of 40 or 20 minutes.

How do you protect against these types of attacks? First of all, don't use WEP. I don't really encourage anyone to use static (or even rotating) PSKs if it's at all avoidable. If the wireless should be secured in an enterprise, then 802.1X should be used for authentication and key rotation. At this time, the keys in 802.1X and the rotation have not been exploited.

It's worth noting here that there has been an attack named Hole 196 that exploits the use of shared keys, but it is the implementation that's vulnerable and not the keys themselves.

If an organization needs to support legacy devices that can't participate in 802.1X exchanges, it should use the strongest encryption algorithm supported and isolate that usage from the rest of the network with VLANs (Virtual LANs) that terminate at a firewall or a routing switch with ACLs (access control lists) that restrict those devices only to the resources they need. A great example is a handheld scanner. If the best it can do is WPA2 with a PSK, then use that, and put them on their own VLAN that only has access to the server they communicate with.

The third piece of advice is not to use default SSIDs, even if it's not YOUR default SSID. I've seen a lot of organizations with enterprise APs that use “linksys” as the SSID to trick would-be hackers into thinking it's a different type of wireless, with a different set of default passwords etc. This will make you more vulnerable to the WPA Cracker attack, which uses thousands (maybe tens of thousands) of popular and default SSIDs in their rainbow tables.

Who's the fairest of them all? It's not Snow White; it's one of the evil dwarves. I'm pretty sure it's Dopey. There are a host of attacks we can launch on wireless networks, from wired networks. One such attack is a mirror/monitor attack. If you're familiar with switching at all, you've probably seen or used a port monitor to mirror traffic from key ports. The traffic is usually used for analysis, monitoring, and logging or to get specific types of information to network appliances, such as sending DHCP traffic to a network access control (NAC) appliance. I give this hack a Low Tech Level 3. With the right access, a hacker can very easily view all wireless traffic from an AP, set of APs, or entire controller system, without using wireless protocol analyzers and special drivers. It still takes some tech savvy to dig out the interesting pieces, so it doesn't quite earn a 2.

An attacker could also use this handy little switch feature to duplicate all traffic from an AP and send it to a laptop or other wicked hacker storage device. “But wireless traffic is encrypted,” you might argue. It's true, but most wireless, if encrypted at all, is decrypted at the AP and passed in cleartext over the wire.

There are exceptions to this rule. Some wireless vendors offer encrypted tunneling from wireless stations all the way to the controller, and extremely security-conscious organizations may implement an IPSec tunnel for their wireless clients. To address the former, a strategically placed tap could be outside the controller and catch traffic after it's been decrypted by the controller but before it leaves the network. An attacker would more than likely get a deluge of other random traffic with this placement, but that's not necessarily a deterrent. To address the latter, there's little a low tech hacker can do to break your IPSec tunnel. The more affluent hackers might go after SSL certificates and trustpoints, but evil Dopey is unlikely to get into your tunnels.

As a network administrator, it's important to understand how your wireless system works, how the APs communicate to the controller, and how it integrates into the wired network. There are many types of wireless in terms of these variables. Some authenticate and then drop traffic locally on the designated VLAN at the switch. Others tunnel (but don't encrypt) traffic from the AP to the controller so you don't have to provision all the extra wireless VLANs throughout the infrastructure. A few wireless solutions offer an option to tunnel and encrypt from the APs to the controller, and those usually also offer wireless station to controller encryption.

Modifying switch configurations isn't as difficult as you may think. I'd say 90 percent of the time, I find some hole in the wired infrastructure management, whether it's a default SNMP read/write string or a web management interface left open. In this scenario, a hacker would have an easier time with physical access to the network, but this attack can certainly be executed remotely, should he or she successfully infiltrate the network.

Taps and unauthorized monitoring can be prevented with port access controls and mitigated with strict network monitoring. Network administrators should be aware of sudden traffic spikes on previously low-volume ports, and any configuration changes.

Garish Gary is a guest. You love my alliteration, don't you? You give Gary a guest login to your nice shiny new wireless guest management system. He connects, accepts the terms and conditions, and is browsing the Internet in no time. That's the access you wanted him to have, right? Just Internet; that's all he needs. You get called in to a quick meeting down the hall. Gary finishes answering a few emails and gets bored while he's waiting for you. He opens up a network scanner, pokes around the wireless as in the last attack, and then starts exploring outside the wireless network. He looks at the display on your new laser printer, sees the IP address, and uses that as the seed for his next target scan. He scans your internal network, runs NMAP (a free network mapper tool with a super-easy-to-use Windows GUI), finds a domain controller or two, and closes it all back up before you're saying your good-byes down the hall.

You're lucky Gary isn't a hacker, because he would have just scored complete and total network domination. I know this little trick works, because I've channeled my inner Gary on more than one occasion.

You're sure the guest network is the guest network and only has Internet access. But what you don't know is your network administrators didn't put ACLs on the routing switch. Or maybe they did, but they didn't add them to the new one installed last month. Maybe the ACLs were written for a specific guest scope and the DHCP scope was expanded and now serving addresses outside the IP range in the ACL rule. It's possible the guest VLAN terminated at the firewall and someone made an update or replaced it. Maybe the CFO came in and his daughter was having problems getting to some game she liked to play online, so the IT department temporarily removed the ACLs and forgot to reinstate them. Who knows how it happened, but the end result is your curious guests have unfettered access to your production network.

This attack gets a Low Tech Level 2 because it requires only a simple free GUI-based tool and minimal knowledge to execute. So easy, even a Gary could do it.

These types of attacks are easy to prevent but hard to maintain. A simple ACL on a switch would have prevented the attack, but keeping up with the maintenance and management of routing switches can be difficult for an IT team strapped for time. Everyone's putting out fires, and no one's teaching fire safety.

I encourage organizations to perform their own light pen tests internally from time to time. There are many tools out there that are easy to use, free or inexpensive, and that provide a wealth of information about vulnerabilities and misconfigurations on your network. I also strongly encourage network administrators and IT staff of all types to attend conferences, webcasts, and demonstrations of pen testing and hacking techniques so they can be familiar with the tools and methodologies.

We're following the guest attack with another hack that takes advantage of a likely unintentional configuration that allows unfettered wireless access. In this case, the unintended access is not between the wireless and wired networks but between clients connected to the same wireless AP. In most cases, any stations attached to the same SSID on an AP are in the same VLAN and broadcast domain. There are a few exceptions, such as SSIDs that use dynamic VLANs specified by the authentication server, but still in that case, the users that authenticate and are assigned the same dynamic VLAN are in the same network. Sorry, I had to digress for the sake of accuracy. The important part is, you can think of devices that share a wireless network and AP similarly to devices on a wired network within a VLAN or broadcast domain. It's all layer 2; these things can see one another and talk using their MAC addresses, without having to consult a router for direction.

In terms of malicious activity, it means a hacker on the same network could easily get to, attack, and even deliver a dangerous payload (virus, rootkit) to any other vulnerable device within that broadcast domain. As we saw in Mogull's man in the middle attack earlier, access to the host device serves as a gateway for a variety of attacks. Viruses attack the applications and may spread to other devices on wireless (and possibly wired) networks. Rootkits provide attackers with back doors to the system. The bottom line is, once an attacker has access to the host system, many types of attacks can be launched, and the severity of the attack varies with the tools and intent. The only way to segment the traffic at layer 2 is to further VLAN the network or to physically separate the devices. There is simply no other control on a wired medium.

However, on wireless networks, we have the option of layer 2 protection not available on the wire. Here's the hitch: it's probably not enabled. Cisco calls the option PSPF (Public Secure Packet Forwarding), other manufacturers call it inter-station blocking, peer filtering, station isolation, and other similar terms. Regardless of the name, it keeps wireless stations attached to the same network from being able to see and directly communicate with one another.

Many network administrators assume this feature is enabled by default, and while I think it probably should be, the fact is even in many enterprise wireless systems, it's not. Someone has to research that vendor's moniker for this feature, find out how to enable it, and configure each controller or AP accordingly. From a hacker's perspective, I give this one a Low Tech Level 3. It's pretty simple to execute and doesn't require any special tools or applications.

There are times when using interstation blocking is not appropriate. Networks supporting medical equipment, wireless phones, handheld scanners, and proprietary systems should check with their vendor before enabling this security feature. As an example, voice over wireless (VoWiFi) phones that have push-to-talk (walkie-talkie style) features need direct communication among the devices because the protocol uses multicasting. If a wireless system needs this type of communication, just make sure those devices are on their own SSID and segmented from the other wireless data.

Securing from this attack is pretty simple. To make sure your organization doesn't fall victim to a peer hack that uses this gateway, network administrators should clearly inventory all (read: ALL) wireless, including controller-based systems and any autonomous APs, no matter how inconsequential. Once they can determine which SSIDs are being used for what and determine that interstation blocking can be enabled on one or more SSIDs, that security can be pushed throughout the wireless infrastructure. As an added layer of security, it's always recommended that organizations use endpoint security tools that offer firewall protection at the host, thwarting attacks from peers, viruses, and spyware. Most modern antivirus providers offer standalone and enterprise-managed tools with this type of protection.

Staying in the vein of peer attacks, let's look at the hacking potential with ad hoc networks. Ad hoc is defined as formed or used for specific or immediate problems or needs, followed with fashioned from whatever is immediately available: improvised . ⁴ In terms of 802.11, an ad hoc network is an independent basic service set (IBSS), which just means there is no AP.

Without an AP, everything connected in an ad hoc network is a peer; there's no master and therefore no one to regulate the chaos. Because of this, ad hocs are dangerous networks to have floating in an enterprise. You don't know who's connected to whom, what they're accessing, and you can't see or control the traffic or access. These unhampered connections cause less heartburn in homes and home offices where users are looking for the convenience of connectivity without the hassle of architecting a true network.

I've given this scenario a Low Tech Level 2 because it can be performed with a variety of wireless devices and only requires a small configuration change to implement. An ad hoc network gives a hacker surreptitious access to its peers, allowing the same type of attacks seen in the previous peer-to-peer hacks.

There are some obvious limitations to exploiting an ad hoc network, since a hacker would need to get close to your other wireless clients, as the antennas in laptops aren't as strong as those in APs. The warning to heed here: this attack is a great approach for an insider attack. The data he or she acquires, either wirelessly or via a wired bridge, is virtually untraceable. Your switches, routers, firewalls, IDS/IPS, and data leakage prevention (DLP) tools at the gateway will not see data stolen in this manner.

Organizations, especially larger ones, are strongly encouraged to use a variety of tools to protect against these types of attacks and possible data theft. Settings on laptops and forced configurations through group policy or endpoint security tools can prevent endpoints from participating in ad hoc networks. In addition, the protocol analyzer or WIPS can be used to look for IBSS traffic, which would alert you to an ad hoc network in the environment.

An attack is an attack, regardless of the source or intent. If someone wants to take your stuff, destroy your stuff, or tamper with your stuff, whether that person is part of your organization or an outsider, is inconsequential. More often than not, rogue devices are introduced into a network by authorized users such as employees and contractors. Even if the intent of the user isn't malicious, his limited knowledge of technology probably means the added device has not been properly secured and is accessible by fiendish users who may connect for access, as well as connect to the management interface and make changes or reroute traffic.

A rogue device is any device—client or infrastructure—that attaches to your infrastructure without knowledge or consent by the organization. Rogue devices are a huge security risk in an enterprise. They open unknown and therefore unmonitored paths to data and critical resources. Someone could be siphoning data from your network at this very moment via a rogue access point, and you may never know it happened.

Should a hacker decide there are juicy tidbits on your network, he may not even need bother with breaking in to the authorized production network. Chances are, he can find an employee who's thrown a wireless AP in the office so he can move around more freely, get better signal or let his kids play online with their Internet-enabled games. I've assigned this hack a Low Tech Level 2, because our happy little hacker doesn't even need to hack much; your employee did the work for him.

In this scenario, a nefarious individual can attach to a rogue AP and 99% of the time he'll get right on the production network, instead of a guest network. Why? Because when the IT department adds wireless, it provisions the proper VLANs, networks, and settings to offer secured wireless for the organization, whereas the ignorant employee will simply plug an unconfigured AP in the most convenient wall plate (on the production network) and go on about his business. He may not even intend to leave it in place; perhaps there was some immediate and sudden need.

The key takeaway here is these rogue devices added haphazardly by non-IT employees won't have the appropriate configuration, security, and management controls. If you don't know about them, you can't manage or secure them. If you can't manage or secure them, they're at risk.

Mitigating rogue access devices, such as APs, is a daunting task. There are a variety of ways to prevent new devices from being inserted into the network or to monitor for devices after they're added. My preference is to be proactive and inhibit rogues, but if you can't do that because of logistics or budget, monitoring and reactive mitigation are acceptable. Organizations can:

I'm never able to communicate exactly how insecure management access is for many organizations' network devices. Even in environments that have telnet disabled, SSH used, and web GUI access removed, there's usually some little back door. Perhaps an SNMP read/write string set to the default public/private. Many times one secure management feature is configured and enabled, but the less secure option is not disabled. For example, SSH might be set up, but Telnet was left on, or HTTPS enabled, but HTTP still accessible. It's possible in some systems that a manager password is set for the CLI, but the web GUI uses a different username/password combo, and it's still on the default.

Regardless of the specific vulnerability, nine times out of ten, there's SOME way to access the management interface of a switch or access point. And if a hacker can get to the management interface, they can pull many underhanded tricks. Unless the hacker affects the services, for example, launching a DoS attack, the changes he or she makes may go unnoticed for an extensive period of time.

One such sly trick is to add a new SSID on a wireless AP or controller. With this, the hacker has two options, depending on the culture of the IT staff. He can add an SSID with a completely different name (something that would appear to be a neighbor's wireless, if someone were to view the list of local SSIDs from a laptop), or he can add something very similar to a current enterprise SSID that might seem like a legitimate corporate network. The former works in a smaller organization that doesn't regularly manage, maintain or audit the wireless systems. The latter works in a larger organization with a more segmented network management team. With divided responsibilities, one management team might not question a configuration change that could have been affected by another team. There also tend to be more turnover and movement of personnel within larger organizations, versus a small IT shop, with one or two folks who have built and maintained the networks for years. This hack gets a Low Tech Level 3 designation. It doesn't require special equipment, and it uses a relatively simple attack on device management, followed up with the extremely easy-to-execute process of adding an SSID.

If an attacker were to gain access to the management of an AP or controller (I've already explained why this is not farfetched at all), he could add an SSID that would be the least obvious to the users and IT team. By setting his own security options on the SSID, he wouldn't need to bypass any other security to get network access. The network wouldn't show a rogue device, because the SSID would appear to be rightly configured on an enterprise AP.

The rogue SSID would allow a hacker to access the network, possibly directly to the wired production network. You know, if I were performing this attack, I'd definitely put my rogue SSID on the production or management VLAN, depending on what my goal was. This type of access would give him entrée to the wired network, to other network devices or network users and to whatever data he configured the SSID to give him access to – servers, credit card info, HR records, etc. He'd have this access until someone noticed the additional SSID; it could be days, weeks, months, or even years.

How do you combat this attack? Handling this vulnerability is actually pretty easy, but most organizations don't think about it. I've worked with many enterprises and government offices that had a mish-mash of wireless equipment, layered with both controller-based and autonomous APs. With such a random jumble of equipment and usually a short-handed network team, these organizations rarely revisit or audit the wireless. It gets set up, it works, and it gets left alone until something breaks. Here are ways to combat this attack:

This is a hack everyone can appreciate. It's a little twisted, elegantly simple, and quite sinister. The majority of new wireless networks are using controller-based systems. These use a central controller (or group of controllers) to manage access points across a single location or full enterprise. Controller-based APs come in many flavors, but one is particularly easy to implement and, for that reason, potentially dangerous.

The systems vulnerable to this attack are light-AP-based controllers that are configured to use a single provisioning VLAN. A provisioning VLAN is used between the controller and APs to communicate, and usually all wireless traffic is encapsulated in it. It's great for large organizations, because the IT department can add a wireless AP with different SSIDs without having to pipe through all the wireless VLANs. I'm going to use the HP WESM solution as an example. By default, it uses VLAN 2100 to communicate between the controller (HP WESM) and AP (HP Radio Port). If our guest VLAN is 99 and production wireless is VLAN 5, we still only have to extend the provisioning VLAN 2100 out to the AP. Traffic from VLANs 5 and 99 will be tunneled over VLAN 2100 with no additional VLANs on the switches along the way.

To make life even easier, many of these systems offer an auto-provisioning feature. I'm picking on HP here, because I know their VLAN assignments off the top of my head, but many other vendors do the same thing, and network administrators love it. The auto-provision lets the organization add an AP. The switch says “Hey, you're an AP, you get VLAN 2100.” The controller then sees the AP pretty immediately and auto-adopts the AP. When it auto-adopts, the configuration is pushed out, with SSIDs and security settings, and the AP is ready to use in no time!

Sounds fabulous, right? It is. It lends to a more plug-and-play-style operation and saves the IT teams from the daunting tasks of having to identify every single interswitch link and add two or more VLANs.

There's a downside to all this auto-provisioning plug-and-play. If an outside attacker or mischievous employee wanted to extend the corporate wireless network to an area that was intended to have no access, the most inconspicuous way to do so would be to use the same equipment already in place, and simply add to it. The AP would most likely be auto-adopted by the controller, and the IT staff wouldn't think anything of it. If the network staff even noticed the new addition, it would seem innocuous – just an extension of the corporate wireless. If the IT staff didn't have alerting set for new APs, they might not even notice until they performed some type of refresh or coverage survey.

Extending wireless outside the intended boundaries can be troublesome; the SSIDs and access served may be intended only for specific groups of users, in specific locations. In some instances, they're provisioned for equipment in healthcare and manufacturing and not intended for general data use. Adding APs can disrupt RF planning, compromise security containment areas, and create a quality-of-service issue if the new users cut into bandwidth for the intended users of the system.

Preventing this type of attack is straightforward. In an environment where wireless containment is critical, network managers should turn off auto-adopt and auto-provision of APs and VLANs. All organizations should set alerts that report on new APs and keep a detailed inventory of where every AP is, with its MAC address and physical location. In addition, regulated businesses may also use WIPS and RF sensors throughout their facilities or locations to alert for the presence of new RF in the environment. PCI DSS standards require this, and it's a good practice if a location shouldn't have wireless, to offer assurance that there is, in fact, no wireless:

There are organizations that may have a business case for auto-adopt and auto-provisioning, so I wouldn't make the blanket statement that these features should never be used. The IT staff just needs to be aware of the possibility and keep a closer watch on the wireless network.

In the earlier section, Ad hoc, ad finem, we looked at attacks that took advantage of the vulnerabilities in ad hoc networks. Here, we extrapolate on that concept and dig one layer deeper to exploit bridged network access in these environments. Bridging lets devices connect two network interfaces—for example, wired to wireless and vice versa.

Wireless ad hoc networks aren't only menacing due to the lack of control of wireless access; they can also become gateways to the wired infrastructure in an enterprise. We've already seen how hackers can exploit ad hoc networks; think of the possibilities if they used that access to penetrate the wired infrastructure as well.

Users can bridge the wireless and Ethernet NICs, either deliberately or accidentally, through the use of self-configuring applications. In this scenario, an attacker would get immediate and probably undetectable access to your wired infrastructure, via an ad hoc network.

This attack doesn't stop at vulnerable laptops. Newer wireless-enabled printers, cameras, and other networked headless devices can also become gateways for destruction. These devices are designed with easy plug-and-play functionality, so without configuration they'll advertise and participate in ad hoc wireless networks. The other end of that printer or camera is attached somewhere to the wired network. With an 802.11-enabled printer as our example, an attacker can easily access the management interface via a web GUI, upload vulnerable firmware, and/or simply modify the settings so the wired and wireless interfaces are bridged. The same attack works on some camera and security systems as well.

Securing the network from hazardous bridged configurations requires a bit of tenacity and attention to detail. As suggested earlier, group policies and forced settings will protect laptops from misconfigurations and configuration tampering. Disallowing the use of ad hoc networks and forbidding interface bridging is a good start for laptops.

The headless devices, such as printers, are a bit more troublesome because they're so often overlooked and undocumented. The IT department should have an accurate inventory of ALL network devices and maintain an accounting of what it is, when it was added, where it is, why it's there, and who's responsible for it. Strength in enforcement can come from technology but will be more effective with organizational policy and strict regulation. To do this, the IT department must be monitoring the network regularly for new devices. The organization should have very clearly documented policies on adding networked devices, and those policies should be communicated clearly and often to all employees. If someone is discovered to have added a switch, AP, or even printer without permission, he or she should be reprimanded appropriately.

The technological difficulty for many organizations is not having the mechanism to be alerted on new devices. To this end, port access security, NAC, and MAC-based management systems offer the only enterprise-level solution. Other more manual techniques for smaller organizations may include switch-configured MAC-learn and MAC-lockdown features. These tell a switch to learn the MAC address (or addresses) of what's plugged in, and not allow anything else to be connected. Another manual option would be for the IT department to run a light network mapping scan every so often to identify devices that have been added. Free scanning tools such as NMAP can report on findings from scans to target networks. More advanced network management tools (usually paid) include advanced reporting, archival data, and comparative tools that are better at notifying the network team of changes. Just remember: knowing something has changed does no good if the organization's management team doesn't act on it and enforce policies.

It's like taking candy from a dingo! Wait, no. It's like taking a dingo from a baby…. No, that's not right. The dingo ate the baby? Oh, never mind. This hack needs no introduction. People have been using default passwords since before Al Gore invented the Internet. Sometimes for legitimate uses, other times for malicious intent, if default settings are left in place they will be exercised.

Within the realm of wireless, there are many default settings that are of interest to a hacker, including:

Armed with one or more of these little gems, a hacker has the potential to modify management settings, lock out legitimate admin users, reconfigure devices, launch man-in-the-middle attacks on authentication, participate in 802.1X and other authentications without an account, attach to a device, and/or engage in out-of-band device management. These are more general assertions of possible hacks using default settings, but the list is really limitless.

I don't have to tell you what the appropriate steps are to prevent this manner of attack. (I will anyway, but I don't need to.) Always, always, always change default settings and default accounts that are provisioned within any part of a wireless system. This includes, but is not limited to, the controllers, APs, switches, endpoints, authentication and directory servers and any management hardware or software.

As seen in Figure 4.19, simple Google searches can yield a wealth of information, including default management passwords for just about any type of hardware (or software) you can imagine.

Not long ago, several ISPs were offering wireless as an add-on to their Internet service and doing so by providing a branded wireless router with a default SSID and default PSK for WEP, WPA, and WPA2. Figure 4.20 demonstrates the availability of these preshared keys on the Internet in various knowledge bases and web forums. The preshared keys were generated from an algorithm that was later compromised. I'm not sure if the algorithm used by the ISP was accidentally shared or reverse engineered, but the end result was any preconfigured wireless PSKs were vulnerable to access by unauthorized users privy to the phenomenon. This paragraph sums it up:

This hack is assigned a Low Tech Level 2, because there's really not much to hack. If a hacker uses a simple wireless network scanning tool, knows the system is vulnerable to this attack, and simply uses a search engine to look up the algorithm converter, then bingo! He's in.

The obvious fix for this low tech hack is not to use default SSIDs and/or default PSKs. Most important, don't use the default PSK, but if you read the section, Crack Attack, you'll know why you shouldn't use the default SSID either.

One of the most entertaining (and revealing) gateway attacks is precision Google hacking. If you've read Johnny Long's Google Hacking for Penetration Testers, Volume 2 (ISBN: 978-1-59749-176-1, Syngress), you know exactly what I mean. The resources and examples provided in the book are rather exhaustive and appropriate for all types of information gathering and hacking.

For wireless, there are a few specific Google techniques that can serve as a launching pad to many of the other low tech attacks in this chapter. One of my favorite Google hacks is searching for configuration files stored on Internet-accessible servers. If you look into Chapter 4 of Google Hacking, you'll see specific examples for using the Google inurl operator with key phrases like “conf” or “config.” Expanding on that search, you could also look for specific filename strings and file extensions, .txt, .pcc, .ini, and many others. Finding this information will give a hacker information about the organization (based on the IP or server found) and configuration of various network devices, including wireless APs, controllers, switches, routers, and more. Important information such as management configurations, SNMP strings, IP schema, routes, and VLANs could be gleaned from these configuration documents. I've also been successful in finding backup archives containing this information online. Along the same lines, you can Google foo to find log files, including Putty log files. Putty is a tool used to connect to CLI interfaces of devices, via SSH, telnet, or serial. They frequently contain technical troubleshooting output and therefore may be even more interesting and telling than just a configuration file alone.

Chapter 8 of Google Hacking details specific strings for finding Internet-accessible network hardware. With Johnny's search strings, an attacker can easily find devices such as switches, routers, wireless hardware, printers, firewalls, cameras, monitoring systems, and more. Examples include searches for “intitle:DEFAULT_CONFIG –HP” to find HP Networking switches and “intitle:”switch home page,” “cisco systems,” “ Telent–to,” for Cisco switches. The list spans seven pages and includes juicy search tidbits for all types of devices. Clearly, finding live production network devices on the Internet opens up a host of attack possibilities that can be executed remotely.

Google hacks create a field day for hackers. Save yourself from Internet-launched attacks by making sure critical systems, backups, and configurations aren't accessible from the Internet, and perform your own Google hacking every 3 to 9 months to ensure you're not a search result. Google Hacking for Penetration Testers, the cover of which is shown in Figure 4.21, is one of the best, if not the best, resources I've seen on this topic.

Here's an easy one. In our going static strike, a hacker simply uses a static IP address to bypass dynamic host configuration protocol (DHCP)-enforced security. Many monitoring systems and even NAC devices (whether in monitor-only mode or full enforcement) rely on DHCP and layer 3 configurations for security. Some network security solutions simply look at DHCP traffic to get a map of what devices are connecting, when and where. Other products use DHCP to serve containment IP addresses, default gateway and DNS settings to clients. You'll usually see this method of enforcement on wireless captive portals as well as NAC appliances that protect both wired and wireless network access. As an added layer of DHCP security, some access solutions also use DHCP fingerprinting to identify and verify the type of device requesting access. We'll tackle that attack in a later section, MAC Switcharoo.

In some instances, a static IP won't be enough to bypass the system; for example, NAC solutions that use a layer 2 (VLAN) enforcement may appear to be containing clients via IPs and routing, but in reality the system is flipping VLANs at edge ports or wireless SSIDs. Setting a static IP on these will just further isolate you from the network, since you'll have assigned an IP associated to the wrong VLAN and, therefore, have no way to access any default gateway.

It's hard to say how often this hack will be successful. It's so easy to test, it would be more of a trial-and-error attack than one heavily researched by a hacker.

You'll know if this attack works on your network. Even if you don't understand the operation of your access security enough to deduce whether it's layer 2 or layer 3, you can (like the hacker) just give it a whirl and see where you get (or where you don't get). You have the added benefit of knowing your IP schema, so you can be precise in your self-pen test and know for sure whether a hacker would also be successful.

Protecting the network from statically addressed devices is multifaceted. Believe it or not, there are many organizations that are still (intentionally) using all or partially statically configured devices. Each has its own reason for doing so, and many are trying to transition, but it's important to note that some of the protection against static rogues isn't suitable for environments with intentionally static-assigned devices. For DHCP environments, there are numerous options. Most name-brand enterprise switches have DHCP protection features, some of which look for MAC addresses that appear on the switch but don't match to the DHCP requests seen going through. That gives a very high level of assurance that the device was statically configured. Other solutions are software-based and plug in to DHCP servers and/or directory services to correlate data between network devices and switches.

Organizations may also choose to provision different networks and access types for managed and unmanaged endpoints. The managed production network might offer access only to corporate assets, which can be more strictly controlled via group policy. Meaning, the IT department could set a policy to disallow employees from setting static IP addresses on any network interface. The guest, or unmanaged, devices would use another network that is perhaps less restrictive but doesn't offer access to internal resources that would pose a security risk.

Good ol' fashioned MAC spoofing is a great way to get around a variety of security controls in place. MAC (media access control) addresses are unique identifiers for each network interface on a device. A laptop, for example, probably has at least two- one for the wired network port and one for the wireless card interface. They're hex characters (0-9 and a-f) displayed in the format 00:00:00:00:00:00 or 000000-000000 and are put on the hardware by the manufacturer at production. It's worth knowing the first six digits in a MAC address identify the manufacturer. Each manufacturer may have several unique identifiers. Although the MAC address is coded on the machine, it can be changed in the software, making it possible for a user to change a MAC address on his device.

For systems that use layer 2 enforcement on a wired or wireless network, the system uses a device's MAC address to uniquely identify it, and access is then allowed or denied to that particular MAC address. At the time of this writing, the majority of access solutions out today use MAC addresses to control access. Some more advanced solutions (like NAC) use a combination of criteria to identify and authenticate combinations of users and devices, but the vast majority of solutions aren't there yet.

MAC addresses can be changed on most devices with a few clicks of the mouse, making it an easy option for even nontechnical users. Traditionally, MAC filtering has been used more often in wireless networks than wired. There's some debate in the industry over whether or not MAC spoofing is a hack or not. Spoofing a MAC is an action usually affected on the attacker's own machine in an effort to subvert or circumvent security.

There's a current federal indictment against a programmer, Aaron Swartz, in Massachusetts, who is charged with illegally accessing the Massachusetts Institute of Technology (MIT) network in order to steal electronic documents from a non-profit who hosted archives and provided access to colleges and their students for a fee. Over the course of many weeks, Swartz subverted the security mechanisms in place at MIT with basic MAC spoofing. The college would identify the bad behavior and block the MAC address of his computer(s). Swartz would then change the MAC address, as described above, to circumvent the filter. This process repeated several times and allowed him to successfully access the network and steal millions of pages of content. The full indictment from the U.S. Courts can be found at http://web.mit.edu/bitbucket/Swartz,%20Aaron%20Indictment.pdf.

Some of our NAC vendors are going to hate me for this one. This low tech hack gets a 4, because it does require some street smarts on the part of the hacker and physical access to devices and ports. If you fall victim to this one, maybe you should revisit Chapter 2 to see how Jack recommends you secure your facilities.

As mentioned in Going Static earlier, some network access solutions (NAC and endpoint security) use DHCP fingerprinting to identify and validate a type of device. I'm going to try to describe the behavior succinctly, but I think it's important to understand what happens so you know why this attack works.

In this incident, let's say there's a NAC solution in place, and it's configured to identify any iPads (current or new) on the network, register them in the NAC controller, and then allow them access to the production VLAN. DHCP fingerprinting is one of the most common methods for identifying common commercial network devices, such as printers, phones, handhelds, and even for identifying types of laptops and the operating systems they're running. I'm using iPads as my example because they connect wirelessly, and we're trying to hack the wireless in this scenario.

Here's how the attack plays out. George the hacker, through observation, social engineering, or good guessing, knows that iPads are allowed on the network without additional user authentication. George gets an iPad and connects to the wireless, and the iPad requests an IP address. The NAC system sees the DHCP request, knows it's an iPad, and follows its normal process of registering the device in the system using its MAC address. It's now considered a known device. George then fires up his laptop, spoofs the MAC address of the iPad, and BAZINGA: immediate access for George. Now, if George thought he was going to be abusing this wireless quite often, he could make a small adjustment to his hack and spoof his laptop's MAC address on the iPad before connecting the iPad to the wireless for the first time. This technique will work if only DHCP fingerprinting is in use to identify devices, but it may fail if the NAC is also inspecting the MAC address for the OUI (Organizationally Unique Identifier), which would divulge the manufacturer. If both are inspected and there's a mismatch between the results of the DHCP fingerprint and the OUI, then the attack variation would fail.

There's a key recommendation in network security that would save an organization from this type of attack. That recommendation is to secure appropriately and differently any portions of the network that are provisioned differently. So in this case, if iPads are allowed on the network without user authentication, then they should be segmented from the primary network, secured differently, and only allowed access to what they must have. An iPad may only need Internet access, for example, and a printer may only need to talk to a print server. With this design, an attacker could still bypass the system, but they'd have limited access to the network and likely give up and find an easier target.

Here are two admirable hacks for getting free wireless from paid access providers. We've all used a hotel or airport captive portal. You know how it goes—you read the agreement, promise to pay some exorbitant fee for an hour or a day's use of Internet, enter payment info, and you're on your merry way. This first free Wi-Fi attack requires a simple modification of the HTML in the payment agreement coding. Maybe that wireless is worth $1 or $0 to you instead of $12. Using any of a number of in-browser HTML editors, you make the appropriate change in the code, flip back to normal view, and hit the submit button. And…ta-dah! It's that easy, or so I'm told. I'm not going to share any specific details of this attack. Feel free to Google that one for more! This hack gets a Low Tech Level 2.

The second attack is a bit more work, and so is a Low Tech Level 3, slightly higher tech than the first HTML hack. In this attack, a corrupt user approaches the task a bit differently. Perhaps this fellow is more comfortable with his free sniffer tools than with the HTML editor. In many paid wireless portals, the back-end system keeps inventory of paid devices by MAC address. This is why connecting to a paid system via wireless and moving to wired may trigger a recharge.

This stingy hacker knows how to abuse the system, so he uses a wireless protocol analyzer to look at wireless traffic and find another wireless client already paid and registered with the system. That's the hard part, if there was one. All the hacker needs to do now is spoof one of the registered MAC addresses he sniffed out, apply that to his device(s), and hop right on. It's highly unlikely he'll get any type of captive portal page or notice of charge because the wireless system thinks he's a device that's already paid.