Why securing file permissions is important

[AndZyk]

Right now I am not particular proud of myself, because I maybe had the first occurrence of an hacked ProcessWire installation known to mankind. But not because of ProcessWire itself, but of a stupid mistake I have made. Anyways I want to share my case here:

Over one and a half year ago I developed a medium sized website with ProcessWire 2.6.1 for a small community. In the process of releasing the site I had troubles with getting the installation to run on the shared hosting webspace. Because the hoster hadn't configured their file permissions correct, I was forced to loosen up the file permissions inside the site/assets-folder. Because I was desperate and wanted the installation to work I ended up setting every file and folder permissions inside the folder assets to CHMOD 777. I wasn't very happy with this solution and now I know how stupid it was, but I didn't knew better and at least the installation was running.

This week I wanted to make a small change to the site and noticed something strange: There was a file called sites.php inside the root folder. At this moment it was clear to me, that my installation was hacked. I immediately downloaded the whole infected installation and compared all files with my local clean installation using a diff tool (Kaleidoscope). After comparing I noticed that inside the index.php one line was inserted which included a functions.php inside the site-folder. Also I noticed that inside the site/assets/files-folder there were several php-files uploaded with the same naming convention like the generated images variants (f.e. filename-large.jpg).

So what did those scripts do? Luckily not much, that is the reason I haven't noticed this hack for a long time. The database is as far as I can tell not corrupted and the site was still working properly. All those scripts were doing, was generating spam aliases and redirecting to a medical shop site using the http host of my site.

Interestingly on my research I have found out, that most of those malicious scripts were intended to infect Drupal and WordPress installations. A few of those files inside site/assets/files are explicitly targeting WordPress specific functions. If you are interested I can share those scripts for further investigation. But I am not sure if uploading those scripts directly to this board is against the board rules, so if I should upload them to a external service, I am willing to do so.

Meanwhile I am confident to have cleaned the site from almost all malicious scripts (I will investigate further) and I am still removing all spam search results from Google using the search console. Also I am in contact with the hoster and try to sort things out, even if it means switching the hoster (which I would prefer).

Please don't be to harsh with me. I know I have made a stupid mistake and learned my lesson the hard way, but I wanted to share this story anyway to prevent others from making the same mistake. So always make sure to secure your file permissions!

Regards, Andreas

[teppo]

It's a real shame that your site got hacked, but this is definitely something we can learn from, so thanks for sharing it.

Shared hosting and lax file permissions are an easy way to get into trouble, but I'm still quite curious about how exactly the site was hacked. From what you've mentioned here (uploaded files, etc.) it kind of sounds like the login credentials might've been compromised, or did you perhaps have something on the front-end that could've caused that?

Of course if it really was an "inside job", i.e. if the site was attacked by another user on the same shared server, the files inside /site/assets/ could've been planted there manually. Did you have anything else installed on the same hosting account, another site or web application or anything?

If you do find out anything else, please let us know, but just in case: if it turns out that this was actually a result of a flaw in the system itself or perhaps a third party module, please let Ryan know of it before posting to the public forums. I'm extremely confident in the security of the core and have a lot of trust in most of our third party modules, but there's no guarantee that nothing will ever go wrong.

[Tom.]

Interesting, I agree with teppo. This could cause caution for something bigger going off here. 777 file permissions isn't great by any means, however for them to understand the ProcessWire file directories could mean that this was a more targeted attack. 

[matjazp]

20 minutes ago, teppo said:

Shared hosting and lax file permissions are an easy way to get into trouble, but I'm still quite curious about how exactly the site was hacked.

I'm all ears to hear(read) the method used to hack the site, regardless of 777...

[AndZyk]

48 minutes ago, teppo said:

Shared hosting and lax file permissions are an easy way to get into trouble, but I'm still quite curious about how exactly the site was hacked. From what you've mentioned here (uploaded files, etc.) it kind of sounds like the login credentials might've been compromised, or did you perhaps have something on the front-end that could've caused that?

Now that you mention it, the site has a login form on the front end for users. The code for it looks something like this (I kept only the important parts):

<?php

echo "<form action='./' method='post'>";

if($user->isLoggedin()) {
	// Show user name and logout button
} else {
	echo "
			<input type='text' name='user' placeholder='Username'>
			<input type='password' name='pass' placeholder='Password'>
			<input type='submit' name='submit' value='Submit'>
		";
}

