A couple examples of the simple explanation that .js files just obviously might house some .php and invoke it:
Die Datei wird durch einen Aufruf von
which means, basically, that the rogue PHP function in the flowplayer js would be called and activated by a require_once() call. But where is that call?
The second clue is that there were actually three files involved in the intrusion, not one, and all three are critical to the intrusion. The somewhat unhelpful post from OpenX says to md5sum the following files:
The question then is: what is special about the other two files, and why would changing them be related to closing the backdoor?
player.delivery.php ver 2.8.10 has this line:
MAX_commonReadFile( $pwd . ‘/’ . $file_to_serve);
whereas vers 2.8.9 and 2.8.11 have:
echo file_get_contents( $pwd . ‘/’ . $file_to_serve);
Versions 2.8.9 and 2.8.11 don’t have this function, so it was also injected. Here is the function in 2.8.10, nestled between MAX_commonConvertEncoding and MAX_commonSendContentTypeHeader:
* A function to read a contents of SWF file
* @param string $file The path to SWF file to read
I’m puzzled currently about the [‘debug’][‘read’] item – it seems to be a way of throwing admins who are trying to trace problems with the site and thus who are in debug mode. Anyone else have an idea?
So, a few final thoughts:
- Currently we have no idea how the code got in there. I am looking forward to the article which traces the evolution of the code tree and speculates about the account(s) involved in these three code updates.
- Heise articles suggest that OpenX might be involved in some issues for a long time, including before this event. This backdoor was discovered only after 7 months. +1 for the person who finds any more problems in the codebase.