Firesheep Fallacies and Practical Advice

Firesheep is a threat, but not in the way you have heard from most mainstream news sources. Most of the mainstream media is ‘spinning’ the Firesheep story completely wrong, attempting to pin open Wi-Fi hotspots as the wolf dressed up in sheep’s clothing.

They’re wrong.

Firesheep is NOT an issue with open Wi-Fi, it is an issue with application security as implemented by many content providers and website owners.

… here’s why

Firesheep’s Elder Sibling, Sidejacking

Listening to the news last week, Firesheep would appear to be a catastrophic new attack. However, it’s not new. Back in 2007 Robert Graham presented at the Black Hat security conference and introduced the sidejacking attack. What’s more, it wasn’t a theoretical attack, it was real. He released two tools called Ferret and Hamster to exploit website cookies in an easy point-and-click fashion.

What’s interesting about the 2007 sidejacking exploit is not the attack itself. Cross-site scripting and man-in-the-middle (MiTM) attacks have been around for years in multiple fashions. No, what’s interesting to me was the response to the attack (or lack thereof). As security goes, new exploits are always coming out. It’s literally a cat-and-mouse game all the time between hackers and defenders.

The lack of action and dismissal of the sidejacking attack by almost every major service and content provider, as evidenced by their vulnerability to Firesheep, shows that the lack of accountability for consumer data protection by businesses, and results in weak and poorly designed information systems. It’s been 3 years since sidejacking came out, why are we still in the position as consumers of being vulnerable to this attack?

As a customer of many of these businesses, I’m dismayed (even angered) at their lack of corporate responsibility and apparent disregard for consumer data privacy and protection.

Crying Wolf over Open Wi-Fi Hotspots

Open Wi-Fi hotspots are the easy scapegoats in this story. Due to the history of poor wireless security (WEP) and scrutiny attached to Wi-Fi network security, including wireless as a buzzword in a story headline is an easy way for media outlets to draw attention and readers to their content, which ultimately helps drive their bottom-line through advertising and sales.

Yes, open Wi-Fi networks carry certain trade-offs for consumers. However, they are generally worth the risk for most people. And it is our job as industry professionals to strike an appropriate balance between usability of service offering and security. That balance can easily be met on open Wi-Fi networks by applying proven technologies, such as SSL session encryption for secure public content, built-in device firewall capabilities, and VPN software deployment on corporate assets, just to name a few. These are all proven technologies that are not new to the marketplace.

Open Wi-Fi networks themselves are not the risk, it’s how providers often fail to properly architect the systems and applications that run over these networks that lead to problems.

Encrypted Wi-Fi Doesn’t Mitigate the Underlying Issue

Most reporting is claiming that encrypting the wireless hotspot network will solve the Firesheep issue and protect consumers from the evil hackers. This couldn’t be further from the truth.

Basic encryption, in the form of WPA or WPA2 pre-shared key provides no user authentication and actually very minimal data privacy when used for public networks. In a public setting, hotspot operators typically offer the service to all patrons within their premises. In this environment, access to the network is usually free or readily attainable with minimal effort.  What’s less well understood by most is that a pre-shared key is the same for all users of the network and provides the ability for anyone with access to the network (ahem, everyone) to be able to decrypt and read any other user’s traffic. This is easily accomplished by de-authenticating a user and capturing the WPA 4-way handshake to reveal a user’s data encryption key.

More advanced encryption uses dynamic keying, resulting from 802.1x/EAP authentication to the network. However, even using unique encryption key material for each user will not be sufficient to stop hackers from using Firesheep and other MiTM attacks. That’s because authorized users on the network can employ other techniques to eavesdrop on traffic and bypass encryption privacy. Tools that manipulate network operation to re-route traffic through the attacker can enable MiTM attacks. The most common among them is ARP cache poisoning, whereby a hacker injects false addressing into the local network to make the client and router both think traffic should go through the hacker’s machine to reach its destination. Hole-196 is also another method of executing the ARP poisoning attack on wireless networks. Freely available and easy-to-use tools such as Cain & Abel and Ettercap can facilitate these attacks and have been around for a long time.

