Gmail 'hacking' - some perspective

["Dave Farber" <dave () farber net>]

From: Roelof Temmingh [mailto:roelof () paterva com] 
Sent: Friday, August 10, 2007 12:46 AM
To: dave () farber net
Subject: Gmail 'hacking' - some perspective

 

Dave - for IP if you wish:

At BlackHat in Las Vegas, Robert Graham had a demo of 'hacking' Gmail  - the
media lapped it up and it even made Slashdot [
<http://it.slashdot.org/article.pl?sid=07/08/03/1241217>
http://it.slashdot.org/article.pl?sid=07/08/03/1241217], CNN etc. Surely it
filtered to people on the IP list as well. Having worked on the same issue I
feel compelled to put it all in perspective.

On a positive side the following. The 'bug' is not new - I reported the same
issue to Google around June 2005 and was told that another researcher (which
I won't mention, but know personally) have reported the issue to them a
month earlier. The issue has nothing to do with Web2.0 as was mentioned in
the BlackHat talk - it is plain simple session hijacking that has been
around since the introduction of cookies as a state-keeping mechanism. As
such - this is not a Gmail problem specifically - in fact ANY web
application that transmits session information in the clear has exactly the
same problem. Furthermore the session time-out (or the reported lack
thereof) is as follows - if you checked the 'remember me' checkbox the
session lives for about 2 weeks, regardless of logout. If not, the session
is destroyed about 10 minutes after logout. This is different than was
discussed during the talk, and has absolutely nothing to do with the PREF-ID
cookie that expires in 2038. In a 'properly deployed system' the session
time-out is actually quite irrelevant as we'll see later on. 

On the negative side the following. Robert showed how the cookies can be
grabbed using a sniffer. In real world a much more effective way of doing it
is using a transparent proxy at ISP or large companies (which is in many
cases already deployed) and getting all data that flows through it. In this
scenario the ISP (or corporate network admin) will be able to extract the
cookies from the proxy and perform any action on it - for example searching
the user's email (all of it, including older messages) for keywords, or
collecting the contact list. With this in mind the time-out of the session
does not play a part, as this hijack happens in real time and requires no
human intervention. The difference between just sniffing the mail traffic
and sniffing the session is that getting access to the session gives access
to the application, with all of the bells & whistles (searching email,
contacts, search history etc), while sniffing the traffic gives you access
to...well...just the email itself. 

The solution to the problem is simply enforcing SSL for entire session -
thereby encrypting the session ID as well, rendering sniffing in any form
(either with a proxy or dedicated sniffer) useless. Google indicated in
their response to me that this will burden their servers with considerable
load, and that you can force SSL by logging into https:/mail.google.com.
While this is a bit of a work-around you are still redirected to the non-SSL
page when clicking the mail icon on Gtalk client etc., and it's clear that
many people just won't go through the hassle of going the SSL route. Blaming
Google for this entire issue is a bit heavy, as most web mail services (and
indeed many other public web applications) are prone to the same problem.
What is interesting to me is the response this talk generated from the press
and the public - perhaps this is a wake up call to understand just how
little technical knowledge of web applications goes around with the average
security conference attendee. 

Regards,
Roelof Temmingh.

------------------------
Roelof Temmingh
+27 83 448 6996
GMT+2 

-------------------------------------------
Archives: http://v2.listbox.com/member/archive/247/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com