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.

Who’s Affected?

If your WordPress site allows users to post comments via the WordPress commenting system, you’re at risk. An attacker could leverage a bug in the way comments are stored in the site’s database to insert malicious scripts on your site, thus potentially allowing them to infect your visitors with malware, inject SEO spam or even insert backdoor in the website’s code if the code runs when in a logged-in administrator browser.

Multiple WordPress Plugins are vulnerable to Cross-site Scripting (XSS) due to the misuse of the add_query_arg() and remove_query_arg() functions. These are popular functions used by developers to modify and add query strings to URLs within WordPress.

The official WordPress Official Documentation (Codex) for these functions was not very clear and misled many plugin developers to use them in an insecure way. The developers assumed that these functions would escape the user input for them, when it does not. This simple detail, caused many of the most popular plugins to be vulnerable to XSS.

Continuous Web site defacements are being perpetrated by individuals sympathetic to the Islamic State in the Levant (ISIL) a.k.a. Islamic State of Iraq and al-Shams (ISIS). The defacements have affected Web site operations and the communication platforms of news organizations, commercial entities, religious institutions, federal/state/local governments, foreign governments, and a variety of other domestic and international Web sites. Although the defacements demonstrate low-level hacking sophistication, they are disruptive and often costly in terms of lost business revenue and expenditures on technical services to repair infected computer systems.

It appears that the author of that Flash malware continued with this method of infection. Now we are seeing more varieties infecting both WordPress and Joomla websites. Though it’s uncertain how many iterations existed in the wild when we first reported the issue, this time we’ve found a lot of websites where the infection looks similar:

Identifying the Flash Infection

The similarities are easy to spot once you know what they are. The malicious .SWF file is always stored in /images/banners/ and the file name is three random characters followed by .SWF with an ID parameter appended:Read More

The last 7 days have been very busy with a number of WordPress plugin vulnerabilities being disclosed on multiple WordPress plugins. Some of them are minor issues, some are more relevant, while others are what we’d categorize as noise. How are you supposed to make sense of all this?

To help provide some clarity on the influx of data, we want to provide some insights to help you, the website owner, navigate and understand these vulnerabilities. We will provide a summary and an explanation of the ones that matter and the ones that do not.Read More

Our research team was alerted to a possible malware outbreak affecting many WordPress websites. All the infections had a similar malicious iframe from “203koko” injected into the website. We were also directed to a forum thread where users were sharing their concerns and describing similar issues they were experiencing.

In analyzing the infected websites, we found that all the websites were using the fancybox-for-wordpress plugin.

If you’re a user of the UpdraftPlus plugin for WordPress, now is the time to update. During a routine audit of our Website Firewall (WAF), we detected a “nonce” leak vulnerability affecting the UpdraftPlus WordPress plugin. The vulnerability allows a malicious actor to perform various operations that he normally wouldn’t be allowed to, such as uploading files on the target server, downloading the site’s backups and retrieving WordPress secret keys.

The biggest issue is that the RevSlider plugin is a premium plugin, it’s not something everyone can easily upgrade and that in itself becomes a disaster for website owner. Some website owners don’t even know they have it as it’s been packaged and bundled into their themes. We’re currently remediating thousands of sites and when engaging with our clients many had no idea the plugin was even within their environment.

The Attack Sequence

We have investigated thousands of compromised sites with this injection and based on the logs, we are able to confirm the exact attack vector being targeted.

Discovery: There appears to be an initial reconnaissance scan occurring where the attacker[s] are looking to see if the file exists. Snippet of the code

Take over: If the exploit is successful, they inject the popular Filesman backdoor into the website, which they access directly at /wp-content/plugins/revslider/temp/update_extract/revslider/update.php this provides full access by circumventing existing access controls:

From there, they inject a secondary backdoor that modifies the swfobject.js file and injects the malware redirecting site visitors to soaksoak.ru.

This campaign is also making use of a number of new backdoor payloads, some are being injected into images to further assist evasion and others are being used to inject new administrator users into the WordPress installs, giving them even more control long term. Some users are clearing infections and getting reinfected within minutes and the reason is because of the complex nature of the payloads and improper cleaning efforts.

Do not just clean these 2 files!

We are hearing a lot of recommendations online to just replace the swfobject.js and template-loader.php files to remove the infection.

It does remove the infection, but does not address the left over backdoors and initial entry points. The website will be reinfected quickly. If you are affected by this, expect to find yourself riddled with backdoors and infections, you have to not only clean, but also stop all malicious attacks. You can stop malicious attacks through the use of a Website Firewall, ours or someone else, just use a Firewall, a real one preferably.

We have posted a full payload analysis as well as our original release on SoakSoak:

As long as there are people involved in the process of writing code and setting up systems, mistakes will happen as it is part of human nature. As such, security problems will always be something we have to deal with.

Impact of Vulnerabilities on Websites

Why does it matter that much? Last week, both WordPress and Drupal released new versions of their Content Management System (CMS) to patch important security vulnerabilities. Other popular WordPress plugins also released updates to fix their vulnerabilities.

