Archive

Posts Tagged ‘malvertising’

Proofpoint.com misinforms their audience, makes false malvertising allegations

September 12th, 2014

On Sunday, Sep 7 2014, 11:10am CentralPark.com received a message from Wayne Huang (whuang@proofpoint.com) from proofpoint.com informing us that we’ve been hit by malware. To be more precise he was saying our Ad Server had been compromised. Here’s the entire message we received:

I’m writing to inform you that your website has been hit by malware. Your OpenX ad server, used to serve out the ads on the upper-left corner of your website, has been infected.
Specifically, it is this URL: [url removed for security reasons]
Please react asap. If you need help you are welcome to reach out to me at whuang@proofpoint.com.

We take security issues very seriously, so the entire CentralPark.com dev team investigated immediately and our answer came only a few hours later, on Sunday, Sep 7 2014, 5:04pm:

Thank you for your report. We’ve checked the files and the database, plus the output itself, and could not find any malware or suspicious code. Could you provide more details so we can further investigate this?

And that was the entire conversation. Instead of replying and trying to back their malware report with details, they chose to write an article on their blog, with the following title: “No walk in the park: Centralpark.com malvertising highlights ongoing OpenX infection” (http://www.proofpoint.com/threatinsight/posts/no-walk-in-the-park.php)

The dev team has started another investigation and still couldn’t find anything suspicious.

First of all, their intro sentence “Proofpoint researchers have detected that the web site centralpark[.]com has been hit by malvertising and has been actively serving malware to visitors.”. If that was true, Google would have banned the website after only a few hours. But they didn’t, because there was no malware as we’ll explain below.

The ad server version was old indeed and we’ve taken steps to alleviate this. The zero day vulnerability (CVE-2013-7149) allows an attacker to execute arbitrary SQL code. This means they can only manipulate the database, not the files. We’ve thoroughly checked the database for patterns of known injections and we couldn’t find anything. But let’s move on to the next step in their investigation, maybe it offers more insight – we’ll skip over the stats; they’re correct, and OpenX is known to have a poor security standard.

Here’s a screenshot of where they claim the malware was injected. It’s pretty techy, but we’ll try to simplify it.
09082014-6img

 

The javascript code that serves the ads seems to have a prepended malicious script that points to sar[.]ttsselfstufy[.]com. We can trust the rest of the article which explains what malware is being pulled onto the client computer, however, the injected code can be there only if that code was in the database. The only place where this could’ve been in the database doesn’t allow anything to be written. It’s a “prepend” field and that has been disabled, exactly for this reason. In fact, our entire openx installation has been hardened as much as possible to withstand most of the common attacks. We’re not saying we’re 100% bulletproof, no one is, but chances for the ad server to be infected are quite low.

We also ran a scan on virustotal.com, in case we were missing something. The report can be viewed here:
https://www.virustotal.com/en/url/533d75b592d660e015ad3281ef15d6b7fc977a46d8f096cf7fc81dde7d02b78c/analysis/

Then we ran it on quttera.com too, since they reported suspicious files:
http://www.quttera.com/detailed_report/www.centralpark.com
Turns out their warnings are just a bug in the parser, probably because of our old js packer function.

We took a step even further and analyzed the requests using urlquery.net:
http://www.urlquery.net/report.php?id=1410462359637
Nothing here either.

We appreciate Proofpoint’s effort to notify us of a potential threat, and had their been an actual malvertising breach we would have worked to fix it immediately. However as the accusations are clearly inaccurate (and frankly slanderous) we trust they will do the right thing and pull the article from their blog immediately.

 

Security , ,