Information Security Training. Assignment 3 Web Application Security

Transcription

1 Information Security Training Assignment 3 Web Application Security By Justin C. Klein Keane <jukeane@sas.upenn.edu>

2 Setting Up In order to complete this portion of the training you will need to use a CentOS 6 virtual machine with Apache, PHP, and MySQL installed. Issuing the following command should install all of the necessary packages: $ sudo yum install httpd mysql php mysql mysql server php php mbstring php common php xml php gd php cli Next make sure each of these is set to start at runlevels 3, 4, and 5 using the commands: $ sudo /sbin/chkconfig level 345 httpd on $ sudo /sbin/chkconfig level 345 mysqld on Modify your firewall by adding the following line to /etc/sysconfig/iptables: A INPUT m state state NEW m tcp p tcp dport 80 j ACCEPT Immediately after the line that lists '--dport 22' and restart the firewall using: $ sudo /sbin/service iptables restart Then make sure to start Apache and MySQL using: $ sudo /sbin/service httpd start ; sudo /sbin/service mysqld start Finally ensure that SELinux is disabled on your virtual machine. Next find the ipaddress of the virtual machine using the 'ifconfig' command and point a web browser on your host machine to that ip address. You should see the Apache welcome screen. If not check your logs (/var/log/messages and /var/log/httpd/error_log) for indications of any issue. Once your web server is set up and running you should download the training exercise onto the machine. Use the following commands, as root: # cd /var/www/html # wget # unzip madirish_training.zip # cd madirish # mysql u root < sql/db.sql This will create the database for the application. Once this is done you can point a web browser at the IP address of the virtual machine's IP address plus '/madirish' (for instance: and ensure that the application is running properly:

3 Once you've completed the exercises you may want to see if you can 'fix' the test site so that it's no longer vulnerable to the exploits described below. Be sure to delete the test site when you're done or keep it behind a firewall, since it's deliberately designed to be insecure and could be used to compromise your computer!

4 Cross Site Scripting Cross site scripting (CSS or XSS) is a common web application vulnerability that can allow a malicious user to abuse an application in many ways. The test site has several XSS vulnerabilities. The first of these is presented by the way the application handles failed logins. Pull up the application page and attempt to log in using any made up username and password. You'll note that the application correctly handles the error message by not revealing whether or not the user exists. For instance, some applications may respond to a failed login with a message such as 'password incorrect' or 'user account does not exist'. These types of messages leak information about the failed login that can be useful for an attacker. For instance, if an attacker is trying to brute force an account they must correctly guess the account name and password. Brute forcing is an attack based on guessing. For instance, the attacker could simply try one username with every password they could think of, then move on. Computers are quite good at brute forcing, with automated attack programs that can tirelessly guess usernames and passwords. Given enough time any username and password combination can be guessed by a computer. Giving the attacker clues as to whether an account exists reduces the time it takes to brute force that account because the attacker does not have to guess at account names, merely passwords. The sample application correctly alerts the users that their login attempt failed, but does not hint as to whether or not it was the username or password that did not match. However, there is a critical flaw in how the application alerts the user to this fact. Can you spot the flaw? Can you exploit this flaw to cause the page to redirect to " Try logging in with an incorrect username and password. You'll notice that a Javascript prompt shows up telling you that you failed to log in. Now, examine the URL for the page. Next examine the source code for the page (Ctrl+u in your browser). You'll see there is a URL "GET" variable that is included as part of the page. The URL "index.php?msg=sorry,%20could%20not%20log%20in%20with%20those %20credentials." includes the message that is included as part of the alert. Looking at the source we can see: <script>alert('sorry, could not log in with those credentials.');</script> Try changing the URL so that it reads something else, for instance, try going to the URL "index.php? msg=foo" and observe what happens, view the resulting page source code. Can you spot the flaw yet? Try exploiting this get variable's inclusion into the javascript. Type the URL "index.php? msg=foo');alert('bar" into your web browser and observe what happens. This time you see two alert messages, and if you view the source you can see: <script>alert('foo');alert('bar');</script> You can see that the URL variable is being included directly in the page source. Now try going to the URL "index.php?msg=one moment');location.href=(' and observe what happens. This is known as a reflected cross site scripting vulnerability, since the victim must supply specific parameters to the application to trigger the attack (as opposed to a persistent cross site scripting

