Delivering a black eye to SecTor, the annual IT security conference held in Toronto, Ontario, Canadian security vendor eSentire admitted to collecting and displaying attendee information from what attendees thought was a secured network. With the full consent of conference organizers, eSentire collected login credentials for popular services such as Twitter, Google Mail, and Hotmail and posted the collected information on a “Wall of Shame”.

SecTor, in collaboration with Andover, MA-based Enterasys Secure Networks, provided wireless connectivity to attendees, presenters, and vendors in two formats: an “Open SSID, No Encryption, No Authentication” network named “Sector2009” and a “Secure SSID, WPA2-AES”-encrypted network named “Sector2009Secured”. To use the “secure network”, a short stop at the Enterasys booth to obtain the credentials, was required. Most security conscious attendees used the secure network understanding the perils of connecting to an open and unsecured network. This security blanket, however, was abruptly removed and attendees – who thought they were securely connected – were exposed.

The “Wall of Shame” idea was taken from the long standing “Wall of Sheep” that prominently appears at Defcon and Black Hat security conferences. The Wall of Sheep, commonly referred to as “The Wall”, is an interactive demonstration of what can happen when network users let down their guard. In an attempt to mimic the success of the Wall, eSentire and SecTor decided to create the “Wall of Shame”. This version of The Wall displayed usernames and partially obfuscated passwords for services that attendees connected to using unsecured protocols. Brian Bourne, conference organizer and master of ceremonies, announced that the collection would occur on the first day of the conference. What wasn’t mentioned, however, is that both the unsecured and secured wireless networks were being monitored even though the conference literature expressly stated the “Sector2009Secure” network was, in fact, secure. Most attendees, myself included, thought that using the SecTor/Enterasys provided “secured WiFi” connection would save themselves from the embarrassment of being displayed on the Wall of Shame. Unfortunately this was not the case.

At the SecTor speakers dinner, several attendees were approached by colleagues and informed that their credentials appeared on the “Wall of Shame” for all to see. When questioned about how the encrypted and unencrypted traffic was being monitored, Eldon Sprickerhoff (founding partner at eSentire) stated that, although capturing and decrypting the “secured WiFi” traffic was possible, it was much easier to directly connect a network tap into the physical network and capture both streams of traffic. Because both streams were unencrypted by the time the traffic reached the physical network, the security of the secured WiFi no longer existed. Enterasys, when questioned about their involvement in or knowledge of the collection, stated that they were only aware that the unsecured wireless network was being monitored and were shocked to find out that the physical network was also affected.

Several vendors on the trade show floor were understandably upset when they learned that portions of their sensitive credentials were put on display for all to see. “If vendors are going to be sponsoring the event, then we should be notified that this type of activity is going on.” said Billy Austin, CSO of SAINT Corporation. “Most people know me and personally do not care about my information being shown, however my time is of value and having conference attendees come up to me and tell me that my information is being illustrated on the wall of shame is consuming time away from my busy activities.” Austin stated that if he had been forewarned that the activity on the wireless access points would have been made public, he would have selected an alternative option.

Sprickerhoff stated that this practice had been cleared with the conference organizers to better represent the threat of unencrypted traffic being exposed on the Internet. The problem is that no one was informed that the “secure WiFi” traffic was also going to be subjected to the embarrassment of The Wall. David Fraser, Chair of McInnes Cooper’s Privacy Practice Group, expects that attendees probably had an expectation of privacy with their use of the WiFi network, particularly the secure one. “Broad lists of private communication interception tools are prohibited under the criminal code.” said Fraser “A computer being one of them.” Fraser stated that if a secure connection method and an unsecured connection method were provided to attendees, the expectation of privacy would be enhanced in regards to the secured WiFi option.

