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):
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:
Secureattribute in the Set-Cookie2 header.
logoutfeature 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
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.
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.
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.
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