Chapter 9. Wireless Access

“They do not use lasers, they do not use radio, they do not use hyperwave. What are they using for communication? Telepathy? Written messages? Big mirrors?”

“Parrots,” Louis suggested. He got up to join them at the door to the control room. “Huge parrots, specially bred for their oversized lungs. They’re too big to fly. They just sit on hilltops and scream at each other.”

Ringworld
—LARRY NIVEN

The way to understand the Wi-Fi problem is to realize that there are really four different issues: ability to talk to wireless hosts (which, in this chapter, I’ll refer to as “host access”), ability of the attacker to get on the wireless network (“network access”), ability to eavesdrop on the packets being carried on the net (“content access”), and ability to do traffic analysis (“metadata access”). The first affects whether you let traveling employees use Wi-Fi; the other three are about whether your enterprise should use it. The four problems are quite different; different solutions are needed for each. Furthermore, there are two different classes of popular wireless technology, Wi-Fi and mobile phones; Wi-Fi can be internal or external, and tech toys (i.e., smart phones and tablets) tend to live in multiple worlds. Because of their dual nature, I’ll defer discussion of toys to Section 9.4. (There are, of course, many other wireless technologies in use; however, with the possible exception of Bluetooth, few are serious computer security issues.)

Let’s look at content access first. There is no doubt that eavesdropping on unencrypted Wi-Fi traffic is trivial. Wi-Fi’s advertised operational range is 100 meters; however, with a suitable external antenna, considerably longer ranges than that are quite easily achievable. The canonical do-it-yourself Wi-Fi antenna is based on an empty Pringles can; plans are widely available on the Internet.

If the Andromedans are after you, though, a conventional, wired network may not be any better. Someone I once knew put it like this: “All those Ethernet cables you’ve run? You call them wires; I call them antennas.”

If you’re dealing with a lesser enemy, there is little doubt that an unencrypted Wi-Fi network is easier to eavesdrop on than a wired one. Wired networks are switched; for the most part, machines receive only packets intended for them. Although this can’t be seen as a security measure, let alone a strong one—there are well-known attacks, and even without them some packets are flooded to all ports as part of normal operations—it certainly is a help. With a wireless net, there may be many hosts connected to each access point, which is the only device whose location you really know and to which traffic is filtered by the switch.

Perhaps more seriously, wireless extends the perimeter of your network for active users, letting someone outside your building appear as if they are actually on your LAN. In other words, content access and network access are far easier with wireless nets than wired. Although this would seem to be a significant defect, it is fairly easily countered with proper cryptography.

What applies to access to content applies to access to the network: if your network isn’t properly protected, the lack of a physical perimeter is a serious issue. However, the differential advantage is a lot less than one might suspect when dealing with skilled enemies; an enemy who has compromised any single machine on your LAN has amazing powers.

By playing games with ARP, MAC spoofing, and the like, it’s relatively easy for a rogue machine to divert traffic to itself. In one incident I saw (the boxed story on page 172), the attacker was able to spoof any machine on the LAN, as well as intercept any traffic. An open access point might be useful in achieving initial penetration (indeed, Gonzalez [Chapter 3] and company did use such techniques), but in many situations, there are many other ways, such as spear-phishing, to achieve the same goal.

In other words, wireless networks are indeed somewhat less secure than wired nets. However, the odds of a single-machine penetration of your LAN, especially by a targetier, are sufficiently high that one should not skimp on internal protection. “The machine is on my LAN” is good enough access control only for low-value resources.

Proper use of cryptography—WPA2 Personal and especially WPA2 Enterprise—is a very effective defense. Put simply, the cryptography here works; it does the job it’s intended to do. In fact, in one way it is arguably better than an unencrypted wired net: outsiders with fancy antennas can’t read the data. The details, though, do matter.