Ultimately, using either PSK or dynamic keying in public networks only serves to deter the casual eavesdropper. And casual eavesdroppers are NOT your worst threat, motivated hackers are. And they’re the ones who have spent the time and energy necessary to learn how to bypass these controls to accomplish their goals. Most organizations and security experts know that the worst threats on private networks are “insiders” who have access to the system. On public networks, everyone is an “insider”!

This is an important point, and bears repeating. Dedicated hackers are the biggest threat, and on public networks they are effectively authorized “insiders” to the system, no matter what encryption is being used.

Wired Networks are Vulnerable Too

Oh, by the way, Firesheep can be executed with great success on wired networks too. Funny how no reports have seemed to mention that fact.

Typically, wired networks aren’t public networks and have more strict physical security controls around who has access to plug into the network. However, most organizations have conference rooms full of unprotected LAN ports and allow most visitors unrestricted access to such ports once inside the facility. 802.1x/EAP authentication on wired networks is possible, but almost never implemented due to complexity in migrating legacy systems into such a model. Printers, scanners, phones, etc. don’t support authentication and just expect to get and IP address and work.

This means that it boils down to access into the facility to protect the wired network, and social engineering to gain access can usually be accomplished at all but the most restricted facilities. Once LAN port access is obtained, execution of ARP cache poisoning and MiTM attacks works just as easily as on any Wi-Fi network.

Minimizing Risk

So, now you know that open and encrypted Wi-Fi networks are still vulnerable, as well as wired networks. What steps can be used to minimize the threat?

On Wi-Fi Networks, coupling dynamic key encryption with broadcast traffic filtering, peer-to-peer blocking, wireless ARP proxy, and disabling gratuitous ARP on the router will help minimize the risk.

Dynamic key encryption provides data privacy unique to each user so other user’s only see scrambled data.

Broadcast traffic filtering is another common feature on enterprise-grade wireless solutions that limits broadcast traffic going out over the wireless network, typically to improve performance. However, it has the side benefit of preventing broadcast gratuitous ARP replies from being able to poison the ARP cache of all clients on the same network at once, which will severely limit a hacker’s ability to execute a MiTM attack on a large amount of users at once. Hackers can still target individual users one-by-one and poison their ARP cache individually.

That’s where peer-to-peer blocking comes into play. By enabling this feature, again standard on most enterprise-grade Wi-Fi solutions, hackers can no longer communicate directly with other clients and cannot poison their ARP cache. This prevents hackers from intercepting upstream traffic from the client to the default gateway.

Finally, disabling gratuitous ARP on the router will prevent the router from accepting ARP replies that it did not request (hence ‘gratuitous’). The only time a router will install an ARP entry into its table is when it requested it. When coupled with the wireless network performing ARP proxy for wireless clients, the wireless AP or controller will respond to ARP requests for its connected clients and prevent the hacker from being able to poison the router’s ARP cache. This effectively eliminates the ARP cache poisoning attacks.

On wired networks, enabling DHCP snooping and ARP inspection features can help minimize the risk.

DHCP snooping is a feature on higher-end enterprise switching products that enables the switch to learn the DHCP address assigned to clients and build a MAC address to IP address table dynamically. Building on top of the DHCP snooping binding table, enabling ARP inspection allows the switch to investigate ARP frames traversing the switch ports / VLANs on which the feature is enabled. The switch compares the expected MAC and IP address values in the ARP request and response frames to the DHCP snooping binding table to verify that the values match. If a client is found to be spoofing a value, the frame is dropped and a log message is generated to notify the administrator. This prevents hackers from being able to execute ARP cache poisoning attacks.

Shouldn’t Everyone Implement Secure Wi-Fi Hotspots?

For reasons discussed above, encrypted wireless networks alone still leave users at risk. And for public hotspot networks, encryption doesn’t matter if you let everyone onto the network (ahem, the basic premise of a hotspot in the first place).

