Re: [Full-disclosure] browser exploit web sites

[Nick FitzGerald]

Geo. wrote:

> and you get a ton of websites hosting browser exploits being used to infect 
> computers. setup.exe and a bunch of other crapola. Some of them seemed 
> pretty clever. Nothing new just figured I'd pass on the search info in case 
> anyone was researching these.

I didn't look real hard or at many of the search result pages, but I 
didn't see any exploits involved in this -- just your typical "use JS 
to (quite realistically) fake an online scan of the machine then push 
an installer .EXE" bogus anti-[adware|malware|spyware|virus] sites.


Regards,

Nick FitzGerald

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

Re: [Full-disclosure] on xss and its technical merit

[crazy frog crazy frog]

plz consider reading n3d3v agenda before replaying to his mails.

On 11/5/07, pdp (architect) <[EMAIL PROTECTED]> wrote:
> comments inlined! I have to cuz you inlined yours
>
> On Nov 4, 2007 9:04 PM, reepex <[EMAIL PROTECTED]> wrote:
> > On Nov 4, 2007 2:41 PM, pdp (architect) <[EMAIL PROTECTED]>
> > 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

[Full-disclosure] [Tool] sqlmap: a blind SQL injection tool (release 0.5)

[Bernardo Damele]

Hi,

I am glad to release sqlmap 0.5; sqlmap is an automatic SQL injection
tool entirely developed in Python. It is capable to perform an extensive
database management system back-end fingerprint, retrieve remote DBMS
databases, usernames, tables, columns, enumerate entire DBMS, read
system files and much more taking advantage of web application
programming security flaws that lead to SQL injection vulnerabilities.

* Project web site: http://sqlmap.sourceforge.net
* Download:
https://sourceforge.net/project/showfiles.php?group_id=171598&package_id=196107
* SVN repository: https://sqlmap.svn.sourceforge.net/svnroot/sqlmap
* Documentation:
http://sqlmap.svn.sourceforge.net/viewvc/*checkout*/sqlmap/doc/README.pdf
* ChangeLog:
http://sqlmap.svn.sourceforge.net/viewvc/*checkout*/sqlmap/doc/ChangeLog?revision=88

Cheers,
-- 
Bernardo Damele

Email address: bernardo.damele (at) gmail.com
Mobile number: +39 3493821385

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

Re: [Full-disclosure] on xss and its technical merit

[pdp (architect)]

comments inlined! I have to cuz you inlined yours

On Nov 4, 2007 9:04 PM, reepex <[EMAIL PROTECTED]> wrote:
> On Nov 4, 2007 2:41 PM, pdp (architect) <[EMAIL PROTECTED]>
> 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

Re: [Full-disclosure] on xss and its technical merit

[reepex]

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) <[EMAIL PROTECTED]>
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,  <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> >
> > Date: Sun, 4 Nov 2007 13:26:17
> > To:full-disclosure@lists.grok.org.uk, "pdp (architect)" <
> [EMAIL PROTECTED]>
> > 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
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] Conferences material, etc

[Roman Medina-Heigl Hernandez]

Hello ppl,

Could somebody provide a good link (ftp mirror) containing past
presentations&videos of known security conferences? (defcon, ccc, etc).
Some kind of sorted archive would help :)

I used "opensores.thebunker.net" in the past but it seems not to exist now...

-- 

Saludos,
-Roman

PGP Fingerprint:
09BB EFCD 21ED 4E79 25FB  29E1 E47F 8A7D EAD5 6742
[Key ID: 0xEAD56742. Available at KeyServ]

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

Re: [Full-disclosure] on xss and its technical merit

[reepex]

On Nov 4, 2007 4:43 PM, pdp (architect) <[EMAIL PROTECTED]>
wrote:

> >
> > lets say 1 servers are running a vuln ftpd and another 1 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 1 ftpds, while the
> xss
> > on 1 msg boards would require 1 users to view the page you
> attacked.
> >
>
> well I will go for the 1 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 1 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.



