Security Update 2011-005 Fixes DigiNotar SSL Vulnerability
Apple has finally issued Security Update 2011-005 to address the recent issues around compromised Dutch certificate authority DigiNotar. It was discovered that at least 531 fraudulent SSL certificates were issued by DigiNotar, leading to their root certificate being revoked in all major operating systems and browsers over the past two weeks. A man-in-the-middle attacker in possession of one of these certs (eg. Google, Skype), would be able to intercept SSL-encrypted traffic to those sites. It is believed that the use of these fraudulent certs may have been limited to the Iranian government.
This patch removes the DigiNotar CA from the trusted root certificates in the Mac OS X keychain (which is also used by Safari) for Lion and Snow Leopard. Unfortunately no patch has been issued for Leopard (10.5) users, leaving them at a heightened risk from these bad certificates. It is recommended that Leopard users delete the DigiNotar CA certificate from the Keychain using the following steps:
- Open Keychain Access (/Applications/Utilities/Keychain Access)
- Click on the System Roots keychain in the top-left hand panel
- Click on Certificates in the bottom-left hand panel
- Type DigiNotar into the search field in the top right.
- Right-click on the DigiNotar Root CA, and select Delete.
# sudo /usr/bin/security delete-certificate -Z C060ED44CBD881BD0EF86C0BA287DDCF8167478C /System/Library/Keychains/SystemRootCertificates.keychain
Firefox users should update to the latest version of Firefox. Here is the full Apple description for this update:
Security Update 2011-005
- Certificate Trust Policy Available for: Mac OS X v10.6.8, Mac OS X Server v10.6.8, OS X Lion v10.7.1, Lion Server v10.7.1Impact: An attacker with a privileged network position may intercept user credentials or other sensitive information
Description: Fraudulent certificates were issued by multiple certificate authorities operated by DigiNotar. This issue is addressed by removing DigiNotar from the list of trusted root certificates, from the list of Extended Validation (EV) certificate authorities, and by configuring default system trust settings so that DigiNotar’s certificates, including those issued by other authorities, are not trusted.
Browser and Smartphone Exploits Fly at Pwn2Own [Recap]
With Google offering $20,000 for a Chrome sandbox exploit, Apple releasing fresh security updates, and the organisers allowing researchers to target mobile phone basebands, it was sure make for an interesting Pwn2Own contest at CanSecWest this year.
For the fifth year running, Pwn2Own invited security researchers to discover vulnerabilities and develop exploits for the most popular browsers on Mac OS X and Windows (for some reason Linux is left out this year). Traditionally IE, Firefox and Safari have gotten exploited, with Chrome being the last browser standing at last year’s competition. Google upped the ante by making it significantly more attractive to target their browser this year.
In short: Safari, Internet Explorer, iPhone and Blackberry were all successfully compromised. Chrome and Firefox survive. Hit the jump for the full details! Read more
Clever Full-Site Tracking with XSS-Track
Cross-site Scripting (or XSS) is a common web application vulnerability with varying levels of severity. Generally the capabilities of a XSS are limited to the locations of vulnerable inputs and outputs, and crafting complex XSS payloads can be a time-consuming process.
XSS-Track (cached) helps simplify cross-site scripting by allowing the attacker to silently track the user across the entire site, using a single embedded XSS. It does this by cleverly creating a full-window invisible iFrame, and maintaining control of that window as the user browses the site. This also allows the attacker to look for valuable pieces of information, such as passwords or credit card numbers.
Combining XSS-Track with the older XSS-Shell script, which turns the browser into a zombie of sorts, could give an attacker a significant amount of power over infected sites and their users.
Firefox users may want to consider using the NoScript extension to protect themselves from unknowingly running malicious scripts. Despite having some limited XSS protection, and a JavaScript Blacklist extension, Safari unfortunately does not afford nearly the same protection as the whitelist-style Firefox+NoScript combination. If someone releases a NoScript-style JS Whitelist for Safari then it’ll be a big step forward.
Firesheep Detection and Defence with FireShepherd [and BlackSheep]
When Firesheep intercepts a valid session cookie for the sites it supports, it automatically makes its own request to that site using that session. Just as the Firesheep user can intercept network traffic over wifi, so can the normal users, so this behaviour means that Firesheep itself is detectable.
By transmitting a request to Facebook, Twitter or Google with a fake session ID, and monitoring the network using Wireshark, it is possible to look for follow-up connections from another host, using your fake session ID. By performing this ‘reverse attack’ on loop, it’s possible to flood the attacker’s Firesheep window with tons of invalid sessions. Note that this doesn’t protect you entirely, and any valid login to these sites will still be intercepted by Firesheep. But it’s possible to detect whether a Firesheep user is on the network.
Someone has released FireShepherd (currently Windows only), a tool that automates the flooding of invalid sessions, supposedly temporarily killing Firesheep running on the local network. Note that FireShepherd doesn’t detect the presence of Firesheep on the network.
[Updated] BlackSheep, a Firefox plugin, has been released which alerts the user if Firesheep is in use on the network. It does this using the method described above.
Intercepting Unencrypted Sessions with Firesheep
Firesheep, a new Firefox extension that allows you to intercept unencrypted sessions being transmitted over the network, has been released by Eric Butler. Taking advantage of websites that don’t use SSL by default, such as Facebook and Twitter, Firesheep uses network-sniffing to intercept the cookies used to transport session IDs (also known as sidejacking). Note this attack will work over Wifi by default, but will require extra work on a switched wired network.
Once Firesheep has intercepted a user’s cookie over the network, it allows you to be logged in as that user. The concept of session-stealing is as old as the internet, but to have a Firefox extension that does it in such a user-friendly manner is great. It’s also a lot more dangerous as it makes this attack so much easier for any unskilled attacker to carry out.
Protecting Yourself
The are a couple ways of protecting yourself from sidejacking attacks. The first and foremost is to ensure that you use SSL when visiting popular or particularly sensitive web services, including Gmail, Hotmail, Facebook, Twitter, or any other site that’s of importance to you (online banking?). The best way of doing this is to make sure your bookmarks (or the URL you type in) starts with “https://”, and that no SSL certificate errors appear. Another Firefox plugin, HTTPS Everywhere, from the privacy advocates over at the Electronic Frontier Foundation (EFF), enforces SSL on predefined sites. You can also protect your searches by using Google over SSL (encrypted.google.com).
Another way of protecting yourself is to channel your browser traffic through a VPN or SSH Tunnel. Your data is then sent through an encrypted link to a remote host (preferably one you control), before being sent to the destination.
Installing Firecat
Firebug runs in Firefox on Mac OS X and Windows, however Windows users will need to install WinPcap first. After downloading the extension file (xpi), simply open it by going to File -> Open File (you will need to restart Firefox). To clarify some confusion, once you’ve installed the extension, you need to go to View -> Sidebar -> Firesheep to enable it, and click Start Capturing.
Give it a try for yourself.
[Update] Detecting and protecting against Firesheep with FireShepherd.
Persistent Tracking using Supercookies and Evercookies
Normal websites use cookies to keep track of their visitors, either to remember that they are logged in, track statistics, or a number of other purposes. Sites can usually only track users while they are browsing that actual site (apart from Google who tracks you more or less wherever you go), however the past few years have revealed more and more ways web users can be tracked.
The concept of supercookies and ubercookies is not entirely new, but has been refined recently to turn them into digital cockroaches – very hard to permanently get rid of. Supercookies are basically an amalgamation of different software features that can be used to create a uniquely identifying token, usually one that is hard or too convoluted to delete. Now that HTML5 is becoming more widespread, there are even more options than before.
Modern supercookies comprise a number (or all) of the following:
- Standard HTTP Cookies
- Local Shared Objects (Flash Cookies)
- Silverlight Isolated Storage
- Storing cookies in RGB values of auto-generated, force-cached PNGs using HTML5 Canvas tag to read pixels (cookies) back out
- Storing cookies in Web History
- Storing cookies in HTTP ETags
- Storing cookies in Web cache
- window.name caching
- Internet Explorer userData storage
- HTML5 Session Storage
- HTML5 Local Storage
- HTML5 Global Storage
- HTML5 Database Storage via SQLite
Samy Kamkar recently released Evercookie, a JavaScript API for creating extremely persistent browser cookies. The list above is what is what Evercookie uses to create them. If websites were to start using these techniques, they would be able to uniquely identify you (as a user, not a person) each time you visited, even if you deleted your cookies, cleared your cache, and removed your history (or used a private browsing feature). Due to the use of shared objects, such as Flash, some cookies are persistent even across different browsers!
Ultimately, I wouldn’t panic and stop surfing the web just yet, but this goes to show how the evolution of the browser (and countless plugins that now go with it) is having an effect on privacy and security (which can’t quite keep up the pace set by innovation). Dominic White describes how to delete the Evercookie when using Safari on OSX. Others have written about how to do the same on Firefox and Chrome. One reddit user has created a pseudo lockdown-script which improves the security and privacy of Firefox by making some configuration changes (eg. disabling prefetching, geolocation, caching, etc).
This post by Christopher Soghoian provides a good argument for why privacy (and security, I would add) should be adopted in web browsers by default, instead of letting users fend for themselves. Some browsers are making an effort by adding features such as private browsing, cross-site scripting protection, and Google SafeSearch (although this impacts privacy by sending Google every URL you browse to), however all too often browser plugins and add-ons are given too many privileges.
Browser security and user awareness are becoming more important than ever as traditional programs are phased out and replaced by web applications. Unfortunately both of these are still lagging a bit behind.
- Standard HTTP Cookies - Local Shared Objects (Flash Cookies) - Silverlight Isolated Storage - Storing cookies in RGB values of auto-generated, force-cached PNGs using HTML5 Canvas tag to read pixels (cookies) back out - Storing cookies in Web History - Storing cookies in HTTP ETags - Storing cookies in Web cache - window.name caching - Internet Explorer userData storage - HTML5 Session Storage - HTML5 Local Storage - HTML5 Global Storage - HTML5 Database Storage via SQLite
Loading ...
