Websense’s Claim of Vulnerability in WordPress 3.2.1 Completely Baseless

Last week Websense published a post 3-2-1 WordPress vulnerability leads to possible new exploit kit written by Stephan Chenette their Principal Security Researcher, which made a the claim that there were publicly available vulnerabilities for WordPress 3.2.1 and that a malware infection was hitting only WordPress 3.2.1 based websites. Their post lead to articles in SC Magazine and PC World repeating the claims.

Previously we discussed the fact that the claimed “publicly available exploits” did not actually exist. It’s worth taking a more in depth look at that claim because if there were standards for security researchers than Websense’s Principal Security Researcher would likely have been grossly negligent in this situation.

After our previous post we were still curious with the possibility that there might be a vulnerability in WordPress 3.2.1 based on their claim that all the websites with this particular infection were running WordPress 3.2.1. We looked into this and have found that this is also false. Our finding on that also raises serious questions as to how their researcher could have come to have that conclusion.

What Stephan Chenette and Websense have done by making these baseless claims is highly inappropriate. It is a serious charge to make that software, even if it is an out of date version, has such a serious security vulnerability. To do that based on such blatantly incorrect information and with a complete lack of due diligence is inexcusable and should lead to repercussions for everyone involved in creating and spreading these falsehoods.

Publicly Available Exploits for WordPress 3.2.1?

In the post Chenette said that “Based on my analysis, the site was compromised because it was running an old version of WordPress (3.2.1) that is vulnerable to publicly available exploits [1] [2].”.

The exploits Chenette is citing come from Exploit Database. That website and other similar websites that list claimed vulnerabilities in software include submissions that have not been verified to be actually exploits before being published. Exploit Database includes vulnerability reports that are completely false, like this submission that claimed that the WordPress plugin WP Touch contained a vulnerability in a file despite the fact that the file that doesn’t even exist in the plugin. Anyone serious about security research would verify the vulnerability found on one these websites actually exists before citing it. Those reports also shouldn’t be cited by news organizations unless this has been done.

We know that Chenette didn’t verify these vulnerabilities because if he had attempted to verify the vulnerabilities he would have seen that vulnerabilities mentioned were not in WordPress 3.2.1 or WordPress at all. Instead these vulnerabilities where for WordPress plugins WP-SpamFree and UPM-POLLS. He would have also known if he had just looked at the titles of the exploit reports, which are “WP-SpamFree WordPress Spam Plugin SQL Injection Vulnerability” and “Wordpress UPM-POLLS Plugin 1.0.4 Blind SQL Injection”. What it looks he did was to do a search for WordPress 3.2.1 for that website and just grabbed those results without bothering to look at what they were. If this is level of research Websense’s Principal Security Researcher does, we would hate to see what the subordinates are doing.

There is no evidence that those plugins were exploited on the infected websites and when we checked a few of the websites that we were listed in the Websense post the plugins didn’t even appear to on the websites. In any case because the vulnerabilities are in plugins, if you had plugin installed that was exploitable you would be just a vulnerable whether you were running WordPress 3.2.1, WordPress 3.3.1, or another version.

All The Websites Running WordPress 3.2.1?

The post claimed that all the websites with this infection were running WordPress 3.2.1. If this were true it could be an indication that the infection of the websites was due to an exploit of something specific to WordPress 3.2.1, even though the claimed publicly available exploits did not exist.

As we mentioned in the previous post there are a number of possible explanations why all the infected websites would be running WordPress 3.2.1 without there being an exploit of something in WordPress 3.2.1.

The other possibility is that Websense post was incorrect in claiming all the website were running WordPress 3.2.1. In our previous post we found that for the other claim of a WordPress 3.2.1 vulnerability, by M86 Security Labs, the sample list of infected websites did not contain only websites recently running WordPress 3.2.1 as claimed. In Websense’s case we found that the sample list of 11 websites, included with their post, to have all been running WordPress 3.2.1 recently.

Because the possibility of a remotely exploitable vulnerability in WordPress 3.2.1 is such a serious issue we wanted to look further into the possibility that this infection was in fact due to an exploit of WordPress 3.2.1 as implicated by Websense’s post. The best way to check for this would be to review the HTTP log of an infected website. If an exploit of WordPress 3.2.1 had been the cause that should be discernible in the log. So far we have not cleaned up any websites with this infection, so we haven’t had a chance to do that.

If we could find websites running an earlier version of WordPress (if a website is running a new version it could have been upgraded after the exploit) or not running WordPress at all then that would mean the infection is not limited to WordPress 3.2.1 and likely point to the infection having nothing to do with an exploit of WordPress 3.2.1.

To find websites that contained this infection we looked at Google’s Safe Browsing Diagnostic data. This data includes a few example of website they have found to contain a certain infection. We started with the data for the domain listed in Websense’s post . Two of those domains were now running WordPress 3.3.1. The third doesn’t appear to run WordPress, but it was down so we couldn’t confirm if it contained the malware. We then look at the reports for three more domains involved.

