FatCow Running Over Six Years Out of Date Version of phpMyAdmin

One of the most basic measures for keeping websites secure is to keep software running the website up to date, this is something that web hosts know and tell their customers. Unfortunately, many web host don’t seem to feel that they need to heed their own advice and run out of date software on their servers. This put their clients at risk of being hacked though exploitation of a known vulnerability in that software. Their use of outdated software also a warning sign that they may not be handling the rest of the security properly as well.

When we do work on a client’s website we do a check of what version of some common software (PHP, MySQL, phpMyAdmin, etc.) is running of the server. This is partly so that we can see how well web hosts are doing at keeping that software up date and also so that we can alert the clients when severely out of date software is in use. We continue to see that in many cases web hosts’ servers are running out of date versions of that common software, with known security vulnerabilities. The good news is that for most part we are seeing that the software is less out of date then it has been in the past. That made something we saw while checking a FatCow server in the past few days stick out. The server was using phpMyAdmin 2.8.0.1. That version was released on March 8 of 2006 and the next version, 2.8.0.2, was released eight days later. If over six years out of date hasn’t been the most out of date we have ever come across, it at least the most out of date we have seen in a long time.

phpMyAdmin provides a page that provides a listing of all security announcements for the software (something that other software developers should also be providing). Based on just the announcements for 2006 and 2007, the version of phpMyAdmin FatCow is using probably contains 16 serious severity security issues and 1 considered “quite dangerous”.

Posted in Website Security | Leave a comment

Sucuri Security: How Not to Astroturf

A couple of months ago we wrote a post about someone who came to us after several tools had claimed their website was infected with malware. We found that not only were those tools wrong, but that the false positives highlighted major flaws in these tools. One of them was Sucuri SiteCheck, which we found was not bothering to actual scan a file labeled as malicious before falsely labeling the website as being infected. Since then there was an obvious attempt to get people to comment on the post, not on the substance of the post but with praise for Sucuri. We are happy to receive comments that further the discussion of a post, especially if they disagree with us. We are not interested in our blog being filled with off-topic comments and won’t approve them and you won’t see them. One of the comments we received during this was unlike any of the others, it was a long bizarre rant that had all the hallmarks of an attempted astroturfing by a Sucuri employee. It was later confirmed that this was an astroturfing attempt by Sucuri when the COO of Sucuri visited our website and contacted us using the same computer two weeks later. In our reply to them we mentioned the astroturfing, which they didn’t deny. We don’t know if this is a one-off attempt or if this is a common thing for Sucuri, but you should be on the lookout if you are reading something about them. You also have to wonder what other unethical actions Sucuri might also find acceptance to do.

The comment, which can be found in full at the bottom of the post, is a good lesson on what not to do if you are going to attempt to astroturf. To start with the name you use shouldn’t be something that seems so obviously contrived like the name used in this instance, Intriqued Citizen. Then you would probably want to keep your comment short and to the point. Instead the comment was nearly three times longer than the section on Sucuri in the post itself. Would anyone spend that much time with something that they were not deeply involved in? Their comment also seemed quite obsessed with us competing with Sucuri, which doesn’t fit with what we were discussing in the post (nor does it fit with what we actually do). You also don’t want to use a computer that can be determined is from your organization. Most importantly, making a bizarre rant isn’t going to be the way to help you to win over people to your point of view, which is the point of astroturfing.

We are not going to put you through the misery of us analyzing the whole thing, but there were several things that stood out for us and are worth highlighting.

A good of example of the bizarre nature of the whole thing comes in their response to us stating the basic fact that JavaScript files should be scanned for malware when scanning a web page for malware:

And this is based on what? Your extensive experience building malware scanners? Or wait, is it design? Oh no, maybe its Drupal? Oh, no, it must be publicly attacking every company that you disagree with. At least that what someone gets from reading your other nonsense posts.

In the middle of not addressing at all the substance of what they are commenting on is a mention of Drupal, which comes completely out of left field. The blog post makes no mention of Drupal and the website discussed in the post was running WordPress (which can be surmised due to the first part of the post discussing a WordPress plugin). The rest of their comment doesn’t make any mention of Drupal either. We do run Drupal on parts of our website and provide services for Drupal (as we do for a variety of software), so maybe this is some sort of weird anti-Drupal bias? You might expect something like that from a kid, not from a self proclaimed C-level executive.

Another section claims that we use their service:

Why don’t you post all your other findings of when you used it to clean your own clients sites. Come on, don’t lie, you know you use it.

