Message-ID: <6905b1570711050000x3287858ci1b51d81c6708c85a@mail.gmail.com>
Date: Mon, 5 Nov 2007 08:00:19 +0000
From: "pdp (architect)" <pdp.gnucitizen@...glemail.com>
To: reepex <reepex@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: on xss and its technical merit

comments inlined

On Nov 5, 2007 12:07 AM, reepex <reepex@...il.com> wrote:
>
>
>
> On Nov 4, 2007 4:43 PM, pdp (architect) <pdp.gnucitizen@...glemail.com>
> wrote:
> >
> > >
> > > lets say 10000 servers are running a vuln ftpd and another 10000 are
> running
> > > the same open source web app. Which would you rather have the explot
> for?
> > > also which would be more practical to attack? assuming you have the same
> > > system and a good exploit you could get all the 10000 ftpds, while the
> xss
> > > on 10000 msg boards would require 10000 users to view the page you
> attacked.
> > >
> >
> > well I will go for the 10000 ftpds in general. However, it really
> > depends on what I am doing. As I said, these FTPDs may give you access
> > to the system but probably not access to the data which to me is a lot
> > more interesting. In this case 10000 XSS sounds a lot more valuable.
> >
> >
>
>   Which 'data' are you talking about? the servers info (in this case the
> server running the ftpd daemon) or the data/personal machines of the users
> of the ftpd?
>
>   I would rather have control of the ftpd then simply backdoor the daemon to
> work on indivivual users, just as I would rather control on the web server
> itself rather than any pre-exsiting xss bugs.
>
> again the whole point is that you do not need xss ever if you have client
> side exploits or access to the server itself.
>

well of course. I would like to control the server as well but
sometimes this is simply not possible or feasible in anyway. remember,
we are not talking about whether XSS is suitable for all kinds of
attacks. We are talking about the technical merits of XSS.

Keep in mind that many client side exploits are XSS for the browser,
as I've already mentioned.

Well for example, the FTP and the Web server both have to be in the
DMZ. However the Web server also needs to speak to the Application
Server. Compromising the FTP server does not give you anything apart
from a control over the FTP. You have no access to the data probably.
If you compromise the Web server, ok fair enough, this is more then
critical but again, how feasible is it .... I don't know?

>
>
> > There are XSS script kiddies as well Buffer Overflow script kiddies.
> > Just because you can find XSS does not mean that you've done something
> > amazing and extraordinary. It takes skills and a lot of effort to make
> > something out of it. But as I said before, open your mind. There are
> > endless potentials when it comes to XSS.
> >
>
> yes and i guess bad for you is that the only xss you really see posted (fd,
> milw0rm, security focus) is people posting <script>alert('hi')</script>
>
>
> >
> > BTW, it does look like an achievement when you find a XSS inside an
> > application that 1000 more people play with (look for similar bugs) on
> > a daily basis. XSS in some small apps are stupid. XSS on the default
> > Google Search Interface is as valuable as remotely exploitable buffer
> > overflow for Linux 2.6.x kernels (distribution independent).
> >
> >
> >
> >
>
> Again i think if you are attacking the users of a site instead of the site
> itself this is acceptable but your attacks could become much more hazardous
> if you owned the google server itself (maybe a stretch in the case of
> google) and added whatever code you wanted to the front page/ or embedded
> your nice browser exploit in the page. either of these ways seems much more
> valuable then xssing people who are signed in and visited your page.
>

ok... but what are the chances of hacking into the Google Web server?
Close to nothing, especially when you are dealing with a closed source
software. One of the way to own the server is to trick the admins into
visiting a page which will steal their authenticated sessions or
infect their browsers. IMHO, this one makes a lot more sense and
sounds a lot more feasible.

One of the things that I like about XSS in general is that in order to
exploit a vulnerability you really have to plan every stage of the
attack. Setting traps and making Google's and Yahoo's systems play
your game is an extraordinary experience and a great eye opener.

>
> also (unless im missing) something in another email you mentioned like 15
> different kinds of xss which I am sure are all interesting in their own way
> but the most you can get out of them is simple browser games.
>
>

As I said, this is not the case. Chrome based XSS, we covered a few in
the XSS book I believe, are very different, for example. In some case
the XSS vector resides inside a Sandbox. Now you need to find a way to
get out of the sandbox and and as such reaching again the browser
internals. Flash based XSS can lead to a lot of damages especially
when combined with something like desktop AIR applications which are
granted with full control over the client machine. AIR also can run
HTML pages which also can lead to evalated privilages and as such
access to the system. What about desktop and mobile Widgets?

XSS, like Buffer Overflow attacks, can be very customized. In terms of
Flash, for example, you need to know how the Flash file is structured.
You have to decompile it if you can. Simple decompiler like Flair does
not work for Flex. You need to know about what APIs the developers
have embed and how to use them in order to exploit the victim. XSS in
flash is also fun. You might not be able to modify the file system but
you might be able to steal Audio and Video input from the victim. This
is what I call a super bug!

-- 
pdp (architect) | petko d. petkov
http://www.gnucitizen.org

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists