One of the things we do to make sure we are staying on top of security issues in WordPress plugins in keep track on any news stories mentioning them. That leads us to seeing a lot of really bad journalism, like this article at CSO Online where it was claimed that the LA Times website was hacked without the evidence needed to back this up, much less that it was due to a vulnerability in a WordPress plugin.

When we first came across this we were fairly concerned since the article claimed an older vulnerability in the Advanced XML Reader plugin, which we didn’t have in our data set, was possibly used to exploit the website.

The basic details of the vulnerability seemed to match with what was shown in one the screenshots included with the article, which showed the contents of a WordPress configuration file. The screenshots from someone’s Twitter account are the only evidence backing the claim of a hack and they raise more questions than answers.

Upon closer inspection things didn’t seem to match up. A YouTube video that was released along side the advisory on the vulnerability shows an example of the vulnerability being exploited. What it shows is that the ability to exploit the vulnerability is limited. One method of exploiting it would require you to be able to change the plugins settings and add shortcodes to a page, something that would only normally be available to an admin. The other method would require that you be able to edit an .xml  file that is being accessed by the plugin.

After looking into the plugin we noticed that the screenshot didn’t match this. When exploiting that vulnerability you would visit a front end page in WordPress, but as you can seen the screenshot a file in the /wp-content/plugin/ directory is apparently being loaded and displaying the contents of the wp-config.php file:

Looking at the plugin’s file it doesn’t seem like this could be caused something in the plugin. In the most recent version of the plugin, 0.3.4, the only file containing code is advanced-xml-reader.php. If you try to access that directly it will assign some variables and then will fail when it hits the line:

load_plugin_textdomain( 'advanced-xml-reader', 'wp-content/plugins/'.$plugindata['dir']);

So there doesn’t seem to be anyway this could be being used to get the contents of the file.

Older version of the plugin contain a file curl.php, but it just defines a class and doesn’t look it could be used either.

At this point we looked more closely and noticed the screenshot contained no identifiable information. So there is no way to know if this file is something that was on the LA Times website or not.

We are not even sure what the next screenshot is supposed to be showing. It looks like it is supposed to be the directory for the Advanced XML Reader plugin, but there is no file xmlrpc_upload.php that is part of the plugin and why are there directories named after various subdomain of the LA Times in it? That could point to this screenshot being fake or that the hack didn’t actually involved the Advanced XML Reader plugin, just that some files were placed into its directory (it isn’t uncommon for hackers to place files in a directory not related to the hack).

The third screenshot is most interesting since it looks like the person who claimed to hack the website deleted the copy of it in their Twitter account. That screenshot would seem to indicate that the Revolution Slider plugin was on the website, which if outdated, could certainly be a source of the hack:

Again the screenshot doesn’t contain anything that would make it clear that a hack actually happened.

The original article was updated after posting. The update starts by claiming that the LA Times confirmed the hack, “The LA Times has confirmed the hacking, and says the issue has been resolved.” But reading the statement from the LA Times, they don’t actually say that:

A vulnerability in WordPress security was brought to our attention earlier today. The Los Angeles Times uses WordPress to manage its events.latimes.com subdomain and our technology team quickly worked to identify how our relevant sites might be impacted. We have completed a security review and addressed the issue. We have also taken additional measures to ensure the security of our sites.

From Google search results we could see that the Advanced XML Reader plugin had been in use on that subdomain, so that could be the vulnerability they are referring to in their statement. Even if the website wasn’t hacked, that would be something to address, which could be what they are referring to.