Of the 11 websites that we checked, that appear to had been infected with the malware based on Google’s data, we found 2 were currently infected with the malware and were not running WordPress 3.2.1 or above. We found http://www.weightloss-blogs.org/ which was running WordPress 3.1.3 and contained the malware at the time we checked. This shows that the exploit could not be something specific to WordPress 3.2.1. We also found http://victoryaog.org/joomla/, which as you might guess from the URL is running Joomla instead of WordPress and contained the malware at the time we checked. This shows that it is not something specific to WordPress. We found more that were not running WordPress at all, but were not currently infected so we can’t be totally sure they were infected. Our results show that Websense’s claim that this is infection is specific to websites running WordPress 3.2.1 be baseless.

That finding also raises questions about their data. How could they have found 100+ websites, including the sample list of 11 websites, all running WordPress 3.2.1 but with a much sample set of only 11 we found 2 confirmed instances where this wasn’t the case? They are a few possibilities we could think of.

One possibility is that their data is not very representative of the Internet as a whole, which would make the data unreliable for research purposes and make any reports based on it unreliable as well.

Another possibility is that their system for reviewing their data is flawed or the person doing the analysis screwed up. Maybe they only looked for websites running WordPress 3.2.1, in which case obviously all the infected websites they looked at would be running WordPress 3.2.1. WordPress powers many websites, so finding 100+ that were infected wouldn’t be surprising.

The most troubling possibility, and we need to emphasize that we don’t have any evidence of this, is that their data didn’t actually show that all the website were running WordPress 3.2.1 and they intentionally created a sample list of websites that only contained websites running WordPress 3.2.1.

Posted in Bad Security, WordPress | Leave a comment

Looking at the Claimed WordPress setup-config.php Security Issues

Last week TrustWave’s SpiderLabs claimed that there were multiple vulnerabilities in WordPress 3.3.1 and below. Their report was also discussed in a post on threatpost. Unlike the Websense and M86 Security Labs reports of a vulnerability in WordPress 3.2.1 that were based on false information, these claims are based on factual information but the issues are presented in a way that we consider to be misleading.

What should have been made very clear by TrustWave and threatpost is that the possible security issues only exist if you have placed the WordPress files on your website but have not run the install script. If you are currently running WordPress this is not an issue in your installation.

If for some reason you have an extra copy of WordPress on the website that has never been used and someone could determine where that it is then this could be an issue. You should remove that copy, as you should with any software on your website that is not being used

Here are the findings made in TrustWave’s SpiderLabs’ report and some possible mitigations for the issues raised:

Finding 1

The WordPress ‘setup-config.php’ installation page allows users to install WordPress in local or remote MySQL databases. This typically requires a user to have valid MySQL credentials to complete.  However, a malicious user can host their own MySQL database server and can successfully complete the WordPress installation without having valid credentials on the target system.

After the successful installation of WordPress, a malicious user can inject malicious PHP code via the WordPress Themes editor.  In addition, with control of the database store, malicious Javascript can be injected into the content of WordPress yielding persistent Cross Site Scripting.

What this is saying is that if the WordPress files are on a website and the install script has not been run someone else could run it. They could have WordPress connect to a database sever they control during the install and then they would we be able to place PHP code or JavaScript code on the website. As far as we can tell what they are describing would also be equally true of Joomla, Drupal, and other web software because they have similar web based installers.

It is not uncommon for WordPress to be setup with a remote database server, so removing or restricting the ability to do that would not seem to be advisable.

One possible mitigation for this vulnerability be to require the person using the install script to add or modify a file on the website to confirm that they have control of the website before proceeding through it. A similar mitigation would be to require the database credentials be entered into a file on the website instead of through the web installer. Either of those would make the installation process more complicated for users without providing any security benefit for anyone that promptly runs the install script after putting the WordPress files on a website.

Finding 3

The WordPress ‘setup-config.php’ installation page allows users to install WordPress in local or remote MySQL databases. When using this installation page the user is asked to supply the database name, the server the database resides on, and a valid MySQL username and password.

Malicious users can omit the “dbname” parameter during this process, allowing them to continually bruteforce MySQL instance usernames and passwords. This includes any local or remote MySQL instances which are accessible to the target web server. This can also be used as a method to proxy MySQL bruteforce attacks against other MySQL instances outside of the target organization.

What this is saying is that if the WordPress files are on a website and the install script has not been run someone could use install script to make login attempts on a local or remote database server.

In addition to the mitigations mentioned for Finding 1, it would be possible to place limits on the number of attempts to log in into database servers with the installer. That would add complication to the installation process without providing any security benefit for anyone that promptly runs the install script after putting the WordPress files on the website.

Finding 2

