Being Hacked: Part III y IV – Cleaning the house

 

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?
When an account is compromised, all the sites in the account are. You cannot simply take down your blog to solve the problem, that is a blind way to fix things and if you ignore where the problem is, your are delaying the inevitable, because in some way or other you will have to deal with similar problems in the future.
First of all, I started cleaning the account. Every unused site or file for testing purposes was deleted one by one. That implied an meticulous examination of everything inside the account to alleviate the task of dealing with the problem. After a thoroughly revision at leas 10 test sites were deleted.

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?: Un webshell en una de sus muchas variantes

A webshell in one of its many variations

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

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Leave a Reply

Language
Twitter