lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 5 Nov 2007 10:06:06 +0530
From: "crazy frog crazy frog" <i.m.crazy.frog@...il.com>
To: "pdp (architect)" <pdp.gnucitizen@...glemail.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: on xss and its technical merit

plz consider reading n3d3v agenda before replaying to his mails.

On 11/5/07, pdp (architect) <pdp.gnucitizen@...glemail.com> wrote:
> comments inlined! I have to cuz you inlined yours
>
> On Nov 4, 2007 9:04 PM, reepex <reepex@...il.com> wrote:
> > On Nov 4, 2007 2:41 PM, pdp (architect) <pdp.gnucitizen@...glemail.com>
> > wrote:
> >
> > >
> > > 1) XSS isnt techincal no matter how its used
> > >
> > >
> > > Also, as buffer overflows and other attacks, which are more or less
> > > related to them, attackers need to take into consideration the
> > > execution flow and as such make the attack stealthier.
> >
> > I agree with this on a very high level but not in actual application. Having
> > limited chars in a xss isnt really comparable to having limited characters
> > in a buffer overflow.  having A-Za-z0-9 in xss only limits what scripting
> > elements you can use while the same for bin exploiting makes you rely only
> > on opcodes and addresses in that range. Writing alpanumeric shellcode
> > compared to writing limited xss ( esp with the ease you can redirect to
> > other pages and thus not be limited at all ) is not even a close comparison
> > technically.
> >
> > Also "controlling execution flow" of a browser which you only control
> > javascript or similar is no where near as challenging as having to control
> > the execution of a binary or even moreso a kernel after you have destroyed
> > much of its data and have to repair it to a usable state after.
> >
> >
>
> I agree, it is more complicated but don't you think that you have most
> of the tools already built for you? for example, I needed to write my
> own shell like interface for firefox just to get some of these nifty
> BASH tricks working when doing Web based attacks, including finding
> and exploiting of XSS.
>
> The only reason bin exploits are harder is because you have to deal
> with opcodes. So, this does not mean that you are smarter... it just
> means that you are nerdier. It does require a lot of effort to get
> going... I agree. And I have a great respect for everyone that does
> it. But I don't think that it is something I cannot personally get my
> head on if I really want to. It is all about dedication, something
> that I and a lot of XSS people already showed that have it in some
> solid forms.
>
> But if you are saying that JavaScript is easier to read then opcodes,
> you are right!
>
> >
> > >
> > > 2) people who use xss on pentests/real hacking/anything but phishing
> > >
> > >
> > > XSS is bar far the only way to run untrusted code within the origins of a
> > trusted domain
> > > without having a browser vulnerability on first place. SQL Injection
> > > and file inclusion attacks still exists, I deal with them on a daily
> > > basis, but the attack surface is largely mitigated by various types of
> > > frameworks which power most of the modern applications. However, why
> > > do you need SQL Injection when you can perform the needed action on
> > > behalf of the user by using XSS? It is safer and a lot stealthier. If
> > > you want to change someones details or want to get some data out, XSS
> > > is completely valid type of attack.
> >
> > With software (bin) vulns you arent only relying on a user or browser or
> > anything. you have vulnerabilities in the server software or perimeter
> > devices so you are cutting out any "user interaction" ( which is a very
> > important thing ), but maybe i am caring too much about your wording of "bar
> > far the only".
> >
>
> Bin vulns are finer and there is no doubt about that. But you have to
> think creatively. You are banging on the front door which is gardded
> by god knows what. How is that for a stealth? If you are spreading a
> worm, ok you have no problem with that but in case you want to
> penetrate a network you better think twice. First of all, you may
> fail. Second, you may loose all your hard work for nothing. You are
> giving away your well researched exploit. We have the tools the catch
> the little beast.
>
> It is different when it comes to XSS. XSS attacks can be tangled into
> the Web so deep that you won't be able to find them unless you have
> some sort of control over the remote servers, which you probably
> don't. It is indirect, which means that you have to think several
> steps in advance, because the vector may take any form and place. Most
> of the tools are located on the Web. The data is on the Web, ok the
> Intranet, when it comes to corporate stuff, but it is still based on
> Web technologies.
>
> I am not sure if you agree with me but I always say that you have to
> pick the best tools for the job. So here is a question for you: If
> most of the data is based on Web technologies what tools would you use
> in order to get it? Buffer overflows? Common on, do you have any idea
> how relevant these vulnerabilities are when it comes to the Web. They
> represent in total 0.01%. On the other hand XSS represent 99% .. which
> one would you pick?
>
> >
> > also with xss you are limited to the tasks that web application can do
> > unlike full control of the server which allows you to do whatever you want
> > and allows for much deeper penetration into the network.
> >
> >
>
> I agree but most of the time attackers are after the data not a
> control over the server. This so 1984.
>
> >
> >
> > > the people I've seen who use XSS today, have a vast background on
> > > traditional attack techniques. though, their number is very small
> > > mainly because the topic hasn't reached the level of maturity as other
> > > topics already have.
> >
> > We must know different people because the people i know that tout xss are
> > people that found out about xss and sql injection and have never moved on
> > and consider themselves 'security professionals'
> >
>
> well I have to tell you something. people get into a state of mind
> professional psychiatrist call "comfort zone". if you know about
> something and you've spent so much researching and working on it, you
> will never let it go. it is as simple as that. thanks god I read
> different literature apart form tech books.
>
> >
> > > Not true. If you don't know, XSS is a top priority today. It is
> > > present on almost all websites/application. I am not sure who you are
> > > working for and whether you are doing any pentesting but I can tell
> > > you something: people are interested in XSS and they are afraid of it.
> > > I must say that there is a huge gap of knowledge and understandings
> > > that needs to be filled but the situation is getting better with every
> > > single day. Today, companies are interested in Web2.0. They are
> > > interested of the impact this technology will have on their
> > > organization. There are numerous of things corporate people worry
> > > about when it comes to it. XSS is one of them.
> > >
> >
> >  ok and this is a technical debate not about people getting ripped off which
> > is what businesses care about.  just because xss affects businesses alot
> > does not make it anymore technical or worthwhile to 'research'
> >
>
> As I said, it can get as technical as anything else. Should we start
> witht Firefox peculiarities and IE ECMA standards bugs. If you don't
> know about the internals of the browser, you won't be able to get to
> the interesting stuff. There are many many different kinds of XSS. We
> have simple reflective XSS. Dom based XSS. The persistent kinds of
> XSS. Then we have XSS in websites which result into execution of
> chrome code due to shared trust. We have server based XSS as well as
> client based XSS. We have cached XSS. Local XSS. Remote XSS. ETC, ETc,
> Etc, etc. All of them, very different... very unique.
>
> >
> > >
> > > I used to rate XSS as low sometimes as medium risk two years ago.
> > > Today, if they are unauthenticated, I rate them as HIGH. Why? Open
> > > your eyes. XSS is not only about getting the victim running some code.
> > > There are a number of things you can do. Do you know that if CNN has
> > > XSS on their site and I manage to inject some google adds and kind of
> > > spread around the vector on a couple of bookmarking sites, I can make
> > > tones of money. Think about it.
> > >
> > >  a) CNN is a very important site.
> > >  b) Add Clicks will cost more.
> > >  c) Social bookmarking is a way of life (look at DIGG)
> > >  d) Social bookmarking sites can be spammed (research OnlyWire)
> > >
> > > You have all the components of a successful attack. What about forging
> > > stories? Or performing Black PR? Or maybe even Black SEO? The limit is
> > > only your imagination. Unfortunately, some people lack the imagination
> > > so others have to show them the way.
> >
> > Everything you listed is related (loosely) to phishing, scamming,fraud, etc
> > not to anything technical or groundbreaking.  While things like hijacking
> > adsense may be interesting ( which they are ), they do not require technical
> > feats to accomplish. its simple techniques which any script kiddie can
> > accomplish.
> >
>
> absolutely, but imagination is part of the hacking process - something
> that script kiddies lack. By having only technical skills you are
> nothing more but a very powerful input device. The imagination and
> creativity makes you a hacker. XSS is all about imagination plus
> technical stuff as well. Finding XSS, ok most of the time simple (not
> very simple for the interesting kinds). Exploiting XSS... well, you
> have to know about the following:
>
> XML, XHTML, CSS, JavaScript, ECMA Script, ActionScript, XSLT, SLT,
> RDF, OWA, SWF, WSF, XPath, XQuery, XForms (where needed),  HTTP (let's
> not forget about this one), DOM, Rendering Engines, XPCOM (cross-breed
> XSS), SOAP, WSDL (Yes XSS is possible though services as well, think
> indirect!). MathML (the esoteric kinds), RSS, ATOM, Track Backs, Ping
> Backs, SVG... many many more technologies. Do you really believe that
> this is simple? Do you know what? We can do a tech-quiz pub night on
> these technologies. If XSS was that simple all of us should know about
> them, right? The sad truth is that 80% of sec guys don't use RSS, or
> simple don't know the difference between RSS and ATOM.
>
> >
> >
> > >
> > >
> > >
> > > 5) publishing xss shows your weakness and that you dont have the
> > >
> > >
> > > publishing XSS makes you look stupid as well publishing a DoS cuz you
> > > haven't investigated enough to see whether and how your findings can
> > > be exploited.
> >
> > we agree!!
> >
> >
> > > reepex, I am sorry but all your statements are groundless. I was
> > > expecting something more from you, especially after we exchanged a few
> > > private emails. sometimes, I get the feeling that you actually know
> > > what you are talking about. you definitely know a few things but
> > > c'mon, really... give me something juicy...
> > >
> >
> > Yea after reading my original thing i admit it was pretty weak. i hope i
> > fixed it up here.
> >
>
> you are speeding up but I want more ... so far, it has been like a
> walk in the park.
>
> --
> 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/
>


-- 
advertise on secgeeks?
http://secgeeks.com/Advertising_on_Secgeeks.com
http://newskicks.com

_______________________________________________
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