Security Breach Identified for Users of Popular WordPress Plugin and Theme

If you used WordPress to set up and maintain your website and you downloaded the JetPack plugin or the TwentyFifteen theme, you could be vulnerable to a newly-identified cyberattack.

According to the web security website Sucuri, any WordPress plugin or theme that uses the popular genericons package could be at risk of a DOM-based Cross-Site Scripting (XSS) vulnerability.

Both the JetPack plugin (which has more than 1 million active users) and the TwentyFifteen theme (which is WordPress’s current default theme) use genericons. The threat has been identified in the example.html file that comes with the package.

Eliminating the Threat

The quick fix is to remove the example.html file from the genericons package, which you don’t need anyway.

Sucuri said it detected this vulnerability before it ever became active, so it hasn’t done any known damage so far. Due to the website’s wicked fast response time, the threat level to WordPress users isn’t considered serious. But the site warned that it would be easy for the vulnerability to be exploited.

Sucuri reached out to the most popular web hosting services and notified them of this vulnerability and gave them the patch they needed to eliminate it. So if you use any of these services, you already have the virtual patch you need to protect yourself:

– GoDaddy

– HostPapa

– DreamHost

– ClickHost

– Inmotion

– WPEngine

– Pagely

– Pressable

– Websynthesis

– Site5

– SiteGround

But if your site is hosted by a different company, you may need to manually fix the issue yourself. All you have to do, according to Sucuri, is go to the genericons directory and delete the example.html file and you will be completely protected.

Who Is Responsible?

How the vulnerability got there in the first place and what its designers’ intentions were is not known. It’s strange that Automattic and the WordPress team would leave a simple example.html file in the genericons directory. Was this simply an oversight or something more sinister? At the moment, we don’t have a good answer for that question.

Here’s a wonky description of what it does from the group OWASP:

“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.”

What that means, I don’t know. But I do know that the XSS payload is never sent to the server side and is executed entirely at the browser level. So even if your website has a firewall, it can’t do anything about the vulnerability because it doesn’t ever see it. While it’s possible to patch the exploit, DOM-based XSS can be very difficult to block.

A Close Shave

But they also are more difficult for hackers to exploit because they require a high level of social engineering to get people to click on the exploited link. But if hackers can get someone to click through, it provides the same level of access as other types of XSS attacks. Theoretically, the exploit could be used to execute javascript in your browser and take over any site you are logged onto as the admin.

Had this exploit not been caught, it could have had a devastating impact on unsuspecting website owners and businesses alike.

In any case, if you remove the example.html from the genericons directory, you should be okay for now.

Google Announces Cancellation of Its PageSpeed Service

If you currently are using Google’s free PageSpeed Service to speed up your web pages, you should probably start looking for another service now.

That’s because Google recently announced that it is cancelling its PageSpeed service, effective in August.

Google’s PageSpeed Service, which was first launched in 2010, uses tools to analyze and optimize websites in order to implement the best web performance practices. Fast and optimized pages lead to better visitor engagement, retention and conversions.

But Google is pulling plug on the service, although the free tools it offers will still be available on other open source platforms.

Google’s official announcement came May 5, although rumors of PageSpeed’s demise have been flying around tech message boards and have been hinted at in numerous tech blogs for the past several weeks.

August 3 Deadline

Web page owners using Google’s PageSpeed Service have until August 3 to make the necessary DNS changes to remove sites safely.

Google recommended that webmasters using the service login to the PageSpeed console and look at the list of their domains. Any domains that are labeled “Enabled” will be affected once the service shuts down for good.

If a web page’s DNS is not changed prior to the shutdown of PageSpeed, it will be completely unavailable. The console will offer advice if a webmaster tries to delete a live domain. If this change is not made by August 3, the site will break, Google warned.

On May 5, big pink banners began appearing on PageSpeed pages stating, “PageSpeed Service has been deprecated and will be turned down on 3rd August.” A link is provided that directs visitors to Google’s official announcement.

Options to PageSpeed

Google offered PageSpeed several options – some free and some paid — that they can switch to prior to the service’s being shut down.

Web masters are advised to check with their service provider to see if they offer provider hosted PageSpeed. In some instances, switching to this version could be as simple as checking a box in the provider’s control panel.

There also are PageSpeed modules available for many of the most common web servers. So web page owners who run their sites of their own server are advised to install one of these.

Google also has developed the open-source Apache module mod_pagespeed. There are currently two pre-built binary modules available: Apache 2.2 and Apache 2.4.

There’s also a plugin for Nginx that Google has developed. But this must be compiled from the source.

Other options include:

– IIS – WeAmp has a commercial port of PageSpeed to Microsoft IIS.

– Apache Traffic Server – WeAmp also has ported PageSpeed to the Apache Traffic server.

– OpenLite Speed – This platform supports a PageSpeed module that can be compiled and loaded into a webserver.

– Cloud-Based Alternatives – If webmasters prefer to use a cloud-based product, EdgeCast EdgeOptimizer integrates Google PageSpeed with its CDN offering. Or, many CNDS offer similar functionality that don’t use PageSpeed technology.

Why PageSpeed Mattered

PageSpeed was designed to allow web pages to load faster for users. It features a quick and easy setup and allowed users to keep up with the latest optimization technologies without having to constantly search for them online.

One of the biggest benefits was that it used Google’s existing fast and secure infrastructure, which won’t be available for web masters who switch to open source server modules. It was widely praised for creating happier users and better conversions.

While Google doesn’t explicitly explain why it has pulled the plug on this popular, helpful service, some tech bloggers speculate that CloudFare captured this market and Google may have decided to stop focusing on this type of service, at least for a year or two.