JetPack and TwentyFifteen Vulnerable to DOM-based XSS

Any WordPress Plugin or theme that leverages the genericons package is vulnerable to a DOM-based Cross-Site Scripting (XSS) vulnerability due to an insecure file included with genericons. So far, the JetPack plugin (reported to have over 1 million active installs) and the TwentyFifteen theme (installed by default) are found to be vulnerable. The exact count is difficult to grasp, but both the plugin and theme are default installs in millions of WordPress installs. The main issue here is the genericons package, so any plugin that makes use of this package is potentially vulnerable if it includes the example.html file that comes with the package.

DOM-based XSS

The XSS vulnerability WordPress is experiencing is very simple to exploit and happens at the Document Object Model (DOM) level. If you are not familiar with DOM attacks, the OWASP group explain it well:

DOM-Based XSS is an XSS attack wherein the attack payload is executed as a result of modifying the Document Object Model (DOM) “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

Read More

WP Symposium – Zero Day Vulnerability Dangers

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 knew 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

This is the kind of discovery that keeps us up late at night, and why we invest heavily in our routine 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?

The Art of Website Malware Removal – The Basics

When talking about defense against malicious hacks, the attack vector is a common topic for Information Security (InfoSec) professionals. The primary concern is to understand the anatomy of the attack and prevent it from happening again. However, there is a less glamorous task that must take place once an attack vector is exploited; that is malware removal (a.k.a., cleaning up the mess).

The task of cleaning, removing, malware often falls on your shoulders as the website owner / administrator.

While unfortunate and frustrating, malware infections greet us like flat tire or a burst water pipe in the middle of the night. It’s never expected, it’s always while you are sleeping and it’s impacts are felt greatly. They hurt search engine rankings (i.e., SEO), spread malware to users, introduce branding issue, cause websites to be shutdown and a slew of other less than pleasant experiences. The important thing to note though, is that like other problems that surprise us in life, malware infections must be dealt with quickly and correctly. You cannot drive your daily commute on a flat tire, nor can you operate a website that is infected with malware.

Malware needs to be removed as soon as possible before the consequences begin to amplify themselves and their impacts.

Four Common Malware Families Affecting Websites

Like the real-life pests and diseases that they are named for, worms, viruses, and other types of cyber-menaces that have earned metaphorical aliases have many varieties, purposes, and ways to deal with different types of malware. The treatment of one kind of skin infection may have no effect when applied to another, and attempting to remove a hornet nest with the same caution as a bird nest would lead to disastrous results. The scenario is virtually the same when cleaning an infected website.

Due to the multitude of technologies, languages, frameworks and tools, code on the web can be as diverse as human culture itself. This brings about millions of possibilities to achieve very similar goals in software development. Malware takes on this model, and rears it’s ugly head in many different forms, functioning to serve many different purposes.

1. Blackhat SEO Spam Injections

Everybody who reads this blog has seen it before: a website with some very out of place looking advertisements, that are usually of the pharmaceutical, pornographic, knock-off designer brand or fast-money lending nature. These websites have been hit by a criminal user looking to feed off of the website’s traffic in order to advertise for products and services that would normally be very restricted or banned by most hosting policies. Using the victim website as a billboard, the hacker earns commission based income off of the number of clicks or forced redirects that are generated because of the injected malware.

The malicious code that causes injected spam content can be structured in several ways, placed in many locations, or be encoded in a multitude of ways to appear like normal software. Because of this, it is very difficult to have an across-the-board detection method for all types of SEO spam. There are many varieties in the wild that infect websites every day. Furthermore, some infections are scripts can activate based on time or events on your site. These can constantly update posts and pages to display junk or redirect users to affiliate pages, even after you’ve done the work to get rid of it. This can cause a major strain on cleanup, so the best solution is to be prepared with a full backup. By updating to a recent clean version from before a successful attack, website owners can go back in time to a moment before the hack took place, and update their security measures to make sure their content is not overshadowed by blackhat SEO spam.

2. Phishing

Little do many webmasters know, but millions of websites across the internet have pages that definitely should not be there. These hidden pages are home to code that is crafted to resemble other websites on the Internet, like,,, Hotmail, Gmail, Facebook, and many others.

