Full Disclosure mailing list archives
Re: on xss and its technical merit
From: "pdp (architect)" <pdp.gnucitizen () googlemail com>
Date: Mon, 5 Nov 2007 10:15:21 +0000
reepex they are not weaker. they are different. in situations where the corporate network is protected by two layers of different types of firewalls, IPS, IDS, etc, etc ... one of the ways to sneak in is via XSS. Buffer Overflow wont work cuz you can attack only machines that are on the Internet facing side. You have a bunch of firewalls and IDSs which will stop any packet the data of which contains something like a nop sled. Ok you might be able to evade the IDS detection by replacing the nop sled with other types of useless but equal to "performing nothing" instructions but you must admit that we are pushing BFs here too much. BF is not a universal solution. XSS in this case will serve almost the same maybe even better job. Moreover, the technical expertise that is required in order to get something like the XSS scenario pointed above, is beyond the capabilities of most security guys out there. you need to have a very good understandings about browsers, networks, the web in general and other things like that, because once your payload is dropped inside the corporate network you are blind as a bat. You have no idea what you are doing. You have no control over the process. Believe me, it is really hard to pull a trick like that. I've done it a few times for demonstration purposes and I needed to spend 5 days on average in research and testing prior to the exercise. Not to mention that in order to passby some IDS you have to be very creative with how you are obfuscating the payload. Oh, when speaking about payloads, XSS is very different beast when compared to BF attacks. The payload is custom every time. This is the reason why I started coding AttackAPI as a library rather then exploitation toolkit like Metasploit. Here, I would like to draw your attention to the origins of XSS cuz I believe that you as well as others are very confused what this attack is all about. The attack came as an alternative of the client-side exploits Georgi Guninski was releasing for IE at the time. The issue was not new but I believe David Ross and bunch of other guys from Microsoft first described it in a formal manner. The attack was known as script injection before that. Cross-site scripting is rather misleading name. We are not cross scripting sites. We are cross scripting origins. For example: https://google.com http://google.com are the same site. But https://google.com is not accessible to http://google.com, i.e they are in different origins. Therefore Cross-site scripting should be really called Cross-origin Scripting. Cross-origin Scripting is nothing more but the attack vector known as Cross-zone scripting, the root cause for browser/client-side vulnerabilities. Therefore, any client-side exploit that relays on injecting scripts into a different origin is XSS. Keep in mind that I am following a very simple logic here. Even my grandfather can understand that. Also, remote file includes should be known as a form of XSS. Why? Cuz we are scripting a different origin again. SQL Injection is also a form of XSS - we scripting the origin of the SQL backend. However, let's not use XSS in this way cuz I believe a lot of people will get even more confused about it. You may disagree but this is how I see it and I stick behind my words as I've done it so far. XSS is largely complicated type of attack. It is very hard to pull and requires a lot of technical knowledge. It is easy to find useless XSS vectors but exploiting them is an art very few can practice at the moment. The beauty of buffer overflow exploits is in their sharpness. The beauty of XSS is in the imagination of the attacker and the level of tangled complexity you have to deal with. On Nov 5, 2007 12:11 AM, reepex <reepex () gmail com> wrote:
you see i do not agree with this because you are relying on other bugs to make xss useful and again you are relying on interaction from the user. any bug that requires another (form of) bug to be useful or that requires user interaction is inherently weaker then then other "any time" bugs like bof/sql injection/whatever On Nov 4, 2007 5:16 PM, pdp (architect) <pdp.gnucitizen () googlemail com> wrote:well valid point. XSS can alway be used as a career to whatever kind of attack you have in there. Just imagine the MySpace XSS warm combined with the IE VML or one of these ActiveX bugs that allow you to write into arbitery files on the file system (so that it is not a software bug). Hmmm? On Nov 4, 2007 11:51 PM, <nate.mcfeters () gmail com> wrote:What about when xss leads to stack overflows and command injections?See http://xs-sniper.com. It would seem that if you subscribe to the thought that only attacks that take over a victims computer are valid, then you would have to now admit xss as valid as well.Nate Sent via BlackBerry from T-Mobile -----Original Message----- From: reepex <reepex () gmail com> Date: Sun, 4 Nov 2007 13:26:17 To:full-disclosure () lists grok org uk, "pdp (architect)"<pdp.gnucitizen () googlemail com>Subject: [Full-disclosure] on xss and its technical merit Pdp architect and I have been emailing back and forth about whether xsshas a place in fd, bugtraq, or the security research area at all. He decided that we should start a discussion about in on here and gets peoples unmoderated opinion. This discussion should not concern whether its important due to stealing bank info, paypal, whatever it should only stick to xss as a pure research area. Or as pdp described it:"we are talking about whether XSS is as technical as other securitydisciplines. We are also talking about whether it should have a deserved an recognized place among FD readers and contributers. however, the topic wont cover only whether you can detect or inject XSS, this is lame. it will cover the whole 9 yards... pretty much all the topics covered inside the XSS book."My ideas on the topic are 1) XSS isnt techincal no matter how its used 2) people who use xss on pentests/real hacking/anything but phishing arelame and only use it because they cannot write real exploits (non-web) or couldnt find any other web bugs (sql injection, cmd exec,file include, whatever)3) XSS does not have a place on this list or any other security list andi remember when the idea of making a seperate bugtraq for xss was proposed and i still think it should be done.4) if you go into a pentest/audit and all you get out is xss then its afailed pentest and the customer should get a refund.5) publishing xss shows your weakness and that you dont have the abilityto find actual bugs ( b/c xss isnt a vuln its crap )i think pdp is going to respond first. should be fun ;) _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/-- pdp (architect) | petko d. petkov http://www.gnucitizen.org
-- 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 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 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)