> 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 alert('hi')



>
> 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.

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.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] on xss and its technical merit

[reepex]

wow you are an idiot. could you please stay off this discussion. we wanted
valid (professional) opinions not your retarded comments.

On Nov 4, 2007 5:07 PM, Dude VanWinkle <[EMAIL PROTECTED]> wrote:

> On 11/4/07, reepex <[EMAIL PROTECTED]> wrote:
> >
> > On Nov 4, 2007 3:13 PM, pdp (architect) < [EMAIL PROTECTED]>
> > wrote:
> > > This
> > > is not very offline.
>
>
> So you are taking peoples offline conversations and posting them
> against their wishes?
>
> Are you trying to make a name for yourself by saying "look this guy
> actually talks to me"?
>
> What a joke.
>
> -JP
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] on xss and its technical merit

[pdp (architect)]

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,  <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>
> Date: Sun, 4 Nov 2007 13:26:17
> To:full-disclosure@lists.grok.org.uk, "pdp (architect)" <[EMAIL PROTECTED]>
> 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

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

Re: [Full-disclosure] on xss and its technical merit

[pdp (architect)]

dude, are you a bot? cuz you answer like a bot.. completely out of
context and without any sort of sense... listen English is not my
first language either but at least I am trying. I would suggest to go
back an re-read the email over and over again until you understand the
meaning.

On Nov 4, 2007 11:07 PM, Dude VanWinkle <[EMAIL PROTECTED]> wrote:
> On 11/4/07, reepex <[EMAIL PROTECTED]> wrote:
> >
> > On Nov 4, 2007 3:13 PM, pdp (architect) < [EMAIL PROTECTED]>
> > wrote:
> > > This
> > > is not very offline.
>
>
> So you are taking peoples offline conversations and posting them
> against their wishes?
>
> Are you trying to make a name for yourself by saying "look this guy
> actually talks to me"?
>
> What a joke.
>
> -JP
>



-- 
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/

Re: [Full-disclosure] on xss and its technical merit

[pdp (architect)]

comments inlined...

On Nov 4, 2007 9:26 PM, reepex <[EMAIL PROTECTED]> wrote:
> i seemed to reply to nexxus as you were writing your original reply which
> ive since replied to. about this email though...
>
>
> On Nov 4, 2007 3:13 PM, pdp (architect) < [EMAIL PROTECTED]>
> wrote:
> > XSS today is where buffer overflows were 10-15 year ago. Moreover, did
> > you missed when I said that 99% of all sites are vulnerable to XSS.
> > Given the percentage of available XSS vulnerabilities, what chance you
> > think you have finding one? simple math! of course it is easy. It is
> > easy for most of XSS issues. However, those that really matter are not
> > easy at all. DOM based XSS is a debug hell, mainly because every time
> > you want to do something you have to deal with the remote server. This
> > is not very ofline.
>
> yes buffer overflows were everywhere then and yes xss is everywhere now. but
> to say that xss is the buffer overflow of 15 years ago is not a good
> comparison. Even if xss evolves for 15 years, which it may, would the result
> be as damaging as even simple stack based overflows have been? Could you
> have such mass damage worms as overflows have caused? I know there has been
> myspace worms (which you mention), but xss cannot have the same effect as
> overflows to a server.
>

MySpace grew from 20 infected profiles to over 3 million in less then
24 hours. I am not very good at computer virology, but to my
knowledge, this is the fastest spreading worm ever. Today XSS worms
can be a lot more powerful. I wrote a paper on that called "For my
next trick... hacking Web2.0". Check it out if you trust my
professional input.

>
> lets say 1 servers are running a vuln ftpd and another 1 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 1 ftpds, while the xss
> on 1 msg boards would require 1 users to view the page you attacked.
>

well I will go for the 1 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 1 XSS sounds a lot more valuable.