The WordPress ‘setup-config.php’ installation page allows users to install WordPress in local or remote MySQL databases. When using this installation page the user is asked to supply the database name, the server that the database resides on, and a valid MySQL username and password.

During this process, malicious users can supply javascript within the “dbname”, “dbhost” or “uname” parameters. Upon clicking the submission button, the javascript is rendered in the client’s browser.

What this is saying is that if the WordPress files are on a website and the install script is not run someone could create POST requests to the install script page which cause arbitrary JavaScript to included on the page in response to that request.

It seems like it should be possible to sanitize these parameters to prevent the described issue, but it doesn’t seem like this would be likely to be exploited as it would make more sense to exploit the issue mentioned in Finding 1. Exploiting the issue in Finding 1 would allow arbitrary JavaScript to be placed on pages without requiring a POST request, which would be easier and evade cross-site scripting (XSS) filters built-into some web browsers, as well as allowing other things to be done which are more of a concern then being able to place arbitrary JavaScript on a page.

WordPress’ Response

WordPress responded to the report by stating that “We give priority to a better user experience at the install process. It is unlikely a user would go to the trouble of installing a copy of WordPress and then not finishing the setup process more-or-less immediately. The window of opportunity for exploiting such a vulnerability is very small.”

We largely agree with WordPress’ view. We would further say that trying to make this a WordPress issue seems inappropriate as the most serious claim is related to having a user friendly web based install script, which is common among web software, rather than something specific to WordPress. If TrustWave’s SpiderLabs believes this is a serious issue they should have raised it instead of trying to make this into an issue with WordPress.

Posted in Website Security, WordPress | Leave a comment

Claims of Vulnerability in WordPress 3.2.1 Supported by False Information

In the past few days they have been two reports of a vulnerability in WordPress 3.2.1. In looking into these we found that the claims to be supported by false information and no evidence of a vulnerability in WordPress 3.2.1 was presented. A number of news organization including SC Magazine, The Register, and PC World repeated the claims without bothering to check the information for themselves. We still would recommend that anyone running an outdated version of WordPress upgrade to version 3.3.1 (which one of the security companies making the claims hasn’t done itself) and to make sure you keep all the software on your websites up to date at all times.

Websense

The first claim is by the Principal Security Researcher at Websense. In their post it is stated that “Based on my analysis, the site was compromised because it was running an old version of WordPress (3.2.1) that is vulnerable to publicly available exploits [1] [2]“. Looking at the exploit reports they are for two WordPress plugins not for WordPress itself, so the analysis is fundamentally wrong.

If those exploits actually work (we didn’t test them) then it wouldn’t matter what version of WordPress you were running only if you were running the vulnerable version of the plugins. We checked a few of the sample websites they listed and it did not appear that they were running either of those plugins.

Their other evidence that the exploit was something related to WordPress 3.2.1 is the claim that all of the website were running that version of WordPress. If this is true (the sample list of 17 websites they provided were all recently running WordPress 3.2.1) it doesn’t necessarily mean that the hack was related to something in WordPress 3.2.1 or WordPress at all.

One likely possibility is that they are all running some other outdated software, maybe a WordPress plugin, that contain a vulnerability. Websites running an outdated version of WordPress are more likely to have not kept other software on the websites up to date as well.

WordPress and WordPress 3.2.1 run on many websites so it also could be that some other type of exploit, like compromised FTP credentials or hacked hosting providers, could be the source. We know that sometimes hackers specifically target WordPress installations when using non-WordPress related exploits, something that Websense has in the past falsely claimed as being an exploit of WordPress itself.

M86 Security Labs

The second claim comes from M86 Security Labs. In their post they state that “A few days ago, hundreds of websites, based on WordPress 3.2.1, were compromised. ” We checked what version of WordPress the sample list of 33 website they included in their post were running. We found that many of them were not running WordPress 3.2.1. Here is the breakdown:
3.3.1: 7
3.3: 2
3.2.1: 8
3.2: 1
3.1.1: 1
3.0.3: 2
3.0.1: 1

They were also 11 websites that were inaccessible at the time we checked. Of 22 we could check, less than half were running 3.2.1. Nine were running newer versions and five were running older versions. It possible that the ones running newer versions were upgraded after they were exploited, but it makes no sense that websites running older versions were running 3.2.1 at the time of the exploit. This clearly indicates that the websites were not all running WordPress 3.2.1 as claimed and that exploit is not something specific to 3.2.1. It is possible that it could be related to something that existed in 3.2.1 and below, but there is no evidence provided by them to support that.

If you visit the M86 Security Labs Blog with our Meta Generator Version Check extension (available for Firefox and Chrome) you would get an alert the blog is running an outdated version of WordPress, 3.1.3.

M86 Security Labs Blog WordPress VersionIf they really believe there is a vulnerability in outdated versions of WordPress why are they running an outdated version on their own blog?

Posted in Bad Security, WordPress | Leave a comment

