The Web has still not switched to SSL-only

In November 2010, the release of Firesheep highlighted the dangerous consequences of not using secure HTTPS transactions. Following this, I provided some of the reasons why the web has not switched to SSL-only yet. There have been some improvements since, notably Google+, which works only over HTTPS, and from Twitter.

But those are very small steps. A lot more needs to be done.

SSL by default

One trend involves offering HTTPS as a new option. Facebook and Twitter took this path. Unfortunately, the option is usually disabled by default. Half of the users do not understand what this option does and the other half is not aware of the new feature well hidden in their profile!

HTTPS option under Security settings in Facebook

HTTPS should be enabled by default, perhaps with the option of disabling it for the very few users having problems with it.

Facebook

While Facebook has fixed the 2 bugs I mentioned in the earlier post - SSL: the sites which don't want to protect their users, it is practically impossible to use HTTPS on Facebook. The problem arises from the fact that the use of SSL breaks most of the applications I've tried on the platform. I used to get error messages, now users are warned that they need to switch to HTTP. They have to logout, and login again, to get HTTPS back.

Most Facebook Apps cannot be used with HTTPS

HTTPS cannot be used for popular applications like CityVille from Zynga. I doubt many users will take the hassle to logout/login constantly to switch back to SSL.


Insecure cookies

I've seen HTTPS implemented incorrectly on many sites, including Facebook. The main purpose of HTTPS is to hide the user cookies, so that tools like Firesheep cannot be used to hijack a user session. That means the HTTPS cookie should never be sent over HTTP. There are two ways to achieve this:

1. Use the secure keyword when sending a cookie with Set-Cookie. This mean the cookie can be sent by the client only over HTTPS
2. Use a different sub-domain that support HTTPS only (like encrypted.google.com) and restrict the cookie to this sub-domain

Otherwise, when the user connects to the website over HTTP the user session is vulnerable. Unfortunately, Facebook uses the exact same cookie over HTTP and HTTPS, without securing it. If you type "facebook.com" in your address bar, you will send your cookie in clear text, even if you are then redirected to https://www.facebook.com/ and simply visiting a site that uses a Facebook widget, a Like button for example, leaks your user session in plain-text, even if you check the "Secure (HTTPS)" option in your profile. Nowadays, it is a challenge to not visit a website that does not contain any element from Facebook...

My Facebook cookie leaked on a random web site (Like widget)

In the end, it does not really matter whether you use HTTPS or not for Facebook. Your Facebook cookie will be leaked when visiting other websites anyway.

Google

Google did the right thing with Google+. The website works with HTTPS only and there is no way to use HTTP. User cookies cannot be sent in clear text.

You can also use their search engine over HTTPS, unlike Bing, which does not offer a secure alternative.

But Google still has some work to do on the rest of their current web applications. For example, the Google Personal Home Page cannot be accessed over HTTPS (users get redirected to HTTP) and Adsense, the major adverting network, does not support HTTPS, which leads to a Mixed HTTP/HTTPS warning for sites would would like to use SSL.

Mobile

The situation is even worse in the mobile space. Most of the applications used on smartphones and tablets need to contact a web server to function: to retrieve advertising (Admob/Adsense Mobile), to get data from a web service, etc. But there is no way for the user to know whether sensitive information is sent over HTTP or HTTPS. There is no UI element equivalent to the lock shown in browsers and no visibility into the URLs. Researchers have illustrated that mobile developers cannot be trusted to secure communications, as all too often, they send user credentials in plain text.

While some websites have taken a few steps to protect the users, there is still a great deal to do. HTTPS should be enabled by default on all new web sites requiring user authentication. HTTPS should not just be required for login, it should also be required for all requests sent with a cookie.

-- Julien

Twitter ReTweet Spam (XSS)

This morning before I even logged into my system, I was receiving inquiries about the Twitter Spam going around. The source looks like:


And appears in Twitter as:

