Brilliant, keep us posted!
Brilliant, keep us posted!
J87 mentioned he got some non WP sites hacked on this other thread:
Sorry i double checked the list of sites agin:
I have a simple HTML website on that server, this one did not get hacked.
I also have a iWeb website that has not been hacked either. (though this one is also going through a proxy security service)
still trying to figure out how they got in...
I'm having similar problems but my host doesn't seem to have a good backup and two sites were build the hours before the site was hacked.
One thing we noticed was that the database is affected, so the first widgets don't show properly. It's a major problem.
Anyone know how we can get the widgets back after the hack without reverting back? I noticed the same thing.
@Kyunaga: That's a separate issue and needs a new topic.
Based on what you folks are saying, there are some factors here that are consistent with this being the Apache-symlink-cross-user exploit that has remained unpatched largely due to cPanel and Apache both being unwilling to step up to the plate and solve this one.
The factors that lead me to think this is consistent symptomatically are:
The hack works by exploiting another account on the server somehow, probably through outdated or insecure scripts. Once that is done, the symlink exploit is used to read the database username and password for other sites on the same server (ie from your wp-config.php files) and use that to attack your WordPress installations. Joomla sites and anything with a guessable db config filename are also being attacked.
There are two fixes to this, both of which need to be put in place. The first is an Apache patch, which needs to be installed by the host at the server level, requiring root access. The patch makes it much harder to exploit the symlink issue, although there is a way around the fix via a race condition. The second part of the fix is to change permissions on all .php files to mode 600, which prevents the cross-user part of the symlink attack from working. It's actually sufficient to change mode of your wp-config.php file to 600.
Warning: Some servers run Apache and PHP in DSO mode under a single shared user. If this is the case with your host, it's fundamentally insecure and this patch won't work. However, the server is already insecure anyway and doesn't need symlink exploits as the config files can just be read. If your website stops working when you change your wp-config.php file to mode 600, then you have this problem and you either need to get your host to address it, or move hosts.
Summary - change the mode on your wp-config.php file to mode 600, and change the password on your database and, if the hack is via this method, you should be protected.
For hosts, I have a brief discussion and more details on the fix at http://whmscripts.net/misc/2013/apache-symlink-security-issue-fixpatch/
ps: Installing the free version of the Wordfence plugin may also help slow down these exploits, as it should block the majority of the SQL exploits.
The problem is we tried making a new WordPress Install and then exporting content and the theme. Not sure if the problem is the database being exported or the theme itself but we can't seem to get the original widget areas to show.
There is only one post in each of the two sites I mentioned and there is no iframes, noscripts and display hacks in there.
We're going through the theme itself looking for this as well. Any help would be awesome.
then exporting content and the theme
And thereby importing the hacker's back doors right back into your new install if you have not completely and thoroughly cleaned your database, content and themes.
Kyunaga, search your DB for the entry widget_text in the wp_options table and remove the script that has been injected into it or drop it entirely.
That is where the script should be hiding.
Okay we've checked again and it seems the hack also includes altering the theme. We don't know how to revert the theme as it was custom made for us, and the customizer (along with the host failed to keep backups despite a fairly lengthy agreement). Anyway we swapped the theme out with another theme (TwentyEleven) and found all the widgets were working fine.
If anyone knows where in the theme the widgets were affected, let us know as it would help with the final stages of cleaning. We're kind of new at this.
Since this is a custom theme, the best anyone can do is to take a guess and say "look in your functions.php file". If the newly-registered widget area isn't in there, it could be almost anywhere. You may have to bite the bullet on this one and consider hiring someone to carry out the clean-up work for you.
Had some news back from my hosts who point towards the code being passed through comments perhaps in WP.
"The WP issues are merely a modified operation of the WP alone, due to unclean processing of invalid requests facilitated by UTF sub-set usage and argument passing. These are not server problems contrary to the common belief expressed in WP blog discussion. The 403 pages were just a coincidence, and were the results of permission model issues outside web server operation completely.
I think the widget substitution and cross site scripting is a vulnerability in WordPress only, which is either facilitated by themes or comments related PHP functionality. It is well explained here:
It is by no means a server created problem, but a way of fooling WordPress into accepting invalid data that bypasses its internal sanitation. It should be enforced in HTML headers to use the correct encoding and it should be prevented by proper theme coding to not allow any PHP output before HTML has finished the header sections."
Anyone got any examples of what should be present in a secure header in WP?
rossagrant, the point the host is conveniently ignoring is how the language got changed to UTF7. If that's the default, then there's no issue and you should stop reading this now.
However, I suspect the database was changed to change the language, then the database was changed to enable the widget exploit.
Your protection against this is to make your config file mode 600 as described above, and then to change your database password through cpanel and save in the newly protected file.
It seems that about 50% of hosts are not protected against this, and the "Badi" character seems to have been using this Apache symlink exploit elsewhere as well, from what I've read.
Kyunuga -- you really should have had your own backup, and blaming the host and the developer doesn't change that. Yes, they both should have had backups, but so should you! Strongly recommend automating a backup of your site to an off-server machine, given the lack of your hosts' understanding of security. (speaking as a host)
My host also said this regarding sum link:
I have double checked that symlink if owner match is enabled and set to on in default Apache web server configuration, according to the recommendation in the post. Mind you this is a setting that was present before the WP database injection techniques were discovered, and is a configuration in cPanel present in the server administration WebHost Manager by default. As for the permission model, this server uses PhpSuExec meaning it can not serve PHP files having world writeable flag, or an error 500 is generated and script not executed. This forces a more sane permission model where users are discouraged into doing anything permission related since the web server already has write access by default permission levels, and open basedir protection restricting each PHP instance to its homedir is enforced too.
It's a bit over my head, but does this cover what you have queried above?
I guess I can change my wp-config permissions to 600 no problem.
Let me know if that is all I need to do.
I have already updated passwords absolutely everywhere.
Thanks so much for your time.
Ross, when the account is hacked they can disable the SymlinkIfOwnerMatch setting in the local .htaccess file; not 100% sure whether the host would have been able to make the setting forced on. I'm afraid all the stuff after "As for the permission model..." is just not relevant in this case. And regardless, there is a reliable race condition that can be used to exploit the server even if it has SymlinksIfOwnerMatch set!
In any case, for it to be used to hack your account, they don't need to change the setting in .htaccess as they only need to use one account on the server to hack all the others - it's used to read the wp-config.php file and the details from that file are used to hack your site's database.
So, long and short of it is, change your wp-config.php to mode 600 and change your database password after doing that (again if you had already done it!).
And you could helpfully pass this info on to the host. Most hosts don't understand this, so they're totally not alone!
ps: even if apache is fully protected, there are other ways to read any file on the server. openbasedir can be avoided in a wide variety of ways. Now this style of hack has started, you can guarantee that clever hackers will mutate it fast. Change your wp-config.php file mode now to avoid the rush!
Thanks Brian, that's super helpful and I have passed it on to my host.
I have now set the wp-config.php permissions to 600 and also moved them up one level to root, so hopefully they are well locked away now.
Will keep everyone posted here when I hear back from my host.
Out of interest, I am on a kind of 'shared' dedicated server.
It's a decent server but there are 12 of us on it, not hundreds like you usually get.
Would a VPS stop any of the cross site scripting?
I think I want my host to move me to a VPS as opposed to the current setup. Would that be even more secure?
From what I've read and from the couple sites I've examined with this issue, the problem appears to be specific to certain shared hosts. This does not appear to be a problem with WordPress itself.
Basic security tips:
- Set the permissions on the wp-config.php file to 600. If this "breaks" the site, then you can adjust it to 640 or 644 to make the site work. However, the site may not be secure in these circumstances on a shared hosting account. You may want to switch to alternate hosting in such a case.
- Ensure that your shared hosting system is using "setuid" or "setuser" or "suPHP" or some method involving the letters "SU". Different names for the same basic concept, really.
- If the host uses directory-level access protections, then moving the wp-config.php file up one directory can mitigate some issues. However, this is generally not intended as a security measure, and may be ineffective. If I have the ability to run code on your server on one website, and the server has poor-intra-user security, then I can leverage that to read any files the webserver can normally read. An "SU" method would prevent this.
-Finally, if you are on a shared host and find yourself repeatedly vandalized like this, then switch hosts. If your site generates a lot of traffic, consider switching up to a VPS or something not on a "shared" host to eliminate this as a problem.
Note that the initial hack has nothing to do with "cross-site-scripting", and the "UTF-7" thing is a red-herring in this specific instance. It is not a prime-cause of the attack, nor is it related to how the site was compromised.
Just out of interest, has anyone been hacked by this that WASN'T on a shared server?
Anyone get hit on a VPS or dedicated server - not in a shared environment?
Interestingly enough no. Are we allowed to name which hosts were hacked and what wasn't? I've got 3 shared hosts on my end and one that I'm helping out for and only that one (that I'm helping out for) got hacked.
Also any pointers on what I can tell the hosts to patch up? The hosts are apparently denying anything happened and are saying it was outdated wordpress... but I have 3.5 across the board. We're vigilant about updates. Cpanel always worked fine and that seemed to have escaped the problems that other people mentioned.
Are we allowed to name which hosts were hacked
There is no rule here to prohibit it and it might be very useful to compare notes in this particular case.
The only information that we have is a claim that this was a server hack via an insecure site on the server.
@rossagrant: I cannot thank you enough. Your fix has got my blog back up. I'm not a coder, nor do I use wordpress for any professional reasons, but like everyone else I have wasted hours trying to work out how to fix it.
I had given up, and was about to resign myself to a long down-time, when I just thought I'd re-check this thread, and within 15 minutes my blog was back.
Thank you, thank you, thank you.
If there is any info I can give you that will help figure out how they got in, let me know. I won't randomly post info, as I don't know what is helpful.
Thank you again.
No worries eplans, glad you got it fixed!
Esmi, I'm not sure if we should post hosts as those that are less pro-active in fixing this issue may be retargeted.
Perhaps when we know everyone has heard back from their hosts with what action has been taken and that any potential issue has been resolved.
People right now need to be setting their wp-config.php file to the permission 600 if possible and moving it up one level above the default directory.
That will stop anyone from reading DB passwords if they are hacked.
You too should do that eplan.
FTP into your install and right click your wp-config..php file, click on permissions and change it to 600.
See if the site still functions properly. If not use 640.
Then when it works, move your wp-config.php file up one directory into the root of your server.
If it all works and your blog functions leave it there, it will be much safer.
I am not on a shared server and still can't seem to figure out how to get my website up and running.
I was unable to find the UTF charset option in wordpress settings > reading as I am running wordpress 3.5.1, I am wondering if anyone hase a fix for this yet?
@thehighersociety You could always change the encoding in PMA - just search for UTF-7 in wp-options (option_name = blog_charset).
I got attacked with a similar attack yesterday, sidebar contains JS that replaces page contents using UTF-7 to bypass security. Long-ish blog post that describes the thought process: http://sqroot.eu/2013/02/victim-of-a-xss-attack-speaks/
Mine is hosted at Namecheap aka Web-Hosting.com. I'll try to ask if they can restore a good back-up since I only noticed the problem now. :-(
You need to start working your way through these resources:
Other than that, please post your own topics.
This topic has been closed to new replies.