DreamHost Does Store Non-Hashed Passwords

On Friday DreamHost reset all of their customers “FTP/shell access passwords” after they had unauthorized activity within one of their databases, the situation is discussed in blog posts on DreamHost Status blog and the The Official DreamHost Blog!. Since then there have been questions and confusion as to whether DreamHost only stores passwords in their hashed form. While we have no way of knowing if the database they detected unauthorized activity stored non-hashed password there is no question that they store non-hashed passwords in their systems. It’s fairly easy to see that DreamHost is doing this and we will show you how you can check this for yourselves at the end of the post.

The fact that they stored passwords in a non-hashed form has been discussed for many years and DreamHost has so far has decided that insuring that they were follow proper security practices by only storing password hashes wasn’t necessary for whatever reason. It’s then not all to surprising that they had this most recent security incident and the other apparent security incidents they have had over the years. For some time we have listed DreamHost in our list of web hosting providers with security issues due to them storing non-hashed passwords.

One possible reason for some of the confusion from DreamHost is that they don’t understand the difference between encryption and hashing, in which case it they probably shouldn’t be handling the security of a website, much less that of a major web host.

While discussing DreamHost’s security it is also worth bringing up the fact that both of those blogs are running an outdated version of WordPress, 3.2.1. They are also are running an outdated and now unsupported release of MediaWiki, 1.16.5, on a portion of their website (so are a number of the websites of web software). In a message that was forwarded to us while we were cleaning up a hacked website for client recently, DreamHost had told them that they should make sure to keep web software running on their website up to date. Obviously DreamHost don’t feel it is important to follow the advice they give to their customers. If you want to see when websites are running out of date version versions of WordPress, MediaWiki, and other software check out our Meta Generator Version Check web browser extension for Firefox and Chrome.

Considering DreamHost’s questionable security practices we would recommend that people avoid using their services until they have fixed these lapses in their security. We also don’t think that WordPress should be recommending them or describing them to be one of the hosts that “represent some of the best and brightest of the hosting world”.

What is Hashing?

You can think of hashing as one way encryption.  To produce a hash you run a hash function on a specified value, in this situation it would be the value being set as a password. For example, using the MD5 hashing function the hash for the password value “password” would be “5f4dcc3b5aa765d61d8327deb882cf99”.

Unlike encryption, hashes are not meant to be decryptable and ideally you wouldn’t be able to determine what the password value was if you gained access to its hash. This is why it is important to store passwords as hashes. If they are stored them in a non-hashed way someone that gains access to them could easily use the passwords to log into your account, which has happened previously after web host’s were exploited, or if you use the same password on different systems they could potentially gain access to those as well. There are a number of ways to determine the underlying value of passwords hashes, so systems using hashing for passwords need to insure they follow best practices including making sure they use salts.

So how does a system know that the correct password was entered during a login attempt if they only have the hash? The answer is that when the login attempt is made the password you enter is run through the same hash function and then compared with the stored hash of the password. If the two are they same the login attempt will succeed. If you entered the wrong password the hashes would be different and it would fail.

If passwords are only stored in hashed form there will be no way for a provider to retrieve the password from storage that for you. The only instances where they could show you the password would be when they are generating a new password for you or if they show you the password in response to you entering it.

The most common place to see that passwords are being stored in non-hashed form is on pages for handling a situation where you forgot your password. If they can show or send you the password it means the password in being stored non-hashed in their systems. With web hosts we also sometimes see that passwords are visible somewhere in the control panel for the websites.

Spotting Non-Hashed Password Storage at DreamHost

From the DreamHost’s homepage click the Panel link at the top and then click the Forgot password link. That page currently looks as follows:

DreamHost Forgot Password Page

If the password were only stored in the hashed form they wouldn’t be able to email you your password because they wouldn’t know what it was.

Posted in Bad Security, Website Security, WordPress | Leave a comment

Outdated Software Running on Websites of WordPress and Other Web Software

When the makers of web software talk about security they always emphasize the importance of keeping software updated. One of the developers of WordPress said it this way “The only thing that I can promise will keep your blog secure today and in the future is upgrading.” Keeping software updated is good advice, but isn’t advice that the software makers, including WordPress, always follow themselves.

We recently mentioned a pretty egregious example of this from OpenX. Their blog, where they recently said it is critical to keep software up to date, is running a version of WordPress that is over three years out of date. Also, the main portion of their website appears to be running a version of Drupal that is over a year out of date.

MediaWiki, the software the powers the Wikipedia, is run on portions of many web software websites so we decided that it would be a good choice to see if software makers are keeping other people’s software running on their website up to date. There are several ways to check what version of MediaWiki is running and the easiest way to check for outdated MediaWiki installations is to use our Meta Generator Version Check web browser extension, available for Firefox and Chrome. The extension will show a warning icon when a web page has a meta generator tag from an outdated version of web software.