We have never used Sucuri to clean up a hacked website, as we actually do our own work. We have seen the shoddy work they do, so it would also be unethical for us to have ever outsourced the work to them. On a fairly regular basis we have people come to us to clean up a website that Sucuri had previously been hired to clean up, but had been reinfected after their initial cleanup (and in some instances after they did multiple cleanups). There are certainly reasons for that which would not be Sucuri’s fault, but in all of the instances we have dealt with basic parts of a proper cleanup had not been done by Sucuri. This included not doing the most important, but also the most time consuming and difficult, part of a cleanup. We don’t know if this is due to them offering to cleanup websites without knowing how to properly clean them up or if they are choosing to cut corners (they could probably get away with that in many instances), but would you really want to deal with a company that does either one? This is something we will expand on in a follow up post, as Sucuri certainly isn’t alone in not properly cleaning up hacked websites.

Full Comment From Intriqued Citizen (aka Sucuri’s COO):

Wow, so you have obviously put in a lot of effort to get this word out to every one you can as I am seeing this on a number of search engines and Facebook. Either you love them, you are genuinely trying to get the word out, or you’re simply trying to tarnish their reputation by putting out a post that really says nothing. Which is it?

So let’s look at your post:

What appears to have happened is that Sucuri automatically flagged the code based on their signature without actually scanning the JavaScript file for malicious code, which, if their scanner was reliable, would have determined that it was not malicious.

Is this in fact what happened? Did you contact them? Did you ask the question or are you simply talking out of your rear? Did you try to understand how it works or simply look to benefit off their name?

Interesting comment here:

That should be a basic part of scanning the page for malware even if it wasn’t in that odd location or part of a signature.

And this is based on what? Your extensive experience building malware scanners? Or wait, is it design? Oh no, maybe its Drupal? Oh, no, it must be publicly attacking every company that you disagree with. At least that what someone gets from reading your other nonsense posts.

Then there is this:

When you don’t actually scan things for malware before falsely identifying them as malware, you really shouldn’t be calling what you do website malware scanning.

So instead, your recommendation is that they sign up with you? So it appears you’re a competitor or at least trying to play with the big dogs, no? Why would I choose to go with you over Sucuri has a stellar reputation and you have a… umm.. who are you again? Oh that’s right, the guy that bashes everyone and spends money on … umm.. ???

Oh, here is a juicy one:

The more troubling aspect of this for their customers is the fact Sucuri’s idea of protecting websites is detecting that they already have been hacked and then cleaning them up.

Really? That’s their idea? Odd, didn’t see that. Where did you see this? Or, again, are you talking out of your rear?

holy run on sentence batman:

Putting aside the fact for the moment that properly secured websites are highly unlikely to be hacked and that allowing websites to be hacked has consequences even after they are clean again, with a scanner this poor it is unlikely that it will actually do a good job of detecting when website are infected.

So, I’m confused, this sounds like opinion based around what? Your test of one site? Honest question, you think that’s a good objective test from a competitor? Why don’t you post all your other findings of when you used it to clean your own clients sites. Come on, don’t lie, you know you use it.

Alright, let’s look at all your even more ridiculous comments:

Your response to Buck:

At that point it isn’t even actually a malware scanner.

And this is again based on what? Your one test? Not very trustworthy assessment in my opinion, but what do I know.

There is a big difference between perfection and not bothering to actually scan for malware with something claiming to be a malware scanner.

Another empty statement with no facts.

We actually know about security. Not the kind the kind that involves throwing around catchy phrases like “defense in depth” and “security is a process, not a state”, but the kind that deals with the real world.

You do? Based on what? Your ability to detect software is out of date? Good job there turbo.

If people do the things in the article that we linked to at the beginning of the post, then that will prevent the kinds of hacks that are actually causing the average website to be hacked.

Are you serious? The crap in this post: http://www.whitefirdesign.com/resources/secure-your-website-from-hackers.html? You mean the same shit every other security company offers? Oh my you said sanitize all inputs to avoid SQL injections.. you rockstar you.. again, where was the real value in this post? I get more from reading http://sucuri.net/learn then I do from that post. But maybe I missed the sheer genius that was going to keep me safe in all that high-level non sense.

(There is more that security community can do to improve security beyond that, but unfortunately many of them are instead focused on pushing products and services that don’t fix the real problems.)

Oh, like this post and every other one that references your services section? Like that you mean?

The solution to this isn’t for people to spend money on an unreliable malware scanner or even a malware scanner that works perfectly. At best a malware scanner would tell you that the website is infected after it already has been infected.

Got it, so if I understand correctly, what you’re saying is, you don’t need a car alarm or a house alarm. As long as you don’t forget to lock the doors, get a blot lock, use a bolt lock on your steering wheel? Is that about right? Just want to make sure I understand this statement.