To associate with a WPA2-protected network, a node needs a cryptographic key. With WPA2 Enterprise, a login and authenticator (often, though not always, a password) are needed as well. Using these and some randomly generated values, a separate session key is generated for each user. This means that other nodes on the same net can’t read the data. There are two important caveats here, though. First, with simple WPA2 Personal, an attacker who is on-net before a target node joins can overhear the key exchange dialog and can calculate the session key just as well as the target can; eavesdropping is thus possible. This sounds like it takes a sophisticated adversary; in fact, there are popular open-source tools that do just that. WPA2 Enterprise prevents the attack, since the user’s secret authentication data is also part of the session key calculation. Second, WPA2 encryption is link encryption, that is, between the wireless access point and the nodes. Traffic deliberately sent to an attacker’s node (perhaps in the wake of an ARP-spoofing attack) will be encrypted to it, not to the proper recipient, so it will be readable by the attacker. To protect against this sort of diversion attack, you need to encrypt at Layer 3 or above. That, however, is identical to what can happen on a wired net.

The conclusion is that WPA2 Enterprise is somewhat better than wired LANs against content access and network access attacks. This applies even to the Andromedans with their souped-up Pringles cantennas. Plain WPA2 is slightly weaker than wired LANs, since many more nodes are associated with a typical access point than with a port on a wired switch, so machines using the same access point can eavesdrop on each other.

On the other hand, wireless networks are significantly more vulnerable to metadata access attacks. Even with encryption, the source and destination MAC addresses of packets are sent in the clear; anyone within range can pick them up. Yes, the Andromedans can do the same to a wired net, but it takes rather more unusual equipment. This is probably not an issue, though, for most enterprises; metadata access is rarely of interest to any threat level short of an APT (though even the lower grades of APTs will do it), and even though the bad guys gain some advantage from tackling a wireless net, doing so still requires reasonable proximity. Most attackers would probably find it easier to hack into a router or network management station and capture the NetFlow data.

The situation is rather different for external, public Wi-Fi nets. Here, use of encryption is extremely rare; the nets are, after all, public, and expecting Joe Sixclick, the proverbial mouse potato, to turn on encryption when visiting a local hotspot is simply not realistic. (I’ve seen published suggestions that hotspot login pages tell users to reconfigure to an alternate network name with a public WPA2 key. I strongly suspect that the people making such suggestions have never run any network larger than their own houses’. How much free customer care can you afford when your real business is selling coffee?) Network access is not a concern, of course, but access to content is much greater than on a typical switched network; as discussed below, use of a VPN or application-level encryption is absolutely mandatory. There is one area of concern to some network operators: the ease of sniffing MAC addresses complicates access control at paid hotspots; unscrupulous users can pick up addresses of people who have paid for the service and piggyback on them. (That’s a bit more complicated than it sounds; see [Clayton 2005] for some details.)

What about danger to the hosts themselves? Are they at more risk on wireless nets than wired? The answer is a qualified “no.”

For encrypted internal Wi-Fi networks, there is strong access control; thus, there should be no new attackers present. There is one more moving part—the key negotiation component—and it’s quite conceivable that some implementations have exploitable security holes. I haven’t seen any reported, but given how many other network entities have proved vulnerable it would be foolish to assume that it can’t happen. Still, at this point at least the incremental risk seems to be low.

External networks are another matter. Attackers who set up fake access points or who play ARP games can capture content. If you’re cautious, it should all be encrypted, so you shouldn’t have any problems. Alas, there are complications.

The ideal form of encryption on a public network is a VPN, with all traffic going back to somewhere safe. In fact, what we really want to do is to lock down our hosts sufficiently well that they won’t emit anything unencrypted. That turns out to be hard; most hotspots want your browser to talk to a login session first; often, you have to pay, and they want to show you more ads [Seltzer 2015]. (Most also want you to agree to a long laundry list of terms and conditions that their lawyers drew up, though even some prominent judges don’t bother reading that kind of verbiage [Weiss 2010].) Perhaps more seriously, using encryption in such scenarios requires proper bilateral authentication; all too many software packages and users get this wrong. Besides, as discussed in Chapter 8, getting it right can be quite hard. The risk, then, is low under good conditions—proper software and well-trained users—but noticeable under other conditions.

Because outsiders—your potential enemies—have access to the same wireless net as you do, mobile hosts may also be at risk in two different ways. First, access to some of your traffic may enable an attack. It shouldn’t—you should be using a VPN—but as noted, there is generally a brief period when that just isn’t feasible, even if everything else is set up properly. Can a sophisticated attacker who fakes a login page send your browser nasty stuff via a drive-by download? It’s almost certainly possible, though it’s hard to assess the odds. The second risk is network scanning attacks: attacks intended to learn what hosts are present and what services these hosts are listening for. These are, of course, possible against wired nets, assuming that your attacker knows your IP address. Proper IPsec software should reject non-VPN packets; it isn’t clear that all implementations do so properly, and some other types of VPN don’t even try.

