Backdoor found in OpenX open source version 2.8.10 – some thoughts

Two days ago, Heise (the German news and IT firm) reported that a backdoor was found in the prominent advertising platform OpenX.  (German link here, and I leave translation to the reader.)  The backdoor itself was injected into a somewhat obscure flowplayer javascript file, with obfuscated php hiding the fact that it was a remote code execution bit of php.  With this code there, it would be trivial for a solid hacker to build a shell for the server and completely compromise it. The question which immediately came up for me was, Huh?  Since when is a webserver interpreting a javascript file as a php file?  I doubted that it is typical for web servers to be configured to have .js files interpreted by the .php interpreter first, then sent to the browser.  However, none of the technology reporting said anything about how the OpenX backdoor was getting the .js file to be executed as .php. A couple examples of the simple explanation that .js files just obviously might house some .php and invoke it: http://arstechnica.com/security/2013/08/backdoor-in-popular-ad-serving-software-opens-websites-to-remote-hijacking/ http://nakedsecurity.sophos.com/2013/08/07/openx-ad-servers-pre-compromised-official-distro-contained-remote-code-backdoor/ But web servers don’t do that.  So there must be something else in the OpenX code which allows javascript to be interpreted as php.  One clue was that the original Heise article said: Die Datei wird durch einen Aufruf von require_once() aktiviert 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...