The reality that the Internet is not secure, especially on open networks like coffee shops wireless services and mobile connections, is well known but little understood, and acted upon even less. Users know that these networks are unprotected, but many are unsure of what that means, or what information of theirs is at risk.
For casual users, it’s natural to assume that if you have logged into a web application using a unique username and personal password that your session will be safe, but that is not the case at all. Logging in is actually the act of opening a connection to a network, with no guarantee that connection will remain safe. Open networks usually offer no protection, and plain HTTP connections are unencrypted, so if a hacker can gain access through that connection to the system, they can use your connection to hack into your account, steal information, change your password, and while they’re at it, access other open connections on the same network. This session hijacking is known as “Sidejacking”.
Vulnerability
The wireless networking 802.11 standards have a poor record in terms of security. Early wireless networks relied on Wired Equivalent Privacy, or WEP, which is an authentication system that was intended to offer an equal degree of security with wired networks. However, as it turned out, WEP had inherent problems built into it, and any WEP implementation could be hacked into all too easily. In addition, wired networks were far less secure than most people realized, so even if an equivalent degree of security had been achieved, there was still an enormous amount of risk incurred by doing banking, e-commerce, or other sensitive interactions online.
WPA2, or Wi-Fi Protected Access version 2, was the successor to WEP. It improved security by combining encryption with authentication. Despite the improved security available with WPA2, unprotected, WEP-secured Wi-Fi hotspots are still commonly provided for public access because of ease of use and ease of connectivity. Hotspots often rely on access control that is provided through a form of proxy authentication by the local hotspot router – with the authentication unencrypted and executed over unprotected HTTP.
Wi-Fi networks are inherently insecure because signals can be intercepted without having a physical connection, but there is a widespread misconception that wired networks are safe. Nothing can be further from the truth. Through social engineering, hacking tools, sniffers, and brute force computing, wired networks are also at risk. Security experts have demonstrated that wired networks are vulnerable to sidejacking attempts as well.
Additional vulnerabilities exist in mobile communications. Although security awareness and implementations are growing for mobile devices, most mobile sites still don’t make use of security measures like SSL certificate, even though they are becoming compatible with more mobile browsers. In addition, many people’s mobile devices are not latest, leaving them open to vulnerabilities that technically no longer have to exist. Even a visit to the app store is an opportunity for hackers –browsing and buying activity can reveal a password, or give a hacker an opportunity to substitute the legitimate app you just bought with malware at the point of download.
Secure Socket Layer (SSL) and its replacement, Transport Layer Security (TLS) is standard protocols for establishing a secure, encrypted link over the internet. Users can see that a given web page implements improved security because the protocol displayed in the address bar is HTTPS rather than HTTP. It is often shown green address bar and is displayed with a lock symbol. Unfortunately, many sites still use HTTP, which was the original application protocol of the Web, even for e-commerce and other applications which should demand privacy. Even if TSL/SSL is used to establish the link, parts of the remainder of the session still might be conducted over open, unencrypted HTTP. This means that all traffic travels around the local network in plain text and that anyone on that same network can read it.
A particular vulnerability exists in a common practice of websites that use cookies. HTTP is said to be stateless, or connectionless, and session less, meaning that a connection is created and terminated for each message that is exchanged. Applications provided over the Internet, like a shopping cart, or a bank account, must themselves provide a mechanism to keep track of users and their session data – information such as user credentials, user activity, what information had been submitted, what page they are viewing, and what they’re doing there. Web sites keep track of session detail by using cookies, which are a type of information stored on a user machine.
Although there is a “secure” flag that can be sent with cookies, it isn’t commonly used, largely because it interferes with the user experience. The flag tells the browser to send the cookie only over an HTTPS (TLS/SSL) connection. Someone monitoring an open network can see the data in the cookies sent over HTTP. The cookie data then can be used to spoof the user. This attack is known as sidejacking, and is a form of session hijacking. This is what the hacker’s aid Firesheep does.
Firesheep Attack Tool
Firesheep was developed by security expert Eric Butler as an extension for the Firefox web browser. It was released in October 2010 at the hacker conference ToorCon 12 in San Diego. Butler says he released it to raise awareness of the security problems of open wireless networks.
Firesheep uses a packet sniffer. It shows the names of users on the open local network and the services to which they are connected that are using unsecured cookies. It can piggyback on those sessions if the hacker simply double-clicks on the name. The hacker, once connected to the local network, can monitor the web sessions of other users on the same open network and even take over their sessions. All this is available to casual hackers, using a tool that’s universally available as an extension for a universally available browser.
Firesheep was meant to target open Wi-Fi networks, but the cookie vulnerability exists even on conventional, wired Ethernet networks.
The solutions to these problems lie with the network chain: the hotspot provider, the user, and the web service provider. Hotspot providers should provide secure networks. The website that provides the services should use TLS/SSL for all connections to the website, not just to pages that are considered sensitive, but to all of them, including the home page. There is a perception that there is an overhead in processing power, and therefore in cost and performance, but true costs are very little, and the benefits are great. Users should educate themselves in how to protect themselves on open, public networks, but even if most of them do – which is unlikely – a network is only as strong as the weakest link. Anyone not taking proper precautions on an open network opens everyone on that network to intrusion.
Protection for the hotspot provider
- WPA2 is a good solution on the hotspot provider end. It implements authentication, encryption, and even user isolation to prevent packet sniffing.
Protection for the Web services provider
- Always-on TLS/SSL is the best solution to protect users. Full use of TLS/SSL entails the use of the “secure” flag for cookies.
It had seemed that if users logged into their accounts over HTTPS with a unique username and password that it would be sufficient to secure a session, but it turns out that a Firesheep attacker or any other sidejacker could gain access to unprotected cookies and manipulate information within that account. But always-on SSL, meaning having a website secured with HTTPS, and encrypted, from the time of first access to the time the user leaves. Always-On SSL even encrypts the cookies exchanged between two ends and secures entire user experience and make it safe to search and share.
Sites that use TLS/SSL then also need to use a trusted Certificate Authority, to ensure the safety of the certificates. Good certificates cost money, but it’s a fixed, predictable cost. Many organizations worry that the problem will be hardware costs because using TLS/SSL involves encrypting all traffic at one end and decrypting it at the other. Intuition would say that on a major site, this could entail big costs for hardware. But consider Google, which converted their Gmail service entirely to HTTPS in 2010. To do this they deployed no additional machines and no special hardware. In their case, and for many data-driven online sites, SSL/TLS would account for less than 1% of the CPU load, less than 10KB of memory per connection, and less than 2% of network overhead.
Protection for the user
There are steps you as the end user can take to ensure the ultimate effectiveness of your own and everyone else’s security efforts:
- The user can get a virtual private network (VPN), many of which are available at low cost online. A VPN creates an encrypted tunnel from the user to a host on the Internet which acts as a proxy for all client communications.
- Use VPN options for mobile devices; they can encrypt data you send over mobile apps.
- Check for HTTPS at the start of the web address throughout your online session, not just when you log in. Many websites use encryption on the log-in page and sensitive e-commerce pages, but if any part of your session isn’t encrypted, the entire account could be vulnerable.
- Log out of your accounts when you are done. Do not stay permanently signed in.
- Use strong password management – different passwords for different accounts, long enough and varied enough to be hard to break.
- If your web browser warns you about a fraudulent website, don’t go there!
- Keep your browser and security software is up-to-date.
- Change your mobile settings to ensure that you don’t automatically connect to public Wi-Fi, so you can have control over your network connections.
- Favor the coffeehouse with WPA2 over the one with WEP.
- Make sure your home wireless network is secure by using WPA2.
- The Electronic Frontier Foundation (EFF) released its own extension, called HTTPS Everywhere. This extension tries to turn HTTP into HTTPS. The problem is that it only works with sites that have SSL available but default to HTTP. Also, it can impede connections to certain wireless networks and even some Google services. And it can’t intercept user activity on a site using JavaScript to transmit cookies in plain-text. There is a similar extension called Force-TLS, but it also can’t operate on all websites.
- Be especially careful when using mobile apps. They don’t have a visible indicator like HTTPS to tell the user whether or not information is encrypted. Many mobile apps don’t encrypt information properly, so you probably shouldn’t shop or do your banking using mobile apps on unsecured Wi-Fi. If you want to use your mobile device for things like that, be sure you are using a secure wireless network – or your phone’s data network, which often incurs charges.
- If you are in a situation where you must use an open wireless network for banking or other transactions, use the mobile website on the browser, where you can check for HTTPS in the URL, instead of the mobile app, where you can’t.
Conclusion
Wireless hotspot providers, businesses that provide web services, and users must all look out for themselves, and not assume that the other participants in the network are providing the security. With a browser extension like Firesheep available to any amateur hacker, hotspot and application providers should do what they can to make the environment safe for the user and specifically to prevent sidejacking by Firesheep or any other means. But the user ultimately must assure his or her own safety – by checking the environment, using safety tools like VPNs if appropriate, and taking special precautions when using a mobile device for sensitive business.
There are things that can be done by everyone in the chain to make the Internet a safe place to do business, and the way to have the most effective, most secure Internet would be if everyone assumed their logical part of the responsibility.