The real danger from use of external networks, wired or wireless, may be indirect. Suppose that a machine does become infected. The real risk is when that machine comes home and connects to your organizational network: will they bring the infection home? For that matter, if they only use their VPNs part of the time, will the infection traverse the tunnel when they do set it up? The incremental risks seem somewhat less today than a few years ago (possibly because machines are as likely to be infected from inside-your-walls web browsing and email as they are when traveling), but if you’re worried about APTs and your employees are visiting Andromeda, special precautions may be indicated. Indeed, there are people who bring “burner laptops” with them when traveling to some countries, and they leave their smart phones home [Perlroth 2012]. The inconvenience is considerable, but so, apparently, is the threat.

Another way to look at the issue is to consider the Wi-Fi threats posed by our different classes of attackers. We will assume WPA2 for internal nets and no encryption for external ones.

Joy hackers If they’re geographically very close (i.e., within 100 meters), they can use a wireless net more easily. Joy hackers are the group most easily defeated by Wi-Fi encryption.

Opportunistic attackers Random attackers, by definition, aren’t likely to be particularly close in the physical world, so there is little difference in risk. You might stumble on one at a public hotspot; again, you want to use VPNs there in any event.

Targetiers Targetiers are the most interesting case. Many will have ways to penetrate at least one machine on your LAN. Some, in fact, will be disgruntled insiders and hence already have access. While they may also seek to gain initial entry via poorly protected wireless nets, they can do so much damage once they’re on the inside that simple external access control will do little. In other words, there is little differential security for a Wi-Fi net.

On the other hand, poorly secured Wi-Fi nets have been entry points in the past. Again, though, WPA2 is a strong defense against network access attacks on internal nets; the more interesting question is host access attacks against roaming devices.

MI-31 There is little that can be done to prevent eavesdropping by the Andromedans; ubiquitous cryptography, at all layers, is the best answer. Although the use of Wi-Fi encryption will help deflect one entry point to your net, they have many other ways in. Wi-Fi does make metadata access easier, which they may find to be a significant advantage.

In other words, the usual recommendation for wireless security (using Wi-Fi encryption) is quite effective against most threats. If the Andromedans are not in your threat model, there is no reason to eschew wireless connectivity; the precautions you have to take on any network are more than sufficient to deflect common wireless threats.

There is one more aspect of wireless security that is rarely mentioned, but is familiar to many system administrators: finding the offending host when there’s a problem. If you use managed switches (and except possibly for in-room use, an enterprise should use nothing else), and if you have good records about which switch ports are connected to which jacks, localization is easy: map the offending IP address to a MAC address, map it to a switch port, and look up the offender’s location. (That’s what was done in the story on page 172.) Except under unusual circumstances, that’s much harder in a wireless world. Even without snack food container antennas, the range of an access point can be up to 100 meters; that’s a lot of area to search for a malefactor, especially if the malefactor is actually a piece of malware living unsuspected on someone’s machine.

What can you do? Sometimes, there are special circumstances. I recall one conference where nasty stuff was coming from someone’s laptop. We knew from the switch logs which access point was involved; given the layout of the network, we were fairly certain what room the offending machine was in. Someone ping-flooded the machine, while someone else wandered around looking for the combination of a brightly lit indicator LED and the bewildered face of someone wondering why he suddenly couldn’t get out to the net. . .

There are more general techniques, of course. Tao et al. describe using RF signal strength to localize machines within a few meters [2003], though it seems likely that directional antennas would defeat their scheme [Wallach 2011]. Generally speaking, the easiest thing to do is to blacklist the offender’s MAC address; if it’s an innocent party’s infected machine, they’ll complain soon enough. Better yet, put it on a separate VLAN, where any web page they try to visit tells them what’s going on and how to get help. Some universities do that, especially for student machines in dorm rooms.¹ That won’t block a skilled attacker who can change the machine’s MAC address, but even pros can forget to do that [Williams 2010].