For those not familiar with MediaWiki they currently provide security updates for the two most recent releases 1.17.x and 1.18.x. The most recent version of those releases 1.17.2 and 1.18.1, both of which were released on January 11. We update our web browser extension a month after a new version is released, so until then it will check for MediaiWiki versions below 1.17.1.

Before mentioning the websites running outdated versions it is worth noting that one website we checked was actually up to date. TYPO3′s TYPO3Wiki is running 1.18.1.

WordPress

WordPress MediaWiki Version

The WordPress Codex is the most out of date as it is running 1.15.5, which is two supported releases out of date. Support for 1.15.x ended in December of 2010.

Zen Cart

Zen Cart MediaWiki Version

The Zen Cart Wiki is one supported release out of date and running a version, 1.16.2, that that is three minor updates out of date. Support for 1.16.x ended in late November of last year.

Joomla

Joomla MediaWiki Version

Joomla! Documentation is one supported release out of date and running a version, 1.16.4, that that is one minor update out of date.

phpBB

phpBB MediaWiki Version

The phpBB Development Wiki is at least running the most recent version of 1.16.x, 1.16.5, but that release is no longer supported.

Moodle

Moodle MediaWiki Version

MoodleDocs is at least running a supported release, 1.17.x, but the version, 1.17.0, is two minor updates out of date.

Posted in Joomla, MediaWiki, Moodle, phpBB, Website Security, WordPress, Zen Cart | Leave a comment

Does Security Really Matter to OpenX?

On December 1st OpenX finally made a public announcement on their blog about OpenX 2.8.8, which fixed a vulnerability that had already been exploited for some time before OpenX 2.8.8 was released. There post claims “If ever we find an issue, we address it quickly and communicate any updates as soon as possible.” Would anyone think a month is “as soon as possible”. What makes the length of time for the announcement even more troubling is that back on November 8 when we posted about the lack of a public announcement, and other issues, we had many visitors from OpenX visiting the blog so if they hadn’t yet thought it was important to make announcement before that they should by then.

Their post begins with the claim that “OpenX takes security seriously.” It hard to take that seriously considering that that this is third post on their blog titled Security Matters (1, 2) making the same claim and yet they have had to continually released fixes to vulnerabilities after those are already being exploited. It is understandable that software can have vulnerabilities, but when hackers are finding and exploiting them first instead of the developers finding and fixing them first it is an indication that their process for insuring the security of their code is lacking.

While there has been a fair amount of time between new vulnerabilities being exploited, and then fixed by OpenX, it is reasonable to consider that it might not be due a limited number of vulnerabilities but a lack of need to exploit more vulnerabilities. From what we have seen there seems to plenty of ad server running outdated versions of OpenX that hackers have been able to exploit well after new versions are released, so it doesn’t seem unreasonable to think that hackers might know of or could easily find more vulnerabilities in OpenX but as long there are enough ad servers running on outdated versions of OpenX to exploit there would be no need to make OpenX aware of a new vulnerability so that it can eventually be used when they run low on outdated ad servers to exploit.

It also is hard to take them seriously when there is such a public example of them not following their own advice. As part of their post they say “It’s critical to the safe maintenance and operation of any software that you not only maintain a current version of the software, but also take steps to regularly audit accounts that have access to your system.” They correctly state that it is critical to keep software up to date, but you don’t have look far to see that they don’t follow their own advice. The blog that they posted to is running WordPress 2.6.2 (if you want to see when websites are running out of date version versions of WordPress and other software check out our web browser extension for Firefox and Chrome). That version is now over three years out of date. They have failed to apply the last 16 releases that included security updates and 27 overall.

The CHANGELOG.txt file for www.openx.com indicates that it is running Drupal 6.19, which, if accurate, means the Drupal install is a year out of date and they missed a security update for that as well.

Posted in Bad Security, OpenX | Leave a comment

Our First WordPress Plugin Security Bug Bounty Payouts

We finally have an opportunity to discuss our first two security bug bounty payouts for WordPress plugins, both for relatively minor issues. We actually paid them out in late October but we were waiting until after one them was finally fixed (the other was fixed within hours of the developer being notified) to write about the issue.

Both NextGEN Gallery and WP e-Commerce suffered from reflective cross-site scripting (XSS) vulnerabilities in the portion of the plugin accessible in the admin area. With a reflective XSS vulnerability if an attacker can get you to visit a specially crafted URL they can cause the website included arbitrary HTML code, most often JavaScript, which they specify. That could be used to cause actions to take place of the web page, another file to be loaded, your browser cookies to be read, among other things.

XSS vulnerabilities are not as big an issue as vulnerabilities that allow adding arbitrary code to a database or into a file. Because these two vulnerabilities are only accessible in the admin area, it limits there severity even more. If they were to be used by an attacker they would be used in a attack to target at an individual website instead of a mass attack. Most attacks on WordPress based websites are mass attacks.

