This Blog Is Not For Reading

A blog, just like any blog, only more so

  • Subscribe

  • Categories

  • RSS Bob Jonkman’s Microblog

    • Favorite 13 March 2019
      bobjonkman favorited something by lnxw48a1: You go to post, you look it over. It looks okay. Hit "Post" and now there are words missing, words spelled incorrectly, punctuation missing.
    • bobjonkman repeated a notice by lnxw48a1 13 March 2019
      RT @lnxw48a1 You go to post, you look it over. It looks okay. Hit "Post" and now there are words missing, words spelled incorrectly, punctuation missing.
    • New note by bobjonkman 7 March 2019
      If you have an external clock that's transmitted exclusively over an analogue channel, then everyone would hear the beats at the same time (barring speed-of-light transmission times, which is really only a factor if the transmission uses geosynchronous satellites). But if there is any digital transmission then you're back to the same problem. Not everyone […]
    • bobjonkman repeated a notice by lauraritchie 7 March 2019
      RT @lauraritchie @bobjonkman @strangeattractor what if they instead of playing reactively everyone played to a world clock? - people could always record their contributions and video magic can be done with screens in a room and then the one room is streamed.
    • New note by bobjonkman 4 March 2019
      The solution would be to have an analogue connection from end-to-end. But today, even analogue phones are connected to digital switching networks, so you can't even use ordinary landline phones and expect to get no delay. You can get "leased lines" from the phone companies that are analogue end-to-end, but leasing a tuned circuit that […]
    • New note by bobjonkman 4 March 2019
      Performing music together over an Internet connection is next to impossible if there is *any* lag at all. Typically, the lag is caused by short 10-50 millisecond delays for every router hop, at minimum one hop from you to your ISP, another from ISP to Internet Exchange Point (IXP), IXP to my ISP, and a […]
    • bobjonkman repeated a notice by lauraritchie 4 March 2019
      RT @lauraritchie More on the livestreaming dilemma...I need to have the option of multiple participants AT THE SAME TIME - like playing in a band. So maybe the keyboard and drums are in one place (live) and the sax player joins from another country via a link. Does anyone know of a platform that lets […]
    • New note by bobjonkman 3 March 2019
      The duct tape is in very good condition.
    • New note by bobjonkman 3 March 2019
      Test receive, also pls ignore
    • New note by bobjonkman 25 February 2019
      ...and wouldn't you have to include the time to insert 225,000 microSD cards in your laptop, write 256 GBytes to them, and then (after transporting them at about 10 PBytes/second, assuming 6 seconds of flight time), spend more time to insert those 225,000 microSD cards in the other guy's laptop to read those 256 GBytes? […]

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"; 
@error_reporting(0); 
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.

–Bob.

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 | Comments Off on Recovering from a WordPress hack

 
Better Tag Cloud