1. “PaIRS: Point of contact and Incident Response System,” http://goo.gl/xhroc.

The oldest form of Wi-Fi encryption, Wired Equivalent Privacy (WEP) is all but useless and should be avoided [Borisov, Goldberg, and Wagner 2001; Stubblefield, J. Ioannidis, and Rubin 2002; Stubblefield, J. Ioannidis, and Rubin 2004]. It has no redeeming virtues save for backwards compatibility with ancient hardware; any device manufactured since, I suspect, the late Cretaceous period should support something better. WEP is a poor implementation of a weak cipher (RC4); in addition, it has the key distribution weakness discussed below.

There are two newer encryption standards, WPA and WPA2. WPA will run on older hardware; however, it generally uses RC4, which means that it can be cracked in about an hour [Vanhoef and Piessens 2015]. When available, WPA2 should be used. (If it’s not available on some of your gear, upgrade the hardware and/or the OS; something that old probably has other security weaknesses as well.)

Any time you use cryptography, key management is a crucial question. Even apart from the cryptanalytic weaknesses of RC4, which were not known at the time WEP was designed, the architects made a very serious blunder: every authorized device has to have the same key. This in turn has two important consequences: first, departure of an employee or loss of any single device (a phone, a laptop, etc.) compromises the key for everyone, necessitating an immediate key change; second, when this happens it’s extremely difficult to change the key in an organization of any size, since every device and access point have to be rekeyed more or less simultaneously, including the keys in gadgets belonging to telecommuters and road warriors, as well as the 12,345.67 nodes of yours that are currently out for repair. In a practical sense, this is impossible for organizations much larger than a family.

The right answer is enterprise mode. With it (and, to be sure, a RADIUS server), every user has a separate login. Individual keys can be revoked without interrupting connectivity for everyone else. You may think that setting up a RADIUS server is unnecessary work—but the first time you have to change a widely shared key, you’ll wish you had done it. Besides, you probably need RADIUS anyway, for other access control decisions.

For external use, there is, of course, no access control. What then? As noted, the most important defense is a VPN. Always enable triangle mode (and disregard complaints about performance—but if you’re a large, multinational corporation, give your employees access to all of your VPN nodes around the globe, unless some quirk of local laws makes that undesirable). Pay a lot of attention to bilateral authentication, in software you buy, in software you develop, and in user education and training.

It pays, of course, to ask who the threats are in this environment. With very few exceptions—some hypothetical Big Ear Bar outside a SIGINT agency, where off-duty spooks go to drink after work, or perhaps a conference or trade show at which some company will always have a significant presence—targetiers are rarely causes for concern here; there are just too many places for such an enemy to cover to have any real chance of success. MI-31 is of course a threat; knowing where employees of their targets tend to be is part of their stock in trade. Still, this is an expensive attack, even for them, since it requires people to be physically present for just the right amount of time—too little time and they’ll miss their targets; too much and they’ll stand out and be suspicious, especially to the counterintelligence folks who also hang out at the Big Ear Bar.

The biggest risk, then, is the opportunistic attacker, someone sophisticated enough to create fake access points complete with nastyware. While they’re good, they don’t come one per hotspot; the odds on encountering one are reasonably low. In other words—and if you’re not being targeted by Andromedan agents—ordinary care (fully patched systems, VPNs, antivirus protection if indicated) and no more than the usual allotment of luck will keep you safe enough that excess paranoia isn’t necessary.

The Apocalypse Codex
—CHARLES STROSS

Suppose you think random Wi-Fi is too risky. What then? Are there risks you incur by eschewing it?

It’s trite but true to observe that availability is generally considered a security property; thus, not being online for fear of Wi-Fi is by definition a problem. That may very well be; however, engineering is the art of picking the right trade-off in an overconstrained environment, and it’s perfectly reasonable to decide that some (presumably small) sacrifice of availability is a better, if imperfect, choice. Are there more threats?

One issue is access to security updates. Sometimes, problems are urgent; indeed, as I was writing this section a news blog ran a story headlined, “Attention all Windows users: patch your systems now: A critical IE vulnerability Microsoft patched Tuesday is under active exploit” [Goodin 2012a]. A delay in installing a patch can be serious, especially for folks who are willing to insert others’ USB drives.

