14 DAY TRIAL // The OpenCart development team has finished assessing a series of unpatched vulnerabilities discovered by a group of security researchers as part of an educational project. The conclusion reached is that most of the bugs can be mitigated without the Web application requiring any patching.
For example, one medium and two high risk bugs, which according to the researchers allowed for arbitrary code execution, were located in the installation script. According to Daniel Kerr, the lead OpenCart developer, these issues can be mitigated by simply removing the install directory, as recommended during the installation process.
"Even if the installation directory is still left on the server the database details must validate before anything is written to the config files. Arbitrary code would not run because it would not match the db hostname, db, username and password," he explains in an email to Softpedia. We haven't checked this back with Mr. Eduardo Vela and his colleagues, who reported these bugs, so we'll have to take the developer's word for it.
However, we still feel that it would be sensible to actually enforce the removal of the install directory. A simple check could be implemented to prevent OpenCart from running after installation until this folder is removed. A message with clear instructions could be displayed to instruct users of what they need to do. Relying on users to follow recommendations is not really a security principle.
There is another possible arbitrary command execution issue, which stems from failure to properly sanitize input and is marked as high severity by the researchers. However, Mr. Kerr stresses that this is a bogus report and that he couldn't replicate the issue, despite trying numerous times.
The fourth and final high risk bug is a cross-site request forgery (CSRF) vulnerability that Mr. Kerr claims to have already fixed in the latest version of OpenCart. However, his comments regarding this flaw are intriguing. "It's also rated as high even though to pull [off] this type of hack [would be] very hard. A store owner would have to be logged into their administration of their site and at the same time visit another site with the exploit in."
From our experience and the numerous incidents we reported over time, tricking someone into visiting a malicious page while having an active session on another site is not hard at all. It is actually quite the opposite and it happens very often.
Another medium-risk issue involves passwords being sent in unecrypted form during the login process, which makes them succeptible to network traffic sniffing attacks. Mr. Kerr had this to say about it: "Well this is why SSL was invented and if you'r on a unknown network and don't have SSL on your site then don't login to your store admin."
There are two more vulnerabilities which Mr. Kerr rejects as invalid, because according to him they can't be exploited to do what the researchers claim. One is the ability to read template (.tpl) files as plain text, which the OpenCart developer says doesn't have security implications and the other is apparently just a simple bug and not a vulnerability.
Finally, Daniel Kerr rates six other path and server information disclosure flaws as low risk. According to him, four can be mitigated by turning off error reporting, one by using SSL to encrypt the connection and one by making sure the server correctly handles .ini files.
Regarding this whole incident, the lead OpenCart developer commented: "Mr. Vela contacted me informing me that OpenCart has been selected to receive free security auditory in the next couple of months by elhacker.net. I believe Mr. Vela's decided to do this to get some sort of recognition among the security blog sites after reading that I told another security researcher to stop wasting my time. "After I told him not to bother me and my community he decided to put out a statement that he had found 14 vulnerabilities. After reviewing these vulnerabilities I have found that they have no credibility. Mr. Vela has not been able to show me any working hack that would compromise a user's site. "After I confronted Mr. Vela about the inaccuracies in his statement Mr. Vela said it was his team that had found the vulnerabilities and he had just graded them, there by trying to absolve himself of any responsibility."
Regardless of whether we agree or not with Mr. Kerr on the severity or importance of all of these issues, we are glad they were investigated and we thank him for keeping the best interests of the OpenCart community at heart. We consider this incident closed now and we think all parties involved got a fair chance to express their opinions, even though they still don't see eye to eye.
You can follow the editor on Twitter @lconstantin