At that point you need to clean up the infection and secure the website to make sure the infection doesn’t reoccur. We think it is better to secure the website before it can be infected.

Oh but wait, based on what you said, there is no need to clean them up. They should be hardened to prevent this, so suck it up. No?

Your responses to Shaza:

The rest of your comment actually shows that Sucuri is reactionary and not preventative. They only fixed the TimThumb vulnerability on your websiteafter you were hacked.

Awkward, sounds like they only signed up after they were infected. If that’s the case, how would they have cleared the TimThumb issue? Is that what they did? Do you know, or are you talking out of your rear, again?

If you want to pay someone to keep your website secure (and we never suggested you should or shouldn’t do that), then you should find someone who actually does the things that keep websites secure instead of hiring a company that uses a faulty malware scanner to attempt to detect that websites are already infected with malware as you are with Sucuri.

Are you serious here? Did you really just say in your last comment not to go with people that push service or product but then push your own? Come on, that’s just retarded bud

If Sucuri was actually interested in keeping WordPress based websites secure, instead of profiting off them remaining vulnerable, you have to wonder why they haven’t had an effort to get the issues with unresolved plugin security vulnerabilities fixed.

Do you work for them? How do you know they haven’t or aren’t? That’s odd.. : /

Now, let’s see how big your balls are and if you’re really serious about bringing this issue to people’s attention. Go ahead and approve this and respond and let’s have an honest conversation. Not doing so will simply show how much of a slime ball you are putting out false information with no real facts or anything of real value that any one should pay attention to.

Posted in Sucuri Security | 1 Comment

2012 2nd Quarter WordPress Plugin Vulnerability Stats

As part of our continued focus on the problems related to the security of WordPress plugins, last month we compiled some statistics on plugin vulnerabilities found during the second quarter of 2012. As they might be useful to others we wanted to share them.

We used Secunia’s advisories for our data set as their advisories include vulnerabilities discovered by the developers of the plugins and those discovered by others, which provides a good mix of data. Secunia reviews the reported vulnerabilities so their advisories do not include false reports of vulnerabilities that we find in other sources of vulnerability data.

It is important to keep in mind that the vulnerabilities found are not necessarily representative of what vulnerabilities remain in plugins. A lot of what determines what vulnerabilities are found is what kind people happened to look for or find.

A few more quick notes on the data: we have excluded a plugin that was not ever available in the WordPress.org plugin directory, the data was generated on July 16, and the numbers in the charts do not correlate with each other as some plugins had multiple vulnerabilities.

This chart shows the breakdown of the types of vulnerabilities found in the plugins:

WordPress Plugin Security Vulnerabilities

The largest percentage were reflective cross-site scripting (XSS) vulnerabilities, which, while serious, are not a kind of that are likely to be used in an targeted hack of a website so they are not a major concern. The second largest group of vulnerabilities was unrestricted file upload vulnerabilities. This type of vulnerability can be easily exploited to place backdoor script on a website, which a hacker can then use to do pretty much anything on the website. Some may be familiar with the TimThumb vulnerability, which was this type of vulnerability. That so many unrestricted file upload vulnerabilities were found is a good reminder of need for plugins with file upload capabilities to be carefully scrutinized to insure that plugins with this type of vulnerability are not available in the plugin directory.

This chart shows the number of plugins with vulnerabilities that have been fixed and not fixed:

WordPress Plugins Fixed or Not?

That over a quarter of the plugins have not fixed is troubling, but even worse is the types of vulnerabilities in those plugins:

A third of those vulnerabilities are unrestricted file uploads. Not surprisingly due to the ease of exploitation and power granted, we have been seeing attempts to exploit the plugins found to have those vulnerabilities.

There is good news, plugins with unresolved security vulnerabilities are getting removed from the WordPress.org plugin directory, which had not always happened in the past. That is partly due to our making sure that plugins with unresolved security vulnerabilities are reported to the people maintaining the plugin directory, so that they get properly handled. Removing the plugins does not help when the plugin is already installed and that is why WordPress needs to provide alerts for removed plugins with unresolved security vulnerabilities. In the mean time you can use our plugin No Longer in Directory to check if you are using plugins that have been removed. If a removed plugin has a Secunia advisory that will be linked to in the plugin’s report.

Posted in Website Security, WordPress Plugins | Leave a comment

SC Magazine Australia Blames WordPress Plugins for Unrelated Hack

