4

I have many wordpress sites hosted in a Bluehost shared hosting environment. Recently when I searched one of the sites in Google, it said "The site might be compromised".

I got alerts from Google Webmaster about a script in one of the WP sites. When I checked the sites, I found some links in the footer, mentioning "myteenmovies.net" and one another site. Whois information showed, they were Russian sites.

I also found some other PHP files with weird names, wxwz.php,xypz.php etc... The PHP code was encrypted with some eval(gununcompress(base64_decode())) like that. There was ananother file which had a comment "#Web Shell by orb".

I understand that the hacker has got complete access to my server (with Webshell script). All the sites are quite old (about a year), Wordpress 2.5. Permissions are 755. Can anyone guess or advise, how did the hacker upload the files? FTP/SSH/Cpanel passwords are quite strong. Any other ways?

Izzy
  • 8,224
  • 2
  • 31
  • 35
Sam Alex
  • 204
  • 2
  • 3
  • 7
  • it's unlikely they had "complete access" with the webshell script. They will have had the only the privileges your scripts are executed with. All of your site will have been accessible, Other sites sites on the server *may* have been accessible, Your servers OS and other services on the server are likely to be safe. – ollybee Apr 16 '11 at 22:12

6 Answers6

10

That's your problem right there. Most of these attacks are carried out by automated scripts that look for known vulnerabilities in older wordpress systems. Since anyone can look at bug reports and changelogs, it's not too difficult to engineer a script to exploit a weakness.

Your best defense is to always have your wordpress version AND your themes/plugins up to date.

I used to have this problem with a few of my defunct blogs, but keeping them constantly updated fixed it.

Do a grep on your existing blogs and look for any iframes or eval method calls in your WP directory. Also check the DB. Once it's all clean, update your WP version and themes/plugins and keep it updated.

Next login to Google webmaster and, if you haven't already, prove ownership and ask for a review of your site. The warning should go away after awhile.

JohnP
  • 248
  • 5
  • 12
  • Hi John, Thanks for the tip. I have been doing the steps which you told. But could you tell, how the hacker was able to upload the file ? How will i be able simulate? Consider, i have a basic WP installation. – Sam Alex Apr 16 '11 at 17:06
  • It depends. If it's a WP specific hack then the attack was not carried through FTP. There were vulnerabilities in the user access level part of WP. On the other hand, if it was a more general attack (I doubt that, which is why I haven't addressed it in the answer) then you need to scan your PC for malware and change the password of your FTP account. – JohnP Apr 16 '11 at 17:22
  • Ok, I agree. But there was only one admin user. and the site was a static site. WP was just used as a CMS. Any idea, which vulnerability might be used ? – Sam Alex Apr 16 '11 at 17:31
  • If it's running on WordPress, it isn't a static site. – ceejayoz Apr 16 '11 at 17:33
  • @ceejayoz yup, bingo! @Sam you'll need to go through all blog posts/bug reports to find out exactly which one. Check your DB, and take a backup and install a completely new version of WP. You might also want to go through your FTP logs to make sure it wasn't a targeted attack – JohnP Apr 16 '11 at 17:35
  • @ceejayoz, i said i use WP only as a cms. I said it as a static site, as the content doesn't change frequently.(NEVERMIND).@JohnP, Hmm, I didn't find anything good in FTP logs. – Sam Alex Apr 16 '11 at 17:44
  • 1
    That's not what "static site" means. Static site means it's plain HTML, no database / server-side executable code. A site running on WordPress as the CMS is a dynamic site even if the content is rarely updated. – ceejayoz Apr 16 '11 at 17:58
6

Welcome to reality. Your sites got hacked because you completely failed to take any precautions. Running such old and vulnerable versions of WordPress is simply asking for this to happen. Given the invitation you've created don't be surprised when people come to the party.

I suggest you either put some effert into your web sites or stop playing at being a webmaster and get someone who knows what they're doing to manage your systems and ensure all reasonable safety measures are implemented, including upgrading as necessary. There's more to a web site than just throwing a prepackaged version of software on it, typing some content and sitting back.

John Gardeniers
  • 27,458
  • 12
  • 55
  • 109
4

Unless you have the logs from the day it happened, there's probably no way you're going to know how it happened. There's tons of exploits against historical versions of wordpress like 2.5. Here's a few CVEs that might be how they got in:

Do you keep your plugins up to date? There's exploits against them too, that could be the avenue of attack too.

You could spend days looking at CVEs and exploit code but the reason they got in there (assuming it was through wordpress) was through some bug in the code. This bug was probably found several years ago, widely published, and already fixed. There's probably nothing special about your wordpress install, it was probably exploited through some automated tool looking for old versions of wordpress.

