Webhosting Companies And Security Related Attacks

[Ipstenu]

Both and neither. I could rant, but Matt and Otto really said it right and best. It's not WordPress, it's how the net works. Look at what had to happen for this:

1) Someone saved their wp-config.php file in a way that it was readable by the free world.
2) Someone scanned for and found that file.
3) The user was using their ID and Password, rather than creating a DB user just for the blog.
4) That account had read access to other accounts on the same server
5) Lather, rinse, repeat

We're talking a perfect storm of stupid. If you pull out just one of those, the horribleness of this becomes a great deal less and we would all chastise the user for using insecure folder permissions. But. Instead, people are taking the easy way out and just pointing fingers.

Maybe this will inspire people to find out how to make more secure connections from PHP to SQL.

[kgraeme]

Well, not necessarily, in this case. It seems the the vulnerable WordPress installs were ones for which wp-config.php had file permissions set such that the file was publicly accessible. The hackers just scanned servers for publicly accessible wp-config.php files, and harvested the database credentials.

So, they were harvesting database credentials from publicly accessible wp-config files, and then using those credentials to access the database directly.

From what I understand they weren't scanning via the web but by the filesystem from a local server user account. So it doesn't matter where the wp-config file is located, if it was on the server with world read permissions then it was vulnerable because the host didn't properly sandbox user account space.

So while your patch may allow for flexibility in locating the file, I doubt it would hinder this attack.

[chipbennett]

From what I understand they weren't scanning via the web but by the filesystem from a local server user account. So it doesn't matter where the wp-config file is located, if it was on the server with world read permissions then it was vulnerable because the host didn't properly sandbox user account space.

So while your patch may allow for flexibility in locating the file, I doubt it would hinder this attack.

So, I'm not experienced with administrating shared server environments. Wouldn't setting wp-config to 0640 prevent this attack, even if all else were held equal? (Apparently, only WordPress installs for which wp-config.php was 755 were getting compromised.)

[Otto]

So, I'm not experienced with administrating shared server environments. Wouldn't setting wp-config to 0640 prevent this attack, even if all else were held equal? (Apparently, only WordPress installs for which wp-config.php was 755 were getting compromised.)

640 or 750 indeed prevents this.

The reason WP doesn't check for that is two-fold:

1. On a standard server with a basic and straightforward configuration, The site will fail with 640/750 on wp-config, because Apache won't have rights to read the file. For 640/750 servers, you must be running suPHP for it to work. suPHP lets Apache run with the user credentials. Many, many hosts don't run with suPHP.

2. On a single-site box (dedicated), you don't need to worry about other users reading your files, since hopefully you have no other users. So requiring esoteric configurations makes that setup harder.

Basically, shared hosts *NEED* to run suPHP in order to be secure. suPHP prevents webapp attacks from moving outside their personal sandbox, and it allows users to set xx0 file permissions to eliminate other users on the box from reading their files.

But, suPHP is not the default configuration, so unless the host knows their stuff, they don't do that sort of thing.

[andrea_r]

The reality is that there's a heck of a lot of web hosts out there that do not know thier stuff. They set up cheap boxes, slap on the default software and let 'er go.

Toss in support staff reading canned responses.

Now, I'm not saying this is the case in the recent attacks going around, as I have never dealt with their servers. But, I consider myself intermediate in web server things, with a couple-few short years of experience in digging around & breaking things and yes, even being hacked due to my own stupidity. The more I leanr the more I realize some of these people don't know a web server from a web browser.

The take-away lesson here is, unsecured shared hosting is becoming more common. Even a good-looking respectable-sounding company who carefully manages users can do absolutely boneheaded things and think it is perfectly secure.

I've run into them personally, and it was an uphill battle because well, for starters I'm a girl, and I'm not a "server expert" I'm just a wpmu expert. (their viewpoint). I should leave the server setup to them.

****

Is anyone else tempted to google for "set wp-config.php to 755" and then follow up with reminders plastered everywhere to at LEAST make sure people switch it back???

[aldenml]

Wow, what do you think of this?

http://wordpress.org/development/201...e-permissions/

Ok, Matt is right about the fact that it isn't a WP problem, but if you want to attack in such a way, you need to have a perfect accuracy in your argument.

"WordPress, like all other web applications, must store database connection info in clear text"

This statement is wrong. This is the case in solutions that can only connect to database engines with the same security levels of MySQL.

[Jeffro]

I don't know if that is right or wrong but it's very hard to make accurate blanket statements. Maybe he should have written like almost all other web application

[chipbennett]

So, I tried patching wp-load.php with the above code, uploaded, moved wp-config.php to my root directory, and it worked!

So, I submitted a Trac ticket with the proposed change.

Well, so much for that. It got closed-wontfix within all of an hour.

[kgraeme]

So, I'm not experienced with administrating shared server environments. Wouldn't setting wp-config to 0640 prevent this attack, even if all else were held equal? (Apparently, only WordPress installs for which wp-config.php was 755 were getting compromised.)

Yes. 640, 750, any xx0 should prevent other users on the local filesystem from reading the wp-config. But that's all dependent on how the server is configured. I've seen setups where all web user accounts share the "web" group or whatever and in that case 640 would still let users read each other's files.

On a VPS or Dedicated host though there are a whole variety of possible configurations.

[chipbennett]

I don't know if that is right or wrong but it's very hard to make accurate blanket statements. Maybe he should have written like almost all other web application

Or, like any other PHP/MySQL application.