Our friends at SpiderLabs released a blog post today talking about the latest WP Symposium file upload vulnerability, and the attacks they have been seeing in the wild.

This specific vulnerability was disclosed publicly Dec 11th, and attacks against it have started. If you use this WordPress plugin we encourage you to update your plugin.

Scan Timeline

This plugin is not one of the more popular ones, it has some 150,000 downloads, but we decided to look at our internal data threads to see if we could verify SpiderLabs findings.

Indeed, it was/is happening.

Filtering through this month, December, we see a large increase in the number of scanners looking to see if the plugin is configured on websites:

It went from 0 scans pervious months, to a couple early December, to sharp increase after it’s disclosure on the 11th of December. Since, the number of scans have been growing, with a slight pause for the holiday’s (guess everyone needs time to open gifts). As this plugin is not widely use, most of the scan attempts are generating mostly Not Found error (404 pages – plugin no found).

Exploit Attempts Timeline

The scan attempts timeline is not that interesting per se.

Yes, we started seeing a few more scans before it was publicly disclosed, but it doesn’t tell us much.

However, if a site is found to be using this plugin via one of these scan attempts, the next step is the exploit.

And what was really interesting to us is that when we looked at this specific exploit payload in our logs, we found this (look at December 1st and 9th):

What you see is that on December 1st, (11 days before the public disclosure), one of our sites was attacked using this specific exploit. And again on the 9th (2 days before disclosure).

Someone out there new of this vulnerability and was actively attempting to exploit it. Whether it was made public via underground forums, they are the ones that found it or some other means. Either way, we were dealing with an active 0-day vulnerability.

The website targeted in our stack never used this plugin, so they were naturally protected against it. Regardless though, even if they had the plugin, our Website Firewall would have blocked it through one our Virtual hardening signatures:

2014-12-01 19:24:10: 191.181.x.x – – “POST /wp-content/plugins/wp-symposium/server/php/index.php HTTP/1.1″ 403
BLOCKREASON:VIRTUALHARDENING

This is the kind of discovery that keeps us up late at night, and why we invest heavily in our routing audits. What if it happened in a plugin we were actually using on our own blog? Our WAF blocked it this time, but if it was another vulnerability? Would we block as well? We have many sleepless nights worried, and it’s the foundation of why and what we have built.

This is a classic example of what attackers could do with your website, what are you doing to protect yourself? What are you doing to make sure that website owners don’t abuse your websites resource and reader trust? How are you staying ahead of the threats?

Via Sucuri.net