Do you keep your plugins up to date? There's exploits against them too, that could be the avenue of attack too.

If you just want to see how someone might exploit some old version of wordpress, just search http://exploit-db.com .

FTP/SSH/Cpanel passwords are quite strong

Do you reuse passwords? Is your FTP password the same for that forum you maybe registered for 3 years ago that stored their passwords in clear text and got hacked? That's another avenue of attack.

Mark McKinstry
  • 935
  • 7
  • 5
2

See FAQ: My site was hacked « WordPress Codex and How to completely clean your hacked wordpress installation and How to find a backdoor in a hacked WordPress and Hardening WordPress « WordPress Codex

Celso Bessa
  • 145
  • 7
markratledge
  • 519
  • 5
  • 13
  • 26
  • Thanks for the info, but do you have any idea about recreating this attack ? – Sam Alex Apr 16 '11 at 17:33
  • The hack came from another Bluehost account or through your old WP installs. Stay updated, and look at the Hardening Wordpress link above. – markratledge Apr 16 '11 at 23:29
  • We really do prefer that answers have content, not pointers to content. This may theoretically answer the question however, [it would be preferable](http://meta.stackexchange.com/q/8259) to include the essential parts of the answer here, and provide the link for reference. – Chris S Jul 31 '12 at 15:23
  • Chris, This question/answer is over a year old; and I realize content is better than links, but that's a lot of content to include here. Two of those links go to docs at wordpress.org and one to a wordpress employee's site, and all those links are boilerplate for the wordpress.org forums as well as WP Stack Exchange. – markratledge Jul 31 '12 at 16:06
2

This question is really old, but since I've been recently dealing with the same type of attack, here are some very basic things you can do:

  1. Edit your php.ini file to disallow base64_decode functionality. Find the line that says disable_functions = and change it to disable_functions = eval, base64_decode, gzinflate. A lot of these scrips use this function to unpack their files and get them running on your server. This will at least stop the files from auto unpacking.
  2. Change your wordpress table prefix. You'll have to do this in your MySql database as well as your config.php file. The default prefix is wp_ and that makes guessing table and field names very easy for 90% of the wordpress blogs out there. It's not a silver bullet or anything, but it'll force them to try to guess what your database names are which could slow them down enough to give up trying to insert things into your database.
  3. Change the name of your uploads folder. Wordpress allows write access to this folder via the media uploader which makes this is a really easy place for them to upload PHP files that contain shell scripts and it's likely you won't see them here. They wont show up in your media library AND they'll be buried in a place you're not likely to navigate to when using an FTP program. Just like changing the default database prefix, if you leave this folder as the default anyone with any skill at all can guess the file path to that folder. We've also gone so far as restricting file types that can be added to that folder to .jpg, .gif and .png since the uploads folder name can easily be discovered by checking the url of any image on your blog.
  4. Get a good security plugin like Wordfence. I've been very pleased with it so far.
  5. I wouldn't recommend inexperienced users to this, but another good way to keep your filepaths secret is to move your contents folder outside of the main wordpress install (ie application directory). It'll work similar to having a virtual directory, where the URLs on your blog don't reflect the literal file paths. By doing this if they try to upload to directories found in your URL they will run into errors. There's information on changing the location of your contents folder in the codex here

In general, it's a good idea to change all defaults to customize your install as much as possible. There's much, much more you can do and I highly recommend reading up on hardening wordpress and php, but simple things like this will keep out most casual hackers and those using automated vulnerability scanners.

Also know that if they had full access to your server you are going to have to change all of your user accounts. Change your account name. Change your passwords. ALL your passwords, including database, FTP... anything that requires validation is now compromised and if they have those, all the hardening in the world means nothing.

kristina childs
  • 141
  • 8
  • I see many situations where `base64_decode` could be used in non-hacker ways... and wouldn't disable it for that reason, as opposite to `eval` – Mathieu Rodic Feb 24 '15 at 22:39
1

Alex, unless you're a full-time security person, doing forensics on stuff like this is a waste of your time. Running WP 2.5, which is 3 years old, is just asking to be pwned.

A few simple rules:

  • Be very conservative in what types of files you allow users to upload to your site. Best choice is "none".
  • Keep current, tested, off-site backups of everything.
  • Use/require good passwords for all accounts.
  • Keep your software up-to-date,
  • And, if you're the sysadmin, don't expose any services you don't have to (I normally limit it to ports 80/443 for web, and 22 for SSH).
Peter Rowell
  • 343
  • 1
  • 9