January 5th, 2012
Shaw Communications is a large cable TV, ISP and media company in western Canada (where the Renderlab is located). In the last few years, they have been expanding operations into all sorts of things. Most recently, they are expanding thier internet offerings to try and implement a municipal WiFi solution, accessible by their customers.
Right now they are in trials in a few places around town. As soon as I heard about it, I got a big ol' smile on my face since I knew that there was potential for mayhem and chaos which I do like to sow on occasion, in a constructive manner of course. This is written in order to bring to light a security deficiency, in order to hopefully have it corrected. The ever increasing rise in computer crime, and the general populations lack of understanding of technology and security makes it nessecary to spell it out from time to time in order to improve things for us all.
The details are all on Shaws Website but the short version is that they are installing access points in public places like malls, conference centers, etc. It's the usual captive portal solution. Your shaw email address is the login name and your email password is, well, the password.
They state on the website that there are two SSID's present at each installation. "ShawOpen" is as it sounds, a wide open network (no crypto) that leads to a captive portal. The other is "ShawSecure" which they indicate is encrypted.
After reading through the FAQ, a few things caught my attention (well, they lept out at me to the point where I had to beat them with a stick). The "ShawOpen" SSID is obvious. It's wide open, so no expectation of privacy and security, so we can safely ignore that for the moment, but we will get back to that. The "ShawSecure" SSID though was what caught my eye. Upon reading the FAQ, I found the 'ShawSecure' do be far from secure, and probobly worse than using the "ShawOpen".
Throughout the documentation in the FAQ and in Various Press Releases talking about it being secure (the 'ShawSecure' option anyways). The Cisco Press Release on the matter uses the phrase "Highly secure" to describe the network. To paraphraseThe Princess Bride -"They keep using that word. I do not think it means what they think it means."
As I will show, the network is curiously far from secure. It is a constant sore spot with me when companies claim security of thier products but it's only lip service. I'm a big advocate of testing things yourself, which often results in some scary findings.
In the FAQ, Shaw provides the WPA passphrase to access the "ShawSecure" network. The passphrase is "shawwifi", which is far from creative, but indicates they are using WPA-PSK (As opposed to WPA-Enterprise which would most likely need a username and password, depending on configuration). They also point out in the last portion of the FAQ:
Remember this assertion, it becomes silly later.
WPA-PSK generates several layers of keys, each client recieving a unique key in the end for that session. The key generation process is bootstrapped with the pairwise master key (the PMK) which in turn generates pairwise transient keys (PTK's). For a good description I would suggest reading this paper
The technical nitty gritty is that while WPA-PSK provides security, the standard rule of thumb with crypto is that the security lies with the secrecy of the key. While WPA-PSK does generate a unique, per-session key (the PTK) that is supposed to prevent users from sniffing each other, the PTK is generated from the PMK (in this case, "shawwifi"). If an attacker knows the PMK, he can use that to follow the handshake between clients and the network that generates the PTK for each client and thus, decrypt the whole session fromthen on. If the attacker misses the handshake or is late to the party, they can juse deauthenticate the client and capture thier return to the network. Shaws use of a public PMK means the false sense of security is in some ways worse than no security at all.
To demonstrate this, I visited one of these installations, not terribly far from the RenderLab. I connected my Iphone to the secure network as per the instructions and began to collect data with my laptop.
It was trivial to decrypt the data. Wireshark, the free and open source network protocol analyser, makes this easy. In the preferences you can set a WPA passphrase for a network and once a 4 way handshake is captured, the whole session can be decrypted. The Wireshark FAQ shows how to do this, but a live example from live testing is below.
Fig.1 Packet capture before decryption - Note all data is encrypted
Fig.2 Entering the WPA passphrase
Fig.3 Same packet after decryption - Note packets are decrypted and visible
Another method is to use Airdecap-ng, part of the Aircrack-ng package. airdecap-ng -e ShawSecure -p shawwifi capturefile is the command you need to post-process the captured packets to decrypt them.
Another risk with these networks is the fact that they are using email addresses and the username and the password for that email account as the password. While using email addresses as a unique identifier is not new, this is the first time I have seen where the password for accessing mail is required, as opposed to creating a different password, seperate from mail retrieval purposes.
While it may be convenient for Shaw to use this existing username/password scheme, it is a dangerous practice. Best practices for security as well as common sense tell us not to use the same passwords for different things. The danger comes from people entering thier email addresses and email passwords into a network that says it is Shaw's public network, but there is no real (or easy) way to verify that it is. It is trivially easy for an attacker to set themselves up as one or both of the Shaw network SSID's and present a page that looks identical to the normal login page, harvest usernames and passwords and then pass through that authentication to the real access point to provide seamless interenet access (The login page is SSL encrypted, but very few people know how to authenticate a SSL page, so that it is not reliable).
As you can see, the security of the 'ShawSecure' network is pretty much negligable. It is trivial to decrypt the data being sent over the secure network, so much so that you may as well be using the 'ShawOpen' network.
Let's look at that last FAQ entry again:
While technically true, Shaw is negating the effect of the security by handing out the key to anyone and everyone. A WPA-Enterprise (WPA-Radius) solution would provide a great deal more security. Since Shaw is using thier users email addresses and passwords to authenticate users in the captive portal, it is presumable that they could use the same system could be adapted for use as a backend for a WPA-Enterprise solution which provides true unique keys per user and prevent the problem noted above. The downside is that the client device configuration can be a royal pain in the butt and cause a great deal of tech support calls since WPA-Radius(Enterprise) has a large number of variations in supported encryption standards that are not supported evenly accross all devices.
While the attempt at a secure option is nice to see, anyone who wants to capture client data can do so with ease. Shaw would do better to either implement a WPA-Enterprise solution for those who really want security (leaving the open network for those who do not or are oblivious to the risk and the WPA-PSK network for those who want a false sense of security), or scrap the secure option entirely and do more to educate users about the security risks associated with open, public Wifi.
Shaw should also consider a way to diverge the login page password for the captive portal from the password used to connect to email. While loading this password does help boot strap operations (and presumably uptake of the service), it would be recommended to have a way to change the login password and/or username used for the captive portal. This gives people at least the option to not reuse passwords in a situation that is easily compromised.
Additionally, if Shaw did implement a 3rd network with WPA-Enterprise(Radius), Bi-directional certificates could be used to authenticate the network to the client and vice versa for mutual authentication that would remove many of these risks. This however has the downside of being a royal pain to setup on the client and will generate alot of support calls, costing lots of money.
As a user, there are a few things you can do to protect yourself should you choose to use these networks, or any public networks for that matter.
First, never trust anyone who says 'your secure'. Verify it yourself or seek out other opinions.
Second, a VPN is your friend. A VPN establishes a secure 'tunnel' to a trusted system (like your home or office). In this way, everything between your device and the access point (and beyond, all the way to the other end of the VPN) is encrypted. There are a host of different products and protocols for VPN's, it all depends on your devices and what they support. Ask your IT person or the nearest 11 year old.
Third, for any online service that uses a password (Email, twitter, facebook, etc), use SSL. That usually means going to the https version of a site instead of the http version. Check if your ISP on how to enable SSL for accessing email. Plugins such as HttpsEverywhere can redirect you automatically to the https version of many popular sites automatically, preventing you from accidently going to the insecure version of a site and revealing your passwords. Also learn how to authenticate the certificate of a site you are about to enter a password on. Just because it is SSL secured does not mean it is the real site: READ ERROR MESSAGES!To Shaw's credit, this is just a pilot program, concievably, to ferret out these sorts of issues. It is hoped that they take this advice to heart and can implement some changes before a large scale roll out. Sadly I have little faith that these changes will be implemented or even considered and Shaws customers will suffer because of it.