>
> xss just does not have the same potentional as overflows do unless browsers
> develop some new technology or extend an old one to let client side
> scripting to have much more control on the system.
>

they don't have the same potentials yet but they can be as nasty as
buffer overflows. as I said, most of the applications people use today
are located on the Web. In this case owning their machine is
pointless. OK, you will be able to install sniffers and keyloggers but
for what? You can simply infect their profile with XSS so every time
they open the application you gain control. Isn't that the same. Hook
the victims on a XSS proxy such as Carnaval and you have a botnet. The
concepts are exactly the same. The only difference is that Web
application are written with Web technologies, where bin applications
are compiled from C, or whatever language you have, sources.

So XSS for Webs is like Buffer Overflows for Bins.

>
> >
> >
> > if you want to do it right, then it is harder to get a successful XSS
> > attack. do you know why? cuz XSS involves a bit of strategy as well.
> > because it is an indirect type of attack. A single XSS attack
> > sometimes may involve several sub XSS each one of which call the next
> > one in an exponential manner. By the time you reach level 5 you head
> > is so screwed up that you need to start all over again because you
> > code breaks on 50 places. JavaScript in particular is not an easy
> > language. You may think that you know it but you don't know 90% of it.
> > When it comes to scoping you get into a mess of things. Have you ever
> > done XSS on GMail. Try it! See how far you will go. Unless you have
> > some solid understanding on AJAX debuging and some nifty tools that
> > can put back Google's mess into order, you have no chance. Today
> > software hackers relay on tools such as IDA Pro or Soft Ice, which is
> > discontinue but still. Check this out there are not tools like that
> > for XSS and in particular AJAX, therefore I have to start from zero.
> > Where is my JavaScript deobfiscator? I don't have one... I have to
> > write it myself. Where is my debugger. I am stuck with Firebug for
> > Firefox... Great! How about dynamic tracing, tracking, stepping and
> > all other things on a complete BlackBox application that you can only
> > see the incoming and outgoing requests. At least when you have a
> > binary you know what it is. You can do it offline and you have all of
> > the parts.
> >
> > XSS can be very complicated. Don't be fulled by what people post on FD.
> >
>
>
> the problem is that if you are going to xss 5 times deep why cant you just
> find a client side browser bug?

Re: [Full-disclosure] on xss and its technical merit

[Dude VanWinkle]

On 11/4/07, reepex <[EMAIL PROTECTED]> wrote:
>
> On Nov 4, 2007 3:13 PM, pdp (architect) < [EMAIL PROTECTED]>
> wrote:
> > This
> > is not very offline.


So you are taking peoples offline conversations and posting them
against their wishes?

Are you trying to make a name for yourself by saying "look this guy
actually talks to me"?

What a joke.

-JP

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

Re: [Full-disclosure] on xss and its technical merit

[nate . mcfeters]

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 <[EMAIL PROTECTED]>

Date: Sun, 4 Nov 2007 13:26:17 
To:full-disclosure@lists.grok.org.uk, "pdp (architect)" <[EMAIL PROTECTED]>
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/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] on xss and its technical merit

[pdp (architect)]

ok... so you are rejecting my well put arguments... no problem

1) how hard is it find xss in applications

How hard was to find stack overflows in 1990 or even before that? 'A'
x 1 or 'A' * 1 and then check the EIP for
0x41414141... great trick! I was still a kid when people were mass
exploiting everything that was under the sun and as you can see there
was some very successful worm outbreaks... today, hacking stacks and
heaps and all that comes with them is harder, yes... of course it is
harder. you are dealing with some 40 year old problem. People know
about it. People understand it.

XSS today is where buffer overflows were 10-15 year ago. Moreover, did
you missed when I said that 99% of all sites are vulnerable to XSS.
Given the percentage of available XSS vulnerabilities, what chance you
think you have finding one? simple math! of course it is easy. It is
easy for most of XSS issues. However, those that really matter are not
easy at all. DOM based XSS is a debug hell, mainly because every time
you want to do something you have to deal with the remote server. This
is not very ofline.

