Symphony.

@iPOTS,

Sorry to hear that. Are there any specific easy-to-spot symptoms of this you could describe, so we could check our own installs? That might help indicate/discount Symphony as the culprit.

edit: Beat me to it; see previous comment…

We had something similar happen last year here at work. The guys who managed our servers claimed over and over that it was Wordpress, or that PHP was inherently insecure. We did everything imaginable to lock down Wordpress and tighten up our PHP environment. Injection kept happening. Finally, someone listened to me and we moved our sites to a different host. Problem solved.

I’m not saying that’s what’s happening here. Just, you know, FWIW.

An injection attack can happen in a couple of ways.

1. Someone has the ability to access and manipulate the file system directly. This can be achieved either directly, E.G. someone has your login details, or indirectly via a shared host exploit. Are you on a shared host or dedicated?
2. Someone plants a malicious script on your server, somewhere, that can be accessed remotely. This script reveals files on the system it infects allowing access. As we’ve seen in Symphony 1.7, this can happen via insecure upload scripts.
3. A security flaw in some software on the server allows the actual injection to take place.

3, in PHP at least, would require the use of file_put_contents() or fwrite(). I have looked at all the core code and no use of those functions would allow the arbitrary injection of code into the func.utilities.php file. Where they are used, either the data being written cannot be externally influenced, or the destination cannot.

2 has happened in the past, but the exploit revolved around a malicious user using a MySQL injection attack to gain a valid cookie and thus access to the v1.7 file manager. This allowed the uploading of any arbitrary file, but not the injection of code. The exploit was fixed some time ago. In v2, all uploading done via the core is strictly bound to the /workspace folder. So, feasibly the only way this could be exploited is if someone managed to upload a script to /workspace which could then be used for malicious purposes. You’ve already said there is nowhere on the front-end that uploading can take place correct?

Number 1 is not something we can really do anything about, other than to say make sure your permissions are tightened up so writing can only happen by the file owner. Also, if you are on a shared host, it is quite possible the attack is coming from another user of the hosting, or exploited software on their side.

Hope this helps.

Actually, 3. could also require the use of include($file) in cases where the attacker can modify $file.

Update: I’ve reviewed the content and permissions of the entire server. I didn’t find any malicious scripts however i did find one folder full of html files which i removed. This folder was located in the “extensions” folder.

I also found the the “uploads” folder (accessible only via Symphony’s CP) had 777 permissions. I corrected this.

What extensions do you have installed?

Installed and Active

• Advanced Symphony Database Connector (ASDC)
• Classicist: Library
• Export Ensemble
• Field: Page Select Box
• Field: Select Box Link
• Filter: Email Template
• Global Resource Loader
• Google Custom Search Engine
• jQuery Date Picker
• Maintenance Mode
• Publish Filtering
• Textile Text Formatter

Installed and Inactive

• Field: Image Upload & Preview
• Markdown and SmartyPants Text Formatter
• Yahoo! Search BOSS

Update: Injected attack again, this time directly into the index.php file.