If, as an organization, you still prefer to avoid Wi-Fi, keep it turned off on all laptops. Better yet, have the hardware surgically removed. Do NOT use Wi-Fi internally while barring it externally; it’s just too easy for an attacker to set up a fake hotspot bearing your own organization’s network identifier [Legnitto 2012], at which point employee laptops will automatically associate.

It is important to consider the organizational culture, personnel training, and actual usage demands before making such decisions. If the job demands some way to exchange files or deal with web sites or email when out of the office, most people will find some way to do that, be it flash drives, personal devices (with your data loaded onto them), and more. You may find that in reality, you’re taking a greater risk by barring Wi-Fi than if you figured out how to lock down machines against all network threats.

There’s one more point to consider, and it goes to the heart of this book’s theme: is living disconnected worth it? Employees have laptops and network connections because there’s a business need for such things, and not just to provide them with recreation in lonely hotel rooms or a cheap way to make a video call home. As always, the proper question is not “is Wi-Fi access safe?”; rather, it’s “is the benefit to the business from having connectivity greater than or less than the incremental risk?”

The whole Bring Your Own Device (BYOD) issue is quite complex; I’ll address other aspects of it in later chapters. For now, though, let’s focus on connectivity.

When in Wi-Fi mode, the connectivity issues are, of course, the same as for any other device. When outside, though, toys will fall back to mobile phone networking. Indeed, depending on the vagaries of your access points and the Wi-Fi geography of your building, this can even happen when inside the office. As a consequence, toys, more than most devices, live in both worlds, and have to be able to function that way. In particular, access to essential resources, especially email, need to be readily and transparently available no matter where the toy is or which network it is using. The most secure way to accomplish this is via a VPN.

For phones in particular, it is often reasonable to bar outside Wi-Fi use; most emails that people will actually deal with on a phone are short enough that downloading over a phone network only is not a hardship. Folks will gripe (and often with good reason), but it’s a trade-off worth considering. The big exception, of course, is for people who travel internationally; international data roaming prices are generally extremely high.

Of course, we haven’t yet answered the question of whether mobile phone data networks are safe (or safe enough, or safer than Wi-Fi). Are they? Let’s look at the same four categories.

For most people, including most attackers, it’s a lot harder to intercept or modify phone traffic than Wi-Fi. Governments, though, including that of Andromeda, have already solved that problem; they have fake base stations that can trick phones and mobile hotspots into associating with them instead of with the real network [Department of Justice 2005; B. Heath 2015; Strobel 2007; Valentino-DeVries 2011]. In other words, the defensive technique fails against precisely the same class of enemy who can generally defeat Wi-Fi security. (If you still prefer this technology to Wi-Fi and want to connect from your laptop, make sure you use a dedicated USB modem instead of a portable Bluetooth-or Wi-Fi-connected hotspot. Why expand your attack surface?)

Traffic on mobile phone networks is generally encrypted these days. While the encryption isn’t that strong [Biryukov, Shamir, and Wagner 2001]—indeed, the claim has been made that it was deliberately weakened by governments—it is strong enough that it’s not the weak point in your defenses. Sure, MI-31 can cryptanalyze it, but they’re the same folk who have the fake base stations or who can gain access to the wired part of the cellular network. In addition, the encryption is probably a good enough defense against metadata access to data packets.

We don’t have to worry about the security of access to mobile phone networks. That’s generally the concern of the carriers; very few organizations run their own such nets. All that said, it’s pretty good; there are few technical attacks on phone authentication these days.

To sum up: mobile phone networks are reasonably safe against attackers short of APT status. The toys themselves carry some risks, but as noted I’ll discuss those in Chapter 15 and Chapter 16.

The Atrocity Archives
—CHARLES STROSS

As can be seen from Table 9.1, the incremental risks from Wi-Fi are not great. There is some extra danger to mobile nodes, but this is often manageable, especially if you use VPNs and don’t have to deal with annoying web login pages. (Those of you who realized that there should really be a 3-dimensional table, to match our threat categories, get an extra gold star on your copy of the book. I covered that in the text; besides, I don’t think that having four different, near-identical tables would help comprehensibility.)

