Message-ID: <7E3B942D6F9AE64EA28CE80B7283C1EC35D8925261@exch01.isecpartners.com>
Date: Wed, 28 Apr 2010 14:05:18 -0700
From: Chris Palmer <chris@...cpartners.com>
To: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: 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@...d{\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@...cpartners.com

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

Powered by blists - more mailing lists