Steve Gibson over at GRC.com has advised the use of WPA/WPA2-Personal (using PSKs), and Glenn Fleishman recommended going one-step further using WPA/WPA2-Enterprise (authenticated and uses dynamic encryption keying per-user). But they’re both wrong, implementing encryption doesn’t require hackers be able to break the encryption protocols to execute attacks on public networks. They can easily gain access to the network by simply requesting access from the hotspot operator. All they need to do is get onto the network, which is often freely available and happily provided in hotspot scenarios, and execute the relatively simple ARP poisoning attacks which most hotspot operators can’t protect against with consumer-grade Wi-Fi equipment, can’t afford to purchase enterprise-grade equipment to implement the necessary security features, or won’t be savvy enough to know how to protect against. And I don’t blame them; they are offering free Wi-Fi as a perk for customers and are often small businesses that lack technical expertise.

Fundamentally, though, not all hotspot business models are created the same. Applying encryption using either pre-shared or dynamic keys may aid the situation for some hotspot operators, but there are also a large number of hotspot operators for which encryption is not appropriate and does not fit the required business model. Often times these advanced hotspot operators are looking to provide more than just Internet access as a customer perk by developing customer loyalty programs and mobile marketing campaigns using highly localized and relevant (personalized) customer information. For these hotspots, knowing the customer (authentication) is required to provide tailored customer interaction and enhance the value proposition of offered services.

The emergence of mobile devices as a primary information consumption medium and the increasing need to integrate advanced application intelligence into mobile platforms such as smartphones, places added premium on making hotspot solutions usable for the consumer. Requiring strong authentication using 802.1x/EAP is still non-intuitive for the average user and makes connecting to the service painful to point that most consumers may not feel it’s worth the effort. Usability of the solution is paramount to creating an effective business model for the provider and ensuring adoption of the service by the consumer. If the operational requirements are too high of an effort for the consumer to overcome, then the value proposition fails in their eyes and so too does the business objective.

“Secure Open Wireless”

In addition, the IBM ISS X-Force team has proposed using publicly signed certificates to provide secure authentication and dynamic keying for public Wi-Fi hotspots. Providing signed certificates by a publicly trusted 3^rd party (VeriSign, for example) is a proven method for implementing website security on the Internet. They propose extending the use of publicly signed certificates for wireless use. In theory this is reasonable, but there are limitations in products on the market today that will prevent this from working.

When using a browser to access a secure website, the server sends the client its certificate which has been signed by the mutually trusted 3^rd party. Several things must occur for the client to accept this certificate without issue:

1. The URL the client is accessing must be the same as the Common Name (CN) of the certificate
2. The certificate validity period must include the current date
3. The certificate must be signed by a trusted Certificate Authority (or Intermediate CA) for which the client has the Root CA certificate in its certificate store. All modern devices included a built-in list of trusted Root CAs.
4. The certificate presented must not be on the Root CA’s Certificate Revocation List (CRL), which would indicate that the CA has revoked the server certificate due to compromise.

However, network supplicants don’t work exactly the same as the browsers. Whereas browsers rely on DNS to resolve URLs to server IP addresses and there is a clear correlation between the client’s intended destination URL (DNS name) and the Common Name presented in the certificate, no such correlation exists when network supplicants attempt to connect to a wireless SSID. The link between the advertised network SSID and the owner of the presented certificate is effectively broken since there is no way to distinguish what entity should own a given SSID name.

 If I connect to an SSID named “XYZ Free Wi-Fi” and am presented a certificate with a CN of “hotspot.xyz.com”, how is the client to determine the rightful owner of the SSID? The network could just as easily present a certificate with CN of “attacker.evil.net”. Both certificates may be valid and signed by a trusted 3^rd party Root CA, but there is no link between the SSID and the certificate for comparison.

Because of this, network supplicants today don’t blindly trust any publicly issued certificate. CA trust must me manually configured on the client. I have installed Wi-Fi networks with public certificates purchased from and signed by 3^rd party public CAs. Every client network supplicant still throws an alert and prompts to the user to validate the certificate prior to accepting. In corporate settings this is manageable because the IT department can dictate the configuration and CA trust settings for the client machines without involving the end users. For public hotspots, this puts the consumer in the position of determining if the certificate is valid for the network they are connecting to. Most users have no clue what a certificate is, let alone if it is valid. Even savvy IT professionals would have no way of correlating a certificate to an SSID even if they know what they are looking at. This promotes bad behavior of just clicking to accept whatever message pops up on the screen to get connected. That is not security!