Once a vulnerability is found and a patch is available, the solution is simple: Apply the patch (by doing an update) and you are now protected. It is the endless cycle that is known as software development. A bug will be found, a patch will be available, the patch is applied, another bug is found, a new patch is available, the patch is applied. Every time a new feature is introduced, new bugs are also introduced with it.

It seems like a simple process for a webmaster that as long as he is updated, he is safe.

However…

How do you protect against unknown software vulnerabilities?

What if you do not know about a specific vulnerability, how do you patch and protect your website?

What if an update goes out over a long weekend? A 0-day gets disclosed before an update is available? Or what if a vulnerability is discovered by the bad guys and they start using it without telling anyone?

The latest SQL injection vulnerability in the Drupal platform was being exploited within 7 hours of it’s disclosure.

Websites were being compromised via TimThumb before the public knew about it and a patch was available

We have hits in our logs from days before the latest XSS vulnerability in WordPress was disclosed.

So the question is, how do you increase your security so that you can minimize the risk and the chances of being compromised when (not if) someone tries to attack your site misusing an unpatched / unknown vulnerability?

You have options:

Restrict who can access parts of your site to minimize the attack footprint.

These are just some examples. They may sound hard or too advanced, but they are actually doable and every website owner should look into it.

Think about your desktop / notebook computer for a second. Why does every (or almost every) desktop have a personal firewall, an anti-virus, a spam filter and other similar tools? Yes, even Macs have them as well.

Why do most networks (including home networks) run behind a router with basic / advanced firewalls working to filter and prevent attacks from the Intranet?

The reason is simple: minimize the footprint and options for an attacker.

Now think about your website[s]. Let’s look at a few examples into how that can be applied to your Website security:

WordPress 4.0 Long Password DOS

Both Drupal and WordPress had a vulnerability disclosed last week that allowed an attacker to DoS (Denial of Service) a site by sending many, very long passwords in the login requests.

Prevention:Access Restriction / Reduced Footprint.
Block wp-login and wp-admin access only to authorized IP addresses. If an attacker can’t reach your login page, he won’t be able to exploit this vulnerability.

Simple solution that anyone can do by adding an .htaccess to your wp-admin allowing just a few IPs. We find this feature important enough that we employ it to our stack by default and set it as default for all users of our Website Firewall product.

Paid Memberships Pro Path Traversal

Paid Memberships Pro is a popular WordPress plugin that had a path transversal (arbitrary file download) vulnerability disclosed last week. The exploit is possible by accessing: wp-admin/admin-ajax.php and passing a file to be downloaded via getfile:

wp-admin/admin-ajax.php?action=getfile&/../../wp-config.php

Prevention:Access restriction / reduced footprint.
The same as before, restrict access to only whitelisted IPs.

Prevention 2:WAF/IPS.
Even if the previous restriction was bypassed, an Intrusion Prevention System (IPS) or Web Application Firewall (WAF) would prevent it from being exploited through generic Local File Inclusion / Remote File Inclusion (LFI/RFI) rules.

WordPress 3.9.x stored XSS

WordPress versions 3.9.2 and earlier are affected by a critical cross-site scripting vulnerability, which could enable anonymous users to compromise a site. This was reported and patched last week as well.

This vulnerability abuses the core commenting system, an attacker is able to craft a simple comment to send a malicious payload that when viewed by the administrator, allows the attacker to take over the site. This explains it’s severity.

Prevention:Reduced footprint.
First, if your site does not need or use comments, why leave it open? You can block any access to wp-comments-post via .htaccess and be covered right away. If you do need comments, you can use external commenting systems that keep untrusted (user data) away from your trusted data (posts, pages, etc).

Prevention 2:Prevention technology.
Even if you do allow comments, employing a WAF or IPS would probably have blocked this XSS via generic XSS signatures that most good prevention products have.

WP-Statistics XSS

Our research team found a stored XSS in the very popular wp-statistics plugin.

Prevention:WAF/IPS.
This is where having a good WAF / IPS solution in place becomes a must. A WAF have (or should have) a XSS detection that will block this attack generically, without even knowing about this specific vulnerability. On our own WAF, we were blocking it automatically before even knowing about this bug, in a way that we did not even need to write a virtual patching for it.

Staying ahead of Unknowns

Last weeks releases are growing in number each month, as they do the importance of being able to tackle the problem of unknowns grows. Following some of the steps above would improve your over Security posture allowing you to better recognize and respond to these issues, reducing your overall risk footprint.

We offer a product that can do this all, but many of the recommendations you can employ on your own by leveraging open technologies and .htaccess changes:

Restrict access to wp-admin/wp-login (and any other access point) only to authorized IPs.

Limit footprint. Do you need comments? Do you use XMLRPC? Blocking everything and only allowing what you really need.

Leverage a WAF / IPS and you can do this with products like Modsecurity and OSSEC.

We’ve obviously built a technology that automates all these things for you, allowing you to get back to running your business, but you can see there are various options available to you. If you’re interested in a free trial, ping us at info@sucuri.net.