2) how hard it is to successfully exploit the vulnerability

now we are talking. it really depends on what you want to do. let's
say that you want to steal some cookies. ok lame. not very
interesting! but exploiting a XSS vulnerability is an art on its own.
check this out man:

myspace. we know samy right? ok, the guy needed to write a worm on a
live application without releasing it too early. so you think that
this is not a skill on itself. when did you performed agile code
execution of a life system. I doubt that anyone has ever done it.

if you want to do it right, then it is harder to get a successful XSS
attack. do you know why? cuz XSS involves a bit of strategy as well.
because it is an indirect type of attack. A single XSS attack
sometimes may involve several sub XSS each one of which call the next
one in an exponential manner. By the time you reach level 5 you head
is so screwed up that you need to start all over again because you
code breaks on 50 places. JavaScript in particular is not an easy
language. You may think that you know it but you don't know 90% of it.
When it comes to scoping you get into a mess of things. Have you ever
done XSS on GMail. Try it! See how far you will go. Unless you have
some solid understanding on AJAX debuging and some nifty tools that
can put back Google's mess into order, you have no chance. Today
software hackers relay on tools such as IDA Pro or Soft Ice, which is
discontinue but still. Check this out there are not tools like that
for XSS and in particular AJAX, therefore I have to start from zero.
Where is my JavaScript deobfiscator? I don't have one... I have to
write it myself. Where is my debugger. I am stuck with Firebug for
Firefox... Great! How about dynamic tracing, tracking, stepping and
all other things on a complete BlackBox application that you can only
see the incoming and outgoing requests. At least when you have a
binary you know what it is. You can do it offline and you have all of
the parts.

XSS can be very complicated. Don't be fulled by what people post on FD.

On Nov 4, 2007 8:42 PM, reepex <[EMAIL PROTECTED]> wrote:
> you see you are arguing how useful xss can be for an attacker, but the point
> of this argument is
>
> 1) how hard is it find xss in applications
> 2) how hard it is to successfully exploit the vulnerability
>
> compared to other vulnerabilities xss is way down on the scale
>
> i also believe this is what pdp wanted to argue as he believes xss is on the
> same scale as other bugs following 1 and 2
>
> On Nov 4, 2007 2:28 PM, < [EMAIL PROTECTED]> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> >
> >
> > reepex wrote:
> > > 1) XSS isnt techincal no matter how its used
> > I totally disagree with you.. isn't technical for those who cannot
> > realize how much powerful can be a xss, especially if persistent.
> >
> >
> >
> > > 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)
> > Imho the pentesting will move day by day closer to web applications
> > flaws testing, since the web applications are self written by webmasters
> > and more exposed to possible bugs. Concerning sql inj or rfi are not
> > more difficult to be discovered..
> >
> >
> >
> > > 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.
> > Dunno about that, even if i agree that all the xss flaws found should
> > not be reported here, they would be too much.
> >
> >
> >
> > > 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.
> > 

Re: [Full-disclosure] on xss and its technical merit

[pdp (architect)]

thanks reepex for starting the discussion. it will be really great if
we can get more people involved into this. it seams that there is a
lot of confusion on the merits of XSS. I hope that we can answer all
of your questions once and for all.

1) XSS isnt techincal no matter how its used

XSS can be as technical as it can gets. It can be very technical or
not technical at all. Under the term XSS we have variations of
technologies and techniques in a similar way when compared to
software(bin) (buffer overflows) hacking. Therefore, just injecting
meta characters inside a page, does not mean anything as well as
when injecting data into a buffer - it does not mean anything at all.
What is more interesting, is how you use the vector. Keep in mind that
when dealing with XSS, we have pretty much the same obstacles as with
buffer overflows - we are limited by size and allowed characters.
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.

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)

