Re: [WEB SECURITY] Advanced Web Attack Techniques using GMail

[Jeremiah Grossman <jeremiah@xxxxxxxxxxxxxxx>]

On Jan 28, 2006, at 6:49 AM, Amit Klein (AKsecurity) wrote:

> On 27 Jan 2006 at 14:18, Jeremiah Grossman wrote:
>
> > A few months ago, I discovered a vulnerability in GMail where it
> > became trivial to compromise someone's email contact list. I
> > demonstrated the issue to a friend at Google by emailing his GMail
> > account with simple link. Upon clicking the link and viewing the
> > page, no XSS required, your contacts were displayed on screen (see
> > screenshot). From there the email addresses could be easily stolen.
> > Imagine if a spammer stumbled across this!
>
> Nice one!
>
> Your trick involves "runtime" access to the confidential  
> information inside the JS
> resource, by modifying the Array object constructor (BTW - did you  
> try this with other
> objects, e.g. String? I think String would be more powerful). This  
> is indeed cool. But
> there's another, quite similar technique I came up with (after  
> reading your message), that
> grants access to the SOURCE CODE in some cases. Assuming the JS  
> resource contains
> information inside FUNCTIONS, and that the interesting functions'  
> names are known, then a
> simple funcname.valueOf() yields the function's source (including  
> comments...). This works
> in IE 6.0.
>
> In comparison to runtime techniques:
> - valueOf() works only for functions, not for "free" code.
> - valueOf() requires you to know the name of the function.
> - valueOf() grants access to comments, dead code, un-executed  
> branches.
>
> Of course, I don't know how the GMail JS resource looks, so I can't  
> tell if valueOf() would
> have been of help.

Wow, you extended that one quick! This same concept works on Mozilla/ 
Firefox browsers as well.

Where this technique also becomes very interesting is in the area of  
AJAX Desktops. I've been experimenting with Google Modules, Windows  
Live Gadgets, Netvibes, Protopage, etc. They are essentially running  
collections of javascript mini apps (widgets) within the same browser  
window.  The risk comes in when widgets start accessing and  
displaying "authenticated" data, such as Gmail, and Y! Mail. In this  
context, sibling widgets can read into other widgets and compromise  
data. Perhaps even modify them on the fly. Javascript malware if you  
will.

From looking at the developer code, it appears at least Google is  
already aware of this and tries to sandbox widgets from one another.   
Obviously javascript wasn't design to offer this type of security  
model and techniques like you've describe can circumvent a lot of it.

I expect we're going to see increased usage of these high-end AJAX  
desktops moving forward. It's only a matter of time before more  
sophisticated widgets arrive combining web services from all over  
that access our bank account details, calendar, blogs, etc. Let the  
fun begin!


Tangentially, Gerv blogged about this attack and asked the following  
question
http://weblogs.mozillazine.org/gerv/archives/2006/01/ 
interesting_ajax_attack.html

------
Would it break much of the web if we failed to send cookies on  
<script> src requests which were cross-domain?
------

I've found that MOST (websites) do not need authentication cookies  
for issuing script tag responses. However, there are some edge cases  
I've come across who do.

Does Google Adwords banners require cookies for tracking? Maybe other  
advertising banner guys do as well?




Regards,

Jeremiah Grossman
Founder and CTO, WhiteHat Security, Inc.
www.whitehatsec.com



---------------------------------------------------------------------
The Web Security Mailing List
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/