Active Sidejacking

The topic of Active Sidejacking has come up again and apparently the vulnerability has not been closed. Recently Edson sent around links to relevant articles (with a few added items by jimc):

• Robert Graham's Hamster, presented at BlackHat 2007. It passively monitors an open network, records cookies not sent over HTTPS, hijacks the session, and uses the cookie to impersonate the client/victim. This is called sidejacking. (Sorry, no URL.)

• Mike Perry's announcement of CookieMonster (2008-08-14), a program (in Python) which actively stimulates clients/victims to send (in plain text) cookies that are being used in a HTTPS session. If the cookie identifies the client to the server, the hacker can impersonate him.

• Eric Bollens' article on HTTPS security (2008-09-16). UCLA login required. Summary:

  • The web designer needs to use HTTPS to acquire the client's credential (loginID and password). To identify the user he deposits a cookie with the client. But he also needs to only receive the cookie over HTTPS, to keep it away from sidejackers.

  • As of 2008, vulnerable sites (sending the ID cookie on HTTP) included Gmail, Hotmail and the majority of Web 2.0 applications.

  • There is an option in the cookie header restricting it to be sent on secure connections only. This option is rarely used when it should be (see RFC 2965 below).

  • What the web designer should include in the application:

    • Use the Secure attribute in the Set-Cookie2 header.
    • Provide content over HTTPS when the cookie is to be received.
    • Avoid HTTP links (e.g. to images) from a page sent via HTTPS. (jimc's addition)
    • Restrict the session to the origin IP address.
    • Make cookies expire promptly.
    • Provide a logout feature that actively tosses the cookie.

  • What the client should do:

    • Use WPA on 802.11 (wireless networks), or some kind of encryption on 802.3 (wired Ethernet).

    • Lacking level 2 encryption, use a VPN, particularly from off campus.

    • To test if a particular app or site is secure, log in, then delete all cookies marked Secure. If the remaining insecure cookies are sufficient to get you the protected content, then a sidejacker could get it as well.

    • Well-known sites that were vulnerable in 2008 when the article was written: Bank of America, Discover Card, Amazon, eBay, and the Apple Store .

• RFC 2965, HTTP State Management Mechanism (2000-10-xx) by D. Kristol and L. Montulli. (Supercedes RFC 2109.) Per section 3.2.2, the server is to send a response header of Set-Cookie2: Itsname=VALUE; attr[=value]; . . . where one of the attributes may be Secure (no value). RFC 2109 uses a keyword of SetCookie but otherwise is similar and includes the Secure attribute. When sending back the cookie, the user agent SHOULD use no less than the same level of security as was used when it received the cookie from the server. The security mechanism is not mandated by this RFC.

• Firesheep by Eric Butler (Codebutler) (2010-10-10). See also the source code. It's a Firefox extension. Install it (on MacOS-X or Windows, Linux coming soon). It opens a sidebar. Assuming you're on an insecure wireless network with sheep ready to be shorn, click the Start Capturing button. It will capture session cookies and show a list. Double click on a name and you will be logged in as that person, using the stolen cookie.

• Presentation about Firesheep by Eric Butler and Ian Gallagher (2010-10-xx) at Toorcon 12.

Jimc's conclusions:

First, I'm going to do the test that Eric Bollens suggested, to see if key websites (e.g. Fidelity Investments) are still vulnerable to this attack.

I have got to get a decent VPN working from Android to vpn.ucla.edu and/or my home server. So far the solutions I've tried have been unsatisfactory.

Most of my system administration activities are done over ssh, which is independent of the whole morass of web insecurity. But there are important non-sysadmin activites that do depend on the web.

Checking our web apps to see if they use insecure cookies.

• My OOBA does not use browser cookies; it puts the authentication cookie (encrypted and with HMAC, to resist tampering) in a hidden field in the action form, which is sent out and returned via HTTPS. The field is hidden because the cookie is ugly, not because anything bad happens if the hacker sees it.
• Dima's event editor needs to be checked.
• CUPS (print server) for actions that need authentication expects Plain auth over HTTPS on every web request. This should be verified carefully.
• The MCG internal web pages are protected by Plain auth over HTTP. The pages are considered to be not secret enough to require effective security. Nonetheless this should be improved, at least by upgrading to HTTPS.
• UCLA's Shibboleth auth service on shb.ais.ucla.edu (cookie name SHB2123Cookie) definitely lacks the Secure attribute on the cookie, and similarly for the two session cookies from this site. (A directive recently came out (2010-11-02) that all UCLA web apps, presumably including this one, must use SSL (HTTPS) when receiving the cookie, so the Shibboleth hole likely will be plugged soon.)

There's a lot of jabber about if we use SSL for every page it will overload our servers. A number of comment posters referred to Google's blog post about activating SSL for all Gmail service: it added about 1% to their CPU load, and 10Kbytes per connection, which is insignificant for them. However there is a problem on Android (and presumably other Java-based phone OS's): it looks like they're doing SSL in Java! What a crock! Of course this takes a lot of CPU time, slowing down data transfer, and eats battery.