There is some confusion surrounding the issue of file and folder permissions, and a lot of this is because there has been a change in methods in the last few years and many are not aware of.
There are in general two philosophies with virtual hosts now which have come into play probably because of the esculation in traversial type server intrusions.
Before, the common method which Ill refer to as method 1, the first of the two primary methods, was to use folder and file permissions as a means of controlling the writability of content where the server script, in this case php, needed a file to have a write permission of 666 to be able to write to that file.
The case was the same with folders, which like files of 644, were by default non-writable. In order for php to write to files in that folder, or to create files or delete files or even chnmod files, the folders have to have permissions of 777. 777 though meant that the writable folder was prone to an attack from another infected website on the webserver, using a directory traversal, an attacker could write into any folder within other websites that were writable.
And because it is possible in method 1 for malicious scripts to execute outside of the virtual host folder, it is possible for affected scripts to be used to read higher up into the server, like to nab the root user and passwords, scan all directories and files, read them, which usually could give an attacker enough information to be able to enter every site on that server (consider for a minute that a configure.php file chmod to 644 is still readable, even chmod to 444 is still 'readable' in this method 1 type configuration. In configure.php are the user and passwords for your mysql server, and in many situations, that user and password is not that different from the cpanel login, and the FTP user and password.
So while this restricted the overwriting attacks (often referred to as defacements) to just writable folders and to writable files on your website, it did allow attacks to span across multiple websites, often referred to as a mass defacement. It allowed attackers to run arbitrary code on non-root services like APACHE and spamassassin and others.
The second method, method 2 which has come into play with several php mods, usually in share hosting configurations, is to assign the owner privaleges to the user and the script, thus pretty much making the whole file and folder permissions almost redundant if your web code security is crap. On the plus side, if another site on the shared server is exploited, the attack is not able to spread their attack across virtual hosts, in other words, the attack is restricted to just the site that has the weak security coding.
On the downside of method 2, if your site is the one that has been attacked, every file and folder in that configuration is pretty much vulnerable to be overwritten irregardless of the file permissions (if malicious backdoor files have been installed, or code appended into files from the previous admin bypass exploit).
Sure you can chmod a file to 444 via a filemanager or FTP client (if allowed), but in this particular configuration which is becoming more and more popular amongst shared hosts, because PHP has user permissions therefore is the owner, it is able to chmod file permissions back to writable.
So all an attacker needs to do is call chmod() a file from 444 to 644 before calling fopen($filename, 'a') to append their code to any file they wish, and if they want to be nice, chmod the appended file back to 444.
Of course it is a waste of time doing this to some files, so they go for the main include files usually, like the language file, application_top and the javascripts.
I think the key indicator in all of this is that if PHP is saying that all files and folders by default (644 for files and 755 for folders) are writable, and in some situations, the webhost has given you your own php.ini to play with, then your site is on one of these configurations.
So therefore that means that the attack has come via a file still resident in your file repository or appended code in your site files somewhere that you must have missed.
So that little script above just gives you an indicator that if your index.php file is set to 644 and is writable by PHP, then there is a good chance all the files are the same. And by implication that your site is on a method 2 type configuration, that could mean there is still a rogue file or code somewhere on your site that has been missed somehow, rather than the usual assumption that the attack has been a traversal across from another affected website.
Long-winded I know, but just hope it gives a better insight into why there are differences in server setups where that same code above on one site would say that index.php is read only, and on another, its writable, yet the file permissions are the same.
Edited by Taipo, 24 March 2011, 06:54.
0