A fix for NextGEN gallery was included in version 1.8.4 and a fix for WP e-Commerce was included in version 3.8.7.3.

Web Browser Based Reflective XSS Protection

The ability to exploit the vulnerabilities is also limited by protections in some web browsers designed to restrict reflective XSS vulnerabilities from occurring. While doing a test with a XSS that attempts to load a JavaScript file from a third-party website that reads cookies associated with the WordPress based website we found that the web browsers performed as follows:

We found that both Chrome 15 and Safari 5, whose protection come the WebKit rendering engine they share, were able to successfully block the attempted XSS.

We found that Internet Explorer 9 only blocked the attempt XSS if you were already logged into WordPress when attempting to access the malicious page. If you were not logged in you would be asked to login and then be taken to the malicious page where the XSS was not blocked. This is due to Internet Explorer disabling the protection for requests originating from the same website. This is one of a number of weaknesses in Internet Explorer’s protection discussed in the paper Bypassing Internet Explorer’s XSS Filter (PDF).

Firefox doesn’t currently provide any similar functionality, but with the NoScript add-on installed we found the attempted XSS was blocked.

Keep in mind that the web browser protections are not full proof and it is possible that XSS attacks could be crafted that can evade the protections.

Testing Security Plugins Against These Vulnerabilities

Now that updates for both plugins have been released the way to prevent these vulnerabilities is to make sure you are running the latest version, which should make sure to with any installed plugins, but what about similar vulnerabilities that developer are not yet aware of? The biggest protection that you have is that targeted attacks are rather uncommon, so you are unlikely to be exposed to this type of issue. Then protection comes from being careful when clicking on links and using a web browser that provides protections against this type of hack.

There are also a number of security plugins for WordPress, some on them specifically claim to protect against XSS. We wanted to see if they would have blocked the exploitation of the vulnerability in either plugin. To test this out a crated a XSS attempts to load a JavaScript file from a third-party website that reads cookies associated with the WordPress based website. We used Firefox without NoScript so that any protection would be from the plugin and not the browser.

For this test, we tested plugins that did not require signing up for any service. We tested the following plugins:

BulletProof Security
Secure WordPress
Better WP Security
TTC WordPress Security Tool

For all four plugins we found that provided no protection. This is rather disappointing as this is just the type of thing they might be useful for. Most times when WordPress based websites are successfully attacked it is due to outdated software, which keeping software updated would have prevented, or it is due to a hacker gaining access to the underlying files that make up WordPress. In a case where the hacker has access to the underlying files the plugins cannot prevent access to the files (making files un-writeable is generally not effective as the hacker generally has the ability to make the writeable again) and the hacker could remove or modify the plugins. They could even modify the software to report that the website is still secure (You probably won’t find much security software of this type warning about this serious weakness, though it doesn’t appear that many hackers bother doing that as the software isn’t popular enough to be worth the time it would take to do that.).

Posted in Website Security, WordPress | Leave a comment

OpenX Continues Questionable Security Posture

Last Thursday OpenX released version 2.8.8 of their software. They have yet to make any sort of public announcement of the update on their blog or anywhere else that we could find. The only information given, found on the Product Updates page in the OpenX admin interface, says that:

It is highly recommended to install this update as soon as possible, because it contains a number of security fixes. The version of OpenX which you are currently using might be vulnerable to certain attacks and is probably not secure.

With a release that includes important security fixes, as this seems to be, you would expect that they would want to make sure people that use their software would be well aware of the update.

There was no information was given as to what the vulnerabilities were or what other changes were made in the new version. This is a continuing practice from OpenX as we have written about before. While it is understandable that developers would want to limit the amount of information to make it harder to for people to be able to exploit the vulnerabilities, hackers have shown that they are able to hack OpenX without this information and the information would be useful for people not looking to hack OpenX.  To repeat what we said after the last OpenX release, “[w]ithout knowing what the issue or issues that were fixed makes it hard to determine the source of a hacking, potentially leading to new vulnerabilities that are exploited in OpenX going undiagnosed in the future if the OpenX installation hacked was running an out of date version.” It also makes it hard for anyone to independently verify the vulnerabilities were fully and properly fixed in the newer version.

The larger concern we have now is that OpenX seems to continue to be releasing security fixes in response to vulnerabilities being actively exploited, commonly referred to as zero-day exploits, instead them being found beforehand during development or during subsequent security reviews. We know that with past vulnerabilities they were being exploited before updates were released. We have seen some reporting that vulnerabilities in the last version were being exploited (with the most specific report we were not able to replicate the vulnerability, but that could be because of using a different server configuration) before this version was released. This at least means that users keeping the software up to date are not safe from being hacked, which they generally are with most web software that have a good track record of finding and fixing vulnerabilities in their software before they can be exploited. It also could be an indication that OpenX is not as concerned about the security of the software as they need to be for something that is so widely deployed.