The hackers that put these pages on your site are using them to trick other users to mistakenly put their credentials into a form controlled by the hackers, instead of the official website they think they are sending their password to. This is the reason those policy memos from your bank are always telling you to thoroughly check the links you click when going to manage your finances, or that you should never click a link to go to your bank account from your email. Those links may actually be under the control of someone looking to steal your information, to then steal your money, from pages hosted on a website of an unknowing person, not actually looking to help criminals steal usernames and passwords.

3. Drive-By Downloads

Malware can be difficult to detect, and often employs social engineering tactics, or methods that trick users into playing into the clutches of the attacker. Forms, pop-ups, ads and other site functions can be compromised to force a user to click on something other than intended, or answer a question where the secret answer is actually Yes, I would like to download that .exe file.

These infections, called Drive-By Downloads, are incredibly dangerous to end-users, as they allow attackers to escalate their control from an infected website, to the potential administrative access of any computer that accesses that website. Once the malicious payload has been delivered to the victim user’s machine, it may activate automatically or wait to be activated by some other method before scraping the user’s machine of sensitive information, and sending that along with remote access privileges to a waiting attacker.

4. Backdoors

While some infectious files are meant to actively perform tasks, create spam or attack visitors, other types are meant to lay in wait, and appear only to the hackers that know they are there. These are called backdoor infections. These can lead to large scale attacks by allowing the attacker to build up a number of websites to use as attack surfaces. They can look very different in separate cases, but often have a similar function at the end of their task list: to provide the hacker with the access needed to control the website or server at any chosen time.

Backdoors can serve multiple purposes, ranging from being able to reinfect websites after cleanup, to linking the targeted site to a network of other sites used in DDoS attacks, or massive spam mail campaigns.

Scrubbing Away the Hacker Residue

Learning to deal with each type of malware infection individually is quite challenging at a technical level, but having a plan to get back to normal under any circumstance is important nonetheless.

If detection fails, a keen eye is needed to analyze website content, functionality and code for any signs of intrusion. Once a thread is noticed, it must be followed to determine where in the files or database that the malware located, so that it can be removed.

Once the code showing the infection (i.e., symptom) is removed you must ensure that you go through the rest of the website and remove / repair any backdoors or potential attack vectors. In further efforts to prevent reinfection, all software should be updated fully to minimize the chance of known vulnerabilities being exploited, and all passwords changed, to eliminate the risk that they were stolen during the attack.

It can always be assumed that a stable backup from before a time where malicious files or database entries existed on the server will solve almost any problem. It is therefore, extremely important to maintain backups that are scheduled to be made on a timeframe that will suit to overwrite the infected aftermath of a website. We’ve spoken about backups at length before, but it’s a necessity.

Contrary to popular belief, malware removal is not a Do It Yourself (DIY) project. It has affected the brightest developers and security professionals; it’s time consuming, and can be the cause of many restless nights and days. If you find yourself in this predicament know that there are professionals out there that specialize in this work.

Remember, website infections are like Icebergs, they only display 10% of the problem.

Most Common Attacks Affecting Today’s Websites

New web-based attack types and vectors are coming out every day, this is causing businesses, communities and individuals to take security seriously now more than they ever have in the past. This is a huge win for the World Wide Web and it’s a trend that is pushing technology further towards more robust and securely developed web applications.

The recent discovery of another vulnerability in SSL has led thought-leaders and developers to immediately phase out the weak aspect of the protocol. The implementation of SSLv3, and its exploitable nature, gained its marketable canine acronym POODLE for describing the ability to force users to downgrade their encryption to a breakable standard, revealing their sensitive data as if it were being passed in clear text.

Read More

WordFence WordPress Security Plugin Pushes a Security Update

If you are one of the many users of the WordPress Security Plugin, WordFence, we highly encourage you to update. They recently pushed out a security update that could be affecting your install. It is important to note however that what is interesting about this release is that it was actually a Low Severity issue. What’s remarkable however is both their immediate response to the issue, and the detail they provide in their change log.

This is a very good way for a development firm to respond in the event of incidents. Snippet from their change log:

