[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Full-disclosure] Impossible to Maintain Secure Session With Twitter.com Web Interface

iSEC Partners Security Advisory - 2010-001-twitter https://www.isecpartners.com
--------------------------------------------

Twitter - Insecure session management

Vendor: Twitter
Vendor URL: http://www.twitter.com
Severity: High (allows unauthorized hijacking of accounts)
Author: Chris Palmer <chris[at]isecpartners[dot]com>

Vendor notified: 2009-12-18
Public release: 2010-04-27
Advisory URL: https://www.isecpartners.com/advisories/2010-001-twitter.txt

Summary
-------

It is impossible to maintain a secure session with Twitter, for multiple 
reasons. Additionally, once a session has been hijacked, it is possible for the 
attacker to maintain control over the account (not just the session) 
indefinitely, unless the user changes their password. This is because the 
session cookie has the same lifetime as the password.

The lack of HTTPS means that users are highly likely to leak their long-lived 
cookie, their passwords, and their direct messages to passive and active 
network attackers.

In light of the 17 Dec DNS hijacking attack, which may have caused many users 
to inadvertently send their _twitter_sess cookies to the attacker's site, this 
problem is especially severe -- the attackers may currently have long-lived 
authenticators for a large number of Twitter users. Therefore, Twitter users 
should either change their passwords, or Twitter should change the session 
management mechanism so that cookies stolen yesterday no longer work today.

Please note also that I discovered these issues purely through non-invasive 
means; specifically, I only observed my own HTTP traffic using an HTTP proxy 
(WebScarab). I never sent any malicious requests to Twitter or attempted to 
compromise Twitter in any way.

Specific vulnerabilities and suggestions for remediation follow.

Cookie Lifetime Details
-----------------------

The _twitter_sess cookie is an encoded form of a Ruby object serialized with 
the Marshal library. It contains a field, password_token, that is a static 
function (presumably of the user's password). That is, it is the same across 
logins. This example shows how to decode my cookie in
Python:

      >>> from base64 import b64decode
      >>> from urllib import unquote
      >>> a 
="_twitter_sess=BAh7DDoRdHJhbnNfcHJvbXB0MDoMY3NyZl9pZCIlOTlmYzY3MzJkMWM5N2M0%250ANTQxMjMxNTkzMDJlNGNjNjY6DnJldHVybl90bzA6CXVzZXJpBIP21AE6E3Bh%250Ac3N3b3JkX3Rva2VuIi0zYjEwMjcxOWU3NWU3MGI3Y2IwYzQzMGJmMjcwZGUz%250AODI1ZmQ2ZDM3IgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6%250ARmxhc2hIYXNoewAGOgpAdXNlZHsAOgdpZCIlNTdlMWYwYzMwNjIzNGJhNTcy%250ANGNhZGY3ZmY0ZjZmMjA%253D--79eee6a5f88b367933755b64ba3bd198f5127b93"
      >>> b = unquote(unquote(a))
      >>> b
'_twitter_sess=BAh7DDoRdHJhbnNfcHJvbXB0MDoMY3NyZl9pZCIlOTlmYzY3MzJkMWM5N2M0\nNTQxMjMxNTkzMDJlNGNjNjY6DnJldHVybl90bzA6CXVzZXJpBIP21AE6E3Bh\nc3N3b3JkX3Rva2VuIi0zYjEwMjcxOWU3NWU3MGI3Y2IwYzQzMGJmMjcwZGUz\nODI1ZmQ2ZDM3IgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6\nRmxhc2hIYXNoewAGOgpAdXNlZHsAOgdpZCIlNTdlMWYwYzMwNjIzNGJhNTcy\nNGNhZGY3ZmY0ZjZmMjA=--79eee6a5f88b367933755b64ba3bd198f5127b93'
      >>> c = 
b64decode("BAh7DDoRdHJhbnNfcHJvbXB0MDoMY3NyZl9pZCIlOTlmYzY3MzJkMWM5N2M0\nNTQxMjMxNTkzMDJlNGNjNjY6DnJldHVybl90bzA6CXVzZXJpBIP21AE6E3Bh\nc3N3b3JkX3Rva2VuIi0zYjEwMjcxOWU3NWU3MGI3Y2IwYzQzMGJmMjcwZGUz\nODI1ZmQ2ZDM3IgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6\nRmxhc2hIYXNoewAGOgpAdXNlZHsAOgdpZCIlNTdlMWYwYzMwNjIzNGJhNTcy\nNGNhZGY3ZmY0ZjZmMjA=")
      >>> c
      
'\x04\x08{\x0c:\x11trans_prompt0:\x0ccsrf_id"%99fc6732d1c97c454123159302e4cc66:\x0ereturn_to0:\tuseri\x04\x83\xf6\xd4\x01:\x13password_token"-3b102719e75e70b7cb0c430bf270de3825fd6d37"\nflashIC:\'ActionController::Flash::FlashHash{\x00\x06:\n@used{\x00:\x07id"%57e1f0c306234ba5724cadf7ff4f6f20'

This cookie works even after the user logs out using the 
http://twitter.com/logout action, and even after the user logs back in again to 
start a new session. The only way to invalidate this cookie is to change the 
user's password, which results in a new, equally long-lived password_token 
value.

(The above cookie should no longer work.)


Cookie Details
--------------

The _twitter_sess cookie is not marked with the Secure flag, meaning that the 
browser will reveal the cookie over HTTP connections as well as over HTTPS 
connections. This makes it possible for passive network observers to copy the 
cookie on any request to http://twitter.com, and for active network attackers 
to copy the cookie on forced requests to http://twitter.com.

For example, on requests to http://www.google.com, the attacker can rewrite 
Google's response to be a 302 redirect to http://twitter.com.
The browser will follow that link, revealing the cookie, and the attacker can 
rewrite Twitter's response to be a redirect back to http://www.google.com. The 
user may notice no strange effect at all, but the attacker has copied their 
cookie.

Tools to conduct attacks like this and similar attack classes are freely 
available on the internet:

      http://www.thoughtcrime.org/software/sslstrip/
      http://www.ex-parrot.com/pete/upside-down-ternet.html

Attackers can also induce the plaintext transmission of the _twitter_sess 
cookie by including a reference in web pages they control to any URL pointing 
to any host in the twitter.com domain. For example, at a coffee shop that uses 
a "captive portal" to authenticate customers who want to use the wifi network, 
the attacker can include HTML like the following in the captive portal front 
page:

      <img src="http://whatever.twitter.com/a.jpg"; height="0" width="0" />

When the user's browser attempts to load this resource, it will include the 
user's _twitter_sess cookie in the request, revealing it to the network at 
large. The attacker can be an active network attacker, or the maintainer of the 
captive portal site.

Similarly, the help.twitter.com site is normally served over HTTP, and its 
HTTPS service uses an invalid SSL certificate. Thus, users wanting to read the 
help cannot avoid disclosing their cookie over the network.

Although reducing the scope of the _twitter_sess cookie's Domain attribute, 
which is currently set to .twitter.com (i.e. the browser will send it to any 
hostname under *.twitter.com or to twitter.com), would cause the 
"help.twitter.com" attack to fail, the attacker can still use 
http://twitter.com/a.jpg. Tightening the Domain attribute is most meaningful 
after the transport security problem has been solved (i.e.
using HTTPS and marking the cookie Secure).


HTTPS Details
-------------

Although it is possible to log into Twitter over HTTPS by explicitly navigating 
to https://twitter.com (note that the certificate used by www.twitter.com is 
not valid for that name), by default Twitter provides a log in form over HTTP. 
Thus, by default, most users will reveal their passwords and their session 
cookies in plaintext to passive attackers on the local network and on the 
internet.

