The vulnerability declared at packetstormsecurity.org and other security alert-type sites is impossible.

There is no ajax.php file in the root of WPtouch, therefore this vulnerability is flat-out impossible.

We take WordPress security seriously at BraveNewCode, having previously issued updates for security exploits in our plugins that we’ve found before they’re in the wild.

We know WPtouch is a popular plugin and one that can be targeted because of it’s popularity and wide install base. We work hard to ensure the safety of our plugins on your WordPress installations.

If you haven’t updated WPtouch in the last few days, then this issue will not have affected you. But we encourage anyone that is running WPtouch version 1.9.27 or 1.9.28 to update to version 1.9.29 immediately.

We apologize to anyone affected by this issue, and thank the WordPress team for contacting us about it and working diligently today to remove any suspicious code.

There’s been a lot of hubbub lately regarding security and WordPress. You’ve probably read a few of the more popular articles about the matter, and likely heard some of the opinions from notable technology gurus. Some of the solutions to increase and maintain security for a WordPress installation are rather straightforward— others… not so much. But they all don’t do anything after an attack or compromised WordPress installation has occurred. This is what Integrity for WordPress seeks to change.

We’ve come up with a plugin that uses a variety of methods to detect if WordPress has been modified in any way. We’re calling this plugin Integrity for WordPress, and it’ll do just that: verify the integrity of a WordPress installation, including themes and plugins. If they are hacked selected e-mail addresses will be notified immediately about the change, told what file(s) were modified, and given some options to act against it.

But we’ll get more in-depth with what Integrity does a little later in the article. For now let’s look at existing solutions so we see what Integrity isn’t.

A, B, U: Always Be Upgrading

Matt Mullenweg, co-creator of WordPress himself recently recommended and advocated that users are best protected by trusting WordPress’ security, with a caveat that it’ll require WordPress users to be running the latest release always.

This approach is indeed a valid one, and certainly for many users it’s easy enough to follow. It doesn’t ensure certain types of WordPress attacks or compromises don’t happen but it does protect against some of the more serious and dangerous ones. However, there are real-world use scenarios where ABU is next to immpossible, if not just impracticable.

We have several larger clients who on an hourly basis are monitoring their websites, making redundant backups, adding/changing content and so-on. If they’re going to do an upgrade they’re going to backup the entire ftp environment along with grabbing a database backup, and that costs time and money.

We also have clients who have an intimate theme/plugin scenario where an upgrade may possibly disrupt this. We work as hard as possible to future-proof our work but other plugin developers and the whole of WordPress itself can’t be quantifiably determined with regards to what will happen next and how it will happen.

So let’s assume there’s a pool of people for whom ABU isn’t viable.

Permissions and Server Side Security

We don’t profess to be gurus in these areas ourselves, but their are some rudimentary precautions and steps you can take to add security to your self-hosted WordPress installation. They’re a very good idea but often require more than a freshman’s knowledge when it comes to applying them properly to your WordPress install. Setting the correct permissions requires knowledge of FTP programs and unix; modifying php.ini or similar requires at least some working knowledge of Apache and server environments. Every web host is also a little different in how they apply settings, what type of allowances/blocks they allow customers to control, and so on.

User Accounts / Coding Practices

Another way for WordPress to be compromised is through the admin account or by using certain types of PHP code in a WordPress theme. Once a hacker has access to an admin account they can do pretty much anything. If your theme contains easily compromised code it’s impossible for WordPress to protect, save for WordPress deciding not allow that code to be used at all which isn’t a very nice approach— potentially thousands of websites unknowingly running themes with these types of holes would be broken instantly upon a WordPress upgrade that disallowed such code.

Existing Plugins

Looking at the WordPress repository for security-related plugins you’ll find a number which on the surface look to be helping the WordPress security scenario but ultimately fail to cover some of the most basic routines (such as checking WordPress and user files for changes) or scanning and repairing permissions on a WordPress install.

So there are indeed plugins out there, but most aim to cover one specific area of WordPress security and none actually prevent themselves from being compromised.

Introducing Integrity for WordPress

Integrity for WordPress does a couple things which are unique. First, it looks at your ‘WordPress Fingerprint’ to determine what is a healthy environment for your WordPress install. It’ll make some recommendations for you and provide some one-click options to beef-up your WordPress security if you choose, but you don’t have to if you don’t want to, and Integrity will still help you if you have a security issue.

There are occasions and circumstances where file and folder permissions may be loosened intentionally, and we think it’s unrealistic to expect all users to remain vigilant on security fronts such as permissions— it’s simply not going to happen because it never has happened, even when their were/are very good reasons for this to be so. Maybe you get an error trying to do something because a particular plugin requests permissions to be changed so you do so. Maybe you have some custom code which needs a more lazy chair environment to run. Regardless whether it’s as a result of sloppy or incorrect code Integrity seeks to add protection and detect issues on your WordPress install.

One of the more common forms of attack on WordPress (and many other kinds of) websites is a Cross-site scripting (XSS) attack. The exploit is pretty simple and in many cases it’s not about compromising your WordPress installation but instead adding chunks of code which represent malware, advertisements or other malicious activity.

The attack isn’t geared to destroy or disable your WordPress environment, but rather to add the code without being detected. In the case of an XSS attack, Integrity would detect this issue and assist you in resolving it.

Last but not least we’re building a method for the integrity of Integrity itself to be verified. Any security plugin faces this pink elephant in the room issue: No matter how strong a security plugin tries to be in preventing security issues with WordPress if it itself is compromised it’s all over. That’s why we’re working hard to develop a method for Integrity to check against itself to see whether it’s genuine and unmodified.

We’ll be posting more in the coming days/weeks ahead as we push for a public beta launch of Integrity for WordPress, so stay tuned!

The way WordPress upgrades plugins is out of our control- so when you upgrade through the admin each time a plugin is moved out of the plugin folder, and the new one unzipped into it while the old is deleted.

What we can control is the creation of a folder for WPtouch in the WordPress uploads folder, which won’t be touched by WordPress, even when you upgrade WordPress itself.

With WPtouch 1.8 you’ll be able to upload your custom icons (securely) and select & activate them- and even delete them! And each time we release a new update you’ll never have to worry about your custom icons disappearing again.

We’ve also worked on hardening WPtouch a little and fixing some more bugs, so we think it’s a great update for everyone.

Look for it soon.

In the coming days we’ll be offering up for our readers a couple tips on securing your WordPress install, to make sure that the ‘front end’ types of attacks are prevented. In this case there was precious little we could do but restore our files, and that was troubling enough, as we moved gigabytes worth of data between servers.

All of this brings rise to the number one thing you can do to ensure that things are always safe online with your websites? Backup!

In the best case scenario, it drives traffic to your site and helps advertise for you, freely. In the worst case scenario you piss off your webhost and in turn have outages.

NOT AN ISSUE

Case in point: BraveNewCode. We want people to link to our downloads, our images, and so on. It’s good advertising for us, and our web setup is such that it won’t really become a problem for us, for now anyways.

TOTALLY AN ISSUE

Case in point: matthewgood.org. For Matt’s site, this is a big problem, especially when you consider 404 errors pointed at non-existent files sucking up bandwidth.

Matt gets a lot of traffic- he’s been a top blog in Canada for years and years- and as such there are links to his site and content that stretch way back. He’s also well indexed by all search engines, and that means that every image & video sitting in a directory on the server needs to be controlled in terms of external access- otherwise he’d be well over the monthly server resource limits allocated to him by Media Temple and his modest shared-server grid plan.

In order to control just who has access to what files, we’ve implemented an .htaccess rule for certain folders which restricts the ability for external sites to index, view, and link to them successfully.

The rule looks like this, inside each .htaccess file in each folder you want to restrict access to:


RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?bravenewcode.com [NC]
RewriteRule \.(png|gif|jpeg|jpg|tiff|psd|flv|mpg|mpeg|mp3)$ - [NC,F]


The first line here turns on mod_rewrite on your server once per .htaccess file.

The next line is needed to allow proxy caches. If you take it out, then anyone without a referer won?t be able to view your site. Many proxy caches, for instance, block referers? and that looks the same as a directly-entered URL.

The third tells the .htaccess file where to allow image files to be served from – in this case it will allow images be served from http://bravenewcode.com and http://www.bravenewcode.com (remember to update this for your own domain!).

The final line is case insensitive (the NC) and instructs the .htaccess file what file types to restrict the serving of. The F in the square brackets forces the current URL to be forbidden.

PEEPING BROWSERS

Lastly, if you want to ensure that someone can’t browse a directory just by entering it as a URL in a browser (visit http://www.bravenewcode.com/example/ to see what we mean), you can add this bit of code to the bottom of your .htaccess files to ensure folks can’t peep your naked goods:


<Files .htaccess>
order allow,deny
deny from all
</Files>


Another option if your server is set up so that it allows overrides is to add this line to your .htaccess file:


Options -Indexes


That instructs your webserver not to allow directory-style listings in that directory.