Message-ID: <6905b1570711050215p327377bcg60e398b0df039151@mail.gmail.com>
Date: Mon, 5 Nov 2007 10:15:21 +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

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@...il.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@...glemail.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@...il.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@...il.com>
> > >
> > > Date: Sun, 4 Nov 2007 13:26:17
> > > To:full-disclosure@...ts.grok.org.uk, "pdp (architect)"
> <pdp.gnucitizen@...glemail.com>
> > > Subject: [Full-disclosure] on xss and its technical merit
> > >
> > >
> > > Pdp architect and I have been emailing back and forth about whether xss
> has 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 security
> disciplines. 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 are
> lame 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 and
> i 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 a
> failed pentest and the customer should get a refund.
> > > 5) publishing xss shows your weakness and that you dont have the ability
> to 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/

Powered by blists - more mailing lists