In the information security universe security engineers, managers, curmudgeons and the like daily flock to the Internet to find their news, perform their research, and read about the topic of the day. More and more these same security minded individuals are flocking to social media sites to learn about the day’s daily infosec gossip – myself included. However in this mad rush for information I have to wonder, are we following or concerned about the same security principles that we all preach about in our professional lives?
One of the more popular sites we all visit is still Twitter – the Microblogging service. If we are going to consider this site a part of our research cadre, should we not require the same security standards of it that we do for all of our other applications?
This article is not meant to fully discuss all the social media security issues on the horizon, or even to evaluate Twitter as an appropriate tool. Instead it’s meant to address simply one topic – How does Twitter handle user authentication to their site?
The big issues that have been focused on the last couple weeks have been Twitter.com’s use of SSL (or lack thereof) and TweetDeck’s use of Base64 encoding for passing user credentials. But for today let’s just focus on the mothership – Twiter.com.
The obvious part of this discussion is that Twitter.com does not require SSL when users authenticate to their site. They are certainly not the first site to have this issue, and many of us were willing for years to authenticate to sites like eBay or others without using SSL. Not that it was right, but it was a reality. So when we authenticate to Twitter our credentials are being passed outside of an encrypted tunnel. But are they being sent in clear text as many have suggested?
The first thing we need to do in order to answer this question is capture some traffic between the browser and the Twitter website. Laura Chappell has already written a great overview of this here:
Twitter Twace Analysis Report (PDF; 2 pgs)
TweetDeck Twace Analysis Report (PDF; 13 pgs)
Twitter Trace Files (ZIP 1MB)
Update: Unfortunately the last time we looked, Lara’s site was down. Let’s cross our fingers that they come back online soon and that the above links reactivate!
The next step is to look into specifically the portion of the web transaction dealing with authentication. To make things simple we can use WebScarab from OWASP to intercept the information. What it turns out is that during authentication we see cookies set and credentials sent to the website. Here is a decoded sample:
lang=en, auth_token=, _twitter_sess=BAh7CzoTcGFzc3dvcmRfdG9rZW4iLTUwOGFmZjNhNzg1NTczMT
ZhOGEzZjY2YWZlMjgxOGQxZTA0ZmU5MmE6CXVzZXJpBD09+QM6DGNzcmZfaWQiJTgxODVl
NjZmYzBjZTc3NDhmMjFhNzBmYWUyZGI4OTk2Og5yZXR1cm5fdG8wIgpmbGFz
aElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAGOgpA
dXNlZHsAOgdpZCIlZmM0N2RkMTJmYTViNGQ5NTk0MDY5MWMxNmMxMjUzNWE=
–a62476dde49ef8df0fbda6be783d00618633253f
If we look at this sample what we notice right away is at the end of the capture is a 40 character series of letters and numbers which looks a lot like a hash of some sort. Knowing that the characters following the double dashes are 40 characters long, and that SHA-1 generates 40 character hash strings, and that SHA-1 is one of the most popular hashing protocols being used right now, let’s assume they’re using a SHA-1 hash for this algorithm.
Guessing that they’re using SHA-1, and since we know the password that was used to create the original hash, we can next determine if the SHA-1 in use is using a salt value with it. It turns out if we place the original password for the account in a hash generator, it does not equal the hash we have here. That would seem to indicate that they’re using a salted (or HMAC) with the original password to help protect the data being hashed (that’s a good thing).
So while the threat of someone cracking the hash has been minimized, this still doesn’t remove the possibility of a replay attack against Twitter’s authentication scheme. Although I haven’t tried this, it appears that there is a possibility that an unscrupulous individual could capture data such as this, modify an HTTP request with this hash in the header, and attempt to authenticate using someone else’s account. Why does this work? Because the site is not using SSL to protect the hash.
So what information do we have that makes this possible:
1. The Twitter username is sent in clear text in the HTTP body. But really, even if it wasn’t we all advertise our handles anyways (I’m @jamestarala and @isaudit, remember).
2. The Twitter authentication credentials are not being sent in an SSL tunnel.
3. The Twitter hash is clearly visible in the HTTP requests. Although the password is hashed, the hash is sent in the clear.
So why do I bring all this up? Well, for a few reasons, let’s summarize:
1. We should all be critically asking questions like this for the applications we’re using. Especially security practitioners.
2. Auditors should consider using processes like this more to evaluate the application systems they’re evaluating. Authentication is hugely important, let’s not let application developers, system analysts, or vendors off the hook.
3. We want to encourage vendors and service providers (like Twitter) to be aware of the risk levels they’re accepting on our behalf.
The bottom line is that these are risk decisions that we’re making on a daily basis. Let’s make sure we have all the information before we make these decisions. Will I stop using Twitter, likely not, but I will certainly be aware of my surroundings when I choose to do so. Life is risky, at least now I feel I can make an intelligent choice about the risk I’m taking in this one case.