$user = $input->post->user;
$pass = $input->post->pass;

if($user || $pass) {
	if($session->login($user, $pass)) {
		// Redirect to internal page
	} else {
		// Show warning message
	}
}

echo "</form>";

Is there a more secure way to implement such a form? Also the form isn't secured by an SSL certificate, which is also an potential risk.

48 minutes ago, teppo said:

Of course if it really was an "inside job", i.e. if the site was attacked by another user on the same shared server, the files inside /site/assets/ could've been planted there manually. Did you have anything else installed on the same hosting account, another site or web application or anything?

This is the only site on this hosting account. But with the misconfigured file permissions on the hoster the attack could also came from another user of the shared hosting.

48 minutes ago, teppo said:

I'm extremely confident in the security of the core and have a lot of trust in most of our third party modules, but there's no guarantee that nothing will ever go wrong.

Me too and the fact that the database and core were not infected proves that to me.

25 minutes ago, matjazp said:

I'm all ears to hear(read) the method used to hack the site, regardless of 777...

Maybe after talking with the hoster I can tell more. I am also curious.

[horst]

What I cannot understand is how the file sites.php in the root folder could stored, the index.php gets an injected line, because those are not under sites/assets/. I assume that you haven't had set 777 for the webroot. So, how can this be possible?

[matjazp]

You should validate the user input using $sanitizer and use CSRF in the form.

[AndZyk]

The file permissions for the webroot are 775 which is almost as bad. 

[teppo]

10 minutes ago, AndZyk said:

Is there a more secure way to implement such a form? Also the form isn't secured by an SSL certificate, which is also an potential risk.

There are two potential issues here: your form doesn't seem to have CSRF protection in place and the lack of HTTPS connection would make it possible for someone to grab the credentials from a request, but other than that this looks fine to me.

My usual advice would be not to do this (use built-in login form instead), but of course there are cases where you don't want to do that. For those cases check this post out for the CSRF protection and enable HTTPS. If the price of the SSL certificate is an issue, check out Let's Encrypt; their free certificates are pretty awesome. If your host doesn't allow you to use these, that in itself could be a good reason to switch hosts.

[teppo]

12 minutes ago, AndZyk said:

The file permissions for the webroot are 775 which is almost as bad. 

This could mean that *all* users on the system have read and execute permissions on your webroot, which would be very bad indeed. Though this doesn't allow everyone to write new files in your webroot itself, as long as you have a writable directory inside executable one, those users *will* be able to write and execute files there. This, in turn, would give them just about everything they need to compromise your site.

Of course this still depends on them having similar access to the directory your webroot is in, and the host not having implemented proper chroot / jail method. I can recall some vulnerabilities that have allowed users to break out of a chroot jail, so it's not exactly 100% reliable method either, but as long as the server is kept up to date it should prevent most issues like these.

[AndZyk]

13 minutes ago, teppo said:

For those cases check this post out for the CSRF protection and enable HTTPS. If the price of the SSL certificate is an issue, check out Let's Encrypt; their free certificates are pretty awesome. If your host doesn't allow you to use these, that in itself could be a good reason to switch hosts.

Thank you, I haven't used CSRF protection until now but will try to implement it into the login form. As for the SSL certificate I am almost sure that this hoster doesn't support ssl certificates. Let's Encrypt is awesome though, I already tried it myself in private.

 

There are maybe some more potential risks other than the file permissions I have to investigate. Maybe I will ask @ryan if he could take a quick look, but as this goes too much into details, I hope you can understand that I can't share more at the moment.

If I find out what caused the attack, I will keep you updated. 

[pwFoo]

I know many hacked joomla and WP sites, but maybe it's cms related...

Permissions have to be set dependent on the hosting environment!

 

Files / directories should be owned by FTP user and the webserver (as group) get read only by default.

If the webserver have to write to directories / files just set group write permissions.

[Tom.]

I'm very interested in looking more into this. Possibly you could share me the infected download? I'm really interested into how this could have happened. The form you presented doesn't really suggest an attack could have been delivered that way.

You suggested that the uploaded files attack WordPress so it could possibly be a bot as it is only making guesses on what CMS you are running. However some how it knows the file structure of ProcessWire. Also it doesn't say how files have been added to root or modified in root.