In the past 48 hours or so, rumours about the SecTor Wall of Shame have been circulating through the intertubes, blogs, twitter and exhibitor floor conversations.
After an obviously agitated media member (a blogger for InternetNews.com) wrote this post about SecTor’s Wall of Shame, several security professionals attending the event began asking questions about the collection of data on the Wall. Honestly, I blew off most of the blogger’s statements due to his poor writing, agitated tone and obvious misunderstanding of the technology and security. I didn’t investigate until a handful of colleagues approached me.
Many of those attendees (and other vendors) didn’t like what they heard; The Wall of Shame was displaying captures from both the secured and unsecured (open) wireless networks.
I heard a flurry of rumours that the vendor hosting the Wall of Shame (eSentire) was cracking the AES encryption, the wireless sniffing was actually a wire tap and several others; some true, some not. After hearing all the noise and being contacted by several peers, I decided to write this post.
Brief History of the Wall
Similar to the popular Defcon Wall of Sheep, the Wall of Shame at SecTor follows tradition of most security and hacker events, at which unprotected user data is prominently displayed to the conference audience. Generally the Walls are run by conference staff or volunteers. They typically capture unencrypted data from users on the Open (unsecured) wireless conference network and display it in a fairly harmless way, with the username and a partially masked password shown. Common practice is to mask (or blank) all but the first three characters of the password. It is not uncommon for conference Walls to collect the wireless data on the wired side, instead of sniffing wireless traffic directly.
Quick Facts: Wall of Shame
- Therewere two conference (non-hotel) wireless networks: Open wireless and WPA2 secured wireless.
- The WPA2 PSK (pre shared key) could be requested at the Enterasys vendor booth.
- The Wall was hosted by vendor eSentire at their booth.
- The Wall was collecting data on the wire (vs sniffing wireless).
- The Wall was displaying data with username and partially masked/obscured password.
- The Wall was collecting (but not displaying) all wireless traffic, passwords, cookies, attachments.
- The conference management announced the Wall and wireless usage to attendees during the opening remarks and lunch breaks both days of the conference.
- At no point did eSentire or the conference management try to mislead attendees or wireless users as to the monitoring of the network.
Why People are Mad
In addition to the blogger, several people have expressed their extreme displeasure in the Wall of Shame. As it turns out, the Wall was, in fact, displaying data from both the Open wireless (as expected) as well as the Secured wireless (not expected). The point of the Wall at most events is to demonstrate how unsecure wireless networks are. The fact that they choose to tap the wire instead of sniffing wireless to get the data is just a matter of convenience. Having said that, it is not common practice for conferences to tap BOTH the Open and Secured networks. By virtue of offering two networks at SecTor, most people had an expectation of privacy on the Secured wireless; and I believe that’s not unrealistic.
How the Secure Wireless was Shown
There was no crazy crypto or magic fairy dust. Since the wireless data was captured on the wired side, it was unencrypted. To be more accurate – any added protection offered by the encryption between the access point and the endpoints had been removed. Wireless security can be applied several ways, a common method being encryption between AP and connecting device (ie laptop). If users were accessing something PAST the conference network securely, then that data was secure as it traveled through the wired and wireless SecTor network. See Figure 1 below.
I did hear a few rumours of eSentire decrypting traffic as well as general notions that the Secured (WPA2) wireless wasn’t really secure, since the pre-shared key was available to everyone. ESentire was not decrypting or cracking anything. Ideally in WPA2 implementations, key rotation is turned on, making the wireless portion secure even with a shared key.
The Good Intent
Although the use of the Wall might have been past our normal expectations, the intent was good and not malicious in the least, both by the SecTor management as well as eSentire. The purpose of The Wall of Shame, just like all other Walls, is to demonstrate exactly how unsecure we are each day. Most users of network technologies don’t understand the vulnerability of sniffing wireless and/or tapping wired networks and eavesdropping. The only way to convince them in many cases is to SHOW them, and that’s exactly what the wall does.
By extending the Wall beyond Open wireless and also showing the decrypted wire-side traffic from the Secured wireless network, I think they further proved the point. They did not ‘crack’ anyone’s encryption, nor did they dig into tunneled or secured traffic passing through the conference network. All they did was shine a light on what people were happily passing through the network, just as they do everywhere else. If it was secured coming in, it was still secure going out, and vice versa.
You can be mad if you want to, but anyone that’s mad about the Wall of Shame should be thankful that it was pointed out to them in a safe, controlled environment. If you were on the Wall, that means every day you connect to networks you assume to be secure. Every day you pass data, unsecured, through other peoples’ networks. Every day you’re vulnerable and every day you’re ONE day closer to being compromised.
Even SecTor’s conference director, Brian Bourne was a victim of his own showcase of vulnerability. Brian posed a tweet, poking fun at himself “Note to self: Tweetdeck does not make SSL connections. My password on wall of shame. I am shamed.”
An Aside On How Not to Be a Sheep
Figure 1 above shows the various methods we can secure wireless (and wired) networks as our traffic passes through other peoples’ networks. This is really another topic, deserving of another post – stay tuned. In the meantime, as you think about the Wall of Shame, keep this image in mind. The Open wireless has security 0 (no encryption, anywhere). Other options might be to encrypt between the laptop and access point (A). Some wireless designs include a controller-based model that allow access points to encrypt data through the first set of switches, to the wireless controller (B). Many secure wireless networks use a VPN model and secure between the endpoint/laptop and some VPN aggregator sitting at the core or WAN edge (C). Using HTTPS sites (secure HTTP) are recommended highly since they encrypt from the browser of the laptop to the web server (D). One of the most secure options is a VPN tunnel through any unknown or hostile networks (including the Internet) to a VPN termination at home office (E).
In the context of the Wall of Shame, methods 0 (open) and A (encrypted to AP) are vulnerable in many ways, such as the Wall demonstrated so clearly. Methods B and C didn’t apply to this scenario and methods D and E would have remained secure and uncompromised on the SecTor conference network.
The Bad
There are a couple of things I didn’t like about the Wall of Shame. I’m not comfortable with a vendor hosting the wall and therefore collecting the data and having access to it; even if the intention is to immediately destroy it. I think there’s a potential for trust violation. What a vendor does is beyond the immediate control of the conference management and staff. That little nit pick aside, I do think users should have been warned in a way that they could not claim ignorance. The conference management told attendees about the Wall and the network monitoring numerous times and made no attempt to hide or mislead the group. However, it is possible to have attended the event and not been present for those notifications. A captive portal with a terms of use clause and warning would fix that. After speaking to conference management about concerns, I believe they are all being addressed in any future versions of The Wall.
Your Opinion?
I feel the technical implementation of the Wall was acceptable. There was no malicious intent, no harm done and it did not introduce any new vulnerability to clients connecting to the network. It was simply a spotlight.
People not familiar with the technology may disagree. To avoid any misunderstanding or further complaints, the Wall was taken down early Wednesday morning and all data removed/destroyed. Brian and the SecTor management have taken the feedback and are planning a better implementation of the Wall for 2010. What are your thoughts?
# # #
[…] Some unhappy bloggers ended up on the Wall of Shame at a recent security/hackers conference and (I summarize…) cried foul because it wasn’t pre-advertised that the network would be hostile. There is a good post on the hub-bub here. […]
Great write up JJ.
[…] Security Uncorked >> Good, Bad and Ugly: On SecTor’s Wall of Shame Tags: ( passwords wireless ) […]
Jason, Justin, Wim, Rodney, Ryan:
I think we’re in agreement. I certainly think the Walls are a great way to responsibly help people be less sheepy :)
Peter, Chris:
Peter, I see your point. I’m not familiar with Canadian law (obviously), but here, if you own the network, it’s not interception, it’s monitoring your own network which is not only allowed, but advised and in many cases, required. I have to agree with Chris- we always assume if YOU don’t own the network you’re on 100%, then your data is not safe if unsecured.
Cjp:
Yep. People dismiss issues with ‘casual’ networking sites such as Twitter, Facebook, etc. The point that’s missed is that even THAT can put you in a compromising situation and more often than not, those low-security site passwords are repeated in use for more secure sites, such as email and online banking, places that people DO care about remainnig secure.
-jj
This demonstration will hopefully outrage people enough such they will demand all their client apps support TLS (or other encryption method), and make it the default method of connection, and make it clear it is working.
Service providers need to disable clear-text authentication mechanisms. There is no reason twitter should allow unencrypted logins through the web or their API. In 2009, there is no reason to have a non-TLS’d IMAP server.
No network, wired nor wireless, is safe from snooping. Use strong encryption everywhere.
Great writeup JJ. I was personally surprised about the fact that they were listening to the “secure” network. When it comes down to it, I always thought that the purpose of the wall of sheep/shame was to illustrate that when you connect to an open network, you are essentially shouting anything you are transmitting to anyone who is within earshot. By connecting to an open wireless and not utilizing secondary encryption such as a vpn you are being led into a dangerous situation.
If the wpa2 network was not intended to be secure, then I don’t understand why all the extra measures were required to connect to it. Requiring people to stop by and talk to a vendor in order to obtain a key to the “secure” network certainly makes it seem like there are precautions being taken to ensure that the traffic that is being passed is safe. While obviously the traffic wasn’t displayed in full, I think it would have been more transparent not to offer a “secure” alternative, and just offer open authentication if the goal was to sniff all the traffic.
When talking about the risks of the wireless to wired transition, you have to assume at some level there has already been a compromise I think. If I have someone sniffing off a tap port in my network for other than diagnostic purposes, then I would consider that to be a compromise in confidentiality and would probably start incident response. We can follow the “what if” train all the way from what if someone gets on the wire, to what if someone is able to modify a MPLS configuration or VPN link, to what happens if someone poorly secures a SSL private key. In the end, all of those are problems and important things to look at, but I’m not sure they were what the wall of sheep/shame was trying to demonstrate.
All in all, I appreciate what they were trying to show, and I think that we learned some good stuff. I know more about how some twitter apps work and some of the other apps that don’t talk SSL by default for sure. I think that SecTor had the best of intentions and that they felt like everybody knew what was going on as the staff communicated multiple times that people were listening, although I am not sure they were explicit enough in saying what they were listening to. I do hope though that they do it a little bit differently next year so that something like this doesn’t distract from an otherwise great conference.
I would have to question how the traffic was captured “fraudulently and without color of right” if the capture was authorized by the network’s owners (SecTor staff) and announced to the conference attendees.
This is in fact, part of the point. You should have zero expectation of privacy on someone else’s network’ If you’re accessing anything sensitive on someone else’s network without securing it over some sort of VPN tunnel which you control’ you’re asking for trouble’ If you’re doing this _and_ your day job is in information security, your company is asking for trouble by continuing your employment’
JJ,
While I totally appreciate your well-articulated thoughts on the events that occured at SecTor this week, the facts do not centre on encryption, lack of it, or otherwise. Simply, section 342.1 of the Canadian Criminal Code says:
“(1) Every one who, fraudulently and without color of right,
(a) obtains, directly or indirectly, any computer service, (b) by means of an electro-magnetic, acoustic, mechanical or other device, intercepts or causes to be intercepted, directly or indirectly, any function of a computer system, …is guilty of an indictable offence and liable to imprisonment for a term not exceeding ten years, or is guilty of an offence punishable on summary conviction.”
Intercept is illegal in Canada.
People missed the point and are still missing the point. The secured wireless was not comprimised, the wire was. All wireless turns to wired at some point along the way. Far to many people put all their attention into securing the wireless portion of their networks but do little to nothing on the wired side. Live RJ45 connections throughout the building, flat networks and more provide attackers (or vendors at security conferences) all they need to capture the traffic.
Just because you are connected to a secured wifi connection does not mean that the traffic going over the wired portion is secured and it has absolutely no effect on your use of insecure protocols (POP3, IMAP, HTTP, etc…) and/or services.
Good write-up JJ.
Same feeling as you and the other readers.
a) if the wall had no purpose, it wouldn’t be showing any data.
b) keep it internal to the conference.
c) make it clear that any data the user her/himself doesn’t encrypt can not be deemed secure on that network.
d) if you consider yourself a tech journalist, you should know better.
Great summary JJ.
I think this wouldn’t have been an issue if they had mentioned that the secure Wi-Fi would have been part of the wall explicitly in the opening.
It sucks that WPA2-PSK is snoop-able despite the addition of the 4-way handshake, but the brute forcing the MAC address used as part of the key makes it trivial: http://www.steve-shead.com/2009/07/08/cracking-wpa2-psk-with-backtrack-4-aircrack-ng-and-john-the-ripper/
Maybe the wall should be using those techniques though rather than cheating with a network tap ;)
Hi;
I liked the fact that there was a wall – I fully agree on a few points:
1. The Encrypted WiFi shouldn’t have been part of the wall – I assumed it wouldn’t have been, so I would have used it, except, I didn’t want to carry a laptop – So I did everything from my phone.
2. A captive portal should always be used in a public setting – setting the standards like, no hacking from here, assume your data will be sniffed, your a .. umm.. yeah if you assume your secure without encryption.
3. The wall needs to be taken in house by the team – they are already “trusted” since people gave credit cards etc to the Sector team, so the data should be safer with them.
Do I want to see a wall next year? I want it displayed full time in the main hall for sure, Biggest screen in there ;). My scariest moments, was not that the wall found stuff – it was more on the number of people that were surprised on how easy it, and other security topics in the talks are to pull off.
Thanks JJ for the digging, and the recommendations next year.
Great write-up! I STILL haven’t made it to SecTor, but I really appreciate how this transpired. Intended or not, the decision to perform packet capture upstream from both unencrypted and encrypted wireless networks was a stroke of genius.
The notion of confidentiality is what drives us toward encryption. This ‘wall of sheep’ implementation brought focus away from the local wireless segment, and violated people’s misplaced trust in the ‘upper layers’ (presentation and application).
Let’s be super simple- the first hop (wireless) was encrypted. After departing that segment, the application design failures (and misplaced trust in them) were clearly documented. (I use tweetdeck too… oops)
Bottom Line: the authentication data wasn’t encrypted, and that is NOT a network failure. The failure was a flaw in application design, an unintended ‘feature’.