full-disclosure - Re: Php Nuke POST XSS on steroids

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]

Message-ID: <45F71EC9.7050801@castlecops.com>
Date: Tue, 13 Mar 2007 17:59:37 -0400
From: Paul Laudanski <paul@...tlecops.com>
To: ascii <info@...t.uz>
Cc: vuln@...urity.nnov.ru, webappsec@...ts.owasp.org, news@...uriteam.com,
	full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
	vulnwatch@...nwatch.org
Subject: Re: Php Nuke POST XSS on steroids

ascii wrote:
> Paul Laudanski wrote:
>   
>> I tried both your scripts at a few locations, and all I get back is this
>>     
> [cut]
>
> hi Paul, long time from ccc : )
>   
Hey sure how are you?  Been well?  I've been really busy with CC.
> it happens because http headers must be on a single line, it's a
> formatting issue (my fault, i used to put a link to a plain text
> version but this time i forgot about it), i've just created a txt
> version of the advisory available here:
>
> http://phpfi.com/214668
>   
Thank you, this works.
> it should be more usable, i dunno when the demos will stop working
> on phpnuke.org so i've asked wisec to upload this video since www.ush.it
> has bandwidth issues
>
> http://www.wisec.it/ush/phpnukexss.html
>
> obviously to bypass the anti-CSRF filter you have to mix the XSS with
> the import_request_variables() trick (this doesn't work on phpnuke.org
> because they have globals on, this is why i choose that domain)
>
> consider that import_request_variables() will allows you to do much
> more than an XSS, this is just an example advisory on an example product
>
>   
I'd be curious to see your POC using the import_request_variables, 
because at the moment:

<br><center><a href="modules.php?name=Downloads"><img 
src="modules/Downloads/images/down-logo.gif" border="0" alt=""></a><br><br>
d4
<form 
action="modules.php?name=Downloads&amp;d_op=search&amp;query=token<>token

" method="post"><font class="content"><input type="text" size="25" 
name="query"> <input type="submit" value="Search"></font></form>
18
<font class="content">[

I'm not sure how this will have any effect as you must POST the data.  
In that sense, you can't exactly exploit a web user -- which is what you 
basically said with a gateway page.  In a sense, you are setting up a 
sort of 'phish' against the site itself. 

For years we've been seeing to disable register_globals, and your 
workaround to enable it imvho is not a workaround at all.  That 
shouldn't even be suggested.

In closing, can you supply an import_request_variables POC?

Thanks as always,
Paul Laudanski
http://www.linkedin.com/pub/1/49a/17b

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