SC Magazine Australia’s recent article “50,000 sites compromised in sustained attack” incorrectly claims that WordPress was associated with a past malware campaign and tries to link general security issues to WordPress. As we continue to see the harmful impact of the bad security information, particularly when it involves WordPress, we want to clear up some of the claims in the article and fill in the critical missing information on actually protecting against security vulnerabilities in WordPress plugins.

The most blatant error in the article comes near the end of the article where it is stated that “Vulnerabilities in WordPress plugins have been long understood. Last year, large malware campaigns including the LizaMoon attacks exploited those holes” The LizaMoon attack was part of a frequently hyped multiyear campaign that targets ASP and ColdFusion based websites that have fairly basic SQL injection vulnerabilities. It had nothing to do with WordPress or any WordPress plugins. The link they provide about the LizaMoon attack makes no mention of WordPress and we are not aware of any source that ever claimed that it had a connection with WordPress. The rest of the article isn’t much better. Earlier it says:

Attackers targeted holes in a string of plug-ins for blogging software — such as WordPress— including timthumb, uploadify and phpmyadmin.

None of those things are themselves plugins for WordPress or other blogging software, nor is blogging software the only thing targeted by hackers. We probably deal with as many websites that are hacked due to outdated Joomla extensions as WordPress plugins, so there doesn’t appear to be a good reason to spotlight WordPress for special attention as the article did.

phpMyAdmin is web based administration tool for MySQL database. Several years ago there was WordPress plugin that added phpMyAdmin to WordPress which contained an exploitable vulnerability, but at this point it isn’t a major target of hackers as the plugin was removed back then. phpMyAdmin itself is frequently probed for on our website, so that is likely why phpMyAdmin would be listed as being targeted. That doesn’t explain why it be listed as a being a plugin for WordPress or other blogging software, though.

The TimThumb and Uploadify libraries are included in some WordPress plugins and those have been targeted (though since we last discussed recent serious security vulnerabilities in WordPress plugins we have seen attackers expand from targeting just the recent Uploadify based vulnerabilities to the other upload vulnerabilities recently identified).

Later in the article it claims then claims that Plesk is being targeted (web hosts are not always good about keeping that up to date), so it appears somebody involved in the article just threw together an incomplete list of software that gets targeted without any specific relation to the malware mentioned, while singling out WordPress.

Another worrisome aspect of the article is that it cites a “malware researcher” from Sucuri, the company that has a malware scanner that doesn’t actually bother to scan a website for malware before falsely flagging it.

Protecting Against WordPress Plugin Vulnerabilities

What the article lacks, as stories about hacks often do, is any information on protecting websites from the vulnerabilities they are warning about. For WordPress plugin vulnerabilities, you would hope the answer is to update your plugins, as by the time a vulnerability is being exploited it should have already been patched. Unfortunately, in an analysis of WordPress plugin vulnerabilities in the second quarter of 2012, that we just did, we found that a fourth of the plugins had not been fixed (we will have a post with the full details of the analysis in the next few days). What makes this even worse is that most of the vulnerabilities in those plugins were serious vulnerabilities that are the most likely to lead to website being hacked. So what happens when plugins are not fixed?

When the maintainers of the WordPress.org Plugin Directory are made of aware of a security vulnerability in a plugin they will remove the plugin from the directory until it is fixed. Unfortunately, when we started looking into this earlier this year we found that many plugins had never been reported and had remained in the directory including one in which hackers were attempting to exploit at the time. Since then we have been making sure that any plugins with reports of unresolved security vulnerabilities are reported and appropriate action is taken (we have also been warning them about security issues that impact plugins, including notifying them about the recent Zend Framework vulnerability that impacted several plugins). While removing the plugins until they are fixed prevents any additional websites from being exposed to the vulnerabilities, websites already using the plugins don’t receive any warning and remain vulnerable as we have discussed before. The process of adding alert in WordPress when plugins that have been removed from the Plugin Directory are installed has begun and you can help to make sure it is given a high priority by voting for implementing that change. Until an alert is added in WordPress itself, you can get a more limited version of this functionality using our No Longer in Directory plugin (we released update for the plugin, with new vulnerabilities, at the beginning of the week).

Posted in Bad Security, WordPress Plugins | Leave a comment

Make Sure to Protect Against Serious Security Vulnerability in Magento

Yesterday, Magento released an announcement on a serious security vulnerability in previous versions of Magento that “potentially allows an attacker to read any file on the web server” that “might include password files, configuration files, and possibly even databases if they are stored on the same machine as the Magento web server”. The vulnerability is due to a vulnerability in the XmlRpc component of the Zend Framework, which was announced last week. The details of the vulnerability can be found in the advisory by SEC Consult.