We leave in different times. The Web has become the only tool we need
and as such the browser is the ultimate platform. 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.

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. I don't want to mention names here mainly because
it s very rude but I welcome all of you to join the conversation.

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.

FD is a general security list. XSS is a security discipline.
Therefore, XSS should be present on FD as well as other security
topics should be present too. However, if someone is serious about
XSS, there are plenty of other places you can attend. Moreover,
nowadays, posting to FD is pointless. The list is out of control and I
as many others, find it rather lame and not worth the effort. If you
want to learn something, start reading blogs.

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.

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.

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.

XSS has more potential then any other type of vulnerability available
today. This is due to the size of the Web. When you start putting all
the things into prospective you will see what I am talking about. For
all of you, who think that XSS is a crap, well you are simply missing
the train and the great ride that comes w

Re: [Full-disclosure] on xss and its technical merit

[reepex]

i seemed to reply to nexxus as you were writing your original reply which
ive since replied to. about this email though...

On Nov 4, 2007 3:13 PM, pdp (architect) <[EMAIL PROTECTED]>
wrote:

> XSS today is where buffer overflows were 10-15 year ago. Moreover, did
> you missed when I said that 99% of all sites are vulnerable to XSS.
> Given the percentage of available XSS vulnerabilities, what chance you
> think you have finding one? simple math! of course it is easy. It is
> easy for most of XSS issues. However, those that really matter are not
> easy at all. DOM based XSS is a debug hell, mainly because every time
> you want to do something you have to deal with the remote server. This
> is not very ofline.


yes buffer overflows were everywhere then and yes xss is everywhere now. but
to say that xss is the buffer overflow of 15 years ago is not a good
comparison. Even if xss evolves for 15 years, which it may, would the result
be as damaging as even simple stack based overflows have been? Could you
have such mass damage worms as overflows have caused? I know there has been
myspace worms (which you mention), but xss cannot have the same effect as
overflows to a server.

lets say 1 servers are running a vuln ftpd and another 1 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 1 ftpds, while the xss
on 1 msg boards would require 1 users to view the page you attacked.

xss just does not have the same potentional as overflows do unless browsers
develop some new technology or extend an old one to let client side
scripting to have much more control on the system.


>
> if you want to do it right, then it is harder to get a successful XSS
> attack. do you know why? cuz XSS involves a bit of strategy as well.
> because it is an indirect type of attack. A single XSS attack
> sometimes may involve several sub XSS each one of which call the next
> one in an exponential manner. By the time you reach level 5 you head
> is so screwed up that you need to start all over again because you
> code breaks on 50 places. JavaScript in particular is not an easy
> language. You may think that you know it but you don't know 90% of it.
> When it comes to scoping you get into a mess of things. Have you ever
> done XSS on GMail. Try it! See how far you will go. Unless you have
> some solid understanding on AJAX debuging and some nifty tools that
> can put back Google's mess into order, you have no chance. Today
> software hackers relay on tools such as IDA Pro or Soft Ice, which is
> discontinue but still. Check this out there are not tools like that
> for XSS and in particular AJAX, therefore I have to start from zero.
> Where is my JavaScript deobfiscator? I don't have one... I have to
> write it myself. Where is my debugger. I am stuck with Firebug for
> Firefox... Great! How about dynamic tracing, tracking, stepping and
> all other things on a complete BlackBox application that you can only
> see the incoming and outgoing requests. At least when you have a
> binary you know what it is. You can do it offline and you have all of
> the parts.
>
> XSS can be very complicated. Don't be fulled by what people post on FD.
>


the problem is that if you are going to xss 5 times deep why cant you just
find a client side browser bug?  you are researching how to basically steal
credentials/force requests/steal accounts when one browser or client side
bug would make all of that unnecesary. People like the ones i mention in the
other email will put this much time into xss because they are incapable
doing the client side bugs because they require much more skill that he ppl
simply do not have.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] on xss and its technical merit