For those unfamiliar with t.co, it is Twitter's link service, which provides URL shortening as well as checks to ensure that the link doesn't go to a known malicious site (see About Twitter's Link Service for more info). You can see from the source of the tweet, that it is leveraging a cross-site scripting (XSS) vulnerability so that the scripting code following the "@" character is executed within the victim's browser, and just by mousing over the tweet you are retweeting it. The tweet name / retweet value varies. (a.no has been seen in addition to the t.co domain).

Doing a Twitter search for "Onmouseover" provides a laundry list of URLs and "victims" of this spam. The results of the spam campaign are tweet spam (annoyance) and a likely strain on Twitter services from the increase in retweets. After doing a Twitter search, after a few minutes, the search results showed over 30K more tweets since my initial search - this illustrates how rapidly spreading the XSS retweet spam is being spread.

Digging a bit deeper into this reveals that it was an Australian teenager going by the handle zzap that discovered the XSS vulnerability whereby arbitrary script following the "@" character is executed (ref. NetCraft). Cross-site request forgery and cookie stealing attacks have been demonstrated leveraging the XSS vulnerability as well. Currently there are a number of Twitter worms leveraging this vulnerability (ref. F-Secure).

Some security precautions for users to consider:

• Avoid accessing your Twitter account from a browser, consider using a Twitter client
• If accessing your account via browser turn off JavaScript or use NoScript

Update from Twitter:

Unlike popular belief, short links on twitter aren't malicious!

Twitter recently announced that it has implemented a new security system to scan all URLs posted in tweets to protect users from malicious sites. This follows a similar announcement from bit.ly in November 2009

Twitter, and the URL shorteners it has helped to popularize, have long been blamed for leading users to malicious sites. I posted on this topic 3 weeks ago and argued that this may not be true. I wanted to additionally do a thorough investigation of the Twitter links both before the security scan and after.

I have retrieved more than 1 million URLs (1,314,615 to be exact) from the public timeline over a couple of weeks before they put any protections in place. I then ran the links through the Zscaler infrastructure to find out which links lead to malicious sites.

The state of the Twitter links

 Prevalence of hostnames on Twitter

As expected, URL shorteners are very popular on Twitter, and bit.ly represents 40% of all links. TinyUrl, one of the original URL shorteners, comes in 3^rd with only 5% of all URLs.

How many malicious links?

I looked for malicious sites - phishing sites, malware, etc. I did not look for spam, only for pages that present a security risk to users.

To my surprise, a very low number of links led to malicious pages - only 773, links, 0.06% of all links scanned, redirected to malicious content.

  Types of malicious sites

Here is the distribution of malicious links by host name:

Bit.ly represents 40% of all links, and roughly the same proportion of malicious links. Same case for TinyUrl:  5% of all URLs and 6 % of all malicious sites. It does not look like bit.ly’s phishing and malware protection is making it any safer than other URL shorteners.  Twitpic.com is used to share images, so it is unlikely to be used for malicious content. Mediafire is known for hosting malware and other viruses, even if it is not blacklisted by Google Safe Browsing.

Note that these links may have been scanned up to 4 weeks after they were collected. Bad sites may already have been taken down, or cleaned up.

Can Twitter and bit.ly really protect their users?

The key to protecting end users, is real-time scanning of both the URL and the content. Twitter and bit.ly can only scan the links periodically.  Malicious websites try to hide their malicious content to non-users by checking the user agent or geography and by requiring a real browser which fully understands Javascript, Flash, etc.  An attacker can present harmless content to the Twitter or bit.ly scanners, but harmful content to a real user.

But remember that only 0.06% of all the URLs tests represented a security risk. It is actually much safer to follow link s from Twitter that from some search results on Google!

-- Julien

Spoofing caller-ID: the new hacking inroad

It is amazing to see the number of bridged services that rely upon the source telephone address of an incoming call (supplied via caller-ID) or SMS message as a form of authentication. Maybe this made sense in the 90's when spoofing caller-ID was hard, and the most it would offer is accessing someone's voicemail without a PIN. But nowadays there are countless online services that allow SMS and caller-ID source spoofing (Spoofcard, Phonytext, etc). Pair this with the growing number of services offering telephony or SMS integration, and you start to have a problem.

Let's review some recent examples of this situation in action. Twitter was found to allow spoofed SMS messages to perform Twitter account actions/changes. The core problem was first identified nearly two years ago, but a recent variant allowed attackers to circumvent previously added safeguards. Twitter offers the option of using a PIN, but using a PIN impacts the ease of use and the overall user experience--so users do not jump at the opportunity to opt-in to this additional hurdle.

Google Voice has also had a fair amount of problems exposed, although some of the problems use different vulnerability vectors than the simple spoofed caller-ID/SMS. Spoofing caller-ID of a mobile phone configured for a Google Voice account allows an attacker to get into the Google Voice IVR system for that account and modify certain settings. Google has since closed these holes.

While we are talking about hacking telephone/SMS-related services, it is probably worth mentioning an XSS bug found on Skype's website. The attacker can try the usual bag of tricks to get a user to click on an XSS-ified link and gain access to the Skype session cookie. Fortunately, it seems Skype session cookies expire after thirty minutes...making the window of exploit opportunity it bit more difficult for an attacker to hit.

Overall, it is important for companies looking to add SMS/telephony bridged capabilities to their existing services to understand that caller-ID and SMS source information is not reliable for authentication purposes. Period. It is no different than asking a user for their username without the additional authentication aspect of a password; it creates an "on your honor" system which is ripe for abuse.

Until next time,
- Jeff