Magento has provided several solutions for protecting against this vulnerability. There is a workaround, patch files for older version of Magento, and a new release, 1.7.0.2, which is secured against the vulnerability. The workaround and patch files will resolve this issue for Magneto installations still running on outdated versions, but we would recommend, as always, that you upgrade to the latest version of software you run (the previous release, 1.7.0.1, fixed “some potential security vulnerabilities” according to Magento).

If you use any software that has the Zend Framework you should check to for an update or announcement from the developers on the status of the vulnerability in the software. Piwik announced last week that the current version of Piwik is not vulnerable as “Piwik neither uses nor includes the XmlRpc component from Zend Framework”. OpenX does contain the XmlRpc competent and uses it, we didn’t check if their use is vulnerable but we did inform them of the vulnerability (we would strongly recommend strongly recommend against using anything from OpenX as they continue to have an atrocious security record). There are several WordPress plugins which contain the vulnerable component and we have informed the WordPress.org Plugin Directory maintainers of the vulnerability so they can take appropriate action.

Posted in Magento, Website Security | Leave a comment

Should WordPress Alert for Installed Plugins With Known Vulnerabilities?

Currently when a WordPress plugin is reported to have a security vulnerability it is removed from the WordPress.org Plugin Directory until the vulnerability has been resolved, but no warning is provided to anyone who already installed it. While many plugins are promptly fixed, there are quite a few that remain vulnerable for a long time or are never fixed. We think that WordPress should alert on the Installed Plugins page in WordPress if an installed plugin has been removed from the directory and provide at least a general reason it has been removed, as many are removed for reasons other than security vulnerabilities, so that appropriate action can be taken by admins. If you would also like to see that happen you can help by voting for our idea on the Ideas section of WordPress.org. To vote you will first need to create a WordPress.org Forum account (or log in if you already have account) and then you can rate the idea by clicking on one of the stars under the heading Rate This (click the right most star for the highest rating for the idea). You can also add your own comments on how the issue should be handled.

Until an alert is added in WordPress itself, you can get a more limited version of this functionality using our No Longer in Directory plugin (we just released our beginning of the month update for the plugin).

While we are discussing the issue of plugin vulnerabilities, we should say that since our last post about this we have been seeing that plugins with Secunia advisories for outstanding issues are being promptly removed from the Plugin Directory until those are resolved. This is great improvement from earlier this year when we found that vulnerable plugins had remained in the directory for years. With that happening we are now looking to make sure that they maintainers of the Plugin Directory are aware of any vulnerabilities which haven’t received Secunia advisories. We just reported a plugin that was found to have a fairly serious information disclosure vulnerability to them and they promptly took action (we alerted the developer of the plugin a week ago and had not received any response). For anyone that finds a vulnerability in a plugin available in the Plugin Directory and is unable to get a response from the developer, you can find directions for contacting the Plugin Directory here.

Posted in Website Security, WordPress Plugins | Leave a comment

Panda Security Still Fails to Take Basic Security Measure Months After Being Hacked

Nearly four months ago a Panda Security web server was hacked into and about two dozen of their websites were defaced, including the PandaLabs Blog. It is probably reasonable to be concerned that a major computer security company isn’t able to keep their websites from being hacked, but once they have been hacked the more important issue is how they respond going forward. Do they promptly take actions to insure they are now following best security practices or do they do the least possible to resolve the issue?

When it comes to website security, the number one thing you are probably are going to hear is that you need to keep your software up to date. By doing this you prevent a known vulnerability in the software from being exploited (assuming the software’s developers promptly fix security issues). When it comes to keeping web software up to date WordPress is one of the best, if not the best, at making the update process easy, so we would expect that any WordPress installs Panda Security is running would be up to date now if they had taken the hacking seriously. Let’s take a look if they have done that:

The PandaLabs Blog:

PandaLabs WordPress Version

The blog for their support forum:

La Piazza WordPress Version

The Panda Research Blog (which admittedly hasn’t been active for nearly a year):

Panda Research WordPress Version

All three WordPress installs we found were using a year and half old version of WordPress. There have been eight releases with security improvements since WordPress 3.0.4 was released.

Posted in Bad Security, WordPress | Leave a comment

Websense Continues To Falsely Implicate WordPress in Malware Infections

Several times in the past we have looked at instances where Websense has inappropriately implicated that WordPress was connected to malware infections. In the most recent instance they falsely claimed that a malware infection was only infecting a certain version of WordPress and that there were known vulnerabilities in that version of WordPress. Just a month later they came out with another post that falsely implicated WordPress with another infection. We missed this at the time they put it out because we don’t follow their reporting as it has proven to be so bad. The post was recently brought to our attention and it is worth discussing it now, as what they continue to do is inappropriate and damaging.

