A trojan had infected their server and was causing the problems. It affected PHP code, but was not a specific attack against ocPortal – all PHP code on the server was infected, not just ocPortal's. So we have no reason to believe there is a security hole in ocPortal, it was likely a problem at server-level, or in one of the other scripts on the server.
As a little project during my Christmas vacation I decided to reverse engineer it inside a sandboxed virtual machine, because it was hard to see what it was doing. It was running through several layers of obfuscated code, and the only realistic way to decode it was to make a modified version of PHP that spits out what was being run through:
- PHP: eval - Manual
- PHP: Possible modifiers in regex patterns - Manual
- PHP: file_get_contents - Manual (remote URL downloads)
The trojan was downloading HTML code from a series of domains registered from a country which has been in the news this year (the "home server"), and then injecting them into the footer of the normal code the infected website producced. It sent various details about the user visiting the site, and either got a payload from the home server, or didn't. It was 'turned off' for the IP I was testing with, but I assume it turned itself on for particular interesting target IPs (perhaps cyberwarfare targets?), or perhaps was turned off prior to a mass activation.
It had clearly been coded to operate under-the-radar:
- Highly obfuscated code that needed C-programming skills to get past
- Coded to only run for user-agents claiming to be IE
- Coded to not run for search engines claiming to be IE, to ensure there was no easy way to index what servers were infected
- Targeted to specific website visitors, not everyone
In the case of this particular infected site it didn't work, because the trojan code assumed a PHP extension was installed that was not installed. So they slipped up, and it was very much over the radar, and I was able to analyse it. I have not mentioned the particular country involved, or any exact details, because it could easily have been faked, and I don't particular want to get in the middle of someone's international cyberwarfare exercise .
- Be a bit paranoid. Make sure your servers are secure. Cleaning everything out is a real pain. In this case there was no evidence of direct victimisation of the infected server (stealing user details etc), but that could have easily been different if the hacker had different motivations.
- In our modern world of "cyberwarfare", innocent servers may be collateral damage, used as pawns for broad-but-targeted attacks.