From: Roelof Temmingh
[mailto:roelof@paterva.com]
Sent: Friday, August 10, 2007 5:34 AM
To: dave@farber.net
Subject: Re: [IP] Gmail 'hacking' - some perspective
Dave,
Sorry....we're in 2007 and I reported it more than a year ago - so that makes
it reported in 2006 and not 2005 as I previously stated. :-\ Sorry!
RT
On 8/9/07, Dave Farber <dave@farber.net> wrote:
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], 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
--
------------------------
Roelof Temmingh
+27 83 448 6996
GMT+2