OpenX ad servers "pre-compromised" - official distro contained remote code backdoor

Filed Under: Featured, Malware, Security threats, Vulnerability

You don't always have to break into someone's web server to get them to deliver your malware for you.

You may be able to implant malware onto a site from which your victim fetches third-party content, and thus serve up your malware one step removed.

You compromise the third party's servers; they pass on the compromise to their customers; and those customers pass the compromised files onto users as they browse.

As you can probably imagine, ad servers are a prime target for this sort of indirect compromise: their whole purpose is to take content they didn't originate themselves and to push it out as widely as they can.

→ Malware foisted on you by an ad server can also be harder to track down and analyse because ads on a site are deliberately varied from visitor to visitor, and from visit to visit. So a URL reported as malicious by a user might have no (or different) malware when visited again later.

We've written regularly about this problem over the years, and the freebie ad server OpenX has popped up in the saga on numerous occasions.

Like running a self-hosted blog site, operating your own ad server is not an undertaking to be entered into lightly, not least because you represent potentially serious ill-gotten profits to a Malware-as-a-Service cybercrook.

So it was no surprise to see the Federal Office of Information Security in Germany (BSI, or Bundesamt für Sicherheit in der Informationstechnik), pushing out warnings about poisoned online adverts in January and in April 2013.

Once again, the BSI pointed the finger at OpenX installations:

In the past few days, online criminals have again carried out large-scale compromises of OpenX servers delivering advertising banners. The BSI already warned about this problem in January of this year.

Then, two days ago, the BSI issued another press release on this topic that may help to explain the prevalence of OpenX in reports about poisoned ads:

The BSI is reporting a backdoor in the current version of (2.8.10) of the OpenX ad server...The backdoor gives an attacker remote code execution of PHP programs.

If fact, it looks as though the Trojanised content was hidden in the OpenX distribution back in November 2012, ten months ago.

Update: OpenX emailed us at 2013-08-07T22:12Z to say that 2.8.11 is out, fixing the problem. Details of how to see if you were affected are on the OpenX forum.

What the Trojanised content looks like

I don't have a complete set of malicious files to show you - happily, 2.8.10 has been pulled from the OpenX download site.

But the core of the attack code is written in PHP and buried, rather unusually, in a JavaScript file that is part of a video player plugin (vastServeVideoPlayer) in the OpenX distribution:

PHP and JavaScript don't usually mix.

JavaScript is delivered to your browser and executed there in order to adjust the look and feel of web pages; PHP is processed on the web server, where it generates web content before it is served.

In this case, the JavaScript you see inside the PHP code fragment above is just there as a visual disguise, consisting entirely of comments that are ignored anyway.

With the comments chopped out, the PHP remaining reads like this:

And this boils down to a short but bitter payload:

This takes anything that attacker posts, via a form field called vastPlayer, reverses it, rot13s it [*], and finally submits it to the PHP engine for execution via the eval() function.

Ouch!

This implies that an OpenX server installed from the compromised 2.8.10 sources may very well have been pre-owned, ready for cybcercrooks to wade in and take over as soon as you made it live.

OpenX doesn't seem to have made any public announcement so far; indeed, the 2.8.10 version is still listed as the current official download from the OpenX servers:

However, as mentioned above, the files have been removed:

Suggestions for mitigation

In you are using OpenX, you can look for evidence of this compromise, or anything orchestrated similarly, by searching through the JavaScript files in your OpenX installation directory for embedded PHP code.

Since embedded PHP code appears between the delimiters <?php and ?>, looking for the opening delimiter is a good start:

$ grep -i '<\?php' $(find /your/openx/tree -name '*.js')

If you have 2.8.10, reports are (and the infected file I received suggests this) that the malicious PHP remote code execution fragment is in a file named:

plugins/
  deliveryLog/
    vastServeVideoPlayer/
      flowplayer/
        3.1.1/
          flowplayer-3.1.1.min.js

This file was unchanged from OpenX 2.8.9, so you can replace it from the 2.8.9 download if you like.

(The vastServeVideoPlayer is found inside the openXVideoAds.zip file in the etc/plugins directory.)

What next?

I hope this helps, and I hope even more that OpenX comes up soon with some official statements that will help OpenX users determine whether they were affected by this hole.

