Last Updated: 2011-04-10 10:37:08 UTC
by Raul Siles (Version: 2)
About a couple of weeks ago we talked about the new Firefox 4 security features. Today is Google's Chrome turn, due to the recently added and short term upcoming security features:
- Malicious downloads protection: Making use of Google's Safe Browsing API, Chrome will warn users when trying to download a suspected malicious executable file (starting with Windows executables, .exe) . URL: http://googleonlinesecurity.blogspot.com/2011/04/protecting-users-from-malicious.html
- Out-of-date browser plug-ins warnings: The latest Chrome version automatically warns users about any out-of-date plug-ins when they access a web page that requires a plug-in that’s not current. By default the plug-in won't run and the user will see a message to get the latest version of the plug-in. This complements the granular plug-ín blocking capabilities added to Chrome 10. URL: http://googleonlinesecurity.blogspot.com/2011/03/chrome-warns-users-of-out-of-date.html
- Due to the recent CA compromises, once again, the trustworhtiness on the Internet PKI (SSL/TLS digital certificates) is under evaluation. Some initiatives, based on digital certificate reputation services or, at the end, on DNSSEC are moving forward. URL: http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html or Perspectives.
With no doubt, web browser and plug-ins security are crucial for a trusted Internet and Web browsing experience, thus improvements in this field are always welcomed.
Without entering into the web browsers wars (or debate ;) to declare which one is the best one (...all them are pieces of software), I honestly recommend you to use (or at least have handy) a few of them and use them for different purposes. Some (the web browsers you trust more) should be used for casual browsing, running in a restrictive mode (NoScript, HTTPS Everywhere, disabling plug-ins, etc) to offer you the best protection. Others should only be used for critical browsing to confidential and sensitive sites. All them are going to become victims (again) of vulnerabilities in the future, so having multiple alternatives will help you to accommodate 0-days and unpatched flaws while still be able to securely (if possible) browse the web.
In any case, always use the latest and most updated version of any web browser (with all the available plug-in updates applied): Firefox 4, Internet Explorer 9, Chrome 10, Opera 11, or Safari 5 (or any other secure web browser of your choice).
Last Updated: 2011-04-10 07:49:33 UTC
by Raul Siles (Version: 1)
Recently I have been involved in a couple of initiatives that addressed Wi-Fi security as one of their main topics. One of them is the upcoming SANS April OUCH issue, focused on "Staying Secure Online when Traveling". The main constraint associated to user awareness programs is the length limitation on the information shared with users, requiring very clear, simple, and direct messages.
Secure Wi-Fi access awareness is a key component of overall user security nowadays, as most users (if not all) connect daily to one or multiple Wi-Fi networks from their laptops, smartphones, tables, and other mobile (personal and professional) devices.
Fortunately, the ISC audience shares a very technical profile, so it becomes the proper forum to go into the technical and security-related details of how Wi-Fi networks are used today worldwide by users, identify areas of improvement, suggest current and future solutions, and take actions.
Although most ISC readers widely accept that WEP is insecure, aware of well known vulnerabilities since year 2001 and knowing it is possible to get the WEP key in less than a minute (or less) since April 2007, still today lots of vendors and service providers deliver their Wi-Fi equipment (Wi-FI access points) configured by default widely open or with WEP (case 0). Besides that, the fact that WEP makes use of a secret key creates a false sense of security on end users, assuming that if there is a secret key involved... it must be secure.
There are three types of Wi-Fi scenarios users commonly connect to:
- A Wi-Fi personal or corporate network, properly secured and configured through WPA2/AES Personal (PSK) or Enterprise, using a robust pre-shared key or the right EAP types and recommended EAP client settings. This kind of network can be considered secure.
- An open or insecure public Wi-Fi network (or Wi-Fi hotspot), using no security at all, WEP, or an easy to guess WPA/WPA2 pre-shared key, where anyone (even external entities) can easily capture and manipulate the traffic from legitimate users. This kind of network is considered insecure.
- A public Wi-Fi network (or Wi-Fi hotspot) properly secured and configured through WPA2/AES Personal (PSK), using a robust pre-shared key. Similar to case 1 but public. This kind of network is considered... secure by most users... although it depends of your Wi-Fi security insight (read below).
A forth very common case all over the world, although we are not going to pay a lot of attention to, is the illegitimate usage of a third party or neighbor unprotected Wi-Fi network without authorization. The "free" access can turn against the unauthorized user, as the owner of the network, as well as other users, can monitor and manipulate the user activities. The saving costs of using a piggybacked connection won't compensate the associated security risks.
There are very simple and common sense options to mitigate some of the different weaknesses and scenarios previously mentioned (identified by case #), while some others are mitigated using additional security layers that not always offer proper protections. Let's analyze pros and cons of the most common scenarios and security practices used today when connecting to all kinds of Wi-Fi networks:
- Case 0: Wi-Fi vendors and service providers must deliver the Wi-Fi equipment configured by default with WPA2/AES-PSK (this could be a reality starting this year; see slides # 44 and 45 of my 2010 GOVCERTL.NL presentation) using a long enough (the IEEE specification says that at least it should have +20 characters) and random enough secret key (pre-shared key), not based on other equipment details (such as the SSID or MAC address, BSSID). The best option would be not to provide a default pre-sahred key at all, and force users to select a custom robust key at installation or deployment time, or force the usage of Wi-Fi Protected Set-up (WPS).
- Case 1: On a secure personal or corporate Wi-Fi network it is assumed that all users within the network are trusted (Please, do not forget about insider threats). In this scenario, it is particularly relevant to monitor the network through a WIDS (Wi-Fi Intrusion Detection System) and ensure the legitimate Wi-Fi client settings are secure and properly configured (including the management of the PNL, Preferred Network List). Remember, once Wi-Fi infrastructures turned out to be secure enough, the Wi-Fi attacks switched to the client side, with Karma-like attacks (impersonating a legitimate network through a fake access point) being extremely dangerous.
- Case 2: The insecurity of public Wi-Fi networks is commonly mitigated by the use of VPN technologies (SSL/TLS or IPSec based), and most people feel confident of using these kind of unprotected Wi-Fi networks combined with VPNs. When you connect to a public or shared network, apply the principle that you are sharing the attacker's network.
There are some facts that must be considered when the real security of a VPN plus a public Wi-Fi network is evaluated. VPN technologies do not protect against layer 2 attacks, therefore an attacker can use the extremely prevalent ARP poisoning attacks to manipulate the victim traffic. Besides that, the establishment of a VPN is in the hands of the user. This means it will take some time to establish the VPN (from seconds to minutes), and it can even not be established at all, due to availability issues or intentional DoS attacks against the VPN infrastructure. All an attacker requires to exploit or compromise the victim mobile device or computer is a few packets before the VPN is established.
A very realistic and common case where this scenario becomes a real risk is in open Wi-Fi hotspots where the authentication takes places through a (web-based) captive portal. Before the user can establish the VPN, she needs to authenticate against the Wi-Fi hotspot and make use of several protocols, typically at least, ARP, DNS and HTTP(S). The attacker only needs to manipulate any or all them to exploit vulnerabilities on the victim device, using one of the most common methods today to compromise client devices, the web browser and its associated plugins (take a look at the "Browser Exploitation for Fun and Profit" trilogy). All these VPN concerns also apply to other scenarios where VPNs are used, such as case 3.
The most secure option, not only for Wi-Fi but for general Internet usage, is to make use end to end encryption and protection for all communications, what typically involves using SSL/TLS technologies for all protocols (IMAP, SMTP, HTTP, etc). The main concerns associated to this are the target service supporting it for the whole session (not just the authentication process), proper verification of the other end due to digital certificate issues (e.g. the "recent" decreased credibility of the Internet PKI due to trusted CA compromises), and the limitation to use these technologies on lower layer protocols (ARP, DNS or even IP; these last two are what DNSSEC and IPSEC are used for).
- Case 3: The main issue associated to public secure Wi-Fi PSK networks is that all users are sharing the same network, thus all them know the pre-shared key, and therefore, even with WPA/WPA2 Wi-Fi encryption, any legitimate user can capture and manipulate the traffic from other legitimate users (any user can extract the temporary key assigned to other users having knowledge of the pre-shared key). The entry requirement to become a legitimate user can be nonexistent (on free public Wi-Fi networks) or the payment of a small fee any attacker can afford.
The main solution to avoid this kind of shared environment is to use WPA2/AES Enterprise technologies for secure public Wi-Fi hotspots, where each user will be assigned an independent temporary key (that cannot be derived from a pre-shared key). The future should follow this route, being the main drawback the verification of the digital certificates associated to the RADIUS servers and the distribution of legitimate usernames and robust passwords (however, from a traffic eavesdropping and manipulation perspective, even sharing a single username and password between all users in this scenario will be more secure than PSK).
Another option to avoid local network attacks is to use the mobile broadband capabilities of your mobile devices instead of a shared Wi-Fi network, enforcing the use of +3G cellular networks and avoiding GPRS/EDGE.
If you are a vendor, can you improve your default Wi-Fi equipment configuration? If you are a service provider, can you provide more secure configurations for home end users, small and medium businesses, and enterprises Wi-Fi equipment? If you are a corporate administrator or security pro, can you improve the security of both your employee and guest Wi-Fi networks, plus the configuration of the corporate Wi-Fi clients? If you are offering any kind of temporary or permanent Wi-Fi access (such as Wi-Fi hotspots) in venues, conferences, hotels, airports, cafés, restaurants, libraries, etc, can you improve the security of these networks? As a user, can you minimize the risk you take when connecting to Wi-Fi networks, avoid insecure environments, and spread the word and create awareness on other users, colleagues, friends, family members, neighbors, management, etc?
It is year 2011, we have the technologies for secure Wi-Fi deployments available, but we are clearly not making use of them in all common usage scenarios. Time to improve (and comment using the section below)!
Please choose a specific diary above to comment