easysale
Forum Replies Created
-
Forum: Fixing WordPress
In reply to: SQL attack on wpress 2.9.2@bottleneck and @songdogtech:
The question is, how do we know that ANY shared host is secure? If the vulnerability that allows a hacker to attack other sites hosted on the same server was as simple as having more restrictive file permissions, I think NS would have figured that out by now. And while this attack does seem targeted mainly at NS, it’s happened on other hosts over the weekend as well.
I’m thinking about moving to HostGator, but the move has the potential to be a major project–not just our WP blog is involved, and we can’t have any significant downtime. But I’m wondering whether anything short of a virtual private server at ANY host will really prevent these
types of attacks (and that assumes I know enough about Linux and Apache security to set up the VPS correctly, which I probably don’t).Thoughts?
Forum: Fixing WordPress
In reply to: SQL attack on wpress 2.9.2@cacoline & @steve D: All of our FTP passwords (except one, inexplicably) were changed last night. Shashi B. at NS confirms this was done by their team and that it was so urgent that they couldn’t notify users. (OK, but why couldn’t be we notified afterward?) In any case, you can log into your Network Solutions Account Manager and retrieve the changed FTP passwords.
@steve D: when you reset your file permissions to 640, are you sure the CHMOD command is successful? I found that it failed on any files that were originally created by the NS WordPress installer. They are owned by root (user 0), so I couldn’t change the permissions. What I ended up doing yesterday, after removing the malicious code from all the index.php’s for the fifth time, was the following workaround:
- Upload the file with a different name that doesn’t already exist on the server, e.g., index-clean.php.
- In your FTP program, rename the file to index.php. The program will ask if you want to overwrite the existing file; say yes. Refresh your FTP directory listing, and you should see that you’re now the owner of the file.
- Now CHMOD the new file to 640. Refresh and then check permissions again to be sure it stuck.
Since I set all the index.php permissions to 640 mid-day yesterday, we’ve had no more problems. But of course, I don’t know whether that’s because of the permissions change or because of something done by Network Solutions.
Forum: Fixing WordPress
In reply to: SQL attack on wpress 2.9.2We are being hit by this as well. And yes, we have shared hosting on this “bad neighborhood” server.
The files affected (at least on our WordPress installation) are:
index.php
wp-content/index.php
wp-content/themes/index.php
wp-content/plugins/index.php
wp-admin/index.phpIf you’re running WordPress, I highly recommend you download and install the WordPress File Monitor plugin. It will notify you of any files that get changed. I have it scanning every half hour. So far, we’ve been attacked 5 times since last night.
Fortunately, the code is easy to spot and remove – it’s at the end of the file, between <script> tags.
I know NS is working on the problem, but it’s hard to believe that they haven’t closed this vulnerability already.
One thing I did that may help is to change the permissions (CHMOD) on these files to 640, which should prevent write access by anyone other than the file owner. These files normally don’t need to be written to at all.