According to Fraser, Section 184 of the Canadian Criminal Code explains the legalities behind the interception of information. “There are laws against the interception of private information.” explained Fraser. “Section 184 of the Criminal Code state that it’s illegal to intercept private communication without consent.” Fraser stated that posted signs, login screens, and other informative mechanisms could have been used to communicate that attendees network activity was subject to collection, but it’s an open question whether that would be enough “consent” for the interception. “If someone walked in late, missed the announcements, and connected to the wireless network they might not have known that the collection was happening until after the fact.” explained Fraser. The act of intercepting private communications without consent is a federal offence and is punishable by up to 5 years in jail. Furthermore, Fraser said that privacy laws, such as the Personal Information Protection and Electronic Documents Act (PIPEDA), also apply to the situation.

During the morning break announcements on the second day of the conference, Bourne informed all attendees that only the unsecured wireless network traffic was being collected and displayed by eSentire on the Wall of Shame neglecting to mention the direct network collection captures. During the lunchtime announcements it was announced that, “due to numerous complaints”, the Wall of Shame had been taken offline and the collected data would be destroyed. To add insult to injury Bourne thanked eSentire and applauded the exercise as a success.

Attendees have not received any guarantee that their collected information was disposed of by eSentire in a forensically sound way. “[eSentire] has an obligation to safeguard the collected personal information and must see to it that secure destruction methods be followed.” said Fraser. “Collecting the information in the first place is unreasonable.” Dr. Michael Geist, law professor and Canada Research Chair in Internet and E-commerce Law at Ottawa University, was also shocked about how the events unfolded. “This is a clear violation of Canadian privacy law.” said Geist. “Someone should file a complaint with the [Privacy] Commissioner as that would provide a more valuable lesson than the fake one the organizers tried to create.”

UPDATE (2009/10/15 at 5:04pm EST): After speaking with Brian Bourne at some length, we both agreed that it needed to be communicated that Eldon Sprickerhoff is a member of the SecTor organizing committee. This committee was responsible for the design and implementation of The Wall of Shame at SecTor 2009.

Yesterday, Twitter announced that they had changed their terms of service (TOS) to allow them to, among other things, hand over your information to advertisers and “use, copy, reproduce, process, adapt, modify, publish, transmit, display and distribute” your tweets. They stress, however, that you own your tweets even though they can do whatever they want with them.

The following excerpt, taken from the Your Rights section of the TOS, tries to expand upon the rights Twitter says you have but really focus on their rights to do whatever they want, whenever they want (highlighted parts are the scariest):

You retain your rights to any Content you submit, post or display on or through the Services. By submitting, posting or displaying Content on or through the Services, you grant us a worldwide, non-exclusive, royalty-free license (with the right to sublicense) to use, copy, reproduce, process, adapt, modify, publish, transmit, display and distribute such Content in any and all media or distribution methods (now known or later developed).

You agree that this license includes the right for Twitter to make such Content available to other companies, organizations or individuals who partner with Twitter for the syndication, broadcast, distribution or publication of such Content on other media and services, subject to our terms and conditions for such Content use.

Such additional uses by Twitter, or other companies, organizations or individuals who partner with Twitter, may be made with no compensation paid to you with respect to the Content that you submit, post, transmit or otherwise make available through the Services.

We may modify or adapt your Content in order to transmit, display or distribute it over computer networks and in various media and/or make changes to your Content as are necessary to conform and adapt that Content to any requirements or limitations of any networks, devices, services or media.

You are responsible for your use of the Services, for any Content you provide, and for any consequences thereof, including the use of your Content by other users and our third party partners. You understand that your Content may be rebroadcasted by our partners and if you do not have the right to submit Content for such use, it may subject you to liability. Twitter will not be responsible or liable for any use of your Content by Twitter in accordance with these Terms. You represent and warrant that you have all the rights, power and authority necessary to grant the rights granted herein to any Content that you submit.

The TOS also expands on how Twitter can, if they want, bring advertisers into the mix (again, scary parts highlighted):

