What Desktop Innovation Needs to Succeed
Open Source Feminism: The Unfinished Revolution
Why Debian Is the Gold Standard of Upstream Desktop Linux
Yesterday's Man: The Fall of Richard Stallman
What's the Future of Free Software?
October 30th, 2014

Drupal Hack & WordPress Users

It’s not a good day for Drupal users, with the security folks at the CMS platform telling all users to consider themselves compromised if they didn’t install a security patch within seven hours of its release on October 15th.

Fixing the infected sites will require a bit of work. Sites will need to be taken offline, and the current install of Drupal blown-up and replaced with a backup from before October 15th. Any changes made made to a site since that date will have to be redone. Site owners will also need to notify their hosting companies of the situation, since the Drupal exploit could also be used to hack into other sites on a host’s server. Hosts will not be happy to hear this.

Users of other CMS platforms can give a sigh of relief — after all, they’ve dodged a bullet — but they’d be well advised to pay attention; a similar scenario could play out on any platform at any time.

Because of automatic upgrades at the point level, standalone WordPress users whose sites aren’t hosted by WordPress may be less likely to see an exact repeat of the current Drupal situation, but that doesn’t mean they can ignore security. Major upgrades to the platform, such as the recent update to 4.0, still require user action, and the Drupal vulnerability illustrates the importance of updating to the latest and greatest version of a platform in a timely fashion — like now. Along with gee-whiz new whistles and bells, every WordPress upgrade will include new security fixes — and you definitely want to have them firmly in place.

This also applies to plugins. Keep them up-to-date.

Most WordPress exploits don’t take place through the core WordPress install, but through plugins, which are mostly unvetted and sometimes designed by amateur coders. Here at FOSS Force, our policy is to look for plugins designed by companies that specialize in WordPress plugins, and will use them over others if they suit our needs. This is not always possible, so we also look at how many times a plugin has been downloaded, its changelog to determine how well its being maintained, and user satisfaction.

Its also not a good idea to leave an old, no longer used plugin on a site in a deactivated state, as a deactivated plugin with a vulnerability might still be used to gain access to a site. If a plugin isn’t being used, delete it. If it’s ever needed again, it can always be reinstalled.

On some of our sites, we use the Wordfence security plugin that’s designed and maintained by WordPress security experts. Although this plugin might be a bit daunting for newbies, it offers a depth of protection we haven’t found in other plugins.

Mainly we use it because the Wordfence folks notify their users by email whenever an exploit (either against a plugin or WordPress itself) is found in the wild. The notification explains what plugin is affected and advises users on what action to take. With an affected plugin, this usually means upgrading (if an upgrade is available) or uninstalling the plugin until a fix is in place. This is particularly useful as it gives site operators a quick and much needed heads up as soon as a security issue arises.

It’s also important for WordPress users — again standalone users not being hosted by WordPress where security is handled by the host — to protect against brute force attacks. A brute force attack is when a black hat attempts to gain administration level access to a site by making repeated attempts to guess usernames and passwords. This is mainly done through bots which can attempt thousands of log-ins a minute. Most websites are constantly under some sort of brute force attack.

Although strong passwords are the first line of defense here, we also recommend using a plugin, like Wordfence, which limits the number of times a particular IP can unsuccessfully attempt to log-in before being denied access to the site for a specified amount of time. The time-out period doesn’t need to be long for this to be effective. On our sites, we generally allow five failed log-in attempts with a time out of fifteen minutes. This cuts a brute force attacker down to twenty attempts an hour per IP — which is more than enough to send them off to look for greener pastures somewhere else.

The current situation being faced by Drupal users is evidence of just how determined the black hats are in their quest to find vulnerable sites and exploit them. According to Drupal, “Automated attacks began compromising Drupal 7 websites that were not patched or updated to Drupal 7.32 within hours of the announcement of” the vulnerability. On any site on any platform, paying attention to security is just as important as paying attention to content.

Christine Hall has been a journalist since 1971. In 2001, she began writing a weekly consumer computer column and started covering Linux and FOSS in 2002 after making the switch to GNU/Linux. Follow her on Twitter: @BrideOfLinux

3 comments to Drupal Hack & WordPress Users