What makes there apparent lack of concern towards the security of their software more troubling is the way they used the update message for 2.8.8 as a chance to promote their hosted solutions. This is the message that followed the warning about the need to update:

OpenX also provides both free and Enterprise hosted versions of the ad server, offering significant improvements in both infrastructure and functionality. Both of these products are managed and operated by the OpenX team, including upgrades, maintenance, and security scans, freeing you and your team from handling such issues. If ad serving is mission-critical to your business, we suggest contacting our team to learn more about OpenX Enterprise. As always, please let us know of any potential security problems by emailing security@openx.org.

All the hacks of OpenX we have dealt with so far have been due to security vulnerabilities in the OpenX software and not due directly to something related to self-hosting. In many of those cases OpenX had released a update before they were hacked, so automatic upgrades provided by their hosted solutions would have helped. But unless OpenX is providing their hosted customers with a more secure version of OpenX, then the hosted customers remain as vulnerable before the fixes for the security vulnerabilities are released. The quality of their security scans should be in question as well, if vulnerabilities keep getting found and exploited before they are fixed by OpenX.

Update (November 14, 2011):

Another thing that should be noted when considering how OpenX views the importance of security is the fact that their blog is still running WordPress 2.6.2. One of the most basic and important security measure anyone running a website should be doing is making sure they keep any software running on the website up to date. The version they are currently running is now over three years out of date. Since version 2.6.2 there have been 16 releases that include security fixes that they have missed (and 26 overall releases).

Posted in Bad Security, OpenX, Website Security | 4 Comments

Our New Web Browser Extension to Warn When Outdated Software is Being Used

We are always looking for ways how we can help to improve the security of the web. One of the basic security measures that needs to be taken to keep websites secure is keeping the software running on them up to date, as newer releases often contain security fixes and enhancements.

The developers of web software have done a lot to make that easier by providing messages in the software that the websites is in need of update and making the update process easier. Even with this there is still many website running outdated versions of that software.

When we are in touch with people running websites whether they are potential clients, people we are contacting to let them know their website has been hacked, or for some other reasons, we make sure to let them know if we see they are running outdated software that needs to be updated. We only reach a limited number of people so to increase awareness that outdated software is running on websites we have created a new web browser extension, named Meta Generator Version Check, to make it easier for others to see when there is outdated software running a website.

With the web browser extension installed, each time a web page finishes loading the extension checks the web page’s source code for a meta generator tag. The one for the current version of WordPress looks like:

<meta name="generator" content="WordPress 3.2.1" />

After reading that, the extension then provides a warning if it detects one of the following software is running on the website:

  • WordPress versions prior to 3.2.1
  • Joomla 1.0 and Joomla 1.6
  • Mediawiki versions 1.16.4-1.13 (earlier versions do not contain a meta generator tag)
  • vBulletin versions prior to 3.8.7
  • TYPO3 versions prior to 4.3
  • Movable Type versions prior to 4.37, 5.06, and 5.12
  • Melody versions prior to 1.0.2

Looking at that list you might notice that there is a fair amount of software missing. The limitation of checking the meta generator is that not all software produces one and some of those that do, do not provide a tag that allows us to identify what version is running. In other cases only partial version information is given. For Joomla, this means the extension can warn about websites running Joomla 1.0 and 1.6, which are no longer supported, but for Joomla 1.5 and Joomla 1.7 there is no indication if they are running the current version of those, as of yesterday they were 1.5.24 and 1.7.2, or an older version.

Another issue we have found as we looked to add checks for more software is that the supported versions of software are not always easy to find. We would recommend that software developers make sure that they prominently display what versions of their software are supported so that people looking for that information can easily find it.

If you see that we are missing a check for software that provides the required information in the meta generator tag please let us know so that we can include that in the extension.

While it would be possible to have the extension do a more intensive check to determine what version of software is running on website, using information not available in the meta generator tag, this would in most cases require requesting additional files when each page is loaded and would provide information that is not being made available by the web page itself.

We currently plan to update the extension to warn that software is outdated a month after a subsequent version has been released or support has ended for a version. For severe security vulnerabilities the extension may e updated sooner provide an earlier warning.

Uses

The main use for the extension is to be alerted that websites that you are visiting are running outdated software so that you can let them know that they need to update it or if they are your client you can do the update yourself.

It also could be useful in looking at who you considering doing business with or what software you might use on your website.

If a web host isn’t keeping software on the frontend of their website updated, it is reasonable to be concerned that they might not be taking proper security measures for their hosting clients as well. After checking just a few web hosts we found that both Just Host (3.0.3) and IX Web Hosting (3.1) were running outdated version of WordPress. It is also interesting to note that homepage of IX Web Hosting’s website has security seals from both McAfee Secure and something called Ecommerce HackerShield (which appears to something created IX Web Hosting’s parent company) claiming the website is secure despite the outdated software, with known security vulnerabilities, running on a sub-domain of the website and linked directly from the homepage.