The Services that Twitter provides are always evolving and the form and nature of the Services that Twitter provides may change from time to time without prior notice to you. In addition, Twitter may stop (permanently or temporarily) providing the Services (or any features within the Services) to you or to users generally and may not be able to provide you with prior notice. We also retain the right to create limits on use and storage at our sole discretion at any time without prior notice to you.

The Services may include advertisements, which may be targeted to the Content or information on the Services, queries made through the Services, or other information. The types and extent of advertising by Twitter on the Services are subject to change. In consideration for Twitter granting you access to and use of the Services, you agree that Twitter and its third party providers and partners may place such advertising on the Services or in connection with the display of Content or information from the Services whether submitted by you or others.

If you’ve sold your soul to Twitter, now might be the time to try and get it back before you’re inundated with advertisements tailored to your tweets. So much for privacy in social media (although I’m not sure there ever was an expectation of privacy in social media).

I, for one, am contacting the Office of the Privacy Commissioner of Canada to see if Jennifer Stoddart can swing her privacy bat like she did to force Facebook to change their stance.

As a followup to the Google Gmail outage post I thought I’d post the email notification sent from Google to all of its “premium account holders”.

I know it’s a form letter but it does convey their apologies, provides links to the incident report, and details the credit that they will be providing for the outage. I really do appreciate the credit as, based on the terms of their SLA, Google was well within their rights to simply claim that the outage fell within their conveyed SLA figures. Good for you Google 🙂

Dear Google Apps customer,

We would like to follow up on the recent Gmail outage and resulting credit through our service level agreement (SLA) with you.

Between 12:45 PM to 2:15 PM PDT | 19:45 – 21:15 GMT on Tuesday, September 1, 2009, Google Apps Gmail users were unable to access their accounts through the Gmail web interface. Users could continue to access their accounts via IMAP and POP. No data was lost during this time; messages were received and delivered, but could not be displayed.

As a result of this incident, we are extending a 3-day SLA credit to your account. This credit will be reflected in an automatic 3-day extension to your Google Apps term date, and no action is needed on the part of your administrators.

We understand that this service outage has affected our valued customers and their users, and we sincerely apologize for the disruption and any impact.

Following are the key points from the incident report:

On Tuesday, September 1, a small portion of Gmail’s web capacity was taken offline during a routine upgrade and service update. This is normal operating procedure as the Gmail web interface runs in multiple locations, and Gmail’s request routing automatically directs users’ requests to available servers. However, we underestimated the increased load that some of the new updates placed on request routing.

As a result, at approximately 12:30 PDT, a few request routers became overloaded and responded by refusing all incoming requests. This response transferred the load to the other request routers, and as the effect rippled through the system, almost all of the request routers became overloaded. As a result, users could not access Gmail through the web interface since their requests could not be routed to a Gmail server. Gmail processing and access through the IMAP/POP interfaces continued as usual because these processes use different request systems.

Upon receiving the error alerts, the Gmail Engineering team immediately began analyzing the issue and initiated a series of actions to help alleviate the symptoms. After determining the root cause to be insufficient available capacity, the Engineering team deployed a large-scale addition of request routers through Google’s flexible capacity server systems. As they distributed incoming traffic across the expanded pool of request routers, access to the Gmail web interface returned to normal.

During the incident, we published ongoing reports to the Google Apps dashboard, Gmail Help Center, the Enterprise and Gmail blogs, and the GoogleAtWork and Google Twitter feeds, to help provide customers with the latest status and available workarounds.

The complete incident report (http://www.google.com/appsstatus/ir/buuqdnt6fcervea.pdf) in the Google Apps Status Dashboard describes the corrective and preventative measures to address the underlying causes of the issue and to help prevent recurrence. For ongoing service performance information, please see the Google Apps Status Dashboard at http://www.google.com/appsstatus.

Once again, we apologize for the impact that this incident has caused. Thank you very much for your continued support.

Sincerely,

The Google Apps Team