5 vulnerability where the script is permanently stored in the site, usually in the database back end). Now, this may seem innocuous enough, but lets take the attack one step forward and URL encode the entire query string. To do this we simply craft the URL using the hexidecimal values for each character that the browser will properly interpret, but which a user won't be able to understand. Try going to the URL: index.php?msg=%27%29%3b%6c%6f%63%61%74%69%6f%6e%2e%68%72%65%66%3d %28%27%68%74%74%70%3a%2f%2f%77%77%77%2e%73%61%73%2e%75%70%65%6e%6e%2e%65%64%75 Notice what happened? Now, an end user certainly won't understand what this URL is up to, but you can clearly see the hidden redirect. What if instead of the University of Pennsylvania web site this redirect pointed to a malicious phishing site that harvested usernames and passwords then redirected the user right back to the URL " confirmed, pleas log in". Many users would never notice they had ever visited the phishing page. This type of error could be exploited to harvest usernames and passwords from our application by sending an to users that said the user needed to log into the site using the above URL to confirm their account. This example clearly demonstrates that a vulnerability exists that might be overlooked by a developer. After all, who cares if a user could craft the JavaScript alert on the index page? Obviously a clever attacker would care very much and could exploit this subtle flaw to their advantage. How can this attack be prevented? The easiest way is to enforce that the application behaves exactly as it was intended. The actual PHP code used reads: if ($_GET["msg"]) { $msg = $_GET["msg"]; echo "<! JavaScript error messages >\n<script>alert('$msg');</script>\n\n"; } Now, if the code was altered so that it read: if ($_GET["msg"]) { $msg = urlencode($_get["msg"]); echo "<! JavaScript error messages >\n<script>alert('$msg');</script>\n\n"; } The message string could be altered, but it would never affect how the application functioned. In essence we want to restrict the URL variable from escaping out of the single quotes in the alert. It is tempting to simply do a string replace and replace all single quotes with an escaped single quote, so that the URL:?msg='alert);alert('foo was converted into the string:?msg=\'alert;alert(\'foo

