Message-ID: <20091114001607.GA15925@sentinelchicken.org>
Date: Fri, 13 Nov 2009 16:16:07 -0800
From: Tim <tim-security@...tinelchicken.org>
To: lsi <stuart@...erdelix.net>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: OS Commerce authentication bypass (ANONYMOUS
 REMOTE CODE EXECUTION)

Stu,


> The file manager seems to be implicated in many attacks on the forums 
> (maybe this is the bit that permits the uploading, and subsequent 
> execution, of PHP code), however it is NOT required for a successful 
> authentication bypass, for example the email functionality can be 
> remotely accessed without using file manager.  The milw0rm crack uses 
> the file manager, so it may or may not be the same vulnerability as 
> the authentication bypass.  

Yes, you are quite right.  The core issue is an authentication bypass.
On top of that is the misguided "feature" of allowing admins to
upload/edit PHP scripts from the web, which is why the end result is
trivial remote execution.


> And, yes, I did overlook the "Impact" section in my email, sorry 
> about that, it's mainly because I'm not really sure, I haven't 
> analysed the code, I have cleaned up a site, and did some research as 
> part of that, and I saw enough to know that this is a nasty 
> vulnerability, but I wouldn't want to get shot for saying that it, 
> for example permitted remote code execution, when it didn't, I can 
> verify that it can send emails and attempts some strange things with 
> file manager, but that was when I zapped it, so I'm not sure what 
> else is possible.  

Yes, I did verify in a recent pentest that with a simple, hand-written
HTTP request I was able to upload a PHP script in one shot.  This was
then accessible to any user.

Note that certain other scripts in the /admin/ area may also afford
remote execution.  Finding these holes I'll leave as an exercise to
the reader.


> I'm not sure if a bot cracked the site I cleaned, but the log does 
> show 12 requests to admin pages in 5 seconds.   A human might 
> generate that traffic, especially if there are redirects or 
> background POSTs or page refreshes etc... or a bot might generate it, 
> with slowness due to network overheads, CPU load etc, and/or a 
> deliberate delay loop.  Certainly, it would be possible to automate.  

Yes, I would suggest checking for the string "php/login.php" or
something similar in the web server logs.  You may not be able to see
the parameters sent, but if I remember correctly, the URL for an
exploit would need to have that in it.

Of course if you do think you're compromised, you should make a
forensic image of your system disks and rebuild from scratch.  I'm
sure you're aware of that, but some other readers may benefit from
this advice.


> As the file manager is not required, those folks who simply removed 
> it are still vulnerable.  Also, yes, moving the admin folder does 
> nothing, so those folks who did that are still vulnerable.  htaccess-
> based authentication on the admin dir fixes the issue BUT means 
> double logins for the admin, a rewrite rule could also fix it, with 
> no double login, except I think there's already other cracks for OSC 
> that mean htaccess in the admin dir is already compulsory....  
> 
> What I don't get is why the advice-givers on the OSC forums seem to 
> think that everyone already has htaccess in the admin dir, as it's 
> not part of the default install.

Right.  I tried to converse with some osCommerce
users/support/whatever on IRC and they gave the exact same response
about using htaccess.  If this is the "right" solution, then a new
version of osCommerce 2.x should be released which strips off the
login form.

But we all know this isn't the right solution.

Here's the GIT commit I was referring to earlier:
  http://github.com/haraldpdl/oscommerce2/commit/8a9dd053a40b44d632999331bc31f309604aceae

I think that's intended to fix the issue, but without more detail in
the commit or an official patch, use with caution.


> Yes, I also think the Secunia listing needs fixing, aside from 
> separating the access bypass into its own vulnerability, it also 
> needs to be upgraded to extremely critical, as exploits are in the 
> wild (this is their defintion of extremely critical, not mine).

Agreed.



> Happy Friday 13th... ;)

=) Have a good one,
tim

_______________________________________________
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