Security compromised on a Concrete5 website
Permalink
Hello,
A site running concrete version 5.4.2.2 has been found to have been compromised and trojans and malware files placed within the files. From what I can gather, this would not really be possible as Concrete5 is very secure. I have a question, the website was running a lower version and then upgraded. As the upgrade keeps all the old files and just adds the new ones in the /upgrade path, could/would it be possible that the security flaws from the older versions be the back-door they would have been able to use to get in?
I know there could have been many other reasons and different avenues that allowed them to achieve this, but from what I can gather on the subject (from a little bit of reading) version 5.4.2.2 had security fixes in it to tighten the security.
Does this sound probable/ at all possible for how it could have happened? I think, it was originally built with version 5.4.1.1
A site running concrete version 5.4.2.2 has been found to have been compromised and trojans and malware files placed within the files. From what I can gather, this would not really be possible as Concrete5 is very secure. I have a question, the website was running a lower version and then upgraded. As the upgrade keeps all the old files and just adds the new ones in the /upgrade path, could/would it be possible that the security flaws from the older versions be the back-door they would have been able to use to get in?
I know there could have been many other reasons and different avenues that allowed them to achieve this, but from what I can gather on the subject (from a little bit of reading) version 5.4.2.2 had security fixes in it to tighten the security.
Does this sound probable/ at all possible for how it could have happened? I think, it was originally built with version 5.4.1.1
On a technical level it's worth pointing out that nearly every PHP file concrete5 uses has the following as the first line of code:
This means that the PHP scripts can ONLY be executed if the request has gone through the proper request path (using /index.php), the only way C5_EXECUTE gets defined.
So the old concrete5 files on the server simply can't be run directly, as this line thwarts that attempt.
It's a requirement for packages in the marketplace to have this line in every php file too.
This means that the PHP scripts can ONLY be executed if the request has gone through the proper request path (using /index.php), the only way C5_EXECUTE gets defined.
So the old concrete5 files on the server simply can't be run directly, as this line thwarts that attempt.
It's a requirement for packages in the marketplace to have this line in every php file too.
Brilliant thanks very much for your responses this gives me something to go back to the client with at any rate, as well as being reassuring.
Thanks very much,
Kind Regards,
Thanks very much,
Kind Regards,
the issues in 5.4.x revolved around cross site scripting in the dashboard.
Things like: if you already have legitimate access to such and such
dashboard page, you might be add some code that would make a javascript
alert show up. These are important issues to clean up, but in themselves
hardly would give the kind of access needed to stick trojans in stuff.
Far more likely is someone had a FTP client with stored passwords in it,
and had malware on the same PC. There's a lot of stuff out there that will
catch a ride on a FTP connection and litter itself in anything that ends in
.php.
Clean it up, upgrade for good measure, and change your FTP passwords. Do
some social work on who has access to this site and how healthy their
workstations are.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz