Sadly, its necessary for me to leave these reminders here:

If you get eval(base64 hacked on wordpress/dreamhost

I have a shared host on Dreamhost that just got hacked to shit. A fairly standard hack, and nothing particularly inspired, but nevertheless some clients from years ago weren’t too happy. If this happens to anyone else, here’s the fix (for now)…

Dyslexic Mayans Want to Sell You Cialis

My shared host account got hacked-TFU last Monday. After looking a little closer it became clear that there had been more than one break in. Apparently my account also got hacked last November, three times in December (twice by the same hacker!) and once in January too, so for the past few months my server has had a back door like Dennis the Menace’s hanging pajama flap.

Simple cleanup solution for the latest WordPress hack

If your site got hacked on the last mass infection of WordPress sites out there, we have a simple solution to clean it up.

Via SSH:

If you have SSH access to your server, run the following commands on your web root:

$ find ./ -name "*.php" -type f |  xargs sed -i 's#< ?php /\*\*/ eval(base64_decode("aWY.*?>##g' 2>&1
$ find ./ -name "*.php" -type f |  xargs sed -i '/./,$!d' 2>&1

And, oh yes—don’t forget the spaces-in-filename clusterfrak:

Unix/Linux — find & xargs — Spaces in filenames

Spaces in filenames can be a problem when using find | xargs combination.

To solve this, use:

find . -print0 | xargs -0 

This tells find and xargs to use the ASCII NUL character instead of space to end (separate) the filenames.

Sometime last July, the Movable Type setup that powered every weblog on our various domains went belly up. All logins failed, password retrievals failed… the database appeared to be empty. But the database was still there, and still flush with all that data. Logging into the web server and running “strings” on the database files showed that all the user accounts and blog entries were still there. So my problem was not that the database was gone – it was that Movable Type somehow couldn’t access the data. I backed up the errant database and went poking around.

I tried re-installing Movable Type from scratch, using the original install files I had stashed away. Still no dice: “invalid login.” I did a new install of a blank Movable Type setup – worked like a charm. That told me I definitely had a database problem, not a problem with the install files. The Oracle of Google told me that others had suffered the same problem:

• http://www.sixapart.com/movabletype/forums/lofiversion/index.php/t25580.html
• http://www.djchuang.com/b2/blog.php/2004/05/18/
• http://www.sixapart.com/movabletype/forums/index.php?showtopic=41725

One of the posts I ran across recommended the MT-Medic plugin. Sounded great – I installed it, then configured and ran it. Same result: no authors, no weblogs. But I knew, having seen the data, that it was all still there. The same post that mentioned MT-Medic also contained the following nuggets of information:

This can be fixed by converting the DB files over to the format used by the new library version; please review the Knowledge Base article on Converting Berkeley DB Files To New Version for more information.

It linked to an entry on upgrading the database version. “The easiest way to convert the DB files is to use the db_upgrade program.” Great! I could just run the “db_upgrade” command. Except… no such program existed on my server! So I then tried the burdensome “dump and reload” method at the end of the article. After laboriously typing in

$ db_dump -f author.db.data author.db
$ mv author.db author.db.old
$ db_load -f author.db.data author.db
$ chmod 666 author.db

…for more than two dozen files, I thought I was ready to go. I fired up the login window… INVALID LOGIN.

Now I was mad. But one guy, Dylan Parker seemed to be having the same types of troubles I was having, and he was equally determined. I re-read his article for clues. Ultimately, I never had to try his solution of upgrading Perl modules, because this paragraph gave me all I needed:

First off, my web hosting site didn’t appear to have db_upgrade, db_dump, db_dump185 or db_load installed. I hunted all over the directory tree and eventually found them in /usr/local/bin but they had the prefix db3_ instead of db_. Be aware your hosting company may have renamed these utilities. Remember… the locate and whereis commands are your friend.

Db3? Locate! Five seconds later, I had found the “db3_upgrade” program that had eluded me while I was searching for its little brother without the 3. Ran it, went to MT-Medic, waited with bated breath for it to load, and magic! The database spilled its guts across my screen: authors, blogs, everything. Moving to the login window, the entire Movable Type installation was back at my fingertips, fully operational.

My next item of business? Export! You’ll soon be seeing some of the old blog entries nestled in new blog homes. Hopefully no other Movable Type users have to go through what I went through, but if they do, I hope this note helps.

Remember, back up your data often.

UPDATE: I’m not the only one.