Wordpress Ready

Parte V: One against the other

In this third part of  Being Hacked  I made a small list of words to search in all account:

backdoor
fx0 //rare to find
get_current_user //too many matches
gzinflate
base64_decode
gzuncompress
secureroot 

After cleaning all the webshells I found, I restarted the search. To my surprise, I found another new files installed less than one  minute ago!. Believe it or not, the hacker was spreading new webshell copies along the account… and this time he wasn’t very careful at all. He started overwriting wordpress files all over, such admin.php (if you log into wordpress you will go directly to this file (!)) Apparently he had noticed the ‘disappearance’ of the webshells installed and taking one of the last remaining, he started ‘farming’ again.

Finally, I solved the problem with three steps:

• Deactivating the plugin which started the problem
• Deleting all the webshells
• Updating all WordPress sites.

Part VI: Epilogue(?)

Checking the log of that day, I could see that in some moment, I was repairing the account while the hacker was using the backdoor. I was lucky: the hacker wasn’t a destructor activist, he simply accessed the account to take advantage without being noticed. But from the moment he installed their phishing sites, it was detected by Google (who sent me an email) and Site5.

The very next day, there were six attempts to register in the site where the vulnerable plugins was running (first deactivated, later updated). That confirmed the entry point who started the problem.

I think I was lucky, but it would probably change in the future. That’s why you have to prevent this problems.

Site5 sent me a step list to better protection to the site, what is welcome of course. (that would be a matter for another post)

What I learned:

• You can follow all the security recommendations and your site will as strong as your weakest link: a vulnerable plugin.
• Without knowing the real problem, the best solution could be useless (except radical solutions like ‘formatting’ your account…)
• Sometimes is good to know if your plugins have a known vulnerability checkin http://securityvulns.ru/ or http://www.exploit-db.com/

 

Part III: cleaning up the mess

From the first part of Being Hacked, one of the problems was to find out what steps to take. If I get in a sinking boat, drain the water does not solve the problem, while the gaps are still not covered. One of my concerns was to find out a complete phishing site installed (used to capture credit card data) inside on my own sites. The hacker had managed to upload a zip with the website , unzip it and installed it. That lead to a several questions that initially couldn’t answer:

• How did the hacker manage to enter the site?
• Where was the vulnerability?
• How to protect yourself from something that is not known?

This cleaning task leaded me to a disturbing discovering. Every site included a file signature gh.html and inside of it the hacker signature, dated 3 weeks ago. It meant the account was compromised time enough to do whatever the hacker wanted to. In the other hand, how to detect something when you don’t have a clue what are you looking for? Finally a starting point: in the logs I detected a repeated access to a album.php file in an uncommon place. What was in that file?:

This discovery uncover why the hacker could modify and install everything he wanted. The webshells are such wonderful tool who allows you to do virtually anything you want with files. Well managed can provide magic. Evidently black magic is what is usually his target. That explained how the hacker installed the scripts, but it didn’t explain how he managed to get into the account.

Parte IV: Unraveling the tangle

First of all, I had to find the webshells around the account. Since the hacker had access to all the sites, it could just install the file everywhere he wanted. I started connecting the dots: the unusual activity in one site, the phishing in another…the problems  were related. Probably the hacker used one site to get into the account and then install the phishing site in another.

Back to the problem the shells are usually encripted in the form:

echo(gzinflate(base64_decode(‘FZrHj……..

So if we search for something as ‘gzinflate‘ or base64_decode, there are good probabilities to find out any webshell, although we also have many ‘false positives’. After some research, I made this search from de the command line:

grep -H -r “base64_decode” . | cut -d: -f1

In short, this command combination makes a global search in every file in the account containing the word base64_decode and listed for location. There is some interesting information about how to look for web shell in this link and also in the following links you’ll find interesting info about find/grep commands:

http://www.thegeekstuff.com/2009/03/15-practical-linux-find-command-examples/ http://www.thegeekstuff.com/2009/06/15-practical-unix-linux-find-command-examples-part-2/ http://en.wikipedia.org/wiki/Find

It is true I got many ‘false positives’ but also I got all the webshells inside the host. There was four or five of them, in different places, different names and different versions. What really draw my attention was to find a couple of them in the following folders:

/xxxxxxx/wp-content/forum-avatars/album.php

/xxxxxxx/wp-content/forum-avatars/smc.php

The very interesting thing about them was that the webshell were inside a images folder from a wordpress forum plugin. And then I realized where was the genius of the hacker: an indocumented  vulnerability in the plugin allowed the user to upload files instead images. So I disabled the plugin to close the security gap.

(Later, I checked the plugin support and there was not records about this vulnerability. Anyway, the plugin was already updated an its vulnerability wasn’t there anymore.). Due the plugin accepted a limited image size, the hacker managed to upload a smaller webshell and with it , uploaded another more complex webshell. The rest is story.

What I learned:

• How to make global searches in my account.
• Webshells can be a useful tools in the proper hands.
• Most of WordPress vulnerabilities are coming from its plugins, instead his core.
• Keeping updated a WordPress site is useless if you have faulty plugins or it has vulnerabilities.
• Pay attention to vulnerabilities that allows uploading arbitrary files…now you know the reason

You can continue reading this story : Epílogue? or going back to the first part: You have been hacked

This is the beginning of a story, based on real events. Due its extension, I decided to divide it in small digestible parts. I hope what I wrote down here could be useful for many WordPress users, and eventhe  hackers will have a little fun with his exploits.

Compared with many Web veterans, my early times building sites and blogging has been very recent. My first sites were about 2005 (using a personal server) but I took the matter seriously in 2008 renting space on a host. In the country I’m living, the Internet connection was close to be a luxury and the idea to run a server proved to be expensive and prone to live with connection downtime on daily basis.

I started my first web site in mid 2008, and it was (and it is) about triatlhon , a sport that involves swimming, cycling and running. My first post (a test by the way) was done in mid-July 2008 and since then I ‘ve been making improvements, learning WordPress and expanding the installed sites when I got some customers. To sum up, has been three years and half from the starting point. Depending on the point of view, it may seem like a lot of time or very little, but if we speak about learning, I can assure you it is a very long time.

From the start I picked Site5 as hosting provider. You may think this is an ad (and maybe it is) but we’ll see that this provider has an important part on this story. I’ve been working with Site5 all this time and it was a rewarding experience. They have an excellent technical support and when there was a problem, they solved at once. The support is very good, prices are reasonable…yeah I’m happy with that, and that is hard to get. You see, I’m very critic with myself and if you are facing toward excellence, finding out a hosting provider who keeps its quality of service along the years it is very difficult to see.

Back to the story: while the number of sites were growing, I perceived the reality of being hacked as diffuse, distant and small,  nothing to worry about. Sometimes I think ignorance and lack of foresight can provide a sense of security.

I mean: a false sense of security.

What could be the odds that someone could hack a bunch of WordPress sites that were always up-to-date?

That kind of thoughts are not very forward-thinking.

And also the hackers are very clever…

Part I: Symptoms ignored because they were never well understood.

A month before what would be the main event, I received a call from a client telling that the activity of his site was unusually high. the client had a WordPress site with  Statpress Reloaded plugin installed so he could easily review the activity.

I checked the statistics, finding these numbers:

Any blogger would be happy to know that your site has an increasing traffic, but if the site is a starting corporate profile, without updates, a dramatic increase of visitors is something suspicious. Also, a sudden change from 10-20 daily visitors  to  300-400 daily visitors in a few days is at least unusual.

The Statpress  plugin is nearly useless in this case. It will give you a clue only in the last 10 activities and in this case, all of them pointed to a the same page:  Camera just installed detects carjacking.  This was the only update in months and there was nothing in there. The real problem stayed  behind the curtains but I couldn’t realize it until much later. If we only get the last 10 pages accessed and we have at least 1000 pageviews, we’re missing the complete picture here.

Finally I concluded that there was some sort of script that recorded comments on that page, (there were hundreds of spam comments also), so I made sure that Akismet plugin was working, I added a captcha plugin to avoid such problems and decided to close the problem.

To be honest, I was far from over.

Part II: your account was suspended

Few days later Site5 detected a serious phishing problem in other site on my account. They sent me an alert by email three times. The problem was that every email alert were filtered as spam , and my account was deactivated 48 hours later without even know that!

This is the worst way to be aware about a problem.

 

 

So I had a weird traffic problem in one site and a phishing problem in other. Were they related? I didn’t make the connection at that moment. I contacted with Site5 and they reactivated my account. An account suspension means that every site in your account will be down. That was a serious impact.

And the phishing implication was disturbing. It meant that someone had found a way to upload files to my hosting. Somebody had privileges enough.

My account was compromised.

What I learned:

• Check spam from time to time. The filters are not 100% accurate. Update the filters if some right email goes to spam.
• Is good to have a tool to check logs. (More on this topic in future posts)
• It is good also to have a record log. Even there was a way to activate a record log, by default the server recorded only the last 24 hours. After that I turned on a continuous recording mode.
• Don’t overlook the problem. Sometimes the rabbit hole is more deeper that we think.

You can continue reading this story : Cleaning the house and Epílogue?

A asked myself a question: How does WordPress position itself  in relation to other CMS systems?. For this I turned to Google Trends which compared three popular CMS systems: WordPress, Joomla and Drupal.

The results are interesting. It shows that at some point in the year 2009, the constantly raising WordPress exceeded Joomla trend.  Joomla in turn has started a slight decline, while Drupal although slightly below, maintains a continuous growth curve, far from its rivals.

In my previous post I was commenting about how to convert a WordPress Theme into a Child theme. ‘Child’ sounds like underpowered to me but I think I have to see it more as ‘young’ because a child theme could be extremely powerful, something what I will try to demonstrate over the following posts.

This brand new Child Theme that I called Clone Freemium is based on Thematic and is derived from the Freemium Theme.
It will look exactly as Freemium, but is a Child Theme. The heavy lifting is done by the functions.php file where you can find all the code needed to custom the theme.
You can download this Child for Free at the download page. Drop me a line about your thoughts.

Let's face it: build a theme from scratch could be hard. Lucky of us, we have Theme Frameworks... and life will be really easy right?. Oh, well...sort of. I think that build a theme inside a framework, any framework could be a headache. Well, for me it is. Consider more variables and more options when designing a new theme isn't help me at all. I have to divide the effort in two different ways, one for designing, one for taking care of the framework... Read the rest of this entry »

You got me. After I did a plugin to solve this problem, Scribefire solve it after all. Eventually it would happen someday.
One good side: Scribefire get better & better, and I learned to make plugins after all.
The King is dead, long live to the King…

Is that possible?

I was testing many twitter plugins for wordpress. Every one has some in common: they didn’t work with weblog clients. There is some kind of technical problem-concept in WordPress. The only one plugin that I found working is the brilliant Alex King’s Twitter Tools. It will send a twitt when you do a new post, I don’t know if can be tweaked with actions send a Twitter msg when you edit a post.

So what’s the buzz around XMLRPC? What is all about it? If you read in previous post One Ring to Rule Them All – Part I and Part II the idea is to get some tools to help you control your blogs in a remote-fashion. Expand your vision and imagine you have many blogs to control(maybe is already your scenario). What kind of tools will you use in such situation? I’m open to suggestions so let me know what you think.

I have been working around this XMLRPC limitation and I finally I got a simpler (maybe not that simple) workaround. This research lead me to a new plugin that I built: Another Twitter Updater.

Xmlrpc-enabled means that you can work with any weblog client and you won’t have any problems, so that’s is the main reason I’m releasing Another Twitter Updater plugin. Go to the Download page page to test it.

The most annoying thing in Scribefire was its inabiltiy to make custom fields in WordPress.

To keep things short, that bugged to me sometime until I decided to build a little plugin to workaround this problem.

Actually I’m thinking that I could do the same using shortcodes but for the moment you can test and enjoy the Scribefire Custom Field Plugin. Access to the Download Page and tell me what you think.

A short story.

Mike is beginning with your blog. One site, one browser, one wordpress editor. He is happy with it, but he has so many areas to cover that it decides he want to work with another blog. Two sites,  two editors.

Life is good.
Mike starts blogging both. Their sites are growing and he’s becoming a blog writer. Log in one blog, write, log in another blog, write… is that just easy. He doesn’t even need to remember log details for each site, the browser does it for him. One small problem though: some times it is painfully slow to edit with WP editor. If he works from Iphone it could be worst.  So many ideas to write, so little time… He wants to write post under 5 minutes, like a Twitter-blogger.

Time goes by and one day he begin another blog. He is working for a client. Three sites, three places to login and write.
Three windows, one for every blog. Things are going good, with some complication but he can handle.

Life is good… but it could be better.

Sometimes he is posting in the wrong places, but it’s alright, it is easy to fix and repost in the proper place. Every time he uses another computer he has to setup from scratch.
Sometimes he wishes to optimize its times, and he wanted to know how to do it.
…
(a year passes).
…
Mike is now blogging actively in few sites, for free, for itself and from other customers. It is getting complicated to follow each one. many users, paswords, and it is beggining to be crazy when he has to upload content on every one. Some time ago he decided to use a personal laptop. He refuses to use another computer, the setup is simply time consuming. Life is something between earth and hell.
***************************************************
Ok, let’s multiply this scenario in some degree. What about if you are a professional blog writer maintaining a couple of sites, what about 10 or 20 blogs? Ok, I’m exaggerating a little bit (or isn’t?), we don’t have to go that far to understand what I’m pursuing here, but what if you are posting in many blogs? Is there any tools to aliviate your tasks?

They are indeed. The weblog client are here from sometime. They have some in common:

• Write post withoout having to be online
• Save drafting
• Faster interface
• Better formatting (well, it should be)
• Cross-post multiple blogs
• Local backups

Scribefire has all of this and a few others:

• Lightweight since it is a Firefox plugin
• easily upgradeable
• continous support
• Portable. If you are a traveller and use different computers, chances are that you use Firefox Portable. No many  blogging clients are portable (is there any?). Scribefire will go with you and with every Firefox Portable version you have on your pendrive.

I tested many blogger clients. I think BlogDesk is nice one, it has a minor drawbacks (non portable , some details related about how to handle draft/post items). Maybe one of the annoying problems (to me) is the inability to handle custom fields, something that we can discuss later in other post.(Yes, there is a solution)

To the point: the main factor for a weblog client is its ability to remote-blogging. You don’t have to log in your blog to post. With a proper configuration, it is much faster to blog from a weblog client than from wordpress editor itself.

Tell me what you think. Grab your timer and do the math.