Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

New Exploit


trogan

Recommended Posts

http://www.milw0rm.com/exploits/9556

 

As far as I can see this vulnerability is on all osCommerce 2.2 RC2a sites.

 

A quick way to ensure that you site is not vulnerable is to password protect the /admin directory. This can usually be done with your hosting control panel (such as Cpanel). Alternatively this can be done using htaccess, there are many guides around the internet on how to do this (e.g. http://www.javascriptkit.com/howto/htaccess3.shtml)

 

Trogan

Link to comment
Share on other sites

An excerpt from the script:

 

$admin_path = 'admin/';
$shellcode = "filename=fly.php&file_contents=test<?php%20@eval(\$_POST[aifly]);?>";
$message="POST ".$path.$admin_path."file_manager.php/login.php?action=save HTTP/1.1\r\n";

Looks like renaming the admin folder to something else (suggested on this forum all over the place) or removing the osC file manager (also suggested more times than I can count) would also provide immunity.

If I suggest you edit any file(s) make a backup first - I'm not perfect and neither are you.

 

"Given enough impetus a parallelogramatically shaped projectile can egress a circular orifice."

- Me -

 

"Headers already sent" - The definitive help

 

"Cannot redeclare ..." - How to find/fix it

 

SSL Implementation Help

 

Like this post? "Like" it again over there >

Link to comment
Share on other sites

i confirm that with an htaccess for the admin path resolve the problem

but it seems that the login.php has a whole so you can write files on the server.

does anyone know which line we have to correct to fix that security bug?

Link to comment
Share on other sites

but it seems that the login.php has a whole so you can write files on the server.

That would be an incorrect assumption.

 

Look at tne code example I posted.

 

It's file_manager.php doing the writing, not login.php

 

Remove file_manager.php or rename the admin folder (if you rename the admin folder you have to change the configure file too - don't be stupid).

 

Either one provides you immunity from this exploit.

If I suggest you edit any file(s) make a backup first - I'm not perfect and neither are you.

 

"Given enough impetus a parallelogramatically shaped projectile can egress a circular orifice."

- Me -

 

"Headers already sent" - The definitive help

 

"Cannot redeclare ..." - How to find/fix it

 

SSL Implementation Help

 

Like this post? "Like" it again over there >

Link to comment
Share on other sites

sorry... my mystake ...

yes it's file_manager.php not login.php (i was writing on it during my post... sorry for the mystake)

rename the folder doesn't change anything ...

with a good http scanner we can find easily where is the admin folder ;)

i just asked if there is any bug correction available ... not a "delete file" solution ....

Link to comment
Share on other sites

My advice would be to do both - remove the file manager and rename the admin folder.

 

Problem solved.

:)

 

Edit: AND add .htacess protection as the originator of this thread suggested.

 

That can't hurt either.

If I suggest you edit any file(s) make a backup first - I'm not perfect and neither are you.

 

"Given enough impetus a parallelogramatically shaped projectile can egress a circular orifice."

- Me -

 

"Headers already sent" - The definitive help

 

"Cannot redeclare ..." - How to find/fix it

 

SSL Implementation Help

 

Like this post? "Like" it again over there >

Link to comment
Share on other sites

Either one provides you immunity from this exploit.
If by immunity you mean, "until they find out your admin folder name and change the script". Renaming the admin folder does not provide what I would call immunity (nor even the lower bar of security). It would prevent that script from working as written and in general stops automated scripts that rely on the admin folder being named admin. Password protecting the directory and using https to access would provide security (not immunity). Removing the file_manager.php would provide actual immunity from this exploit (may still leave other exploits open though; for example, is define_language.php vulnerable to the same kind of exploit?).

 

Incidentally, setting up your server so that it doesn't allow the web user write access to files would prevent this entire class of exploit (and incidentally break file_manager.php and define_language.php). This is what I mean when I say that requiring 444 permissions for includes/configure.php is less secure than allowing 644 permissions -- the server should not be able to write to any files, not just includes/configure.php. If I was going to pick one file to replace to compromise an osCommerce install, it would not be includes/configure.php. That's the file that I don't want others to read. I would want to write to a different file.

 

Unfortunately, it has become common to set things up with the account user as the web user. These really should be two separate functions. It used to be that way. The web server ran as apache or whatever and each user had their own account. Then there were problems with users compromising the accounts of other users, so they separated it. However, they took a step back. Instead of creating a new account for each web user, they started using the user account as the web user. As a result, if your user account has the ability to edit a file, so does the web application. It would be better to have a separate account for the web and the ability to chown files and directories (e.g. the images directory) to be owned by the web.

 

For that matter, for osCommerce purposes, it would be better to have three accounts: a catalog web user account, an admin web user account, and a regular user account. The catalog account could have low permissions, just read on all files in the catalog directory (and its children -- not counting the admin directory, which can be put elsewhere). The admin web account would have higher permissions, which allow writing to image folders and reading the admin directory. The regular user account would have write permissions on all files. By setting ownership and group settings correctly, the system would be secure in general, even in the face of buffer overflow exploits in apache that permit compromise of web users. At worst, such a compromise would allow editing of files in the images directory, which with proper configuration in a <Directory> section in httpd.conf (so that PHP and other CGI scripts do not run from the images directory) is of limited use to a cracker.

Always back up before making changes.

Link to comment
Share on other sites

what if file_manager.php is needed?

i have a client that needs it because he doesn't know anything about FTP and FTP program

so it's easier for him to go thru the file_manager.php

so no solution for him? just learn how to manage a FTP with a FTP program?

file_manager.php is kind of "native" script of OSC and no one can fix it?

fixing a bug by delete a file doesnt fix anything ....

Link to comment
Share on other sites

Do not use file manager, its a security risk & damages files, best removed.

 

http://www.oscommerce.info/kb/osCommerce/Common_Problems/15

 

Is it a good idea to let customers use a application that you know could damage the site when they use it.

 

There are alternatives if u search

Sam

 

Remember, What you think I ment may not be what I thought I ment when I said it.

 

Contributions:

 

Auto Backup your Database, Easy way

 

Multi Images with Fancy Pop-ups, Easy way

 

Products in columns with multi buy etc etc

 

Disable any Category or Product, Easy way

 

Secure & Improve your account pages et al.

Link to comment
Share on other sites

  • 2 years later...

The latest version 2.3.1 does not have this vulnerability. (Also 2.3.1 does not have a file manger)

Link to comment
Share on other sites

what if file_manager.php is needed?

i have a client that needs it because he doesn't know anything about FTP and FTP program

so it's easier for him to go thru the file_manager.php

so no solution for him? just learn how to manage a FTP with a FTP program?

file_manager.php is kind of "native" script of OSC and no one can fix it?

fixing a bug by delete a file doesnt fix anything ....

 

Well, osC's File Manager was poorly written and insecure from the get-go. All of its functionality may be found in any hosting service's "control panel" and a good FTP client such as Filezilla. Given the choice of trying to fix osC File Manager's numerous problems, it was easier just to tell people to use their hosting service's built-in tools to accomplish these tasks.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...