[reepex]

On Nov 4, 2007 2:41 PM, pdp (architect) <[EMAIL PROTECTED]>
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.



> 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".

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.



> 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'


> 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'


>
> 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.



>
> 5) publishing xss shows your weakness and that you dont have the
>
> publishing XSS makes you

Re: [Full-disclosure] on xss and its technical merit

[reepex]

you see you are arguing how useful xss can be for an attacker, but the point
of this argument is

1) how hard is it find xss in applications
2) how hard it is to successfully exploit the vulnerability

compared to other vulnerabilities xss is way down on the scale

i also believe this is what pdp wanted to argue as he believes xss is on the
same scale as other bugs following 1 and 2

On Nov 4, 2007 2:28 PM, <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> reepex wrote:
> > 1) XSS isnt techincal no matter how its used
> I totally disagree with you.. isn't technical for those who cannot
> realize how much powerful can be a xss, especially if persistent.
>
> > 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)
> Imho the pentesting will move day by day closer to web applications
> flaws testing, since the web applications are self written by webmasters
> and more exposed to possible bugs. Concerning sql inj or rfi are not
> more difficult to be discovered..
>
> > 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.
> Dunno about that, even if i agree that all the xss flaws found should
> not be reported here, they would be too much.
>
> > 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.
> I don't agree with this too for the same reasons as before.
>
> > 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 )
> Imho a xss is a vuln as much as the others, since if used smartly could
> get quite dangerous.
>
> Reading a report from zone-h i read that the most effective hacking
> cause it's the xss.. i don't know if i shall agree with this, but
> obviously it should make us think about it.
>
> bye
>
> /nexus
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.7 (GNU/Linux)
>
> iD8DBQFHLitaVVYXVqV+ctMRAkcEAKCLXroIu80OemE/m/voaN4iczrJigCfTH3Q
> EJOb41+Eex4lFNy1AHJ9xhE=
> =ICJh
> -END PGP SIGNATURE-
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] on xss and its technical merit

[Volker Tanger]

Greetings!

On Sun, 4 Nov 2007 13:26:17 -0600
reepex <[EMAIL PROTECTED]> wrote:
> "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.
[...]
> 1) XSS isnt techincal no matter how its used
[...]
> 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.

XSS is a variant on missing or lax input verification. Thus all other
forms of input-nonverification like buffer overflows or char(0)
injections or the like should be handeled similarily.

In its simplest version XSS could be used for phishing - which is bad
enough for banking or business portals. Depending on the application
other elevations might be possible through XSS like session stealing,
cmd/sql injects, etc.

Especially if such an elevated XSS was detected for a software it
definitely would have a place on security mailing lists. But it should
be more qualified than just "XSS found on ". Just running a XSS
scanner is lame - whereas finding out all consequences and possible
attack vectors and maybe even posting a patch might be a worthwile
posting.

Bye

Volker

-- 

Volker Tangerhttp://www.wyae.de/volker.tanger/
--
[EMAIL PROTECTED]PGP Fingerprint
378A 7DA7 4F20 C2F3 5BCC  8340 7424 6122 BB83 B8CB

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

Re: [Full-disclosure] [full-disclosure] on xss and its technical merit

[gjgowey]

My thoughts are that if I take my car to Ford for maintenance then I don't want 
them to not put down that a bulb burnt out because it's "lame."  It's often the 
little problems that lead to far bigger problems later.  Evaluating if 
something should be reported or not based on "lameness" is unprofessional and 
has no real world value.

Geoff

Sent from my BlackBerry wireless handheld.

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

[Full-disclosure] on xss and its technical merit

[reepex]

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/

Re: [Full-disclosure] breaking SIP for fun and toll fraud

[reepex]

