trogan Posted August 31, 2009 Share Posted August 31, 2009 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 More sharing options...
germ Posted August 31, 2009 Share Posted August 31, 2009 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 More sharing options...
SambaMambo Posted September 1, 2009 Share Posted September 1, 2009 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 More sharing options...
germ Posted September 1, 2009 Share Posted September 1, 2009 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 More sharing options...
SambaMambo Posted September 1, 2009 Share Posted September 1, 2009 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 More sharing options...
germ Posted September 1, 2009 Share Posted September 1, 2009 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 More sharing options...
♥ecartz Posted September 1, 2009 Share Posted September 1, 2009 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 More sharing options...
SambaMambo Posted September 2, 2009 Share Posted September 2, 2009 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 More sharing options...
spooks Posted September 2, 2009 Share Posted September 2, 2009 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 More sharing options...
Adrian Bardt Posted April 21, 2012 Share Posted April 21, 2012 Im reading this .... thinking.?.?.?..?.?.... you guys have fixed this ?..... right? Link to comment Share on other sites More sharing options...
♥toyicebear Posted April 21, 2012 Share Posted April 21, 2012 The latest version 2.3.1 does not have this vulnerability. (Also 2.3.1 does not have a file manger) Basics for osC 2.2 Design - Basics for Design V2.3+ - Seo & Sef Url's - Meta Tags for Your osC Shop - Steps to prevent Fraud... - MS3 and Team News... - SEO, Meta Tags, SEF Urls and osCommerce - Commercial Support Inquiries - OSC 2.3+ How To To see what more i can do for you check out my profile [click here] Link to comment Share on other sites More sharing options...
kelagedart Posted April 25, 2012 Share Posted April 25, 2012 The above links are broken. Are there any working links to updating and securing 2.2rc2a? Mine is a fully functional and heavily modded site so I wont be updating anytime soon.... Link to comment Share on other sites More sharing options...
Guest Posted April 25, 2012 Share Posted April 25, 2012 @@kelagedart This is the only link you need to read about Rc2a http://www.oscommerce.com/forums/topic/313323-how-to-secure-your-oscommerce-22-site/ Chris Link to comment Share on other sites More sharing options...
MrPhil Posted April 25, 2012 Share Posted April 25, 2012 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 More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.