Preface on target audience:
I know they’re out there, but I’ve had a hard time finding them. All I really wanted was a guide on basic encapsulation to make my code cleaner, but so many of the guides focused instead on the Inheritance aspect (which is arguably flashier / sexier).
Got hit again, briefly. Was able to recover very quickly thanks to the Git repos I had set up previously. I found a couple extra backdoors, using some alternate obfuscation methods. Instead of the typical “
eval(base64_decode(” the attacker instead took an existing file, commented out all the code, and interwove a series of variable assignments.
I think it’s a good thing to know the enemy, and the more we know about both (a) what they are doing, (b) what they are CAPABLE of doing — the better we can both recover and detect / identify future attacks. I’ve decrypted their backdoor application and pasted it below (after the jump), with some commentary.
It looked like this:
(See parts one and two for background information.).
My sites are almost fully recovered. I’ve ditched the old fancy theme in favor of a more austere default theme that turns out to have some pretty nice features. I like minimalism anyways.
It turns out that the culprit was a vulnerability in timthumb.php. If ANY of your themes, even one you don’t currently have active, happen to use this script, please ensure that you download the latest version of timthumb.php and replace all instances on your server with that new version. It was quite common, particularly among so-called “premium” themes, and many themes that used image rotators on the homepage. Also, backup all themes on your site to your local computer, and then delete all themes you are not actively using on your blog. No reason to introduce any additional vulnerabilities.
In the aftermath, I have been able to implement a few solutions to help prevent this from happening again. I actually already had one relapse, but recovered in minutes. Here they are: Continue reading
So I’m working on this Rails app for Melissa. It’s kind of a secret, but it’s pretty neat. She demoed it at a webinar and it was received well.
One problem I’ve encountered is that her main website that manages subscriptions and users is in WordPress. Users will register with that main website and may or may not have access to the Rails application, separately (depending on their subscription level). What I needed was a method to handle User Authentication in Rails that slaves to the subscription / account information held in WordPress. Ideally, this should all keep with the DRY principle to make it nice and Rails-y.
I wanted to avoid using any messy and potentially unsecure session cookie sharing, and I also wanted to avoid doing any database shadowing. I suspected that since all the data is up on databases on the same server, I should be able to just query it out, right?
Right! Continue reading
Time for some investigative work. This post may get unapologetically technical.
So I began by looking at my access logs from the day that the compromise occurred, I started with just a full browse of the log to look for anything anomalous. Discovered a lot of hotlinking to images on my site! Squashed that problem (go ahead and try it! You might have to clear your cache first to see the effects….)
I suspected that looking for POST requests would be a good place to start since there were likely to be fewer of them.
So as I mentioned in my previous post, this blog was compromised earlier today, with the nefarious base64() hack. I’m still picking up the pieces, and viewing this as being pushed into finally switching to a new theme (I’ve been thinking about it for a while now).
The good news is that it’s not the end of the world, and if you are feeling adventurous, you can recover your blog from this and probably have most of your data intact still.
At this point, I can post about detection and stopping the bleeding. Hoping to have a followup about better prevention, if I can figure out how they compromised a fully-updated WordPress installation in the first place.