IBM’s proposal is to use the DNS name as the SSID and then modify client network supplicant software to check that the SSID name matches the CN of the certificate, similar to how a browser checks the URL against the CN. This would work, but is ugly. All SSID names would then look like DNS names. Additionally, it would require time for all client manufacturers to upgrade their network supplicant software to include this functionality, as well as for network operators to migrate to the new naming convention.

There’s also the issue of checking the CRL list to determine if a certificate has been revoked. For browsers this is perfectly feasible since the client machine is connected to a network that presumably has Internet connectivity to request the CRL list from the CRL URL in the Root CA certificate. However, this becomes a chicken-or-the-egg scenario when applied to network supplicants. The client is attempting to verify the validity of the certificate without having network or Internet access, and thus cannot request the CRL, and must accept the certificate and complete authentication before being granted Internet access. What to do? There are no good options unless the network allows a “walled-garden” access to the CRL location prior to completing authentication. That works for Layer 7 authentication methods such as captive portal where the client has already obtained an IP address and can query other hosts over the network. In Layer 2 authentication scenarios a possible solution would be to adapt the 802.1x/EAP exchange to include request and retrieval of CRL information through the authentication server acting as a proxy. Since the CRL is signed by the Root CA, the client should be able to identify any tampering occurred.

/new-idea

An alternative method might be to create an SSID registry, similar to the DNS registry, by which corporations and individuals may purchase rights to use a particular SSID. The X.509 certificate format would need to be updated to include an SSID extension field, and public Root CAs would have to abide by rules to only issue certificates with a particular SSID after verifying the requester owns the SSID by checking the SSID registry. I like this idea better, but maybe that’s too much work.

/end-new-idea

Any way you look at it, today’s authentication options are not usable without 802.11u and new “Secure Open Wireless” solutions would take time to be developed and implemented into products.

You’re Still Vulnerable

Even with authentication, dynamic encryptions, and all of those fancy enterprise-grade features being implemented, users are still going to be vulnerable to Firesheep and MiTM attacks when accessing Internet-based content.

Other methods for capturing traffic and executing MiTM attacks still exist. Some example scenarios include:

• Disgruntled ISP employee capturing your home / corporate Internet traffic
• Evil twin hotspot networks, presenting a certificate that looks valid
• Hacked hotspots that may have been broken into and are storing / sending data to a hacker

Let me put it this way, even if a Wi-Fi hotspot were encrypted, would you trust banking transactions over that network without the bank employing any application security using SSL? Probably not.

The only way to defeat these attacks is to ensure end-to-end data privacy and integrity between mutually authenticated systems. That means either host-based VPNs or application security.

Mitigating Firesheep for Good

The ultimate answer to Firesheep is for service and content providers to apply appropriate application security that provides end-to-end SSL/TLS session encryption.

This allows current, mature protocols which have already solved these problems to do what they were designed to do. Why go to the length of architecting and designing completely new solutions as described (in length) above, when solutions already exist and those solutions are easy to implement without negatively impacting performance?

Conclusions

Saying that open Wi-Fi networks is the crux of the problem is simply not true. Pointing the finger at open Wi-Fi hotspots is a way to provide an easy scapegoat for sensationalist media reporting.

Let’s stop ‘crying wolf’ over open Wi-Fi networks, they’re not the root issue, and forcing hotspot encryption down everyone’s throats will undermine usability at a tremendous cost to the public good. That tradeoff, as solution options stand today, is not worth it in my opinion. Let’s not cut off our thumb to spite our hand! We will do more harm by destroying the use of public Wi-Fi through the forced use of an unfriendly system than would occur by leaving it the way it is today.

Open Wi-Fi is here to stay, for a while, until the 802.11u amendment is finalized and implemented in commercially shipping products. 802.11u will enable an authenticated Wi-Fi hotspot that maintains consumer usability. Until that happens, open Wi-Fi will continue to be required.

Ultimately, content and service providers need to implement security properly instead of making poor decisions around the privacy of consumers’ data. Placing responsibility and accountability on content providers will make them more diligent in their approach.

In the case of Firesheep and sidejacking, that means SSL end-to-end for the life of the session. That’s the only real fix. And it’s at-least 3 years late in coming. Shame on the content and service providers for ignoring the issue this long!

Cheers,

-Andrew