For software, an example of something that might be concerning that we just noticed with a piece of software that we run on our website, Piwik, is that their website is still running WordPress 3.0.4.

Availability

A version of the extension is now available for Chrome. A version for Firefox is currently pending a review from Mozilla. The Firefox version has some limitations in comparison to the Chrome version due to current limitations of the Mozilla Add-On SDK, as the Add-on SDK is further developed those limitations will also go away. A version for Safari will not be released until Apple modernizes their enrollment process for Safari Extension development.

You can also find a web-based version of the tool here.

Is Running Outdated Software Always a Security Concern?

Outdated software is not automatically less secure than a newer version, it would only be more insecure if it contains a security vulnerability that does not exist in a newer version. Often new releases include fixes for security vulnerabilities or security enhancements. There is also a possibility that changes have been made in a newer version that removed a security vulnerability that was not known to be security vulnerability at the time. To be safe it is a good rule to update the software even if the developers have not warned of vulnerabilities in prior versions. To keep things simple we have decided that the extension will warn if outdated version is running instead providing a warning only when we know an old version contains a security vulnerability.

Is Including a Meta Generator a Security Concern?

With software that includes a meta generator tag there are often people claiming that it makes websites less secure, this is especially true when it comes to WordPress.  We previously discussed the issue in detail in regards to WordPress. The summary of that is as follows: The bad guys are not generally checking the meta generator tag and they usually don’t even check if you are running the software they are trying to exploit. On a daily basic there are attempts to exploit software that is not and has never been on our website. Because the bad guys attempting to exploit vulnerabilities do not bother to check what version of software you are running the website, you will get hacked if you are running a version with that vulnerability even if you managed to completely hide the version running. Finally, if someone wanted to find out what version you are running they could do that even if you remove the meta generator tag.

With our new extension we think it makes even more sense to include a meta generator tag as it increases the usefulness of the tag by letting people inform others they have outdated software running on their website that needs to be updated.

Posted in Joomla, Piwik, Website Security, WordPress | Leave a comment

VeriSign’s Bad Advice on Protecting Websites from Malware

If you do a Google search related to website malware right now you might right run across the following ad from VeriSign:

VeriSign Malware Scan
What you need to know about malware & how to protect your site

Someone interested in how to protect their website from malware might click on the ad hoping to learn about doing that. From the page the ad takes you to you could visit a page titled FAQ: Web Site Malware Scanning. One of the questions in the FAQ is “How can I protect my site from malware?”. This looks like the information their advertising was promoting.  Here is what they say:

Like most thieves, malware hackers look for easy targets—such as a Web site where malware will go undetected for as long as possible. Posting the VeriSign Trust Seal on your Web site is like posting an alarm security sign in your front window. It shows hackers that your site is scanned daily to detect malware.

There are probably many variations on what would be a good answer to this question. Verisigns answer is certainly not one of them. Not only have they given really bad advice for protecting websites, but the answer suggests a scenario that is almost never going to happen.

The scenario in the answer suggests that hackers are going to view the website before they attempt to hack it. In almost all instances that is not the case. Not only is someone not likely to view the website before attempting to hack it, but there probably will not be a person directly controlling the attempted hack. Instead, the hacking attempt is likely to be automated.

For example, someone might setup a program to go through every domain name attempting to exploit a vulnerability in an outdated version of WordPress. Because no one is viewing the website before attempting to hack it the VeriSign Trust Seal will have no impact on whether the website is hacked or not. The best that malware scanning could do in this case would be to quickly warn that the website is infected. The worst case would be the scanner not detecting the infection until it has potentially infected many visitors. What is hopefully obvious is that if you are not running an outdated version of WordPress you would not get infected in the first place.

The right way to protect your website against these types of hacks, which are done in this automated fashion, is by taking the measures we have written about here. If your website is properly secured you are very unlikely to get infected so malware scanning is of little use. If you wanted make sure that you are warned quickly if your website is ever infected you set it up so that Google will send email to an address of your choice if they ever detect malware on your website.

So would the seal have any deterring effect on someone who has decided to target your website? It is hard to say for sure, but it seems unlikely it would have any effect. If someone were looking for easy targets they wouldn’t be trying target specific websites at all. It is much more efficient for them to use untargeted methods to find easy targets. What would be more likely to happen if they were targeting you is that they would test their malware to make sure it is not detected by the scanning done by Verisign before infecting your website. In that situation letting them know it was going on would not be helpful.

Verisign is owned by a major security company, Symantec, so they should be aware of all of this, especially since they decided to run advertising promoting that they would tell “What you need to know about malware & how to protect your site”. Either they don’t know about website malware, but are offering the service any way, or they know about it and they appear to be intentionally misleading potential customers.

Posted in Bad Security | Leave a comment