Full Disclosure mailing list archives
Re: on xss and its technical merit
From: "pdp (architect)" <pdp.gnucitizen () googlemail com>
Date: Mon, 5 Nov 2007 08:00:19 +0000
comments inlined On Nov 5, 2007 12:07 AM, reepex <reepex () gmail com> wrote:
On Nov 4, 2007 4:43 PM, pdp (architect) <pdp.gnucitizen () googlemail com> wrote:lets say 10000 servers are running a vuln ftpd and another 10000 arerunningthe same open source web app. Which would you rather have the explotfor?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 thexsson 10000 msg boards would require 10000 users to view the page youattacked.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/
Current thread:
- Re: on xss and its technical merit, (continued)
- Re: on xss and its technical merit Volker Tanger (Nov 04)
- Re: on xss and its technical merit pdp (architect) (Nov 05)
- Message not available
- Re: on xss and its technical merit reepex (Nov 04)
- Re: on xss and its technical merit pdp (architect) (Nov 04)
- Re: on xss and its technical merit reepex (Nov 04)
- Re: on xss and its technical merit Dude VanWinkle (Nov 04)
- Re: on xss and its technical merit pdp (architect) (Nov 04)
- Re: on xss and its technical merit reepex (Nov 04)
- Re: on xss and its technical merit pdp (architect) (Nov 04)
- Re: on xss and its technical merit reepex (Nov 04)
- Re: on xss and its technical merit pdp (architect) (Nov 05)
- Re: on xss and its technical merit reepex (Nov 04)
- Re: on xss and its technical merit Volker Tanger (Nov 04)
- Re: on xss and its technical merit reepex (Nov 04)
- Re: on xss and its technical merit pdp (architect) (Nov 04)
- Re: on xss and its technical merit crazy frog crazy frog (Nov 04)
- Re: on xss and its technical merit pdp (architect) (Nov 04)
- Re: on xss and its technical merit reepex (Nov 04)
- Re: on xss and its technical merit pdp (architect) (Nov 05)
- Re: on xss and its technical merit nate . mcfeters (Nov 05)