ALL php files hacked = cracked account?


#1

Just figured out all my sites are hacked (they all have eval(base64… at the top). Most/all are WP sites so at first I figured it was a WP problem. But now I see that a PHP files I had in my root director was also edited. Does that mean my account was cracked and not just WP?

I have a backup of my main site from 2 months ago that is clean so I can work from that. But I first want to make sure I lock out whomever it is. Is changing my password enough? I did change it after the DH hack a few months ago.

thanks[hr]
i don’t see any weird logins from elsewhere using ‘last’ on my shell account


#2

This has happened to me as well. Keen to find out how/why it happened, and whether my site has now been compromised. It’s not just wordpress - it appears to be every PHP file on my account.

Edits appear to be around Mar 25 19:27 (server time)


#3

i can’t find any evidence of shell account hacking. i’m working from the theory that it’s wordpress-based, but just worked it’s way up the directory tree and got everything it could. i’m cleaning all the sites, changing all passwords (shell, WP, mysql), examining the databases, removing all unused plugins and themes, and reposting the sites. we’ll see what happens.


#4

My WP sites also have the same code at top of php. I’ve not checked the rest of files. Html pages seem to be fine.
I too changed passwords with last DH hack monts ago.
Dates are Mar 19 and Mar 23
There is a .logs dir in every wp installation with a txt file inside with some weird domain manes witten in it.


#5

Be sure to check, as there is quite a strong chance that it is both.

A bot script will often gain access to the account via script vulnerability (eg. WP plug-in) then upload a remote shell into the user-space, granting an attacker shell access to the account. Some remote shells accept POST’d data, which allows complete automation of the attack with no “real person” input necessary. Note that the user privileges set in Panel have no bearing on this type of shell access and that even “FTP Only” accounts can run cmdline instructions, so be sure that you scour every account.


#6

Can you either enlarge upon how to look for these uploaded remote shells, or point me in the right direction?

Very much appreciated, thanks.

Peter


#7

I haven’t had to deal with this problem, so I don’t have any specific advice for you. But another name for “remote shells” is “backdoors”, so you should start here:


#8

also see http://wiki.dreamhost.com/Detecting_intrusions to help track down the method of entry.


#9

The hard bit about offering advice on what to look for in a specific sense is that any advice given today will not necessarily work tomorrow, so any comment unfortunately must remain somewhat general as it will be quickly invalidated.

Analogically; consider the police (we) are looking for a bank robber (backdoor) in a red getaway car. The bank robber is spotted, so he stops at a panel beater’s and paints the car blue. Now the bank robber is in the same car, but the police are still looking for a red one. Such is our predicament here.

The safest way to deal with it is to delete everything and start again (nuke the entire city).

But of course not many of us would consider that a practical option.

There are an absolute myriad of string searches we could perform (that tomorrow will be inept) but generally I would begin with checking recently changed files - as is outlined in the Wiki articles coolgeek and bobocat linked to above. That being said, if we are exploited by a more hands-on approach then we must consider that the attacker could very well have altered the timestamps of any superfluous files. To our advantage, the bot scripts that are currently prevalent are not being customised much, so our chances that any recent files will still be timestamped as recent files are quite high.


#10

[quote=“sXi, post:9, topic:57336”]
There are an absolute myriad of string searches we could perform (that tomorrow will be inept) but generally I would begin with checking recently changed files - as is outlined in the Wiki articles coolgeek and bobocat linked to above. [/quote]

Assuming no backup or repo exists to use for comparison (ugh!), there are a few steps short of the nuclear option.

If you can recreate your install in another directory or account, i.e. install the same version of wordpress and the plugins/themes that you use, then you can use various tools to compare the file contents (diff) and directory structure (dry run of rsync). That will help narrow down the possible files to investigate.

Also, it seems that most shells are written in PHP and utilise similar functions or obfuscations. Looking for [font=Courier]base64_endecode[/font] is one, but also [font=Courier]curl[/font] and [font=Courier]fopen('http[/font] and similar functions can point to files that need further investigation.

I’ve added links to a few blogs that detail the process (note: not step-by-step instructions which are useless as sXi points out) in the wiki.


#11

The same thing happened to my sites, around the same time as mentioned here. I have backups of most of the files altered, but what specific vulnerability occurred with Word Press that I can fix?


#12

I don’t know if this is any help, but my Drupal sites (and my son’s Wordpress on the same host) were hacked recently.

I think it was my failure to update an insecure version of Drupal at the time I was first notified. Maybe this could be the same for Wordpress??


#13

There is no specific “one size fits all” vulnerability. Whether it be the application core, a module, or a theme that was used as a point of entry the crux of the matter from case to case is that one or more parts of the system employed was open to exploitation and you’ll need to use the resources available to you to fix it.


#14

I use neither Wordpress nor Drupal. I use Zikula. In my case I found three different problems: an old directory of files I had archived when I had upgraded the site, a piece of an old phpBB thing I had played with, and just a sloppy permission on a directory for media uploading. I made it worse by having multiple domains with the same user, which made it harder to find the problem(s) and clean up.

Threads here and the search and replace functions in BBedit helped me find and fix the issues. Good luck.


#15

sXi is correct, however, the elephant in the room for wordpress is ununstalled themes. As has been documented, last july the author of a plugin called timthumb’s own site was hacked by his own plugin. He was able to ‘fix’ the vunerability, but the original unupdated timthumb was part of the 100 themes installed as an easy install option by DH. One thing to understand is uninstalled php has the same power to corrupt your site as installed php, it makes no difference, so having 100 uninstalled themes, probably increased everyone’s vunerability times 100.

Once a hack is found, much like a burglar, a hacker installs a file manager into the php program then has a field day modifying files in your account with traps and back doors. If you have many domains and one user, the hack can invade the other files because they by default were connected to each other.

We wordpress users kind of think we are ‘on it’ when we update wordpress and out installed themes and plugins, how many of us knew that we needed to update our uninstalled themes and plugins? I certainly didn’t.

The problem with timthumb was increased in my opinion by noisy bloggers who blogged about dreamhost’s timthumb vunerability last november, this may have been the final straw, since the beginning of february, lots of scripts searching for ‘timthumb’ are trolling through every dreamhost account. In mid-march dreamhost installed a mod-security fix to eliminate the ability of these scripts from hacking accounts, but we consistantly see other scripts trolling for exactly what package (wordpress, drupal, php, etc.) you have installed, then trying to find their vunerabilities.

This process against hackers and trolls is winnable with education on our part. For us wordpress dweebs, cleaning up our wp installs by deleting unused themes and plugins and making sure what themes and plugins we are using are well supported goes a long way to making life for a troll unexciting.

For more info see the wiki hardening wordpress

-Bill


#16

I had the same thing happen to me but I am on GoDaddy shared hosting which I guess is the same as the situation where you own or control you own server. Of course I got a canned reply from GD to which I complained. They never admit anything.

Here is what I found. Yes a base64_decode( is involved but not in all PHP scripts. I found only certain names that are standard like index.php, footer.php, and template.php. I host about 11 other domains on my account. From my “root” directory down all the above files were hit. As I told GD I use no third party applications and no user parameters in PHP that need to be cleaned. I have no client interfaces anywhere for uploads or logins or anything of that nature. It is all static.

It was easy for me to fix but they will be back I’m sure.

Told GD this “If your server (it is not mine) gets compromised such that a hacker can access all virtual accounts hosted on the shared host then it falls into your area of responsibility. I cannot control the other shared accounts. It is up to you to harden it such that it cannot occur.”

All the files had the same timestamps or very close. From this I discount FTP entry. That would take too long.

They read these PHP files and as soon as they hit the PHP ending mark “?>” they wrote their code. Have a copy. They check for certain bots like Google, Yahoo, Bing etc and don’t execute their code. The code is made to looks like analytics type code and their native language is not English.
The only way I can see that they can do this is to “own” the root of the whole server. How? I don’t know. Try to tell that to GoDaddy.

From my history backup files I see that it occurred March 25 at 12:51 (MST I believe) and again March 31 at 02:41 MST. On the second intrusion the decode info changed. Checked my logs for those time periods and see nothing.

Now they send your user to this base64_decode( URL where they try to inject malware. This staging area must supply different places to go for the malware because sometimes it does not work because that site may be fixed or disappeared. The few that I saw or checked had all been created recently. Must be throw aways. Same type contacts

I also noticed on the scripts that were modified that the permissions were also changed to group rw.

I do nothing in PHP except standard include “xxxxx.php” for same code.

I had it easy compared to some of the posts I see here