Date: Wed, 14 Nov 2007 04:35:07 -0600
From: nocfed <nocfed@...il.com>
To: full-disclosure@...ts.grok.org.uk
Cc: XSS Worm XSS Security Information Portal
	<cross-site-scripting-security@...worm.com>
Subject: Re: Wordpress 2.3 Cross Domain Content Insertion-
	New vulnerability + exploit - xssworm.com

One word: sandbox

XSS only exists in OUTPUT, while filtering should exist in both INPUT and
OUTPUT.  In fact, filtering is not the correct word to use as you should
ONLY allow EXPECTED input via GET and require a POST for user controlled
input.  Upon first review it would be thought that you could create JS to
just form.submit() but as only expected input is allowed via the GET then
that will not be an issue.

Unless you find a way to escape the sandbox, the end user has the
destination site in their local zones, they are using an extension that
evaluates pages in chrome://, or just a buggy extension, then there will be
no interactive javascript ``shell''.

One could construct the XSS/CSS to grab an AJAX type of framework from a
remote site, but then that site would need to be trusted by the client.
Your best bet would be to construct the JS to initialize an JRE Applet and
somehow(probably not too hard) get the end user to accept the foreign
applet, which would also need to escape the JRE Sandbox Security Model(has
been done in the past).

Ohh, fun times.

On Nov 14, 2007 1:57 AM, XSS Worm XSS Security Information Portal <
cross-site-scripting-security@...worm.com> wrote:

> Thank you for these points Dave, I am replying:
>
> With the XSS we can say it is shellcode because shellcode is the code
> injected into process or programme that contain bad validation of input - we
> say shellcode because it contains system call to execute shell commands - i
> think so?
>
> XSS vulnerability is bad validation of input also (and output as you said
> in bold)
>
> and with injected code and web 2.0 and fat rich clients (like in the USA)
> we can make java scripts with reverse shell to desktop with XSS
> & get interactive control over fat clients and make them do things and we
> can write interpreter and make it 'shell' if you want it easy (-;
>
> So XSS is input validation bug just like buffer overflow and we inject
> code that will be interactive 'shell' and execute action or command on
> behalf of user so XSS injection code = shellcode. Only differences in what
> you consider 'shell', 'command', 'action', 'user', no?
>
> With the code is posted we cannot see any bugs either but as you say maybe
> fundamentals
>
> output $_GET['variable']
>
> is this a vulnerability? I am not programmer but I have heard said that
> input validation is sometimes maybe the cause of vulnerabilities.
>
> Thanks vaj.
>
>
>
>
> On Nov 14, 2007 5:51 PM, dave-san <dave@...verted.org> wrote:
>
> > Comments inline..
> >
> > XSS Worm XSS Security Information Portal wrote:
> > > *0day XSS Exploit for Wordpress 2.3* – wp-slimstat 0.92 – [xssworm.com
> > ]
> > >
> > > Source:
> > > http://xssworm.blogvis.com/13/xssworm/0day-inject-exploit-for-wordpress-23-xsswormcom-all-version-vulnerable-with-no-patch/
> >
> > >
> > > There is a serious holes in wordpress 2.3 that can be used with XSS by
> > a
> > > blackhat hacker to attack the wordpress administrator and steal
> > cookies from
> > > blogmins. This attack is known as 0day because it has just been
> > reported to
> > > public and this is first day of public vulnerability, and *0day means
> > > 'published.*'
> > > Proof of concept:
> > >
> > >
> > http://wordpress-web-blog.com/wp-admin/index.php?page=wp-slimstat/wp-slimstat.php?panel=1&fi=/feed/&ff=1&ft=
> > <xss
> > > shellcode>
> > >
> >
> > Hmm.. XSS shellcode? That's a new one for me. I'll take this to mean the
> >
> > injected script. From your post, I don't think you mean "shellcode" in
> > the traditional sense.
> >
> > > This attack to be used against wordpress web blog blogmin to steal
> > > blogosphere token to hack blogs. Of course we have included exploit
> > code for
> > > this bug at the below.
> > >
> > > We have looked at coding for wp-slimstat but we cannot see any problem
> > with
> > > input validating. Maybe some of the xssworm.com readers can show us
> > where
> > > problem is in the php code because we cannot see any porblem here:
> > >
> > > –snips:
> > >
> > > C:\temp>findstr GET wp-slimstat.php
> > > $myFilterField = intval( $_GET['ff'] );
> > > $myFilterType = intval( $_GET['ft'] );
> > > $myFilterString = $_GET['fi'];
> > > $myFilterInterval = $_GET['fd'];
> > > $myFilterField = intval( $_GET['ff'] );
> > > $myFilterType = intval( $_GET['ft'] );
> > > $myFilterString = $_GET['fi'];
> > > $myFilterInterval = $_GET['fd'];
> > > '.(!empty($myFilterString)?'— <a
> > > href="?page='.$_GET['page'].'&panel='.$_GET["panel"].'">'.__('Reset
> > > filters', 'wp-slimstat').'</a>':").'
> > > <input type="hidden" name="page" value="'.$_GET['page'].'" />
> > > <input type="hidden" name="panel" value="'.$_GET["panel"].'" />
> > > <input type="hidden" name="fd" value="'.$_GET["fd"].'" /></form>';
> > >
> >
> > It's late, and I might have missed something, but from the above, I
> > don't see where the vulnerable parameter is being written back to the
> > HTML response. Therefore, I don't think there is enough code in the
> > lines above to locate the entire issue (though it looks like other
> > parameters are vulnerable too). You mentioned:
> >
> >  ft=<xss shellcode>
> >
> > So, in this example, "ft" is the vulnerable parameter. Trace what
> > happens in code with that parameter after it receives input. I'd guess
> > that there is something like..
> >
> >   echo '<maybe some HTML crap here>'. $myFilterType .' more...
> >
> > or
> >
> >   echo '<ditto>'.$_GET["ft"].'<ditto>..
> >
> > Perhaps take a look at where they missed the output formatting/encoding
> > for HTML. I may be so bold as to suggest that the lack of output
> > encoding is the major reason that XSS exists.
> >
> > > –snips
> > >
> > > With programmor using $_GET variable from user into echo into html
> > output
> > > maybe php automatic GET validation filtering is not working for
> > security? We
> > > are not programmers of php so we cannot see any porblems here as bug
> > are too
> > > complex to understand.
> > > Many thanks for your comments on this vulnerability in wordpress 2.4
> >
> > ..edit
> >
> > >
> > > Thanks vaj
> > >
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > Hosted and sponsored by Secunia - http://secunia.com/
> >
>
>
>
> --
> Francesco Vaj [CISSP - GIAC]
> CSS Security Researcher
> mailto:vaj@...pam.xssworm.com
> aim: XSS Cross Site
> ------
> XSS Cross Site Scripting Attacks
> Web 2.0 Application Security Information Blog (tm) 2007
> http://www.XSSworm.com/
> ------
> "Vaj, bella vaj."
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

Content of type "text/html" skipped

_______________________________________________
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