On Nov 4, 2007 8:45 AM, Radu State <[EMAIL PROTECTED]> wrote:
>
>  P is the proxy located at URL:proxy.org
>
 X is the attacker located at URL: attacker.lan.org
>
>  V is the victim located at URL:   victim.lan.org
>
>  V is also registered with P under the username [EMAIL PROTECTED]
>
>  .
>
> Step 3) The accomplice Y steps in and invites victim V, and then
> the victim decides
>
>  to put X on hold
>

to make this "exploit" work you need more conditions present than in The
Malloc Maleficarum.

If Alice sits in bob's lap and bob looks over alices shoulder and sees her
type her password and alice does not notice bob then bob has broken the
security of the windows login.

> POC code:
>
>
>
>  Available ONLY to legitimate VoIP device manufacturers.
>
>
>
> Will you "step down to them" and send them more of your expert perl? or
will you send them iterative loops in lisp


>
>  Humberto Abdelnur, Ph.D student, the Madynes team at INRIA
>
>  Radu State, Ph.D, the Madynes team at INRIA
>
>  Olivier Festor, Ph.D the Madynes team at INRIA
>
>
>
phd is the new cissp!
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] stop cross posting

[Dude VanWinkle]

On 11/4/07, reepex <[EMAIL PROTECTED]> wrote:
> actually no one cares about your posts so it would be better if you stopped
> posting completely
>
> when you learn to install gcc you can come back

sudo apt-get install gcc

Sweet! I am back!

BTW: Nice Profile: http://tinyurl.com/create.php

BTW2: Did you know your s00per kewl haxor handle is previous art to a
pillow manufacturer?

sweet!

-JP

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

Re: [Full-disclosure] stop cross posting

[reepex]

actually no one cares about your posts so it would be better if you stopped
posting completely

when you learn to install gcc you can come back

On Nov 3, 2007 6:39 PM, Dude VanWinkle <[EMAIL PROTECTED]> wrote:

> On 11/3/07, worried security <[EMAIL PROTECTED]> wrote:
> > hi,
> >
> > can everyone stop cross posting?
> >
> > its the same people on all the mailing lists, there is absolutely no
> > reason for cross posting.
>
> Sorry about that n3td3v, won't happen again.
>
> I would hate to annoy you like that.
>
> -JP
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.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/

Re: [Full-disclosure] IDS logs showing outgoing packets on port 80

[Morning Wood]

Skype?

- Original Message - 
From: "Kelly Robinson" <[EMAIL PROTECTED]>
To: 
Sent: Saturday, November 03, 2007 3:20 PM
Subject: [Full-disclosure] IDS logs showing outgoing packets on port 80


> In our IDS logs, I notice many outgoing packets coming from port 80 
> (HTTP).
> These packets are coming from client PCs. What may be happening?
>





> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.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/

[Full-disclosure] browser exploit web sites

[Geo.]

If anyone is interested.. google on

roof moss magnesium vs zinc

and you get a ton of websites hosting browser exploits being used to infect 
computers. setup.exe and a bunch of other crapola. Some of them seemed 
pretty clever. Nothing new just figured I'd pass on the search info in case 
anyone was researching these.

Geo. 

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

[Full-disclosure] breaking SIP for fun and toll fraud

[Radu State]

SIP Digest Access Authentication RELAY-ATTACK for Toll-Fraud

 

 In this post, we would like to inform about a potential Authentication
vulnerability

 in SIP, where all SIP equipments using Digest Access Authentication
which can issue 

 re-INVITEs are vulnerable.

 

 The problem lies in an attack scenario, where a called device can be
triggered by a

 calling party to issue a re-INVITE. Such cases appear when either a
phone is put on

 hold. More general, this is possible whenever a target refresh within a
dialog takes

 place.

 

 The impact is that Toll-fraud, Call-ID spoofing, etc. are possible,
allowing a third

 entity to call on behalf of a victim. The victim is accountable in this
