Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security VulnWatch
[Top] [All Lists]

Re: [Full-disclosure] Php Nuke POST XSS on steroids

Subject: Re: [Full-disclosure] Php Nuke POST XSS on steroids
Date: Tue, 13 Mar 2007 17:59:37 -0400

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/

<Prev in Thread] Current Thread [Next in Thread>