Today, more and more individuals and companies are attracted by the price of the "cloud". Let us undesrtand the reasons for shared hosting popularity before analyzing the underlying threats on sites security.
Generally shared accomodations are much simpler to manage than a dedicated hosting with private access to the server. It does not require systems engineer to configure a DNS or a security certificate or whatever. it is a simple and good market.
If it's so cheap, it's simply because many sites share the resources of the same server. Thus, hosts rely on the fact that all hosted sites do not consume 100% of all machine at any time, and thus many can coexist together. Thus, if a site suddenly starts to consume resources, it is bound to hamper the other.
First flaw: it is possible to bring down a site by hacking another.
In most cases, servers are running Linux or FreeBSD and Apache. Just because that again there is not necessarily need for a system administrator to manage the site. Some hosts will therefore enable economies with installations of PHP / Apache packages. PHP is configured as an Apache module in a well known conventional configuration and very simple to implement. In other words, all scripts are executed with the user name for the Web server. So all the files that a web server needs to access must be accessible to all and belong to the group of users of the Web server.
Each VirtualHost entry, representing a client, will have a directive "open_basedir" that restricts access to files to a specific folder for each user, and one often sees the "safe_mode" enabled also to lock more access to the file system.
Most of the accommodation do not put up really secure solution for their client, even worse: they do not even know of it mostly ...
Access to files
This is the greatest danger of shared accommodation as data is stored in the file system. The Web server needs to access to shared files during the execution of the script, session files, configuration files sites, etc...
Discovering the path to such files can lead to play script like this:
$ Files = explode ("\ n", shell_exec ("locate config.inc"));
This will use the linux command to locate config.inc files searching for all configuration present in the machine: which user has web server access, have all the configuration files of all hosted sites... Try not to make as it can call your administration space "admin"!
If the command has been disabled we can try why not:
$ Dir = new RecursiveDirectoryIterator ("/home");
$ Files = array ();
foreach (new RecursiveIteratorIterator ($ dir) AS $ match) {
if (strpos ($ match-> getFilename (), 'config.inc')! == false) {
$ Files [] = $ match-> getPathname ();
}
}
Here we just search in /home for files "config.inc". It becomes the property of the Web server. Even if you can not open files belonging to a user, you can open files common to all users: session files in particular.
So if the default session manager is used, it can be accessed for reading and writing to files session. For example:
$ Data = unserialize (file_get_contents ("/ tmp / sess_ {number-of-session }"));
$ Data ["admin"] = 1;
file_put_contents ("/ tmp / sess_-number {session}", serialize ($ data));
Assuming that we have recovered a number of valid session, you have access to the deserialized contents of all the variables in the session ...
You can also try to run a cron job that will launch a PHP script. The cron job does not work on Apache, and then ignore "safe_mode" and "open_basedir".
You can try to use other languages, but generally those threats are available in CGI, Perl, Python and compiled programs that can access the file system.
Access to databases
Regarding the database, the easiest way is to retrieve the identifiers in PHP configuration files or .htaccess.
Since you have local access to the server, or at least from a machine on the network, you bypass all firewalls that prevent access generally to databases from outside the network (internet).
As the connection time is very short, you can write a script that will generate a dictionary attack on a DBMS. Hundreds of requests per second can be spend locally, which mean that a weak password will not hold for a few minutes.