Table 9.1: The wireless security problems matrix. The symbol indicates “secure” (or rather, “about as secure as a wired LAN”), indicates “insecure,” and ? means “it’s complicated.” A wired LAN is the standard for comparison. For internal Wi-Fi nets, assume WPA2 or WPA2 Enterprise.

Inside an organization, WPA2 and especially WPA2 Enterprise are very effective forms of network control, if access to the network key is properly controlled. There is some risk if a device is stolen, but only until the affected login is disabled or its password changed. Of course, you can only do that with WPA2 Enterprise, but that’s one reason you want to run it. Another risk is a rogue employee deliberately sharing her or his credentials, but the danger of folks setting up external tunnels is almost as great.

Looking at the table, the two areas of most concern are access to content and risks to the host when on external Wi-Fi nets. Both seem amenable to fixes. For the former, a well-implemented VPN should solve the problem. Most of the risks to the host come from the lack of such protection, especially when dealing with login screens. Those login screens won’t go away; the reasons for their existence are not primarily technical. (There’s already an IEEE standard for network authentication and access, 802.1x. I’ve encountered it exactly once, at an IETF meeting, and of course the IETF prefers to do things in a nice, standardized way. Most sites prefer to hijack an HTTP session.) A sandboxed browser, though, would help, especially if that browser were crippled in such a way as to prevent typing in a URL; that way, it could only talk to a fixed URL, and thus elicit the login screen. In the future, then, we should be able to switch those two entries to . (Exercise for the reader: why do I say that this browser should be crippled?) This question is discussed in more detail in Chapter 10.

Let’s take a deeper look at the suggestion from Chapter 5 that mobile devices should live outside the firewall because of their risk of infection. If they’re to be useful at all, the devices have to have access to some enterprise resources. That has security implications. What are they, and what can we do to minimize adverse consequences? Email is a good case study, since it’s more or less a minimal requirement for device users. We need to consider both the high-level requirements and implementation-level attacks.

First, it’s obvious that email connections need to be encrypted. It would be good to use a special VPN for this, but few devices support VPNs for some protocols but not others. As noted above, it’s difficult to live in a pure VPN environment.

The other way to do it is to encrypt just the email protocols: SMTP for sending; IMAP and POP3 for reading. Fortunately, all of them support Transport Layer Security (TLS) (Chapter 6). TLS is quite secure, but it uses public key infrastructure (PKI) technology (Chapter 8), which carries certain risks unless handled and implemented very carefully. Certificate pinning would work well here, but few, if any, email clients support that. Unfortunately, some TLS implementations, notably OpenSSL, have quite a mixed security reputation; see, for example, [Baxter-Reynolds 2014; Bellovin 2014c; Ducklin 2014] on the goto fail bug or [Andrade 2014; Bellovin 2014b; Schneier 2014] on Heartbleed. It is worth considering moving your mail servers to be outside the firewall. More precisely, they may be better off in a DMZ where they can be reached from both the inside and the outside; this will limit the consequences to the rest of the organization if one is compromised.

Authentication is a second problem: attackers could launch online password-guessing attacks against the mail server. There are several obvious counters here: rate-limiting of guesses, strong email passwords, and so on. A better solution is cryptographic authentication, either as the sole form of authentication or as an adjunct to conventional password authentication. Client-side certificates—issued by the email service PKI, not a PKI—work well here; they provide strong authentication at the TLS level. If the client does not have the proper certificate, it can’t get to the SMTP or IMAP level, and hence can’t launch password-guessing attacks or attacks against the implementations. It sounds great; unfortunately, support for client-side certificates is also lacking today.

I’ve carefully omitted one class of scenarios: a compromised or captured mobile device being used to attack the mail server, or even simply to retrieve email improperly. While those are certainly risks with mobile devices, they are not unique to external mail servers. If we insisted that mobile devices create a VPN to get inside the firewall before retrieving email, the risks would be greater, not less; not only would the email be at risk, but so would everything else inside the firewall. Indeed, it is precisely this situation that leads me to suggest moving email outside the firewall.

The same sort of analysis can be applied to other protocols. The requirements are straightforward: ubiquitous encryption, bilateral authentication, and cryptographic authentication. Web servers are the other class where this can be done fairly easily, if only there were a good solution to the PKI problem.