Ok, so I have linux hosting for my php site.
I have googled for a good while, but I cannot come up with the answer.
How would I make a script that I could insert some PHP code, but the script could not read or write to other files, especially higher level files?
I understand that allowing executable code inputted into a file is dangerous, but I was wondering someone knew the best way to prevent it from reaching outside the file.
How would I make a script that I could insert some PHP code, but the script could not read or write to other files, especially higher level files?
On shared webhosting - without access to the root level - this is going to be impossible.
By default, PHP scripts will be running under a specific user account. That user account (often the webserver's) has to have access to all PHP files. There is no combination of rights settings that can change this fundamental fact.
Related
On of my client approached me to check and fix the hacked site. Site was developed by another developer , Very inexperienced developer not even basic security taken care of.
Well the problem was somehow PHP files were written to the images folder. Hackers also wrote an index.html which displays site is hacked. When I check images folder has 777 permissions. So I came to rough conclusion that its because of folder permissions. Hosting support guy says that some PHP file has poorly written scripts which allowed any extension file to upload to server, and then hackers executed files to gain access or do whatever they want.
I have few questions:
Is it only through upload functionality can we upload other PHP files ?
Is it not possible other way to write files from remote as folder permissions are 777?
Sit has some fckeditors editors and couple of upload functionalities. I checked them, there are enough validations , so when extensions other then images or PDF are tried to upload they just return false .
Does'nt setting folder permissions to lower level fix the issue?
I asked the support guy to change folder permissions and it would solve the issue, but he says there is some PHP file through of which other PHP files were written and he wants that to be fixed otherwise site cannot go live. He says even folder permissions are changed hacker can again change them to 777 and execute whatever he wants because that poorly written PHP file.
How should be my approach to find if there is such PHP file? Any help or pointers would be much appreciated.
777 means that any user on the system (with execute access for all the parent directories, anyway) can add anything to that directory. Web users are not system users, though, and most web servers (Apache included) won't let random clients write files there right out of the box. You'd have to specifically tell the server to allow that, and i'm fairly certain that's not what happened.
If you're allowing any file uploads, though, the upload folder needs to at least be writable by the web server's user (or the site's, if you're using something like suPHP). And if the web server can write to that directory, then any PHP code can write to that directory. You can't set permissions high enough to allow uploads and low enough to keep PHP code from running, short of making the directory write-only (which makes it pretty useless for fckeditor and such).
The compromise almost certainly happened because of a vulnerability in the site itself. Chances are, either there's a file upload script that's not properly checking where it's writing to, or a script that blindly accepts a name of something to include. Since the PHP code typically runs as the web server's user, it has write access to everything the web server has write access to. (It's also possible that someone got in via FTP, in which case you'd better change your passwords. But the chances of the web server being at fault are slim at best.)
As for what to do at this point, the best option is to wipe the site and restore from backup -- as has been mentioned a couple of times, once an attacker has gotten arbitrary code to run on your server, there's not a whole lot you can trust anymore. If you can't do that, at least find any files with recent modification times and delete them. (Exploits hardly ever go through that much trouble to cover their tracks.)
Either way, then set the permissions on any non-upload, non-temp, non-session directories -- and all the existing scripts -- to disallow writes, period...particularly by the web server. If the site's code runs as the same user that owns the files, you'll want to use 555 for directories and 444 for files; otherwise, you can probably get by with 755/644. (A web server would only be able to write those if it's horribly misconfigured, and a hosting company that incompetent would be out of business very quickly.)
Frankly, though, the "support guy" has the right idea -- i certainly wouldn't let a site go live on my servers knowing that it's going to be executing arbitrary code from strangers. (Even if it can't write anything to the local filesystem, it can still be used to launch an attack on other servers.) The best option for now is to remove all ability to upload files for now. It's obvious that someone has no idea how to handle file uploads securely, and now that someone out there knows you're vulnerable, chances are you'd keep getting hacked anyway til you find the hole and plug it.
As for what to look for...unfortunately, it's semi vague, as we're talking about concepts above the single-statement level. Look for any PHP scripts that either include, require, or write to file names derived in any way from $_GET, $_POST, or $_COOKIE.
Changing folder permissions won’t solve the issue unless you’re using CGI, since PHP probably needs to be able to write to an upload folder, and your web server probably needs to be able to read from it. Check the extension of any uploaded files!
(So no, 0777 permissions don’t mean that anyone can upload anything.)
As cryptic mentioned, once a hacker can run code on your server then you have to assume that all files are potentially dangerous. You should not try to fix this yourself - restoring from a backup (either from the client or the original developer) is the only safe way around this.
Once you have the backup files ready, delete everything on your your site and upload the backup - if it is a shared host you should contact them as well in case other files are compromised [rarely happens though].
You've identified 2 issues: the permissions and the lack of extension checking however have you any evidence that these were the means by which the system was compromised? You've not provided anything to support this assertion.
Changing the permissions to something more restrictive would have provided NO PROTECTION against users uploading malicious PHP scripts.
Checking the extensions of files might have a made it a bit more difficult to inject PHP code into the site, it WOULD NOT PREVENT IT.
Restoring from backup might remove the vandalized content but WILL NOT FIX THE VULNERABILITIES in the code.
You don't have the skills your client (whom is probably paying you for this) needs to resolve this. And acquiring those skills is a much longer journey than reading a few answers here (although admittedly it's a start).
Is it only through upload functionality can we upload other PHP files ? Is it not possible other way to write files from remote as folder permissions are 777?
There definitely are multiple possible ways to write a file in the web server’s document root directory. Just think of HTTP’s PUT method, WebDAV, or even FTP that may be accessible anonymously.
Sit has some fckeditors editors and couple of upload functionalities. I checked them, there are enough validations , so when extensions other then images or PDF are tried to upload they just return false .
There are many things one can do wrong when validating an uploaded file. Trusting the reliability of information the client sent is one of the biggest mistakes one can do. This means, it doesn’t suffice to check whether the client says the uploaded file is an image (e.g. one of image/…). Such information can be easily forged. And even proper image files can contain PHP code that is being executed when interpreted by PHP, whether it’s in an optional section like a comment section or in the image data itself.
Does'nt setting folder permissions to lower level fix the issue?
No, probably not. The upload directory must be writable by PHP’s and readable by the web server’s process. Since both are probably the same and executing a PHP file requires only reading permissions, any uploaded .php file is probably also executable. The only solution is to make sure that the stored files don’t have any extension that denote files that are executed by the web server, i.e. make sure a PNG is actually stored as .png.
I've just had an argument with a colleaque.
My index.php contains my mysql connection and therefor also the host, username, password and database name.
He claims it is a security thread for the possibility exists that the php parser may fail which would cause the webserver to return the entire file as plain text.
I however believe that IF the php parser would fail the webserver would give an internal server error to the users.
Can anyone confirm whether it is or is not a security risk?
thank you.
The short answer is no.
The long answer is yes, but only if:
your server's been compromised, in which case people reading your php files are the least of your worries
you've misconfigured your server to parse .php files and plain text, which would be very silly indeed.
Also, if you're using some kind of version control software, make sure your .hg or .svn or whatever folders can't be viewed from a web browser. You'd be surprised how often that happens.
EDIT:
I would be inclined to go with some of the suggestions on here already, which is what I do in my day to day development. Have a config.php file outside of your web root folder and include this in your index.php. That way you know for sure it's never going to be viewable. Btw, I've been developing in PHP for a number of years and have never had the parser fail in such a way that it's resulted in raw PHP being displayed to an end user.
EDIT 2:
If your colleague is referring to parse errors when he talks about the PHP parser "failing" then in a live environment you should have error reporting disabled anyway.
Either outcome is a possibility. The normal course of action is to use require to bring in a separate file containing your db credentials. That file should be outside the webserver file tree so it can't be reached via a browser.
I'm in the belief that you can never be too safe. What's easier, replacing thousands, possibly millions of records if a hacker gets your db information, the security breach you would have to explain to your users (and possibly their lawyers depending on content and breach) or putting your db information in a separate, password protected folder and including the information on the pages you need the connection?
To me, the choice is simple.
Your co-worker is correct but this is very unlikely to happen. The .php file will only be returned as plain text or as a download if PHP has stopped running on the host.
To be safer, use an include() path to the database credentials in a new folder. In that folder have a .htaccess file with 'deny from all'.
That way even if PHP stops running on the server, Apache will still run and protect all the files including the database credentials. If even apache stops running, the whole webserver will be unreachable and your credentials will still be safe.
:)
Personally I'd put the options in a config file outside the web tree and, once uploaded, remove FTP access from that directory. It's not just a matter of whether the PHP parser fails and drops the file out as plain text BUT if the FTP server has a vulnerability that's compromised that file could be accessed by FTP as well as HTTP.
As long as Apache/PHP is running as a separate user to FTP you can still require the config file from PHP.
I would like to upload files (php sites/applications) to given directory and run them there, within my web server. However, already a simple shell_exec call can cause serious consequences.
All the things I can think of are setting the pages directory outside the public_html and setting the permissions automatically so that the user running that page doesn't have any rights outside it.
Other mediocre solution I've found so far is runkit_sandbox, which looks quite unsecure solution, specially as it seems to be abandoned.
Is there really no way? Not even with full shell access (shell scripts)?
No. There are a virtually unlimited number of malicious behaviors that user-uploaded code can engage in, many of which closely resemble legitimate behavior (e.g, sending mail vs. sending spam; accessing external APIs vs. perpetrating a DDoS; running a command-line utility vs. running an exploit; managing files vs. deleting everything). There is generally no "canned" way to do this, and definitely none within PHP.
http://www.suphp.org/Home.html
Use open_basedir to restrict your users to a certain folder. In this way it can execute his files with his ownership, but it will not be able to see anything more than his folder.
Look here for more informations:
http://www.randombugs.com/php/apache-dynamic-virtual-hosting-php-security.html
http://www.php.net/manual/en/ini.core.php#ini.open-basedir
I'm attempting to build an application in PHP to help me configure new websites.
New sites will always be based on a specific "codebase", containing all necessary web files.
I want my PHP script to copy those web files from one domain's webspace to another domain's webspace.
When I click a button, an empty webspace is populated with files from another domain.
Both domains are on the same Linux/Apache server.
As an experiment, I tried using shell and exec commands in PHP to perform actions as "root".
(I know this can open major security holes, so it's not my ideal method.)
But I still had similar permission issues and couldn't get that method to work either.
But I'm running into permission/ownership issues when copying across domains.
Maybe a CGI script is a better idea, but I'm not sure how to approach it.
Any advice is appreciated.
Or, if you know of a better resource for this type of information, please point me toward it.
I'm sure this sort of "website setup" application has been built before.
Thanks!
i'm also doing something like this. Only difference is that i'm not making copies of the core files. the system has one core and only specific files are copied.
if you want to copy files then you have to take in consideration the following:
an easy (less secured way) is to use the same user for all websites
otherwise (in case you want to provide different accesses) - you must create a different owner for each website. you must set the owner/group for the copied files (this will be done by root).
for the new website setup:
either main domain will run as root, and then it will be able to execute a new website creation, or if you dont want your main domain to be root, you can do the following:
create a cronjob (or php script that runs in a loop under CLI), that will be executed by root. it will check some database record every 2 minutes for example, and you can add from your main domain a record with setup info for new hosted website (or just execute some script that gains root access and does it without cron).
the script that creates this can be done in php. it can be done in any language you wish, it doesn't really matter as long as it gets the correct access.
in my case i'm using the same user since they are all my websites. disadvantage is that OS won't create restrictions, my php code will (i'm losing the advantage of users/groups permissions between different websites).
notice that open_basedir can cause you some hassle, make sure you exclude correct paths (or disable it).
also, there are some minor differences between fastCGI and suPHP (i believe it won't cause you too much trouble).
Like always, just want to say thank you for all of the help and input in advance.
I have a particular site that I am the web developer for and am running into a unique problem. It seems that somehow something is getting into every single PHP file on my site and adding some malware code. I have deleted the code from every page multiple times and changed FTP and DB passwords, but to no avail.
The code that is added looks like this - eval(base64_decode(string)) - which the string is 3024 characters.
Not sure if anyone else has ran into this problem or if any one has ideas on how I can secure my php code up.
Thanks again.
The server itself could be compromised. Report the problem to your web host. What is their response?
An insecure PHP script coupled with incorrect file permissions could give the attacker the ability to modify your PHP files. To eliminate this possibility I would take the site down, delete all the files, re-upload, then switch permissions on the entire site to deny any writes to the file system.
Edit:
As a short-term fix try asking your web host to disable eval() for your account. If they're worth their salt they should be running Suhosin which has an option to disable eval.
You should use "disable_functions=eval,exec" in your php.ini or .htaccess as first measure.
yes i have ran into this problem myself, i take it you are on a shared host? are you perchance on rackspacecloud?
this is where i had that problem, the first thing you need to do right away is notify your host, this is a hosting issue, and i suspect the malware has gained access to your server on an ftp level.
make sure you have nothing chmod 777 world writable, if it needs to be writable by your app make it 775
hope this helps, good luck
You should change the file permissions so that only you can write to those files. 0777 (the default on some hosts, I believe) is just asking for trouble. See File Permissions.
Also, it's advisable to not put any files that aren't supposed to be accessible by URL outside of the public_html folder, for example, config files.
I had a similar problem. However, my problem was that I was running a python code evaluator on my site. As far as I remember you need to use eval() function to execute the python code. In one of my php files I had a weird eval statement. What kind of script are you developing? I mean does it involve evaluation of some other code?
You should also note that (assuming you are using a hosting solution to host your site) that it's almost never your fault. An example being that networksolutions hosting company recently had a server hacked and over 1K webpages were affected, not due to security holes on each particular site, but due to some bad configuration/monitering of what was put on that particular server that hosts those sites. If you can't see any thing security wise wrong with your code, aka you sanitize everything properly and or you are running a non vulnerable version of whatever CMS you are using (if your using a CMS) then it's probably not an issue with your site, just the server in general.
You should move to another server. It would appear that the attacker has access to the server or is running some code as a background process which is overwriting the files. It may be possible to identify and remove the problem, but smart attackers will hide additional scripts etc to trip you up later.
I've come across viruses that read filezilla conf files.
I SWEAR TO GOD. at first i was: WOW, then i was: mother f*** sneaky b*stards.
Check your pc for viruses.
One of the possible scenarios is that somebody managed to get write access somehow and changing passwords etc. helped, but he left a php file that can still run.
See if there are any unknown files there. Or delete every damn thing and restore some backups.
Get the last modified time of your files, then go over to your access logs (FTP, HTTP whatever's open, if you don't know where they are ask your host) and find out who was mucking around on your system at that time.
Likely the attacker has installed a script that they can call periodically to re-infect any files you fix.