This Blog Is Not For Reading

A blog, just like any blog, only more so

Archive for October, 2013

Recovering from a WordPress hack

Posted by Bob Jonkman on 29th October 2013

WordPress logo cleaved by axe

WordPress Hacked!

Last Friday I was finally getting around to upgrading the WordPress installations on the SOBAC server from v3.6 to v3.6.1. Surprise! WordPress v3.7 had just been released the night before!

WordPress upgrades are famous for their ease of installation. Surprise! After upgrading the first installation most of the plugins were missing, and the theme was broken. A quick look at a directory listing showed that the plugins and themes were still installed. A quick look with a text editor showed some peculiar PHP code at the top of every .php file in the plugins folders. Surprise! This WordPress installation had been hacked! Fortunately, of the five instances of WordPress on this server, only two appeared to be affected. This Blog Is Not For Reading was not one of them.

Each .php file started with something like this:

<?php $zend_framework="\x63\162\x65(…)\x6e"; 
zend_framework("", "\x7d\7(…)

Injected, obfuscated PHP code at the top of every .php file, referencing the zend_framework

Searching the Internet for “wordpress plugin invalid header zend_framework” I found a reference that makes me think this may have been possible because of a flaw in an earlier version of the WordPress code that handles comments. Most likely one of the comment fields (user name, e-mail, web address or the comment text itself) wasn’t properly sanitized, and allowed some kind of code injection (probably PHP injection, not a MySQL injection; the contents of the databases appeared to be untouched).

From the backups of the server it appeared that the breach occurred in or before August — either just before the release of WordPress 3.6 on 1 August 2013 or just before the release of WordPress 3.6.1 on 11 September 2013. If I had not been slack in upgrading to WP v3.6.1 then this breach might have been identified much sooner.

The upgrade to WordPress identified the modified files because the injected code preceded (and corrupted) the WP headers, and so WP v3.7 disabled any affected plugins and themes.

The Fix Is In

I renamed the directory containing the WordPress code, installed a fresh copy of WP3.7, cleaned and copied the wp-config.php and .htaccess files, uploaded a small image to create the wp-content/uploads hierarchy, then copied the upload folder (which didn’t contain any .php files), and then re-installed and re-configured the themes and plugins directly from the WordPress site.

Aside from the additional PHP code, there didn’t appear to be any other damage to the system. So I used the original wp-config.php (but cleaned, and with the “Authentication Unique Keys and Salts” section refreshed), and the new installation just used the existing databases. If there’s any malcode in the databases then that could re-infect the system, so I’m keeping an eye on it.

I have no idea what the malcode was intended to do. It didn’t corrupt the databases or anything else, but it’s possible it was acting as a keylogger or phoning home some other way. If I feel inclined I might try to de-obfuscate the injected code, but right now I don’t really feel like doing forensics.

Someone suggested using AppArmor to make the WordPress directories read-only. I’m not sure that locking down the WP directory is a good idea. The big new feature in WordPress 3.7 is its automatic update feature. If the WordPress directories are locked down then future security updates won’t be applied automatically. If there is an exploit and WordPress issues a new release to fix it, then a locked-down site will experience a delay in upgrading until the SysAdmin notices and upgrades manually (which is what used to happen before v3.7, but it seems a bad idea to delay upgrades when that’s no longer necessary). Also, the plugin and themes directories would be locked down, and they still require fairly frequent manual upgrades.

I sent the users on the affected sites this message:

While doing upgrades on WordPress yesterday I saw that your blog had been hacked sometime during or before August. I’ve fixed it (re-installed the code, copied your media library, re-installed themes and plugins). I don’t think any damage was done beyond the insertion of malicious code in some of the WordPress files. I don’t know what the action of that code was intended to be, but you should change your WordPress password just in case the bad guys captured it. You can change your password on the “Users, Your Profile page” once you’ve logged in.

After spending some time on Saturday fixing the two hacked WordPress sites I’m a little paranoid, and making sure to implement updates quickly. But a little paranoia is good — it’ll ensure I won’t become complacent again.


WordPress Hacks by Rafael Poveda is used under a CC BY-NC-SACreative Commons — Attribution-NonCommercial-ShareAlike — CC BY-NC-SA license.

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
Posted in code, How To, security, System Administration | No Comments »

Cryptography and Security Events in Kitchener-Waterloo

Posted by Bob Jonkman on 9th October 2013

The months of October and November are shaping up to have some great lectures and presentations on cryptography, security and privacy.

Sheet of paper, strips of paper

Keysigning materials

Yesterday started off with an informal keysigning at the KWLUG meeting. The presentation was on the Scratch programming environment, nothing to do with GnuPG/PGP or cryptography. But a few of us exchanged little slips of paper with our key fingerprints, verified that the name with the fingerprint matched the person we knew, signed the keys, and so improved our standing in the Web of Trust. I hope that this becomes a regular part of all KWLUG meetings. The more people that participate, the more confident we can be about the validity of keys we may not have verified ourselves.

Today I attended the first UofW CSClub lecture on Security and Privacy by Sarah Harvey. If you’ve been following the news about the Snowden revelations you’ll know why security and privacy is important. The room was full of computer science, math and cryptography students, so the discussions were deep and technical.

Sarah Harvey shows a slide of Edward Snowden

Sarah Harvey shows a slide of Edward Snowden

There was a vacancy in the November KWLUG meeting so I asked Sarah if she would repeat her lecture. Let’s see what the KWLUG bosses have to say

There are more CSClub lectures scheduled, check the schedule on the CSClub site.

M-209 cipher machine

KWCrypto logo, the M-209 cipher machine

I’ve volunteered to do a presentation on Encrypting E-mail with GnuPG, Thunderbird and Enigmail, followed by a formal keysigning. I’m developing the presentation notes and keysigning procedure on the KWCrypto Interest Group Wiki that was set up after the Kwartzlab keysigning party last year. Please join me on the Wiki and the mailing list — I’d appreciate the help.


Keysigning Materials picture taken by Bob Jonkman and released under a CC BYCreative Commons — Attribution — CC BY license.

M-209 cipher machine by Greg Goebel used under CC BY-SACreative Commons – Attribution-ShareAlike 2.0 Generic – CC BY-SA 2.0

Picture of Sarah Harvey taken by Laurel L. Russwurm and used under a CC BYCreative Commons — Attribution — CC BY license.

Tags: , , , , , , , , , , , , , , , , , , , , , ,
Posted in KWLUG, PGP/GPG, privacy, security | No Comments »

Why I’m an E-mail Luddite

Posted by Bob Jonkman on 2nd October 2013

Statue of a Luddite

Luddite Memorial, Liversedge

The pervasive expectation of HTML everywhere came to light in a recent e-mail exchange:

Him: Bob, have a look at this video: LOLcats at work

Me: Did you intend to send a link with that?

Him: Yes, here it is: LOLcats at work

Me: Sorry, still no link. Remember, I don’t receive HTML e-mail…

Him: Wut? I’ve never heard of someone not receiving HTML e-mail!

E-mail was never designed for HTML; it is intended to be a plain-text medium. HTML is merely cobbled on, and mail clients have no standard way to render HTML messages, resulting in different displays on different mail programs. Some mail programs, especially those run from the command line, can’t show HTML rendered messages at all.

Although I use a graphical mail client (Thunderbird), I choose to not display HTML for two reasons:

1) Security: HTML mail can have Javascript code or other objects embedded. That’s a great way to get virus infections on your computer. I don’t want any code running on my computer that I didn’t put there myself.

2) Privacy: HTML mail that links to external images allows the owner of those images to track your mail usage: When you open the mail, how often you open it, the location you open it at, what computer you’re using, and whether you forward it to others (and then, when they open the mail, how often, their location, &c).

Not to mention that HTML messages are far bigger than text messages, especially when the HTML contains embedded images, fonts, and other stuff. Now, that’s not such a big deal with fast connections, unlimited download caps, and cheap disk drives, but it will still make a difference on small-format devices like phones and watches.

That said, if you do send me HTML e-mail, be sure to embed any images or LOLcat videos. That way I can still view them as static attachments, without revealing when, where, and how often I view them.

For more info have a look at the Wikipedia article on HTML e-mail


You can send HTML e-mail to Bob Jonkman at

The Luddite Memorial, Liversedge by Tim Green is used under a CC-BYCreative Commons — Attribution 2.0 Generic — CC BY 2.0 license.

Tags: , , , , , , , , , , , , , , , , , ,
Posted in email, privacy, security | 1 Comment »

Better Tag Cloud