6 which would effectively foil this attack. However, this approach fails if the attacker enters the URL:?msg=\'alert);alert(\'foo because escaping the single quote converts the string into the value:?msg=\\'alert);alert(\\'foo which in fact escapes the back slash, rather than the single quote. Trying to plan for variances in URL crafting will ultimately fail. The only safe way to enforce the parameter is correctly interpreted is to use PHP's native functionality (rather than "rolling your own" solution). See if you can find other cross site scripting attacks in the site. Try to only use XSS attacks that will pop up Javascript alerts since these will be minimally invasive to the actual functionality of the site. Once you realize that a XSS attack is possible you can begin to imagine the possibilities. One particularly evil XSS attack is to inject code (Javascript or otherwise) that actually includes an iframe into the page. If the iframe is merely 1 pixel by 1 pixel it is invisible to the user, but could allow new content to be included in the page. There are several browser attacks that can be performed using the iframe, not the least of which could be to prompt the user to download and execute malicious code. The possibilities are endless.

7 SQL Injection Vulnerabilities SQL injection is probably one of the more dangerous attack vectors created by improper input validation. Ideally, web applications collect data, then construct queries which are then submitted to a back end database. Databases allow for dynamic collection and manipulation of data by a web application and are an increasingly common component for web applications. In order to understand SQL injection we'll examine some SQL injection vulnerabilities in PHP and MySQL based web applications. We'll begin by examining a simply web application and the code that powers it. Let us say we have a blogging application. The code is fairly simple. The front page shows a listing of recent blog posts, with links that users can click through to view individual blog posts. The blog posts are all stored in a MySQL database and are identified by a unique id column. Let's assume the SQL table that powers the blog post looks like the following: Field Type Null Key Default Extra blog_id int(11) NO PRI NULL auto_increment blog_title varchar(255) YES NULL blog_body varchar(255) YES NULL user_id int(11) NO This is a pretty simple structure. Now, let's examine the code that displays an individual blog post (the code that executes when someone clicks a link to the post from the application front page). As you can see, this code looks for an id variable from the URL (a GET variable) and builds a SQL query with that data. Assuming we get the number 12 from the URL (i.e. a link of the structure sitename.tld/view_blog_post.php?id=21) the SQL the PHP would generate would be: SELECT blog.*, user.user_name FROM blog, user WHERE blog.user_id = user.user_id AND blog_id = 21

8 This is perfectly valid SQL and will execute properly. The trouble with the query is that users can manipulate the variable to produce other effects. For instance, if the user modified the variable so that instead of '21' the id they passed in was 21 UNION select user_id, user_name, user_password, NULL, NULL from user the constructed SQL query would be quite different. Instead of the innocuous SQL above, it would be: select blog.*, user.user_name from blog, user where blog.user_id = user.user_id and blog_id = 21 UNION select user_id, user_name, user_password, NULL, NULL from user which results in the following output: blog_id blog_title blog_body user_id user_name admin 40f4c edd677fd b3f0 NULL NULL It's worth noting that this output is caused by the fact that there is no blog_id 21 (otherwise the data from the user columns would be concatenated at the end of the blog data) and also that the passwords are not stored in plain text (these passwords actually the MD5 hash of the original password). There are a multitude of ways that attackers can manipulate input in SQL statements to reveal all sorts of information. PHP/MySQL web applications benefit from one major advantage against SQL injections. Many SQL injection attacks revolve around injecting a semi-colon, which is a statement termination character, and then appending an entirely new statement, often overriding the output of the original statement. Luckily PHP/MySQL does not support this query stacking and only one SQL statement can be issued in a query using PHP's mysql_query() function. This forces attackers to be slightly more clever when constructing their malicious SQL statements.

9 Finding SQL Injection Vulnerabilities The most difficult thing about a SQL injection attack is finding a vulnerability. Pulling off a successful SQL injection requires some precise information about the type of database, the database scheme, and even table structures. Finding this information can be quite difficult. Of course, one could always just attempt blind guessing, but this isn't very effective. Fortunately many developers unwittingly provide mechanisms for an attacker to reconnoiter an application for SQL injection attacks. It is quite common for developers to include debugging messages when SQL queries fail. This is completely unnecessary since the errors are useless to an end user and only help to aid an attacker in mapping the data structures. Ideally error messages should be logged and a helpful message should be displayed to the user that indicates whom to contact and perhaps even alerts a developer to the fact that an error log has been produce. All to commonly, however, you will find PHP that looks something like: if (! $result = mysql_query($query)) { echo "Problem with query: $query<hr/>"; die(mysql_error()); } Not only will this expose the error message, it will also expose the query that caused the error. This gives a nice blueprint to an attacker as to the layout of an application. In the test application all the error messages are constructed using this poor reporting. You can trip a SQL error by attempting to log in using a username with a single quote in the name. This will cause a SQL injection that will throw an error. For instance attempting to log in using the username 'foo (leave the password field blank) will cause the following error to be displayed: Problem with query: select user_password from user where user_name = ''foo' and user_password = 'd41d8cd98f00b204e ecf8427e' You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'foo' and user_password = 'd41d8cd98f00b204e ecf8427e'' at line 1 This error message provides a real wealth of information. Let's start by analyzing what caused the error. It's easy to spot the orphaned single quote in the query at the "name = ''foo'" portion. The extra quote in the name is causing malformed SQL. This can be worked around with some cleverness, but proves that SQL injection is possible. The second error message is perhaps the most helpful in identifying the exact source of the error message. The second interesting tidbit is the password part of the query. Instead of passing a blank entry there is a 32 character string. This is pretty much a dead giveaway that the application is, quite wisely, storing hashes of passwords in the database. You can guess that the value inserted by a user is hashed and that hash value is compared to the value in the database. Despite the use of a secured password we can actually use the SQL injection to bypass the authentication of the test application. Looking at the blog posts it seems like there is a user named 'admin'. We can try to authenticate as admin by exploiting the logic in the user authentication query. Because we can manipulate the query with SQL injection we can introduce new parameters to the query. See if you can figure out how to do this on your own.

10 Exploiting the Vulnerability Once you've tried a few combinations we can look at one of the several ways that we can end run this authentication. The authentication SQL query is structured as such: select user_password from user where user_name = '[value]' and user_password = '[value]' Because SQL is evaluated left to right with respect to AND and OR, what if we threw an OR statement into the query that always evaluated as true. For instance, what if we manipulate the query so that it ends up being: select user_password from user where user_name = 'admin' AND 1=1 OR user_name='admin' and user_password = '[hash value]' We can do this by logging in using the username: admin' AND 1=1 OR user_name='admin Go ahead and try this out and notice how the site actually lets you log in as the administrator. This is because the SQL query ends up selecting the password if the name is 'admin' and 1=1 (which it always does) OR if the name is 'admin' and the password is whatever hash we got. You can see the second part of the query fails, but the first part succeeds, and because: IF TRUE OR FALSE = TRUE The query returns the requested value. You can also see how a good understanding of SQL helps an attacker with this sort of attack. There are several other SQL injection possibilities throughout the test site. Because query stacking is illegal using the mysql_query() function the damage from SQL injection is limited to the type of query being executed. Thus, an INSERT statement could be manipulated to insert new or malformed data. More dangerous would be an UPDATE statement. In fact, there is an UPDATE statement available in the test application. If you log in and create a new user account you can update your account name and password. You can perform a SQL injection attack to update the admin password, which would cause a denial of service for the real admin and elevate your own privilege to that of admin. The most dangerous type of SQL injection would occur with a DELETE statement, but there aren't any of those in this particular test application.

11 Protecting Against SQL Injection The easiest way to protect against SQL injection attacks is to sanitize data as it is passed in by a user, as well as sanitizing any data that is pulled out of the database. PHP has several amazingly useful functions for this purpose. The most effective is mysql_real_escape_string(). Using this will prevent any SQL injection by escaping single quotes properly. Using strict data typing can also help. Functions like intval() can be used to translate user input into strict data types. This prevents bad data from even making it into the query. Other functions such as htmlentities(), htmlspecialchars(), and even urlencode() can be used to craft safer data for display. This can prevent problems down the road, protecting against threats such as XSS. The bottom line is that you should never trust user input. Never trust any input from the client. Even hidden form fields can be manipulated, and Javascript checks can easily be evaded (just check out the Tamper Data extension for Firefox to see how easy this is). You have to be sure you sanitize data on the server side before passing it to a SQL query. Even once data is in the database, it should be handled with care when extracted and displayed. Using prepared statements and libraries like MDB2 can greatly enhance your application security. Using a central library for all SQL queries can insure that each query is properly sanitized before being executed (rather than trying to keep track of and secure queries all over your code). Using object oriented code can also help, forcing variables to be passed into objects before being passed to SQL queries provides further opportunities to sanitize your data.

12 File Inclusion Vulnerabilities File inclusion vulnerabilities are a similar sort of beast to SQL injections. In a file inclusion vulnerability an attacker seeks to manipulate a string that is constructed with user supplied input. Let's take the following PHP code example, which is intended to include a story in the body of a page: As you can see here, the code attempts to get the story variable from the URL and then include the appropriate page. This would likely be called when a viewer clicked on a link that included a sub page, for instance: This becomes a problem, however, if a malicious user includes a link to a file on the filesystem, or even on a different filesystem. If the user tried to mangle the variable to link to a local file they might expose sensitive data from the filesystem:

13 An attacker can take this one step farther and actually include remote files which could include PHP that is actually executed on the local filesystem. To do this the attacker hosts a text file on a remote server, and calls it via a URL variable. For instance, if the attacker hosted the following file on the remote system: and called it using the same method above the output would be: It is interesting to note that if the evil_include file hosted on the remote system has a PHP file extension it will be executed on the remote system. It is imperative that the remote file have the.txt file extension in order to be executed on the local system. There are some mitigation strategies that are commonly employed to prevent file inclusion. Unfortunately many of these don't work as the developer expects. Suppose the following PHP code is used instead of that listed above:

14 The developer in this instance appends the file extension onto the file name. This will prevent attacks that call local files or remote non-php files, or so you would think. Unfortunately, because PHP is written in C, it uses null bytes as string terminators. So any string that has a null byte in it will only be interpreted up until the null byte. Thus, the statement: $filename = 'some_file_name[null byte].php'; would only resolve as 'some_file_name' when interpreted in a command such as: include($filename); The null byte character is trivially easy to include in a URL, as the character sequence %00. Thus, if an attacker includes the %00 in their malicious input, they can end run the developers attempts to include the.php file extension. For instance, an attacker calling the PHP code above that includes the.php file extension can overcome it like so:

15 Note that any remote file inclusion requires that certain parameters be set in the php.ini file (usually found in /etc/php.ini). The following must be set: ; Whether to allow include/require to open URLs (like or ftp://) as files. allow_url_include = On If allow_url_include is set to Off then remote file include attacks of this sort will not work. * Suhosin will defeat this attack! [Tue Feb 03 15:22: ] [error] [client ] ALERT Include filename ('../ is an URL that is not allowed (attacker ' ', file '/var/www/html/test.php', line 8)

16 Other Input Manipulations Authentication Bypass Another common information manipulation attack is directed at authentication bypass. It is not uncommon for dynamic PHP web applications to have an administration site or have content restricted to authenticated users. Attackers will often try to probe the authentication mechanisms that protect these resources in order to bypass them. One common way to authenticate users is via cookies. Cookies can be a wonderful way to track session state, but many developers do not consider that cookie values are user supplied data and are subject to manipulation, and thus must be sanitized before utilization. Consider the following snippit of PHP that is included on an administrative index page: You can easily see how if a malicious user manipulated their cookie values they could perform SQL injection to entirely bypass the authentication mechanism. This type of problem crops up in many forms. Common problems are simply checking for the existence of a cookie (a user can create a cookie without application input), or checking that a cookie value is set (a user can set and adjust cookie values at will). Using cookie values in SQL carries all the same risk as using any type of user supplied data.

17 Information Leaking Information leaking is usually a condition introduce by misconfiguration rather than programming error. Some common forms of information leaking include improperly setting file permissions on files, or placing sensitive information in files that are accessible via the web. For instance: While this is just one means of information disclosure, a far more common flaw is leaving directory indexing on. This can be especially damaging if it allows an attacker to browse the filesystem and find files that may include configuration details, or even source code. Attackers will often search for source code, or test or backup scripts that have changed file extensions that would allow the attacker to browse the source code. Finding this sort of information can allow an attacker to craft targeted attacks that are much more effective.