This time it began with a posting titled “New Mass Injection Wave of WordPress Websites on the Prowl“, which is a pretty clear implication that the WordPress software had some involvement in the infection. But if you actually read the body of the post you find that they only mention of WordPress is in saying that a “majority of targets are Web sites hosted by the WordPress”. They don’t make any claim of an actual connection between the infection and WordPress. This isn’t a small distinction, as many websites are running WordPress and therefore it would not be unexpected that a more general issue would impact many WordPress based website. (As we will come back to in a little bit, there is also the issue of how accurately Websense measures what software websites are running.) If the issue isn’t related to WordPress than WordPress shouldn’t be emphasized, if mentioned at all, as many people will unnecessarily worry about the security of WordPress. It is quite clear there posting had that effect by looking at the comments on the post and the title of their follow up post “I have the latest WordPress version – is my Website protected?“.

Because Websense provided such little actual information about the malware infection, probably because they didn’t actually have any, it is hard to determine for sure what infection they are referring to and therefore the source. The infection looks to be related to a hack of many Dreamhost based websites, due to Dreamhost’s poor security. That occurred during the same time period, the malware code looks very similar to what we saw with those websites, and the comments on the first post reference that as well. If Websense’s security researchers were actually interested in doing security research, they would have actually investigated what the underlying source of the infections was instead of creating a post that baselessly implicated WordPress as somehow being related to the infections.

We don’t think Websense is intentionally trying to damage WordPress; the reason for doing this appears to get them press coverage. Unfortunately, just as they did with Websense’s last false report, some of press spread this and its non-existent WordPress connection. PCWorld’s article is titled “30,000 WordPress Blogs Infected to Distribute Rogue Antivirus Software” (Websense’s post actually only claimed that a majority of a total “close to 30,000 unique Web sites” were running WordPress) and the WordPress logo is at the top of the article. Dark Readings’ article actually introduces more harmful information to the mix. The article says that a Websense researcher says that “WordPress is so widely used around the world, every version of it is studied and exploited by hackers”, which is highly alarming but not even close to the truth. While there have been a number of security vulnerabilities found and fixed in WordPress in recent years, there haven’t been any that have lead to a major hack of WordPress based websites. That doesn’t mean that there haven’t been targeted attacks using them, though we haven’t seen any reports of that, or that a serious vulnerability couldn’t be found (so make sure you are keeping WordPress updated), but it does mean that running WordPress, as opposed to less popular software, doesn’t put you at some great threat of being hacked.

A Majority of Infected Websites Running WordPress?

The last time Websense brought up WordPress they originally claimed that all of the infected websites they found were not only running WordPress, but that they were all running a specific version of WordPress. When we did our own small analysis of 11 websites that had been listed as infected by Google, we found that 2 of them were currently infected and either not running WordPress or running an older version of WordPress. There were others that also were not running WordPress, but were not infected at the time so we couldn’t independently confirm they had been infected. Based on that data and the fact that they later admitted that the infection was unrelated to WordPress, there data in that instance was at least unrepresentative, if not faulty in some way. The information provided this time doesn’t provide any confidence that they have improved things since then.

In their first post it says that the “majority of targets are Web sites hosted by the WordPress”. A week later in their second post it says that “when we discovered the attack, we found only WordPress sites, and after a week or so, the picture did not change that much” and that “WordPress still serves the majority of the compromised websites; however, we did see a small amount of other CMS as well”.  It’s not clear why the second post says that WordPress went from the only thing found to just the majority over a week, when the first post from a week earlier said it was only a majority at that time. There definition of a small amount seems off as well. They say that they found 14 percent were running something other than WordPress, with 10 percent being Joomla and 4 percent being “other”. That is a number far beyond what you would expect if this was truly something related to something in WordPress and had then spread to other parts of websites, which were running WordPress and other some software on different portions of their websites.

Another piece of their analysis seems even odder. They have a rather odd chart:

Websense Chart of PHP Use

The chart shows some use of PHP versus an undefined other. PHP is a scripting language, so this could be a measurement of what language the code powering the website was written in, that website is capable of running PHP code, or maybe something else. The text preceding the chart doesn’t do much to explain what it is measuring or how they measuring it:

We checked several aspects of each of these compromised websites and concluded that most of them are served by Apache webserver and PHP environment. As you can see in the pie chart below, PHP dominates the server side:

Both WordPress and Joomla are written in PHP, so even if all of the “other” were not PHP based you would expect that a measure of either websites written in PHP and websites capable of running PHP code to be 96 percent but on the chart PHP is only 94 percent. One possible explanation of this is that it could be due to some of the websites being served by CDN or some other caching infrastructure, so the underlying server powering the website isn’t measured. Another possibility is that it another example of the poor quality of their measurement infrastructure. Whatever the cause of the discrepancy, it is something that would expect to be explained if they were going to present that chart as part of their analysis.

The larger issue is why they brought up PHP in the first place. Based on the fact that so much web software is written in PHP you would expect that many hacked websites would be using PHP, without the hack having anything to do with that. While there was a recent vulnerability in PHP, found two months after Websense postings, that could lead to websites being hacked some very limited circumstances, PHP isn’t something that is generally going to be the source of the hack. In this case, their data says that six percent of the websites are not using PHP, which would be a pretty good indication that it wasn’t related to PHP. The most likely explanation for highlighting PHP usage, and not many other things, is that they highlighted this finding simply based on PHP high usage among the infected website, without having a reason to believe it is connected to the actual source of the infection. You would hope that a researcher would understand that correlation is not causation, especially in an instance where you would expect there to be a correlation.

Posted in Bad Security, WordPress | Leave a comment

False Positives Highlight Deeply Flawed Website Malware Scanners

We often get asked by clients about whether they should be using some sort of malware scanner on their website and our answer has always been no. Two major reasons for this are that with proper security websites can be protected from being infected in the first place and that these website malware scanners are not very good at identify malware. What we haven’t considered before was the issue with these scanners producing false positives. We know that when people are told that their websites are infected with malware it is stressful and it can lead to them taking drastic, including deleting the websites. Deleting a website won’t always solve the underlying that caused the infection when a website is infected, but with a website that is not infected it is just a waste. This is why it is critical for those developing malware scanners to be very careful in making sure their scanners work properly and properly detailing what they are detecting. This is something that has been disregarded by the developers of the AntiVirus WordPress plugin and the Sucuri SiteCheck website malware scanner, as we recently discovered when we were contacted by someone unfortunate enough to have run into these two tools.

We were contacted, as we often are, by someone who wasn’t sure it there website was infected. (We are always happy to do a quick free check to confirm whether a website is infected or in some other way hacked. For potential clients that contact about dealing with a hacking issue we always do this first, as we find on a regular basis that the issue they are experiencing are not related to a hack or have actually already been resolved.) They and their web host couldn’t find anything wrong their website, but they were getting warning from two website malware scanning tools. As with any check we do, it involves discussing what leads them to suspect the website is hacked and us doing some of a variety of manual checks. Automated scanners are not reliable way for detecting issues for a number of reasons. In this instance the two scanners were falsely identifying two different items as being malware. We were able to determine this after a quick review of what they were reporting.

By looking at the false positives a malware scanner produces you can get a good sense of how good or bad it is.

AntiVirus

On the page for the AntiVirus plugin on the WordPress.org Plugin Directory the plugin is described as a “useful plugin that will scan your theme templates for malicious injections” and “a easy and safe tool to protect your blog install against exploits, malware and spam injections”.

On the website we were contacted about the plugin was displaying a warning in the Admin Bar that a virus was suspected:

"Virus Suspected" Warning Shown in Admin Bar

What was being identified is shown in the screenshot below:

False Positive Shown for Theme

As shown in the screenshot the suspected virus was the use of the statement require_once. The require_once statement causes a file to be included, with the further requirements that it only be included once and that an error occur if the inclusion fails. This isn’t a malicious statement and it isn’t something that should on its own be used to claim that malware is suspected. It is possible that something malicious could be included with this statement, but as it was with this website, there are perfectly legitimate uses of it.

After seeing this result we wondered why the use of this statement was being identified as a suspected virus, did the developer of plugin believe that this particular statement was only used with malware? What about the similar include, include_once, and require statements? When went to start testing this, we saw a startling result. As can been seen in the screenshot below, the default theme in WordPress 3.4 was being identified as suspected of containing a virus, for simply using the require statement:

AntiVirus Result for Twenty Eleven Theme

A theme using any of the statements used for including files is identified as being suspected of infected, despite that clearly not being at a reliable indicator of a virus. It is quite troubling that something that is so clearly inaccurate is allowed to be in the Plugin Directory. At the very least it should have a very visible warning explaining what the scanner actually identifies. Looking at the support forum for the plugin you can see there are numerous threads involving these false positives. (There is also a topic where the self proclaimed “Hack Repair Guy” says that he recommends “this to my clients for basic security”, which is affirmation for our warning about that guy last year.)