case for the

 call.

 

 To our knowledge, we don't know if neither the IETF nor anybody else
has addressed 

 this issue yet. 

 

 THIS IN NOT THE KNOWN ISSUE OF MAN IN THE MIDDLE. THE MAIN NOVELTY IS
THAT AN 

 ATTACKER CAN TRIGGER A re-INVITE FROM A CALLED PHONE AND REQUEST IT TO
AUTHENTICATE.

 In the known MITM the attacker has to wait until the victim initiates a
call and the

 attacker may issue the call to a destination choice, but to the one
initially chosen

 by the victim (RFC 3261 Section 22.4). 

 

Description of the attack:

 

Synopsis

 

 An attacker will issue a call to the victim, the victim answer and
later on put the

 attacker on hold. To address to be put on hold, an accomplice of the
attacker may

 initiate another call. Once the attacker receives the re-INVITE
specifying the 

 "On hold", he/she will request the victim to authenticate. This last
authentication 

 may be use by the attacker to impersonate the victim at its own proxy.
Detailed 

 explanation is below.

 

Notations

 

 P is the proxy located at URL:proxy.org 

 X is the attacker located at URL: attacker.lan.org

 V is the victim located at URL:   victim.lan.org 

 V is also registered with P under the username [EMAIL PROTECTED]

 

 Y is the accomplice of X (it can be in fact X), but we use another
notation for 

   clarity sake

 

Objective: 

 

 X wants to call a toll fraud number 1-900-  impersonating V

 

Process:

 

 Step 1) X calls's directly V. 

 "The route set MUST be set to the list of URIs in the
Record-Route header 

  field from the request...The remote target MUST be set to the
URI from

  the Contact header field of the request." RFC 3261 Section
12.1.1 UAS 

  behaviour



 

  X -- INVITE victim.lan.org -> V

   From : [EMAIL PROTECTED]

   To: [EMAIL PROTECTED] 

   Contact: [EMAIL PROTECTED]

   Record-Route: attacker.lan.org

 

 Step 2) The normal SIP processing

 

  X <--- 180 Ringing -- V

  X <- 200 OK - V

 

  X <--- Media Data --> V

 

 

 Step 3) The accomplice Y steps in and invites victim V, and then the
victim decides

 to put X on hold

 

 

 Step 4) The victim, V, sends a re-INVITE to X (to put it on hold)

 "The UAC uses the remote target and route set to build the
Request-URI and 

  Route header field of the request." RFC 3261 12.2.1.1
Generating the

  Request (Requests within a Dialog)

 

  X <--- INVITE [EMAIL PROTECTED]  V

   From: [EMAIL PROTECTED]

   To : [EMAIL PROTECTED]

 

 Step 5) X calls 1900- using the proxy P and the proxies asks X to
authenticate

 using a Digest Access Authentication with nonce
="Proxy-Nonce-T1" and

 realm ="proxy.org"

 

 Step 6) X request the victim to authenticate the re-INVITE from step 4
using the 

 same Digest Access Authentication received in step 5 

 

  X 401/407 Authenticate > V

   Digest: realm ="proxy.org", nonce="Proxy-Nonce-T1"

 

 Step 7) In this step the victim will do the work for X (Relay Attack)

 

  X <--- INVITE [EMAIL PROTECTED]  V

   Digest: realm ="proxy.org", nonce="Proxy-Nonce-T1"

   username= "victim",

   uri="[EMAIL PROTECTED]",

   response="the victim computed response"

 

 Step 8) X may reply now to the Proxy with the valid Digest Access
Authentication

 computed by the victim. Note that the Digest itself it is a
perfectly 

 valid one.

 

 

POC code: 

 

 Available ONLY to legitimate VoIP device manufacturers.

 

Possible Mitigations: 

 

 Avoid re-INVITE

 Use strict outbound proxy with a complementary IDS to detect possible
anomalies

 ...

 

Further reading:

 

 More details (b