Received this message from my hosting company.
"We noted an attempt on your example.com site to exploit a known bug in OpenCart to upload arbitrary files. You can read more about this exploit here: http://www.waraxe.us/content-84.html to prevent this exploit from being possible we have moved this file as such:
catalog/controller/product/product.php -> catalog/controller/product/product.php.vulnerable
Please ensure you upgrade your OpenCart installation to the latest version so that you have the most up to date and secure installation available. Please do not move the vulnerable file back."
I am currently on 1.5.4, but because the I have no product.php I cannot see any product details.
1/Can I update just this file?
2/What is the best upgrade path to overcome this security risk?
3/Do i need to upgrade each revision i.e 1.5.4 . 1.5.? > 1.5.6?
4/Has this loophole been closed?
reading through the vulnerability report, most of it only works on windows. So the first thing would be, are you on a windows server with PHP < 5.3.4?
Short answers to your 1, 2, 3, 4 are yes, none, no, yes. Good on Linux with php.exe 5.3.27 but your support is not being entirely helpful (granted, it is at least alert to protecting the server). Which is your host (via PM if you wish)?
(1) In the /catalog/ tree there will be model/, controller/, language/, and view/theme/template/, each much the same array of subdirectories. Those subdirectories contain families of like-named files, such as ___.php and in the instance of template/ ___.tpl, such as product.php and product.tpl files. ONE of your product.php files was renamed, specifically your catalog/controller/product/product.php file of the set. That put an axe through your product displays. Your products and categories are still in your database.
(2) Pull up or download anew your version's .zip file, and from inside its /upload/ directory send back up FRESH copies of all of your several product.php files, one by one to where they individually belong. That will replace the renamed one, catalog/controller/product/product.php, with a known good one. Delete the bad file, it can be found, renamed, and reactivated if intrusion is still active! Support apparently did not appreciate the ease of doing that.
(3) There may have been something odd in your /download/ directory. If so, then what your support did not understand, apparently, is that /download/ can be invaded independently of OC versions, it can occur in any version, and that intrusion does not necessarily even occur via OC itself, such as where a whereami.cgi file (used in certain blogs, including wordpress) invites intrusion and ability to move through the disc tree via http in a browser. The vulnerabilities after intrusion (by whatever means entry may have been gained) work in several ways, including as seen in http://forum.opencart.com/viewtopic.php ... 60#p440953 and http://forum.opencart.com/viewtopic.php ... 60#p453513 among others.
(4) Delete anything odd that might be left in your /download/ directory. Obtain MarketInSG's free extension to protect that directory (it requires vqmod, install the latest version, and the one for OC, if you need to do so) -- read his http://forum.opencart.com/viewtopic.php ... 20#p403255 before you download and install (by simply uploading it) his http://forum.opencart.com/download/file.php?id=16828.
(5) Ensure that your directories are 755 and your files are 644. You can use FileZilla Client to chmod the numbers in two passes, 755 all directories and then 644 all files, each time recursing through subdirectories. Shift-Click at least two files in the root, right-click to reset numbers, choose all of which, and to recurse. Each pass will take several minutes. Be alert to any 777 that you cannot reset; 777 gives all rights to owner, system, and complete strangers. Be alert to any .dirname/ (with DOT) directories, especially that are 777. Let 777 guide your eye. Look for odd executable files such as default.php, grocery.php (no kidding), etc., those can be extremely vicious hacking consoles, thus far in the ranges of about 29 kb to 34 kb and 75 kb to 79 kb. Such consoles are operated by connecting either for only 2 sec. in http just to transmit commands, or for however long human curiosities might last in hands-on intrusion.
(6) The 2012 April http://www.waraxe.us/content-84.html views product.php on Windows, but that is scarcely the only index.php?route approach for the sake of 64 bit decryption in mime attacks, let alone on Linux. Attacking product.php appears to have been exceedingly rare even on Windows. Attacking by way of double- and multiple file extensions so as to turn fake text .jpg files into executable .php files that actually attack from within has come to light fairly recently, and while not common is no longer rare world wide even on Linux.
(7) You might care to read the currently 4+ pages of http://forum.opencart.com/viewtopic.php?f=20&t=98644
[I may add further links here this evening or in the morning, rather than separating them in another post.]
(8) If your server offers ModSecurity firewalling you may want to utilize it, it works very well in stopping suspicious code.
(1) In the /catalog/ tree there will be model/, controller/, language/, and view/theme/template/, each much the same array of subdirectories. Those subdirectories contain families of like-named files, such as ___.php and in the instance of template/ ___.tpl, such as product.php and product.tpl files. ONE of your product.php files was renamed, specifically your catalog/controller/product/product.php file of the set. That put an axe through your product displays. Your products and categories are still in your database.
(2) Pull up or download anew your version's .zip file, and from inside its /upload/ directory send back up FRESH copies of all of your several product.php files, one by one to where they individually belong. That will replace the renamed one, catalog/controller/product/product.php, with a known good one. Delete the bad file, it can be found, renamed, and reactivated if intrusion is still active! Support apparently did not appreciate the ease of doing that.
(3) There may have been something odd in your /download/ directory. If so, then what your support did not understand, apparently, is that /download/ can be invaded independently of OC versions, it can occur in any version, and that intrusion does not necessarily even occur via OC itself, such as where a whereami.cgi file (used in certain blogs, including wordpress) invites intrusion and ability to move through the disc tree via http in a browser. The vulnerabilities after intrusion (by whatever means entry may have been gained) work in several ways, including as seen in http://forum.opencart.com/viewtopic.php ... 60#p440953 and http://forum.opencart.com/viewtopic.php ... 60#p453513 among others.
(4) Delete anything odd that might be left in your /download/ directory. Obtain MarketInSG's free extension to protect that directory (it requires vqmod, install the latest version, and the one for OC, if you need to do so) -- read his http://forum.opencart.com/viewtopic.php ... 20#p403255 before you download and install (by simply uploading it) his http://forum.opencart.com/download/file.php?id=16828.
(5) Ensure that your directories are 755 and your files are 644. You can use FileZilla Client to chmod the numbers in two passes, 755 all directories and then 644 all files, each time recursing through subdirectories. Shift-Click at least two files in the root, right-click to reset numbers, choose all of which, and to recurse. Each pass will take several minutes. Be alert to any 777 that you cannot reset; 777 gives all rights to owner, system, and complete strangers. Be alert to any .dirname/ (with DOT) directories, especially that are 777. Let 777 guide your eye. Look for odd executable files such as default.php, grocery.php (no kidding), etc., those can be extremely vicious hacking consoles, thus far in the ranges of about 29 kb to 34 kb and 75 kb to 79 kb. Such consoles are operated by connecting either for only 2 sec. in http just to transmit commands, or for however long human curiosities might last in hands-on intrusion.
(6) The 2012 April http://www.waraxe.us/content-84.html views product.php on Windows, but that is scarcely the only index.php?route approach for the sake of 64 bit decryption in mime attacks, let alone on Linux. Attacking product.php appears to have been exceedingly rare even on Windows. Attacking by way of double- and multiple file extensions so as to turn fake text .jpg files into executable .php files that actually attack from within has come to light fairly recently, and while not common is no longer rare world wide even on Linux.
(7) You might care to read the currently 4+ pages of http://forum.opencart.com/viewtopic.php?f=20&t=98644
[I may add further links here this evening or in the morning, rather than separating them in another post.]
(8) If your server offers ModSecurity firewalling you may want to utilize it, it works very well in stopping suspicious code.
Thank you for such a comprehensive reply.
I decided a plan to upgrade without so much risk.
Backed up www directory and sql (sql through phpmyadmin as zip was only format that would restore to another database without error.
Renamed old www directory so http://www.old and then worked on a new copy restored of www
Create a new database similar name.
Edited config.php and admin/config change name database
Backup www directory renamed http://www.original restored copied backup of original site so had 2 copies on host http://www.original and http://www.actual
Restored sql database to similar named database. Tested it was connecting even dropped all restored again to make sure I was working on correct database not original
Uploaded opencart 1.5.6 install files without config and admin config and htaccess and ran www./install and upgraded
followed tips in upgrade file permissions, Applied updated template. install updated vqmod
Made sure everything was working was and most of it was left it at that Because of space left old http://www.original there on server if I run into any problems all I need to do is rename www and I will be back on older version of website.
I will look for the files you have suggested and check permissions I might even install the vqmod protection you outline. I do appreciate your response.
I decided a plan to upgrade without so much risk.
Backed up www directory and sql (sql through phpmyadmin as zip was only format that would restore to another database without error.
Renamed old www directory so http://www.old and then worked on a new copy restored of www
Create a new database similar name.
Edited config.php and admin/config change name database
Backup www directory renamed http://www.original restored copied backup of original site so had 2 copies on host http://www.original and http://www.actual
Restored sql database to similar named database. Tested it was connecting even dropped all restored again to make sure I was working on correct database not original
Uploaded opencart 1.5.6 install files without config and admin config and htaccess and ran www./install and upgraded
followed tips in upgrade file permissions, Applied updated template. install updated vqmod
Made sure everything was working was and most of it was left it at that Because of space left old http://www.original there on server if I run into any problems all I need to do is rename www and I will be back on older version of website.
I will look for the files you have suggested and check permissions I might even install the vqmod protection you outline. I do appreciate your response.
Jolly good.
In exporting db there are often two ways in the control panel to go, one is phpMyAdmin where you may not have choice between .sql and .sql.zip but the file will be zipped if it is "too" large, the other is usually called Backup and generates .sql.zip (or .zip) anyway. Then in importing it the .zip usually must end in .sql.zip to cue the software. There are two idiosyncrasies that can be overcome when need be, minor variations in .sql format or charset, and slight variations in .zip format or compression scheme. Some of that depends upon the mysql and phpMyAdmin versions on different servers. You got past those okay.
In exporting db there are often two ways in the control panel to go, one is phpMyAdmin where you may not have choice between .sql and .sql.zip but the file will be zipped if it is "too" large, the other is usually called Backup and generates .sql.zip (or .zip) anyway. Then in importing it the .zip usually must end in .sql.zip to cue the software. There are two idiosyncrasies that can be overcome when need be, minor variations in .sql format or charset, and slight variations in .zip format or compression scheme. Some of that depends upon the mysql and phpMyAdmin versions on different servers. You got past those okay.
Yes I had to test a few times to make sure the data would restore correctly. Yhe backup done through the admin pages wouldn't restore correctly. Doesn't give much confidence when applying changes like this. At least this way I have a working copy to fall back on. I was going to go xammp route, but hate trying to configure from local to www always seems to lock me out because of paths ect. So this time I took a little risk making sure I was working on correct db every time and did it on the server itself.
Thanks again for your help.
Thanks again for your help.
Welcome. There are reasons for preferring phpMyAdmin Export over OC admin System Backup for the reserve complete database in cases of disaster, but there are also reasons for having BOTH complete databases on hand. They afford more ways to cope with times when barriers to successful transfers are very teensy or just a single line. The free vqmod improvement by rph is worth installing before System / Backup or System / Restore is done. See backup_improved.xml (rph, http://forum.opencart.com/viewtopic.php ... 62#p401314, download at http://forum.opencart.com/viewtopic.php ... 62#p401314).
Who is online
Users browsing this forum: No registered users and 20 guests