Read More

Thoughts on WordPress Security and Vulnerabilities


As avid readers of this blog know, we’ve discovered or written about multiple vulnerabilities within the WordPress ecosystem over the last couple of weeks specifically relating to popular plugins. MailPoet and Custom Contact Forms drove the bulk of the engagement, but those using WPTouch, TimThumb and vBulletin were also made aware of vulnerabilities.

If it seems like most of the problems occur with plugins, it’s because it’s the truth. In fact, it’s not just restricted to Plugins, but includes Themes and any number of other extensions or services that a website might make use of. This actually applies beyond the realm of WordPress and is something that all website owners should be mindful of.

Read More

WordPress and Drupal Core Denial Of Service Vulnerability – Moderately Critical

Both WordPress and Drupal are affected by a DoS (denial of service) vulnerability on the PHP XML parser used by their XMLRPC implementations. The issue lies in the XML entity expansion parser that can cause CPU and memory exhaustion and the site’s database to reach the maximum number of open connections. That will cause the vulnerable site (and server) to go down for a period of time, hence affecting availability of your website.

Kudos to the security teams from both platforms for their collaboration and synchronized disclosure.

The bug was discovered by Nir Goldshlager and disclosed on his blog at BreakSec. He goes onto to explain the specifics of the issue:

Read More

Yoast and Sucuri Partner to Create a Safer Web

Yoast and Sucuri

We’re very excited to finally talk about a partnership that’s been in the works for a few months and in light of the serious nature of the Security in the WordPress ecosystem it only makes sense. It also comes at a time where we, as an organization, are reinvesting into Website Security space through extensive research which gives us a better grasp of the real threat landscape looks like for website owners.

Benefits of the partnership can be seen and felt by both organizations. Over the past 3 weeks we, Sucuri, have been undergoing big changes in our branding and messaging and many have already started to comment. For Yoast, security audits have begun and updates have been proactively pushed to their users. It is our belief that through this partnership we will be able to make a bigger impact to the online threats website owners face on a daily basis. For those wondering, none of Yoast’s plugins or updates to them that we’ve audited contained any serious vulnerabilities.

This post will talk to the specifics of the partnership and how we will be working together.

Regular Security Audits Drive Customer Trust in Yoast Plugins

Read More

Security Issue on vBulletin uploader.swf

The vBulletin team recently disclosed a XSS (cross site scripting) vulnerability in the uploader.swf file that is included by default on vBulletin 4 and 5. This file comes from the YUI library that is not supported anymore, so the vBulletin team is recommending everyone remove that file asap from their installs.

This is their full note:

Read More

Zero Day Vulnerability in OpenX Source 2.8.11 and Revive Adserver 3.0.1

If you are using OpenX or the new Revive Adserver (fork of OpenX), you need to update it ASAP. Florian Sander discovered a serious SQL injection vulnerability that affects all versions of OpenX and all versions of the Revive Adserver. From the Revive advisory:

An SQL-injection vulnerability was recently discovered and reported to the Revive Adserver team by Florian Sander.

The vulnerability is known to be already exploited to gain unauthorized access to the application using brute force mechanisms, however other kind of attacks might be possible and/or already in use. The risk is rated to be critical as the most common end goal of the attackers is to spread malware to the visitors of all the websites and ad networks that the ad server is being used on.

The vulnerability is also present and exploitable in OpenX Source 2.8.11 and earlier versions, potentially back to phpAdsNew 2.0.x.

The XML-RPC delivery invocation script was failing to escape its input parameters in the same way the other delivery methods do, allowing attackers to inject arbitrary SQL code via the “what” parameter of the delivery XML-RPC methods. Also, the escaping technique used to handle such parameter in the delivery scripts was based on the addslashes PHP function and has now been upgraded to use the dedicated escaping functions for the database in use.

We highly recommend anyone using OpenX to upgrade to the latest Revive version, or as a temporary fix, remove the file “www/delivery/axmlrpc.php” from your installation.

Clients using our CloudProxy Website Firewall are already protected against it. If you want to protect your OpenX / Revive install, you can sign up for CloudProxy here.