Jump to content
AndZyk

Why securing file permissions is important

Recommended Posts

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

  • Like 12

Share this post


Link to post
Share on other sites

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.

  • Like 5

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Like 2

Share this post


Link to post
Share on other sites
12 minutes ago, AndZyk said:

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

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.

  • Like 1

Share this post


Link to post
Share on other sites
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. ;)

  • Like 2

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By iipa
      I have added favicon files (.png, .xml, .ico, .svg) into site/templates/images/favicon/ folder. I refer to them in _after.php, <head> tag. Problem is that favicon does not show. When I go to the address of the .png icon, it shows the basic blue icon with question mark = something is wrong. But when I check .svg file, it shows correctly. Browser console and ProcessWire error log don't recognize any issues. All files have chmod 644, and all folders 755. All images added into site through ProcessWire admin are displayed correctly.
      What could be the caused of this issue?
    • By benbyf
      not sure why but PW adds any uploads as permissions 600 (e.g. images wont load after upload unless i go in with the same server user and change permissions to 755 or similar). This ever happened to any one else?
    • By benbyf
      HELLO ALL!
      Context: I use serverpilot to setup and administrate my server patches for my hosted sites. As with many other serving companies, they write tutorials to setup software on their service. I asked them to provide a PW installation instruction and they have obliged however hitting on the following issue on installation with their default linux user:
      Issue:
       
      Basically at the end of the installation there is a warning to secure your config file which could have been done already by the system, I believe they're saying. Is there anything we can do with this, or should i ask them to carry on with the caveat that they should but in a bit of text saying this warning is normal and can be sorted in teh follow ways etc...?
      Interested in people's opinion.
×
×
  • Create New...