Are these scripts safe As I Found this HackerAlert?
libby90
2010-03-20 18:57
I found these 2 resources on this script that I am a bit concerned about:
here are the 2 links so that you can simply read them and get back to me rather then me trying to explain it all here.
(1)http://seclists.org/fulldisclosure/2009/Nov/258 Quick.Cart and Quick.CMS CSRF Vulnerabilities
(2)http://www.milw0rm.com/exploits/2719
Basically they are saying that these script files are not safe to run???
I was going to be using your free version before I make the purchase to upgrade these scripts I need some more clear help with these 2 links that are reporting these issues please?
Also are you safe to run these scripts with the 755 folder version instead of the 777 CHMOD version as I know that the 777 CHMOD is not a safe option.
thank you and I hope to here back soon on this matter before I can make my purchase here for these scripts.
» Quick.Cms v2.x
libby90
kalanta
2010-03-20 21:09
The scripts are really safe. Use 777 for config/, db/, files/ and lang/.
libby90
2010-03-20 22:12
HI kalanta,
thank you for the reply back into this concern, however did you have a look at the links that I posted that said that there was hacker issues with the scripts?
If so are these findings still true for the current version of these scripts please?
Also Can you please be good enough to reply back to let me know what version is the safest version then to use here please?
the other issue is that my hosting provider does not allow 777 folder or file permissions,
so will these scripts run under the 755 Chomod and function still properly?
I saw that someone was selling this script but it was labeled under this here at this website :http://www.highgravity101.com/vortex.htm
but when you go to view one of the websites previews it showes this part at the footer:
powered by Quick.CMS which is how I found this forum and help section for these scripts.
Here is the website of one of those sample sites so you can see what I mean :http://www.highgravity101.com/Clickbank/?clickbank-inner-circle-review,1&Keywords=clickbank,%20Clickbank,%20affilia te%20marketing,%20affiliate%20sales,%20affiliate%20promotion,%20ebook,%20e-book
I thank all who can further help me get this sorted soon so I can start to work with these scripts knowing that they have been fixed.
Can someone please give an update to this security issue.
I have just had to take a site down as someone was able to place brute force php files in the directories that were all 777, if this cannot be fixed then the Quick.CMS system is unsecure for everyone.
these seem to be serious reports. I will look into them more but not fix them yet. At least 1 issue could be easily mitigates so I believe guys from opensolution.org are on top of this.
one thing that is possible to do is to set up your website, create your language(s) and then set the directories config/, lang/, db/ to something else than 777. Their files can stay 777 but there is no need for these dirs to be 777 once the QC/QCMS system is set up.
The directory files/ is different, here it needs to stay 777, as well as its subdirs.
GWMBOX: please check the possibility of computer hijacking attack where an FTP access/password could be stolen. This is the most common case and it's highly unprobably that someone would just hack his way in some other way.
Thanks beholder, I will check with the client re the possible computer hijacking. I have also changed the directories to 755.
Quick question, could I move all the usual 777 directories out of public_html and put them out of the web space and thus not have them web accessible directly... would this solve this issue? I might try it on a test site and see how that goes.
Either way there needs to be a better system implemented where the need to have folders set at 777 is removed and no longer needed. No directories should need to be world writeable.
I'd do just a htaccess protection that's very affordable programming-wise and should cover your ass quite well.
Here is a piece of an advice ( from following website http://forum.joomla.org/viewtopic.php?f=267&t=288032 ): On some shared servers, usually the ones that run php as an apache module, you will be forced to use 777 as the permissions level on certain directories if you want to allow authors to be able to upload images or other media using Joomla.
You may create an .htaccess file with the following code in it, code: # secure directory by disabling script execution AddHandler cgi-script .php .pl .py .jsp .asp .htm .shtml .sh .cgi Options -ExecCGI
Place the saved .htaccess file in any directory that need the 777 permissions for Joomla to function properly. The .htaccess prevents code from being run from the directories it is placed in. It does not prevent someone from uploading code to the directory. This is safer than running an unprotected directory at 777 and is simple to do.
Another method is to remove (delete) the directory with the owner (FTP user account) and recreate it through extExplorer for example or another Joomla file manager. Permissions can then be set to 755 as the owner of the new directory will be apache. This does open another can of worms in that your ftp user will have limited permissions on the directory.
Another option is to request tech support to move your site to a server that runs php as a cgi and uses something like suExec to control access. Then you can set permissions properly at 755 for directories and 644 for files. The webserver then will not have permission problems when accessing directories and files.
----------
BTW, do you have or can you show samples of how your client's site was attacked? I mean the rogue php scripts that resided in the directories mentioned. Along with their location and possibly attack description, if you can add that.. Perhaps it could show us how to protect against threats like these.
It would be also nice (and most probably helpful in this problem) if QC/QCMS would require the main QC dir to be set to 777, the script would create the files/ and db/ and other dirs and thus would be an owner - it would set its permissions to 755 and then it would prompt user to set main dir to 644 or whatever it was set before. Not sure if it's actually possible but after studying this problem for a while it seems to me as a logical solution.
The files were named with random numbers and one was placed in every 777 directory, they were brute force php files used to attack the server and obtain access. They have now all been deleted.
Cheers for the info though as that helps with another site (joomla)