Sucuri SiteCheck

In their marketing material Sucuri describes their SiteCheck website malware scanner as being “highly sophisticated” and that it “leverages internal definitions that are refined daily, external sources, and intelligence to identify both potentially harmful signatures and anomalies that may not be known”. They also claim to be the “de facto standard in website malware monitoring”.

As can been seen in the screenshot below Sucuri’s scanner claimed “Site infected with malware” and that it contained known JavaScript malware:

Sucuri Sitecheck Results

We looked at the code that they identified as malicious and found it to be legitimate and non-malicious. We also found that it was on a legitimate website and we could find no indication that website in question was recently infected, so why was Sucuri flagging it? To try to figure that out we looked at the malware entry that they were flagging the code for. The description given is “A suspicious remote javascript include was identified. It was set in an non-standard place (before the <html> tag) and was used to distribute malware to someone visiting the infected web site.” It is true that sometimes malware is placed at locations were you wouldn’t usually find legitimate code and it would make sense for a malware scanner to flag that for additional scrutiny, beyond a regular scan of the code for malware.

What appears to have happened is that Sucuri automatically flagged the code based on their signature without actually scanning the JavaScript file for malicious code, which, if their scanner was reliable, would have determined that it was not malicious. That should be a basic part of scanning the page for malware even if it wasn’t in that odd location or part of a signature. When you don’t actually scan things for malware before falsely identifying them as malware, you really shouldn’t be calling what you do website malware scanning.

If you are to believe their marketing claims about how great their website malware scanner is, you have to wonder how much worse the other scanners are. The more troubling aspect of this for their customers is the fact Sucuri’s idea of protecting websites is detecting that they already have been hacked and then cleaning them up. Putting aside the fact for the moment that properly secured websites are highly unlikely to be hacked and that allowing websites to be hacked has consequences even after they are clean again, with a scanner this poor it is unlikely that it will actually do a good job of detecting when website are infected. You really are much better off spending your time and money on actually keeping the website secure in the first place, instead hoping that when the website does get hacked it can be detected and cleaned properly.

Posted in Sucuri Security, Website Malware, WordPress Plugins | 5 Comments

Serious Security Vulnerabilities Recently Found in Numerous WordPress Plugins

Over the past few weeks numerous serious security vulnerabilities have been found in WordPress plugins. Many of the vulnerabilities allow arbitrary file uploads, which can be used to add a backdoor script website to a website and allow an attacker remote access to the website. When websites are hacked using an exploit of software running on the website this is often the type of vulnerability that is utilized. Other vulnerabilities that have been recently discovered include file upload vulnerabilities limited to certain file extensions, remote file disclosure (so the contents of the wp-config.php or other sensitive file could be displayed), an SQL injection, and cross-site scripting (XSS) vulnerabilities. The details of many of the vulnerabilities can be found in Secunia’s advisories for them.

So far we have had several attempts on our website to exploit some of these plugins that had vulnerabilities related to Uploadify, which appears to have been first publicly disclosed on April 5. We have yet to see exploit attempts for any of the other plugins.

After spotting the attempts related to Uploadify, we started looking to the vulnerability and if the plugins had been fixed yet. During that process we noticed that some of those plugins were among a large number of plugins with unresolved vulnerabilities listed in recent Secunia Advisories. We then informed WordPress.org Plugin Directory maintainers of the plugins with those unresolved security vulnerabilities. We also informed them, as we have in the past, that they can that they can monitor Secunia Advisories for WordPress plugins, so that they are not reliant on issue being reported to them so that they can quickly respond.

The good news to report is that many of the plugins have been quickly updated to fix the vulnerabilities and the people in running the WordPress.org Plugin Directory have been fairly proactively in removing plugins from the directory until they have been fixed (though there are still some of the plugins we have notified them that still remain in the directory despite their vulnerabilities). The bad news is that some of the plugins are unlikely to be fixed and no warning is displayed in WordPress when these vulnerable plugins are installed. Until the time that WordPress handles that properly, which we have previously discussed the need to do, our No Longer in Directory plugin provides an interim solution. On the plugin’s page in WordPress it will identify any installed plugins that have been removed from the Plugin Directory and provides links to Secunia Advisories when available. We have just put out an update with a refreshed list of plugins removed from the WordPress.org Plugin Directory and added links to Secunia Advisories for 19 of the recent vulnerabilities. The Secunia Advisories include workarounds for the vulnerabilities, so that people running those plugins will be aware of a possible temporary fix for the vulnerability until it is hopefully properly fixed.

Posted in Website Security, WordPress Plugins | Leave a comment