However, even those users who explicitly navigate to https://twitter.com are 
redirected to http://twitter.com/ after authentication, thus revealing the 
user's _twitter_sess cookie to all passive observers on the local network and 
on the internet at large. People can again forcibly navigate to 
https://twitter.com in an attempt to narrow the time window of exposure, but it 
may be too late.


Fix Information:
----------------

These solutions each resolve part of the problem. I recommend using all of 
these means to completely resolve the vulnerabilities identified in this 
report. For more information about the problem of secure session management 
generally, see my prior work on secure session management:

      https://www.isecpartners.com/files/web-session-management.pdf

Michal Zalewski's Browser Security Handbook is a crucial resource:

      http://code.google.com/p/browsersec/

1. Canonicalize the main Twitter hostname to twitter.com. When people browse to 
resources in the www.twitter.com domain, reply with a 301 Moved Permanently to 
the equivalent twitter.com resource.

2. Use valid SSL certificates for www.twitter.com and for help.twitter.com.

3. Mark the _twitter_sess cookie Secure and HttpOnly. (HttpOnly protects the 
cookie against trivial XSS attacks, but is not a real solution to the problem. 
HttpOnly is thus optional, but Secure is necessary for
security.)

4. Make the Domain of the _twitter_sess cookie "twitter.com" (no leading "."), 
or leave it blank (equivalent). If you want to allow people to use either 
www.twitter.com or twitter.com, set the cookie twice, once in each domain.

5. Make the cookie short-lived instead of semi-permanent. In particular, the 
session identifier should be a large random number or some other non-static 
function.

6. For authenticated application functionality, use HTTPS exclusively.
Although arguably possible, it is extremely difficult to provide secure 
application functionality in the same domain as insecure functionality.


Vendor Communication:
---------------------
2009-12-17: Twitter's DNS hijacked by "Iranian Cyber Army"

http://techcrunch.com/2009/12/17/twitter-reportedly-hacked-by-iranian-cyber-army/

2009-12-18: Initial notification of Twitter

2010-01-25: Twitter requests 60 days to engineer a fix before advisory
            release. Twitter believes that the inability to log out problem
            is endemic to Rails apps using CookieStore, although iSEC has not
            found CookieStore applications to have this problem in all
            cases.

2010-02-02: Some details of a phishing attack against Twitter are revealed
            in the press. Twitter advises some users to change their
            passwords to protect their accounts. However, *all* Twitter
            users need to change their passwords to invalidate any of their
            authentication cookies which any attacker may have stolen. For
            example, when Twitter DNS was hijacked, the attackers received
            and could have stored many Twitter users' cookies.

http://thenextweb.com/socialmedia/2010/02/02/twitter-forcing-users-change-password-reported-threat-phishing-attacks/

2010-03-24: iSEC informed Twitter of advisory release. Twitter asks for a
            further extension.

2010-04-23: Twitter asserts that several security fixes are in the
            engineering pipeline, including some dealing with HTTPS.

2010-04-26: Twitter asserts that it is now possible to maintain an HTTPS
            session if the session begins with HTTPS; i.e. users can
            navigate to https://twitter.com to start an HTTPS session.
            However, https://twitter.com/ contains HTTP resources, including
            a JSON response from http://twitter.com. An active network
            attacker could potentially use this weakness to insert their
            own code into the page and maintain control over the user's
            session.

2010-04-27: This advisory.


About iSEC Partners:
--------------------
iSEC Partners is a full-service security consulting firm that provides 
penetration testing, secure systems development, security education and 
software design verification, with offices in San Francisco, Seattle, and New 
York.

https://www.isecpartners.com
info@xxxxxxxxxxxxxxxx

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/