Sophos Anti-Virus on all platforms detects and blocks this malware as Troj/PHP-M.

, , , , ,

You might like

11 Responses to OpenX ad servers "pre-compromised" - official distro contained remote code backdoor

  1. Duncan · 252 days ago

    Hi Paul

    Our organization recently suffered a spike in ransomware attacks that all originated from users viewing youtube videos. I can't seem to find out if youtube uses openx or not. Do you think the two might be related?

    Duncan

    • Jhuliano · 251 days ago

      Hi! I'm not Paul but I'm going to try to answer this.
      I don't think that both events are related.
      Even if youtube used openX and they got hacked and started to deliver malware to users, it would get noticed and fixed pretty quickly (given the amount of people that access youtube and how Google manage their security).
      And also note that Google has its own platform for adds (since that is their main business), so I highly doubt they use OpenX.

    • Paul Ducklin · 249 days ago

      I doubt it.

      How do you know that the ransomware resulted from YouTube itself? If a common video was involved, perhaps there was some other common adjunct to watching the video? (Was it a link in an email? Did the video link somewhere else? Etc.)

  2. Carson · 252 days ago

    "With the comments chopped out, the PHP remaining reads like this:"

    Like what? I cannot see anything.

    • Carson · 252 days ago

      UPDATE:

      After posting the comment, deceiving white spaces appeared between the paragraphs. A right click revealed it was the pictures. Why this happens I have no clue. Maybe its my browser, maybe its the HTML.

    • markstockley · 252 days ago

      Hi Carson,

      Some readers appear to be having trouble seeing the images embedded in this article that show the code. We don't know why but we're looking into it. In the mean time please do try a shift+refresh to see if you can reload them.

      • Paul Ducklin · 247 days ago

        Hahahaha. We probably should have thought of this, but...

        ...you know when AdBlock claims on its that it "can do more than blocking ads [sic]"?

        Turns out to be true. Changing just the first five chars of the image filenames from "openx" to "op-x" seems to have counter-tricked AdBlock. So you should be OK now.

        PS. Thanks to our chum Graham Cluley for reporting this like a model customer! "I have noticed that turning off AdBlock seems to fix this problem," he said. From *there*, it was easy :-)

  3. Jhuliano · 252 days ago

    There is something that I don't get about this backdoor, normally PHP code wont get executed if it's inside a .JS file... You would need to set that rule in your .htaccess or in the webserver config files, I'm right?
    If that is right, I don't think that most servers are configured that way. I know it's still a backdoor, but, maybe the hackers didn't get much out of it.

    • Ben Scherrey · 252 days ago

      It's not PHP code hidden in javascript. It's something pretending to look like javascript code hidden inside obfuscated (but very executable) PHP code. PHP is a virus. Why are people still writing business code in it?

      • Paul Ducklin · 252 days ago

        Actually, it's obfuscated PHP code pretending to be Javascript (those comments that vanish) *hidden in JavaScript*.

        I wrote that the "core of the attack code is written in PHP and buried, rather unusually, in a JavaScript file," and then followed that remark with an image of *just the PHP* dug out of the surrounding JavaScript it's hidden in.

        I probably should have left some of the surrounding JavaScript in my image to make that clearer, or explained what I just said in the article itself.

        In short: the obfu-ed PHP you see above is not the entire malicious file, just a tiny part of it extracted for the article.

        But @Jhuliano is right: this dodgy JS file is not enough *on its own* to effect the compromise, since the flowplayer-3.1.1.min.js would not (as far as I can see) be pushed through the PHP engine by default.

        However, as I intimated in the article, I only have the dodgy JS file, and not the rest of the 2.8.10 distro...if anyone *does* have it, perhaps you can have a (careful :-) look to see if there are any unusual tweaks to config files or setup scripts in there that would cause the JS to be PHPed first.

      • Jhuliano · 251 days ago

        What you are saying is the exact same thing I said, it's PHP code inside a .JS file (javascript). But it's NOT very executable, you will need to do certain configurations to make that PHP code execute.
        And I don't get why you think that PHP is "a virus", I can do that exact same thing using .NET, Python, Java, you mention it... that has nothing to do with bad codding nor language weakness. It's just a random backdoor inserted in a open source project.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog