We just wanted to post quickly and let everyone know that recently a supposed SQL injection vulnerability was found in WPtouch (the free version). This report is false.

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, and have on numerous occasions 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.

Earlier today the WordPress team noticed suspicious commits in the WordPress.org plugin repository: WPtouch was affected, as were the AddThis and W3 Total Cache plugins. You can read more about it on WordPress.org.

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!

We’ve heard from you: each upgrade of WPtouch is painful, we know- you add your custom icons, get everything all set up… only to have to re-add and re-add them over and over again with each successive upgrade of WPtouch.

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.

Just before the New Year we fell victim to a malware attack, which targeted our webhost and compromised our account security. Though it’s a reality that no form of hosting is 100% secure, we’ve decided to move from Bluehost over to the more established Media Temple, a host which we’ve taken issue with in the past but offers more of the types of hosting features we need, anyways (including more security).

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!