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