CHAPTER 10
HACKING WEB SERVERS
After reading this chapter and completing the activities, you will be able to:
Describe Web applications
Explain Web application vulnerabilities
Describe the tools used to attack Web servers
Companies recognize the power of the Web to improve sales and the necessity of having a Web presence. For this reason, Web applications are widely used, and many Web development platforms are available, such as Microsoft Active Server Pages (ASP), Sun’s Java Server Pages (JSP), and ColdFusion.
Normally, a Web application is supported by a Web server that runs on a general-purpose or embedded OS. Each component (application, server, and OS) has its own set of vulnerabilities, but when these components are combined, there’s an increased risk of Web applications being compromised. Skilled hackers can often exploit a minor vulnerability in one function, such as a Web mail application, and use it as a stepping stone to launch additional attacks against the OS. With all the available platforms and e-commerce Web sites, it’s no wonder that security vulnerabilities abound.
Chapter 8 covered OS vulnerabilities, and this chapter gives you an overview of Web applications, explains the vulnerabilities of many Web components, and describes the tools used to hack Web servers.
UNDERSTANDING WEB APPLICATIONS
As you learned in Chapter 7, writing a program without bugs is nearly impossible. The bigger the program, the more bugs are possible, and some bugs create security vulnerabilities. Web applications are no exception, and because they generally have a larger user base than standalone applications, bugs are even more of a problem. The more people who have access to a program, the bigger the risk of security vulnerabilities. The following sections describe Web application components and platforms for developing Web applications.
Web Application Components
HTML is still the foundation of most Web applications and is commonly used for creating static Web pages. Static Web pages display the same information regardless of the time of day or the user who accesses the page. Dynamic Web pages can vary the information that’s displayed, depending on variables such as current time and date, username, and purchasing history (information collected with cookies or Web bugs, discussed in Chapter 4). For Web pages to be dynamic, their code must consist of more than just the basic tags discussed in Chapter 7. These pages need special components for displaying information that changes depending on user input or information from a back-end server. To do this, a variety of techniques can be used for dynamic Web pages, including the <form> element, Common Gateway Interface (CGI), Active Server Pages (ASP), PHP, ColdFusion, JavaScript, and database connector strings, such as Open Database Connector (ODBC). These components are covered in the following sections.
Web Forms
The <form> element is used in an HTML document to allow customers to submit information to the Web server. You have probably filled out a form when purchasing a product online or registering for an e-mail newsletter, for example. Some forms can be quite long and ask for a lot of information, and some have only a couple of input fields, such as username and password. A Web server processes information from a form by using a Web application. The following HTML code shows the syntax for a simple form, and Figure 10.1 shows the Web page created with this code.
<html> <body> <form> Enter your username: <input type="text" name="username"> <br> Enter your password: <input type="text" name="password"> </form></body></html>
Figure 10.1
An HTML Web page with a form
Courtesy Course Technology/Cengage Learning
Gaining skills in creating HTML forms can help you recognize vulnerabilities in Web applications. Forms are an easy way for attackers to intercept data that users enter and submit to a Web server, so security testers should be able to recognize when forms are being used.
Common Gateway Interface
Another standard that handles moving data from a Web server to a Web browser is Common Gateway Interface (CGI), which enables Web designers to create dynamic HTML Web applications. Many dynamic Web pages are created with CGI and scripting languages. CGI is the interface that determines how a Web server passes data to a Web browser. It relies on Perl or another scripting language to create dynamic Web pages, which is quite different from Active Server Pages (covered in the next section). CGI’s main role is passing data between a Web server and Web browser. In fact, the term “gateway” describes this movement of data between the Web server and Web browser.
CGI programs can be written in many programming and scripting languages, such as C/C++, Perl, UNIX shells, Visual Basic, and FORTRAN. Programming languages such as C and C++ require compiling the program before running it. If CGI is implemented with a scripting language, compiling isn’t necessary. The following CGI program displays “Hello Security Testers!” in the user’s browser. This hello.pl program is written in Perl and would be placed in the cgi-bin directory on the Web server:
#!/usr/bin/perl print "Content-type: text/html "; print "Hello Security Testers!";
To check whether the CGI program works, save the program to the cgi-bin directory of your Web server, and then enter the URL in your Web browser, such as http://www.myweb.com/cgi-bin/hello.pl.
Active Server Pages
The main difference between HTML pages and Active Server Pages (ASP) is that with ASP, developers can display HTML documents to users on the fly. That is, when a user requests a Web page, one is created at that time. ASP isn’t a programming language. It’s a technology that enables developers to create dynamic, interactive Web pages and uses scripting languages, such as JScript (Microsoft’s version of JavaScript) or VBScript. Like all Internet technologies, ASP has evolved and has been largely replaced by ASP. NET. However, for the purposes of this chapter, ASP and ASP.NET are used interchangeably.
Not all Web servers support ASP, so if you want to develop Web pages with ASP, the server you’re using must support this technology. Internet Information Services (IIS) 4.0 and later support ASP, and IIS 5.0 and later support ASP.NET. It’s important to understand that the Web server, not the Web browser, must support ASP. In Activities 10.1 and 10.2, you work with IIS to get a better understanding of Web applications.
Activity 10.1: Installing Internet Information Services
Time Required: 30 minutes
Objective: Install IIS on your Windows computer.
Description: To create a Web site, you need to install IIS on your Windows computer. Although IIS is deployed on a server in a production environment, preproduction Web development and testing are typically done on workstations. IIS 5.1 is available in Windows XP Professional, IIS 7 is available in Vista (Business, Ultimate, and Enterprise editions), and IIS 7.5 is available in Windows 7 (Professional, Ultimate, and Enterprise). Because IIS isn’t installed by default, in this activity, you install it and use your Web browser to check that it was installed correctly.
Note
This activity and the next one are written in Windows Vista; in Windows XP, the steps and screenshots won’t match. Installing IIS in Windows 7 is similar, but you can refer to the Microsoft documentation or do an Internet search on installing IIS 7 in Windows 7 Professional, Enterprise, or Ultimate.
Figure 10.2
Turning Windows features on or off
Courtesy Course Technology/Cengage Learning
1. Open Control Panel, and then click Programs.
2. In the Programs and Features section, click Turn Windows features on or off to open the Windows Features dialog box. If the User Account Control (UAC) message box opens, click Continue. Click Web Management Tools, and then click to select the IIS Management Console check box. Under it, click to select the Internet Information Services (IIS) check box, and then click the plus symbol to expand the IIS options, as shown in Figure 10.2. Click the ASP check box, which selects the ISAPI Extensions check box automatically. Don’t clear any options that are already selected. Click OK to have IIS installed.
3. To check that IIS has been installed, click Start, Search, type inetmgr, and press Enter to open the Internet Information Services (IIS) Manager (see Figure 10.3). Click Help, About Internet Information Services from the menu. What version of IIS is installed on your computer?
4. Start a Web browser, type the URL http://localhost, and press Enter to go to the IIS welcome page. A visitor to your Web site would get an IIS welcome message because you haven’t created a default HTML Web page yet. However, clicking the graphic directs you to Microsoft’s official IIS Web site, where you can learn more about IIS. When you’re finished, close the browser window.
5. Next, you need to create a folder on your Web server to hold any HTML pages you create. When IIS is installed, a new folder called Inetpub is created on the C drive. Open Windows Explorer. Under the C drive (substitute the correct drive letter if your installation is different), click to expand the Inetpub folder, and then click to select the wwwroot folder.
Figure 10.3
The Internet Information Services (IIS) Manager
Courtesy Course Technology/Cengage Learning
6. Right-click the wwwroot folder, point to New, and click Folder. For the folder name, type YourFirstName (substituting your first name), and then press Enter.
7. Close any open windows, and leave Windows running for the next activity.
To keep attackers from knowing the directory structure you create on an IIS Web server, creating a virtual directory is recommended so that the path a user sees on the Web browser isn’t the actual path on the Web server. A virtual directory is a pointer to the physical directory. For example, with virtual directories, a user might see http://www.mycompany.com/jobs/default.asp instead of http://www.mycompany.com/security/positions/CEH_Cert/default.asp. The simpler structure that a virtual directory offers is often easier for users to memorize and navigate. Using this design strategy is also a good security feature because it helps hide the actual directory structure from attackers.
Activity 10.2: Creating a Virtual Directory
Time Required: 15 minutes
Objective: Learn how to create a virtual directory on an IIS Web server.
Description: After IIS is installed and physical directories are created, a Web administrator should create virtual directories that prevent site visitors from seeing the physical directory structure. In this activity, you create a virtual directory, using the directory you created in Activity 10.1.
1. Click Start, Search, type inetmgr, and press Enter. In the IIS Manager window, click to expand the computer name, Sites, and Default Web Site (see Figure 10.4).
2. Right-click the YourFirstName folder you created in Activity 10.1 and click Add Virtual Directory to start the Virtual Directory Creation Wizard.
3. In the Alias text box, type your first name. Type (or browse to) the physical path of the folder you created in Activity 10.1 (C:InetpubwwwrootYourFirstName), and then click OK to create a virtual directory that users can access over the Web.
4. Close all open windows, and leave Windows running for the next activity.
Figure 10.4
Viewing IIS Web sites
Courtesy Course Technology/Cengage Learning
The Web server uses the ASP scripting language to generate HTML pages for the Web browser. How does the Web server know when ASP code is being used? You wrote an HTML Web page in Chapter 7; now look at a Web page containing ASP statements in Activity 10-3. The best way to learn ASP is to create a Web page with it. To do this, you need three components: a text editor (Notepad, for example), a Web server (such as an IIS Web server), and a Web browser (such as Internet Explorer or Firefox).
Activity 10.3: Creating an ASP Web Page
Time Required: 20 minutes
Objective: Use ASP to create dynamic Web pages and be able to recognize ASP Web pages.
Description: ASP Web pages are created on the Web server and enable a developer to create dynamic Web pages. In this activity, you create an ASP Web page and use a Web browser to view the page.
1. To start Notepad with administrative privileges, click Start, point to All Programs, point to Accessories, and then right-click Notepad and click Run as administrator. (If necessary, click Continue in the UAC message box.) In Notepad, type the following code:
<HTML> <HEAD><TITLE> My First ASP Web Page</TITLE></HEAD> <BODY> <H1>Hello, security professionals</H1> The time is <% = Time %>. </BODY> </HTML>
2. Save the file as First.asp in C:InetpubwwwrootYourFirstName. Be sure the file is saved with the.asp extension, not the .txt extension. Exit Notepad.
3. To test the First.asp Web page, start your Web browser, type the URL http://localhost/YourFirstName/First.asp, and press Enter. Note that the Web page shows the current time of your location, meaning it’s dynamic. That is, it changes each time your Web browser calls for the Web page. The <% and %> tags tell the Web server that ASP is used as the script language.
4. Click View, Source from the Web browser menu. Does the source code show you the ASP commands you entered?
5. Exit Notepad and the Web browser, and log off Windows for the next activity.
To prevent potential security problems, Microsoft doesn’t want users to be able to view an ASP Web page’s source code. For example, a Web page containing a connection string that reveals username and password information to users could be used for an attack. Not allowing the source code to be viewed makes ASP more secure than basic HTML Web pages. Connection strings are covered later in “Connecting to Databases.”
Apache Web Server
As a security tester, you should be aware of another Web server program. Apache Web Server is said to run on more than twice as many Web servers as IIS, so some familiarity with this Web server can be helpful in the security-testing profession. Apache has important advantages over the competition: It works in just about any *nix platform as well as in Windows, and it’s free. Installing Apache in Linux is different from installing IIS in Windows, but you don’t have to worry about installation because the Apache Web Server daemon (httpd) 2.29 is included in the BackTrack files.
Activity 10.4: Working with Apache Web Server
Time Required: 35 minutes
Objective: Explore basic settings and tasks in Apache Web Server.
Description: Without a doubt, you’ll run across Apache Web Server systems when conducting a security test. Because Apache is a sophisticated, modular Web server, mastering its features and options can take considerable time. Apache’s layout varies, depending on the OS. For example, Apache in Fedora Linux is different from Apache in Ubuntu Linux. In this activity, you explore basic Apache Web Server commands and learn how to find and modify some configuration options (called “Apache directives”).
1. Boot your computer into Linux with the BackTrack files, and log in as root. At the shell prompt, type startx and press Enter to open the KDE desktop manager.
2. Start the Firefox Web browser. In the address bar, type localhost and press Enter. The Web site displays a message indicating that it’s working.
3. Open a Konsole shell. At the command prompt, type apache2ctl stop and press Enter. In Firefox, refresh the Web page. A “Failed to Connect” error message is displayed.
4. To modify the message the localhost Web server displays when connecting, you need to know the location of the default Web page document that Apache displays to your Web site visitors. In the Konsole shell, type cd /etc/apache2 and press Enter to change directories. Then type grep Include apache2.conf and press Enter to see a listing of files and directories where the Apache server searches for additional directives at startup (see Figure 10.5). Note the next to last line, Include /etc/apache2/sites-enabled/. This directory is where Apache checks for Web site configuration files. You can add a Web site by adding its configuration file in this directory without having to change the main configuration file.
5. Type cd /etc/apache2/sites-enabled && ls and press Enter.
6. Open the file in the vi editor by typing vi 000-default and pressing Enter.
7. Make a note of the directory specified by the Apache directive DocumentRoot. Change the AllowOverride directive in line 7 for the /var/www directory to replace the “None” setting with “AuthConfig” (shown bolded in the following example):
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride AuthConfig
Order allow, deny
allow from all
</Directory>
Figure 10.5
Viewing files and directories with an Include statement
Courtesy Course Technology/Cengage Learning
8. Save your changes and exit the vi editor by pressing Esc, typing :wq, and pressing Enter. Change to the directory specified by the DocumentRoot directive you found in Step 7.
9. Type ls and press Enter to list the files in the directory you changed to in Step 8. Open the index.html file in vi by typing vi index.html and pressing Enter.
10. Replace the word “It” in the HTML code with YourName’s Apache Web server. Save the file and exit the vi editor.
11. In the Konsole shell, type apache2ctl start and press Enter. You can safely ignore the “Could not reliably determine the server’s fully qualified domain name” error.
12. View the Web site at localhost to see your updated Web site content; refresh the page in Firefox, if necessary. Next, to see an Apache module configuration change, you set up a password-restricted section of the Web site, allowed by the AllowOverride AuthConfig directive you specified in Step 7. In the Konsole shell, create a new directory by typing mkdir /var/www/ restricted and pressing Enter.
13. Type cd /var/www/restricted to change to the directory you created in Step 12 and press Enter. Then type touch secret.txt and press Enter to create a file in this directory.
14. Next, you create the .htaccess file in the same directory. This file is the local directory configuration file specified in apache2.conf by the AccessFileName directive. If .htaccess exists in any Web site directory, Apache checks it first. In this .htaccess file, you point Apache to the location of AuthUserFile (essentially, a password file). Type vi.htaccess and press Enter. Type the following for the file’s contents:
AuthType Basic AuthName "Password Required" AuthUserFile /etc/apache2/.restricted Require User tester
15. Exit and save the file by pressing Esc and then pressing : (a colon). At the : prompt, type wq and press Enter. In the Konsole shell, create a password file by typing htpasswd – c /etc/apache2/.restricted tester and pressing Enter. When prompted, enter a password and confirm, and then make note of the password. The .htaccess file you created in Step 14 tells Apache to look in the .restricted file for the tester user’s password.
16. Restart Apache by typing apache2ctl restart and pressing Enter. In Firefox, go to http://local-host/restricted, and enter the username tester and the password you confirmed in Step 15. What file is displayed?
17. Why is entering your credentials on a Web site not secured with SSL, such as this site, a problem? What is the fix for this problem?
18. Close the Konsole shell, exit Firefox, and log off Linux for the next activity.
Using Scripting Languages
Web pages can be developed with several scripting languages, such as VBScript and JavaScript. You won’t learn how to be a Web developer by reviewing the scripting languages covered in this chapter, but you should be able to recognize when one is being used because many security-testing tools are written with scripting languages. Also, most macro viruses and worms, and all worms that take advantage of cross-site scripting vulnerabilities (discussed later in the chapter), are based on scripting language.
PHP Hypertext Processor
Similar to ASP, PHP Hypertext Processor (PHP) enables Web developers to create dynamic Web pages. PHP, an open-source server-side scripting language, is embedded in an HTML Web page by using the PHP tags <?php and ?>. Because PHP Web pages run on the server, users can’t view the source code in their Web browsers. PHP was originally used mainly on UNIX systems, but it’s used more widely now on many platforms, including Macintosh and Windows. The following excerpt is a code example for a static PHP Web page showing the use of PHP tags:
Note
Bolded lines in these code examples show how different scripting languages are indicated.
<html> <head> <title>My First PHP Program</title> </head> <body> <?php echo '<h1>Hello, Security Testers!</h1>' ; ?> </body> </html>
This page would need to be created on your Web server as you did with the ASP Web page you created in Activity 10.3. After you have identified that a Web server is using PHP, you should use the methods you have learned in this book to investigate further for specific vulnerabilities. For example, several versions of PHP running on Linux can be exploited because of a line in the Php.ini file: The line file_ uploads=on permits file uploads; however, this setting might allow a remote attacker to run arbitrary code with elevated privileges. The best solution is to upgrade to the latest version of PHP, but if that’s not possible, change the line to file_uploads=off.
Note
You should also be familiar with LAMP (which stands for Linux, Apache, MySQL, and PHP) because it’s a collection of open-source software used for many sophisticated, high-traffic Web applications, such as Facebook and Google. LAMP is known as a “solution stack” because it stacks several programs into one integrated Web application solution. For more information, do an Internet search on the term “Lamp” combined with the Linux version you’re using, such as “Ubuntu” or “Fedora.”
ColdFusion
ColdFusion is another server-side scripting language for developing dynamic Web pages. Created by Allaire Corporation, it’s now owned by Adobe Systems, Inc. Cold-Fusion integrates Web browser, Web server, and database technologies. It uses proprietary tags written in ColdFusion Markup Language (CFML), and Web applications written in CFML can contain other client-side technologies, such as HTML and Java-Script. The following code is an example of HTML code with a CFML tag that redirects the user to a Web page. All CFML tags begin with the letters CF. For example, the column tag is <CFCOL>.
<html> <head> <title>Using CFML</title> </head> <body> <CFLOCATION URL="www.isecom.org" ADDTOKEN="NO"> </body> </html>
As with the PHP example, security testers should become familiar with vulnerabilities associated with a Web server using ColdFusion. A quick search of the Adobe security page (www.adobe.com/support/security/) can narrow your research time, allowing you to focus on the vulnerabilities that affect your situation.
VBScript
Visual Basic Script (VBScript) is a scripting language developed by Microsoft. You can insert VBScript in your HTML Web pages to convert static Web pages into dynamic Web pages. The biggest advantage of using a scripting language is that you have the features of powerful programming languages at your disposal. For those who have programming experience, you can start writing VBScript faster than a dual-processor 3 GHz computer. Take a look at a simple example to help you recognize when VBScript is being used. The following code is entered in an HTML document in Notepad, as you did earlier:
<html>
<body>
<script type="text/vbscript">
document.write ("<h1>Hello Security Testers!</h1>")
document.write ("Date Activated: " & date())
</script>
</body>
</html>
Figure 10.6 shows the Web page generated from the preceding VBScript code.
The Microsoft Security Bulletin Search page (www.microsoft.com/technet/security/current.aspx) is an excellent starting point for investigating VBScript vulnerabilities. A search on a specific Security Bulletin produces a wealth of information, including the severity rating and patch information.
Figure 10.6
A Web page created with VBScript
Courtesy Course Technology/Cengage Learning
To see an example of a VBScript Security Bulletin, visit www.microsoft.com/technet/security/bulletin/ms08-022.mspx.
JavaScript
Another popular scripting language for creating dynamic Web pages is JavaScript, which also has the power of a programming language. As with VBScript, you can branch, loop, and test (the BLT you learned in Chapter 7) and create functions and procedures in HTML Web pages. The following code is a simple HTML snippet with JavaScript code added:
<html>
<head>
<script type="text/javascript">
function chastise_user()
{
alert("So, you like breaking rules?")
document.getElementById("cmdButton").focus()
}
</script>
</head>
<body>
<h3>"If you are a Security Tester, please do not click the command button below!"</h3>
<form>
<input type="button" value="Don't Click!" name="cmdButton" onClick="chastise_user()" />
</form>
</body>
</html>
This code is a little more complex than the previous examples, but it shows you how scripting languages can include functions and alerts. Notice that the third line specifies that JavaScript is the language being used. Next, the chastise_user() function is defined; this function simply displays an alert message. The getElementById() function is a method (a sequence of statements that perform a routine or task) defined by the World Wide Web Consortium (W3C) Document Object Model (DOM). Basically, it returns an object—in this case, a command button you click. The remaining code is fairly self-explanatory. To see how this code works, take a look at the output shown in Figure 10.7. Notice the Internet Explorer warning message about running scripts or ActiveX controls.
Figure 10.7
A command button created with JavaScript
Courtesy Course Technology/Cengage Learning
If the user accepts the security warning and clicks the command button, the alert message box shown in Figure 10.8 is displayed.
JavaScript is widely used, and a variety of vulnerabilities have been exploited in older Web browsers. Security testers and administrators should inspect every computer for unpatched or outdated browser versions and keep up with vulnerabilities. For example, Cyber Security Alert SA09-133B, Adobe Reader and Acrobat Vulnerabilities (www.us-cert.gov/cas/alerts/SA09-133B.html), describes a JavaScript vulnerability.
Figure 10.8
An alert message created with JavaScript
Courtesy Course Technology/Cengage Learning
Connecting to Databases
Most Web pages that display company information to users are stored on a database server. Web pages that prompt a user for information, such as name, phone number, address, and so on, store the information users enter in a database. The technology used to connect a Web application to a database server might vary depending on the OS, but the theory is the same. The following sections discuss some technologies used to connect to a database or an external file system from a Web application.
Open Database Connectivity
Open Database Connectivity (ODBC) is a standard database access method developed by the SQL Access Group. The ODBC interface allows an application to access data stored in a database management system (DBMS), such as Microsoft SQL, Oracle, or any system that can recognize and issue ODBC commands. Interoperability between back-end DBMSs is a key feature of the ODBC interface, allowing developers to focus on the application without worrying about a specific DBMS. The ODBC interface accomplishes this interoperability by defining the following:
A standardized representation for data types
A library of ODBC function calls that allow an application to connect to a DBMS, run SQL statements, and retrieve the results
A standard method of connecting to and logging on to a DBMS
Object Linking and Embedding Database
Object Linking and Embedding Database (OLE DB) is a set of interfaces that enable applications to access data stored in a DBMS. Microsoft designed it to be faster, more efficient, and more stable than its predecessor, ODBC. OLE DB relies on connection strings that allow the application to access data stored on an external device. Depending on the data source you’re connecting to, you might use a different provider. For example, connecting to an SQL database requires using SQLOLEDB as the provider instead of Microsoft.Jet.
Table 10.1 shows some OLE DB providers available for developers. When conducting a security test on a Web server, you should verify how the Web server is connecting to a database and, of course, what type of database or resource data is being collected. The following code line is an example of a connection string used to access data in a Microsoft Access database named Personnel:
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:Personnel.mdb; User ID=; Password=;
ActiveX Data Objects
ActiveX Data Objects (ADO) is a programming interface for connecting a Web application to a database. ActiveX defines technologies that allow applications, such as Word or Excel, to interact with the Web. For example, you can place an Excel spreadsheet in a Web page. To access a database from an ASP Web page, you follow these general steps:
1. Create an ADO connection to the database you want to access.
2. Open the database connection you created in Step 1.
3. Create an ADO recordset, which contains rows from the table you’re accessing.
4. Open the recordset.
5. Select the data you need from the recordset, based on particular criteria.
6. Close the recordset.
7. Close the database connection.
Next, take a look at how these steps are performed and what the result looks like in an ASP Web page. The following ASP code creates and opens the ADO connection:
<% set conn=Server.CreateObject("ADODB.Connection") conn.Provider="Microsoft.Jet.OLEDB.4.0" conn.Open "c:MyDatabaseemployee.mdb" %>
Now you need to create a recordset to contain records from a table in your employee.mdb database:
<%
set rs=Server.CreateObject("ADODB.recordset")
rs.Open "Select * FROM Employee", conn
.....
rs.close
conn.close
%>
You would probably use a loop to print all the records to the Web page, but that’s not important here. You want to understand the technology so that you can recognize vulnerabilities when they exist. Now that you have a good foundation on the components of a Web application, the following section discusses some of these vulnerabilities.
UNDERSTANDING WEB APPLICATION VULNERABILITIES
Many platforms and programming languages can be used to design a Web site. Each platform has its advantages and disadvantages. Some are free, and others cost quite a bit; some require only basic skills in creating Web applications, and others require an in-depth knowledge of programming. Regardless of the platform, security professionals need to assess the system and examine potential methods for attacking it.
Network security is essential to protect company data and resources from attack. The problem is that some security professionals don’t see the importance of application security. One reason is that many security professionals have experience in networking but little or no experience in programming. In fact, most network security books don’t have much programming coverage because the topic can overwhelm beginners. No matter how efficient a company’s firewalls or intrusion detection systems are, most systems ignore the content of HTTP traffic. Therefore, an attacker can bypass these security boundaries as well as any OS hardening that network administrators have done. Simply stated, Network-layer protection doesn’t prevent Application-layer attacks from occurring. All an attacker needs is an understanding of some basic programming concepts or scripting languages. To add to the mayhem, attackers usually don’t need special tools, and there’s little chance of their attempts being detected. After attackers gain control of a Web server, they can do the following:
Destroy the company’s database or offer to sell its contents.
Gain control of user accounts.
Launch secondary attacks from the Web site or infect site visitors’ systems with malware.
Gain root access to other application servers that are part of the network infrastructure.
Application Vulnerabilities and Countermeasures
Luckily, there’s an organization that helps security professionals understand the vulnerabilities in Web applications. Much like ISECOM, Open Web Application Security Project (OWASP) is a not-for-profit foundation dedicated to finding and fighting the causes of Web application vulnerabilities. OWASP (www.owasp.org) publishes the Ten Most Critical Web Application Security Vulnerabilities paper, which has been built into the Payment Card Industry (PCI) Data Security Standard (DSS). The PCI DSS is a requirement for all businesses that sell products online. Visiting the OWASP Web site to learn more about Web application vulnerabilities is recommended. As a security tester, you might need to analyze vulnerabilities such as the ones in the OWASP Top Ten list:
Cross-site scripting (XSS) flaws—In this vulnerability, a Web browser might carry out code sent from a Web site. Attackers can use a Web application to run a script on the Web browser of the system they’re attacking. XSS is one of the easiest types of attacks to perform, which also makes it one of the most common; attackers simply save the form to their local computers and change the form field values. Luckily, this type of attack is also one of the easiest to protect against by making sure that any “post” action is coming from your Web site.
Security Bytes
In 2005, an XSS worm called JS.Spacehero was spread by hijacking browsers visiting the MySpace Web site in 2005. The worm’s creator uploaded a malicious script to his MySpace profile page, and anyone visiting this page was redirected automatically into sending him a friend request. The worm was then embedded in the hijacked user’s profile page. In less than 24 hours, more than a million MySpace profile pages were infected, making the JS.Spacehero worm one of the fastest spreading worms ever. MySpace had to shut down the site to clean up the infection, and the worm’s creator earned himself a felony conviction.
Injection flaws—Many Web applications pass parameters when accessing an external system. For example, a Web application that accesses a database server needs to pass logon information to the database server. An attacker can embed malicious code and run a program on the database server or send malicious code in an HTTP request. Basically, the attacker is tricking the Web application into running malware or making unauthorized changes to data.
Malicious file execution—Some Web applications allow users to reference or upload files containing malware. If these references or files aren’t checked before the Web application executes them, they can give attackers complete control of the system.
Unsecured direct object reference—This vulnerability occurs when information returned via the URL to a user’s Web browser contains information (references) about files, directories, or database records. By simply changing the information in the URL, attackers can gain unauthorized access to information. For example, a Web application from the IRS with this vulnerability might show your Social Security number in the URL returned to your Web browser. By changing the SSN in the URL and sending it back to the Web application, you could then access another person’s information.
Cross-site request forgery (CSRF)—This vulnerability is also known as a one-click or session-riding attack. To send malicious code to a Web application, the attacker exploits a Web browser that has already been authenticated and is, therefore, trusted. Because the malicious code is coming from a trusted Web browser, it’s normally executed without being checked or validated. This vulnerability can be extremely dangerous.
Information leakage and incorrect error handling—If an error occurs during normal operations and isn’t handled correctly, information sent to users might reveal information attackers can use. For example, attackers can take advantage of error messages that reveal what was executed on the stack or indicate what Web software is used.
Broken authentication and session management—These vulnerabilities enable attackers to compromise passwords or session cookies to gain access to accounts. To reduce this risk, using strong authentication methods is critical, and credentials must be kept secret. You can also incorporate back-end servers to authenticate credentials instead of just relying on the Web server.
Unsecured cryptographic storage—Storing keys, certificates, and passwords on a Web server can be dangerous. If an attacker can gain access to these mechanisms, the server is vulnerable to attack. To decrease the chances of a compromise, don’t store confidential data, such as customers’ credit card numbers, on your Web server. Instead, require that confidential data be entered each time users visit the Web site.
Unsecured communication—Connections between the Web browser and the Web application should be encrypted to protect information as it travels across the Internet. Web applications need to encrypt not only the session to the Web browser, but also sessions to any other servers, such as back-end databases. This vulnerability occurs when sessions are left unencrypted. The PCI DSS requires encrypting all credit card information sent over any network, whether it’s the Internet or a private LAN. In Activity 10.4, you entered credentials in your Web site via an unsecured connection.
Failure to restrict URL access—This vulnerability occurs when developers don’t use adequate access controls for URLs. Instead, they rely on a “security through obscurity” model, which depends on users simply not being aware of the location of critical files and directories. It’s like assuming that because a door isn’t advertised as unlocked, no one will try to open it.
The OWASP paper on the top 10 vulnerabilities might cover some areas beyond the skills of a beginning security tester, so OWASP offers WebGoat, an online utility that helps beginning security testers understand the Web application vulnerabilities covered in this list.
OWASP developed the WebGoat project to help security testers learn how to conduct vulnerability testing on Web applications. Many people from all over the world use WebGoat and offer their input. The OWASP developers want to encourage security students to think and figure out how to launch an attack, so solutions aren’t given for all exercises. The latest version of WebGoat, as of this writing, is included as part of this book’s supporting files. In the following paragraphs, you walk through an example of using WebGoat to learn about some basic Web application attacks. You can follow along, if you like, or just review the steps and figures.
Assuming you’ve booted into Linux with the BackTrack files and opened a Konsole shell, you switch to the WebGoat directory with the cd /opt/WebGoat-5.2 command. To start WebGoat, use the sh webgoat.sh start8080 command shown in Figure 10.9.
Next, you enter http://localhost:8080/WebGoat/attack to log on to the WebGoat Web site. After entering “guest” for both the username and password, you arrive at the start page (see Figure 10.10), where you can click the Start WebGoat button to begin the exercises.
Courtesy Course Technology/Cengage Learning
Figure 10.10
The WebGoat welcome page
Courtesy Course Technology/Cengage Learning
Clicking the Start WebGoat button takes you to the first exercise, which is a short introduction to WebGoat. Click the Introduction link on the left. After you enter a name, the server accepts the HTTP request and reverses the input. For example, entering the name “student” returns the value “tneduts.” You can click the Hints menu shown in Figure 10.11 to see tips, Java code, and any cookies or parameters used.
The exercises become more complex after this one, so you probably won’t be able to do them quickly. For example, the Asynchronous JavaScript and XML (AJAX) security exercise on XML injection involves AJAX code, which is used to create sophisticated dynamic Web applications, such as Facebook, Google Apps, and Microsoft Office Live. To help you learn about AJAX vulnerabilities, WebGoat has set up a fictitious travel rewards Web site (see Figure 10.12); your goal is to add more reward miles to your account than are allowed. Perhaps you can get enough points to earn the WebGoat Hawaii cruise!
Figure 10.11
The WebGoat Hints menu
Courtesy Course Technology/Cengage Learning
Other exercises show different aspects of Web security. For example, one requires setting up a client/server configuration so that you can sniff traffic containing credentials to a Web site; another involves launching a DoS attack by creating too many concurrent logons to the database. The last exercise, called the Challenge (see Figure 10.13), takes beginners to a higher level: breaking an authentication scheme, stealing credit cards from a database, and then defacing a Web site. No solutions are given for this exercise, but knowing how to search the Web can give you additional hints.
Figure 10.12
The AJAX XML injection exercise
Courtesy Course Technology/Cengage Learning
Assessing Web Applications
When looking for possible vulnerabilities in a Web application, security testers look for answers to some important questions. Depending on the tester’s experience level and amount of training in securing Web infrastructures, these questions might be difficult to answer. Remember that most of the time, teams are used when performing a security test. If you have only a little experience with Web applications, you might want to consider adding a team member who has expertise in this subject. Each area covered in the following sections might require specialized knowledge.
Does the Web Application Use Dynamic Web Pages?
If static Web pages are used, there’s less likelihood of an attacker inserting program code in forms or fields displayed in a Web browser. However, static Web pages by no means create a secure environment. A form of attack that has been used for at least a decade and is still used today involves submitting a specially formatted URL to the attacked Web server. This attack was carried out on IIS servers until Microsoft issued a security patch. That’s not to say everyone applied this security patch, or no companies run IIS without it. Therefore, you should verify that the vulnerability isn’t possible on the Web server you have been asked to test.
Figure 10.13
WebGoat’s Challenge exercise
Courtesy Course Technology/Cengage Learning
The vulnerability is that IIS didn’t correctly parse the URL information users entered, which allowed attackers to launch a Unicode exploit. For example, if a user entered the /../.. sequence of characters in a URL, IIS indicated an error. In DOS, two dots are used in commands for traversing up or down the directory tree. They’re also used in Web applications. To bypass this check in IIS, attackers substituted the Unicode equivalent of ../: ..%255c. ASCII uses 8 bits to store characters. Unicode, a more sophisticated character standard, uses 16 bits, so computers can handle Chinese, Japanese, and Middle Eastern character sets. Understanding how Unicode works isn’t essential; all you need to know is that every character you type can be represented in Unicode. The following URL traverses a Windows IIS server, runs the Cmd.exe program, and passes the dir c: parameter to it, which gives the attacker the contents of the C drive:
http://www.nopatchiss.com/scripts/..%255c..%255cwinnt/system32 /cmd.exe?/c+dir+c
Installing a Trojan program on a Web server is even possible if the URL is formed correctly. For example, the URL can use Trivial File Transfer Protocol (TFTP) to connect to a server and install the Trojan program. A second URL can then run the Trojan program. Unicode exploits are still possible today and should be part of your security test.
If the application is using dynamic Web pages, your next questions should be “How is it done? Is CGI used as the mechanism for moving information from the Web server to the Web browser, or is ASP or another method in place?” The answers lead you to the next question.
Does the Web Application Connect to a Back-end Database Server?
Web applications that prompt users for information or display available inventory to users usually have a back-end database server storing all this information. The inventory database has tables containing the information to display to customers, and a customer database usually stores data about users that might include credit card information. In this case, database security is of paramount importance. Who has access to the tables? What database software and version is used—for example, Oracle 11g, Microsoft SQL Server 2008, or MySQL? Is there a possibility of SQL injection being used to attack the system? In SQL injection, the attacker supplies SQL commands when prompted to fill in a Web application field.
A basic SQL statement to select records (rows) in a table named “books” looks like this:
SELECT * FROM books WHERE lname = "Leno";
In an SQL injection, attackers insert (“inject”) their own SQL statements in this statement. Remember the logon form created with HTML in the “Web Application Components” section. An ASP Web page that prompts users for a username and password would look almost the same as that logon form:
<form name="Validate" action="validate.asp" method="post"> Username: <input type="text" name="username"> Password: <input type="text" name="password"> <input type="submit"> </form>
The contents of the username and password parameters are passed to the ASP page, Validate.asp. To verify that the username and password are correct, many Web applications have a secured database of valid usernames and passwords. The Validate.asp page could look something like the following:
<%
1. Dim username, password, sql_statement
2. Dim conn, rs
3. username = Request.Form("username")
4. password = Request.Form("password")
5. set conn = server.createObject("ADODB.Connection")
6. set rs = server.createObject("ADODB.Recordset")
7. sql_statement = "SELECT * FROM customer
WHERE tblusername = '" & username & "' AND tblpassword = '" & password & "'"
8. conn.Open "Provider=SQLOLEDB; Data Source= (local);
Initial Catalog=CustomerDB; User Id=sa; Password="
9. rs.activeConnection = conn
10. rs.open sql_statement
11. if not rs.eof then
12. response.write "Welcome!"
13. else
14. response.write "Please reenter your username and password"
15. end if
%>
The line numbers aren’t used in an actual ASP Web application. They’re included only as a reference. Lines 1 and 2 declare the variables used in the rest of the code: username, password, sql_statement, conn (for the connection), and rs (for the recordset). Dim stands for dimension, which was used in the days of BASIC programming to declare variables.
Lines 3 and 4 define the username and password variables. In Lines 5 and 6, the set conn and set rs commands create the connection string object and recordset objects that will be used. In Line 7, the sql_statement variable holds the SQL statement used to query the database.
Lines 8 and 9 show that SQLOLEDB, the OLE DB provider for SQL Server, is used to connect to the database server. In this case, a database named CustomerDB is accessed, as shown in the Catalog statement.
Line 10 shows that by storing the SQL statement in a variable, you can run it later with rs.open sql_statement. Line 11 checks for the end-of-file (EOF) marker. If no records are found that match what the customer entered (username, password), the Web browser displays the message to reenter the username and password information. If a match is found, the SELECT statement lists all the records in the customer table. So what’s the problem, you ask?
Take a look at the customer table that was created and the command for inserting four records in it:
CREATE TABLE customer (
tblCustomerID CHAR(10);
tblusername VARCHAR(25);
tblpassword VARCHAR(25);
/
INSERT INTO customer (tblusername, tblpassword)
VALUES ("bob", "password");
INSERT INTO customer (tblusername, tblpassword)
VALUES ("ted", "pa$$w0rd");
INSERT INTO customer (tblusername, tblpassword)
VALUES ("alice", "G0uLd");
INSERT INTO customer (tblusername, tblpassword)
VALUES ("carol", "n@tw00d");
If Bob logs on with his credentials, the SELECT statement is as follows:
SELECT * FROM customer WHERE tblusername = 'bob' AND tblpassword = 'password'
Suppose Bob enters the following when prompted for his username, however:
' OR 1=1 --
The SQL statement is then the following:
SELECT * FROM customer WHERE tblusername = '' OR 1=1 -- ' AND tblpassword = ''
Because 1=1 is always true, the query is carried out successfully. Double hyphens (--) are used in SQL to indicate a comment. Are there more tricks to hacking into a database? Take a look at a couple of other things an attacker could have entered when prompted for a username and password:
Please enter username: ' OR "=" Please enter password: ' OR "="
The SQL statement is then as follows:
SELECT * FROM customer WHERE tblusername = ' OR "=" AND tblpassword = ' OR "="
Instead of the SQL statement comparing values the user enters with values in the Customer table, it compares a quotation mark to another quotation mark, which of course returns a true condition. Hence, all rows are returned. It’s surprising that this vulnerability exists on many systems connected to the Internet. You shouldn’t test for this vulnerability by attempting SQL injections on Web sites because this attack is considered intrusive and is subject to criminal prosecution. However, you should test any Web applications when you’re performing a security test and are authorized in writing to do so. Basic testing should look for the following:
Whether you can enter text containing punctuation marks of any kind
Whether you can enter a single quotation mark followed by any SQL keywords, such as WHERE, SELECT, INSERT, UNION, and so on
Whether you get any sort of database error when attempting to inject SQL statements (meaning SQL injection is possible)
By determining that the Web application is using a back-end database server, you have discovered an additional way to conduct a penetration test of the system.
Security Bytes
When students apply for graduate school, waiting for an acceptance letter can be painful. A hacker offered these impatient students a way of getting an answer quickly. The hacker, who has yet to be identified as of this writing, gained access to internal admissions records for Harvard, Stanford, MIT, and other top business schools by exploiting vulnerabilities discovered in a Web application called ApplyYourself. The hacker then posted hacking hints on Business Week’s online forum. (To see the instructions, visit http://poweryogi.blogspot.com/2005/03/hbsapplyyourself-admit-status-snafu.html.) Many applicants, without any hacking background, could find out whether they had been accepted. Harvard Business School identified 119 applicants who hacked the system and stated that it would reject their admissions because of an ethics violation. Some people thought the problem was the lack of security on the ApplyYourself Web server, which allowed an attacker to simply modify the Web server’s displayed URL. The applicants who were caught used their logon names and changed only the URL when connected to the Web server. They didn’t attempt to hide their tracks or guess passwords. Was what they did unethical? This question might seem difficult to answer, but Harvard had no problem doing just that.
Activity 10.5: Identifying SQL Injection Vulnerabilities
Time Required: 30 minutes
Objective: Recognize the many platforms that have SQL injection vulnerabilities.
Description: After determining that a Web application is using a back-end database server to store data, a security tester should attempt to test the Web application for SQL injection vulnerabilities. In this activity, you visit the Common Vulnerabilities and Exposures (CVE) Web site to identify some known vulnerabilities.
1. Start your Web browser, if necessary, and go to www.cve.mitre.org.
2. On the CVE home page, click the Search CVE link on the left, and then click the Search NVD link.
3. On the CVE and CCE Vulnerability Database page, type SQL injection in the Keyword(s) text box and click Search. How many CVE entries are listed?
4. Scroll through the list of vulnerabilities and candidates, and read the descriptions for each entry on the first page. When you get to the end of the list, click the Back button on your browser, type SQL injection phpbb in the Search text box, and click Search. How many entries are listed?
5. When an attacker discovers a vulnerability, as you did in this activity, the next step is trying to find out which businesses use the software. To find this information, you can use a search engine. For example, many Web sites using the phpBB software add a footnote to home pages stating “Powered by phpBB.” Type “powered by phpbb” (including the quotation marks) as your search term. How many Web sites are listed in the search results? Do you think most sites corrected the vulnerability you discovered?
6. Because hackers use the same process to find vulnerable Web sites to hack, it’s likely that some of these Web sites contain malicious code designed to infect your system. Visiting these Web sites isn’t recommended, unless you’re using a Live Linux DVD, such as the BackTrack files you downloaded for this book. What are the security ramifications of listing the type of software you’re running on a Web site?
7. Exit the Web browser.
As you learned in this activity, many Web sites use phpBB. After attackers discover a vulnerability, they look for as many targets as possible to attack. As you can see, notifying clients when you discover a vulnerability is crucial—and the faster, the better!
Does the Web Application Require Authentication of the User?
Many Web applications require that a server other than the Web server authenticate users. For example, a Web application might require using a Windows Server 2008 server running Active Directory Services for authentication. In this case, you should examine how authentication information is passed between the two servers. Is an encrypted channel used, or is data passed in cleartext that can be retrieved easily? Are logon and password information stored in a secured location, or is it possible for an intruder to access and retrieve the information? If attackers recognize that a separate authentication server must validate customer credentials, they have another target to go after. The Web server might not be an attacker’s only point of entry.
On What Platform Was the Web Application Developed?
With so many platforms available for Web developers, it’s no wonder that so many vulnerabilities exist. Knowing whether a Web application was developed on an IIS server with ASP and SQL Server or on a Linux Apache Web Server system using PHP and MySQL, for example, gives both attackers and security testers the ammunition to do their jobs. Remember that the reason you conduct footprinting is to discover what OS and DBMS the attacked system is using. The more you know about the system, the easier it is to gather information about its vulnerabilities. For example, knowing that ASP is the mechanism for moving information from the Web server to the Web browser is critical information for security testers. If CGI is used instead, the attack or security test will be quite different.
TOOLS FOR WEB ATTACKERS AND SECURITY TESTERS
After vulnerabilities of a Web application or an OS platform are discovered, security testers or attackers look for the tools that enable them to test or attack the system. For example, if you learn of a vulnerability in CGI, the next step is discovering whether any systems are using CGI. As you saw in the previous section, all platforms and Web application components have vulnerabilities. No matter which platform is used to develop a Web application, there’s undoubtedly a security hole in it and a tool capable of breaking into the system.
Web Tools
You have already seen that most tools for performing a security test or attacking a network can be found on the Internet and are usually free. The BackTrack online supporting files are packed with free tools for hacking Web application, which you can find in the BackTrack, Web Application Analysis menu. You can install new tools with a simple apt-get install packagename command. However, there are always other tools that might be more suitable for a specific task. The following sections cover some popular tools for hacking Web applications. One of the best Web sites for finding other tools is http://packetstormsecurity.org. As a security tester, you should visit this site weekly to keep track of any new tools and to browse through the multitude of available exploits. Exploits posted on this Web site are often added to Metasploit plug-ins.
Cgiscan: A CGI Scanning Tool
Cgi Scanner v1.4 (Cgiscan.c), written in 1999 by Bronc Buster, is a tool for searching Web sites for CGI scripts that can be exploited. Cgiscan, a C program that must be compiled, is included here as an example of a security tool written in C. Tests for new CGI vulnerabilities can be included by adding code and then recompiling. The programmer has written helpful directions for users, even though the following documentation has many spelling and grammatical errors:
/* Cgi Scanner v1.4 I got tired of looking at a ton of cgi hole scanners and none of them had everything included, so I made one for all the kode kiddies out there. I ripped some of this code from 9x's shell script they echo'ed to netcat to update this, and some other code for storage from someone elses broken version that looked for a few of these already. This will basicly ask a web server (Unix or NT) if they have these programs open to the general public, and if they do, it tells you. I could of made this exploit the holes as well, but I have to leave something for you to do (well in the LoU released version it did exploit them). Sometimes it will tell you that the files DO EXIST, but you may not have access to them. By using another hole you may be able to access them though. So if the scan returns that it found something, don’t instantly think you can exploit it. If they have changed their '404' page it will also sometimes return a false reading. To complie: luser$ gcc cgiscan.c -o cgiscan To use: luser$./cgiscan somedomain.com (i.e../cgiscan antionline.com) coded by Bronc Buster of LoU - Nov 1998 updated Jan 1999 [gh] uses this to preform all their eLe3t h4cKs, shouldn't you? */ #include <sys/types.h> #include <netinet/in.h> #include <string.h> #include <netdb.h> #include <ctype.h> #include <arpa/nameser.h> #include <strings.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/socket.h> #define MAX_SIZE 21 /* make this the size of temp[] if you change it */ int main(int argc, char *argv[]) { int s; struct in_addr addr; struct sockaddr_in victem; struct hostent *bad; char foundmsg[] = "200"; char *cgistr; char buffer[1024]; char cgibuff[1024]; int num, i=0; char *temp[22]; char *name[22]; temp[1] = "GET /cgi-bin/phf HTTP/1.0 "; temp[2] = "GET /cgi-bin/Count.cgi HTTP/1.0 "; temp[3] = "GET /cgi-bin/test-cgi HTTP/1.0 "; temp[4] = "GET /cgi-bin/php.cgi HTTP/1.0 "; temp[5] = "GET /cgi-bin/handler HTTP/1.0 "; temp[6] = "GET /cgi-bin/webgais HTTP/1.0 "; temp[7] = "GET /cgi-bin/websendmail HTTP/1.0 "; temp[8] = "GET /cgi-bin/webdist.cgi HTTP/1.0 "; temp[9] = "GET /cgi-bin/faxsurvey HTTP/1.0 "; temp[10] = "GET /cgi-bin/htmlscript HTTP/1.0 "; temp[11] = "GET /cgi-bin/pfdispaly.cgi HTTP/1.0 "; temp[12] = "GET /cgi-bin/perl.exe HTTP/1.0 "; temp[13] = "GET /cgi-bin/wwwboard.pl HTTP/1.0 "; temp[14] = "GET /cgi-bin/www-sql HTTP/1.0 "; temp[15] = "GET /_vti_pvt/service.pwd HTTP/1.0 "; temp[16] = "GET /_vti_pvt/users.pwd HTTP/1.0 "; temp[17] = "GET /cgi-bin/aglimpse HTTP/1.0 "; temp[18] = "GET /cgi-bin/man.sh HTTP/1.0 "; temp[19] = "GET /cgi-bin/view-source HTTP/1.0 "; temp[20] = "GET /cgi-bin/campas HTTP/1.0 "; temp[21] = "GET /cgi-bin/nph-test-cgi HTTP/1.0 "; name[1] = "phf"; name[2] = "Count.cgi"; name[3] = "test-cgi"; name[4] = "php.cgi"; name[5] = "handler"; name[6] = "webgais"; name[7] = "websendmail"; name[8] = "webdist.cgi"; name[9] = "faxsurvey"; name[10] = "htmlscript"; name[11] = "pfdisplay"; name[12] = "perl.exe"; name[13] = "wwwboard.pl"; name[14] = "www-sql"; name[15] = "service.pwd"; name[16] = "users.pwd"; name[17] = "aglimpse"; name[18] = "man.sh"; name[19] = "view-source"; name[20] = "campas"; name[21] = "nph-test-cgi"; if (argc!=2) { exit(printf(" Usage : %s domain.com ", argv[0])); } if ((bad=gethostbyname(argv[1])) == NULL) { exit(printf("Error getting hostname ")); } printf("New web server hole and info scanner for elite kode kiddies "); printf("coded by Bronc Buster of LoU - Nov 1998 "); printf("updated Jan 1999 "); system("sleep 2"); s=socket(AF_INET, SOCK_STREAM, 0); if(s<0) exit(printf("Socket error")); bcopy(bad->h_addr, (char *)&victem.sin_addr, bad->h_length); victem.sin_family=AF_INET; victem.sin_port=htons(80); if (connect(s, (struct sockaddr*)&victem, sizeof(victem))<0) 10 { exit(printf("Connect error ")); } printf(" Getting HTTP version "); send(s, "HEAD / HTTP/1.0 ",17,0) recv(s, buffer, sizeof(buffer),0); printf("Version: %s", buffer); close(s); system("sleep 2"); while(i++ < MAX_SIZE) { s=socket(AF_INET, SOCK_STREAM, 0); bcopy(bad->h_addr, (char *)&victem.sin_addr, bad->h_length); victem.sin_family=AF_INET; victem.sin_port=htons(80); if (connect(s, (struct sockaddr*)&victem, sizeof(victem))<0) { exit(printf("Connect error ")); } printf("Searching for %s : ", name[i]); for(num=0; num<1024; num++) { cgibuff[num] = ' '; } send(s, temp[i], strlen(temp[i]),0); recv(s, cgibuff, sizeof(cgibuff),0); cgistr = strstr(cgibuff, foundmsg); if(cgistr != NULL) printf(" * * Found * * "); else printf(".. Not Found.. "); close(s); } printf(" [gH] - aka gLoBaL hElL - are lame kode kiddies "); return 0; } /* EOF */
Figure 10.14 shows the program being compiled and run on a Linux computer. A security tester can use the information this program retrieved to delve into possible attacks that could be made on the company’s Web server.
Figure 10.14
Compiling and running Cgiscan
Courtesy Course Technology/Cengage Learning
Wapiti
Wapiti is a Web application vulnerability scanner that uses a black box approach, meaning it doesn’t inspect code. Instead, it inspects a Web site by searching from the outside for ways to take advantage of XSS, SQL, PHP, JSP, and file-handling vulnerabilities. Although Wapiti can detect common forms that allow uploads or command injection, it uses what’s called “fuzzing”—trying to inject data into whatever will accept it. In this way, even new vulnerabilities can be discovered. Other scanners search for only known vulnerability signatures. Wapiti is just one of the many Web application vulnerability tools included as part of this book’s supporting files. To start it, use the wapiti http://URL command (replacing URL with the URL of the Web site you’re inspecting) in a Konsole shell.
Wfetch
If you’re tired of all these text-mode programs, Wfetch is a GUI tool that can be downloaded free from Microsoft and is included in the IIS Resource Kit. The 1.4 version works in Windows XP through Windows 7. Microsoft warns users that Wfetch has advanced features that might expose a server to potential security risks, so be careful. Despite these cautions, this helpful tool enables security testers to query a Web server’s status and attempt authentication by using any of the methods in the fourth bullet in the following list. Wfetch 1.4 offers these features:
Multiple HTTP methods, such as GET, HEAD, TRACE, POST, and OPTIONS n Configuration of hostname and TCP port
HTTP 1.0 and HTTP 1.1 support
Anonymous, Basic, NTLM, Kerberos, Digest, and Negotiate authentication types
Multiple connection types, such as HTTP, HTTPS, PCT 1.0, SSL 2.0, SSL 3.0, and TLS 3.1
Proxy support
Client-certificate support
Capability to enter requests manually or have them read from a file
Onscreen and file-based logging
Figure 10.15 shows the information Wfetch gathers, which would tell an attacker the IIS version the user is running as well as the type of authentication (Anonymous, in this example) the Web server is using.
Figure 10.15
Using the Wfetch program
Courtesy Course Technology/Cengage Learning
CHAPTER SUMMARY
Web applications can be developed on many different platforms. HTML Web pages can contain forms, ASP, CGI, and scripting languages, such as VBScript and JavaScript. Note, however, that scripting languages account for more than half of Web server attacks.
Many static Web pages have been replaced by dynamic Web pages, which are created on the fly when a user calls the page. Dynamic Web pages can be created with a variety of techniques, including CGI, ASP, PHP, ColdFusion, JavaScript, and more.
Web forms allow developers to create Web pages that visitors can interact with. Care should be taken, however, to ensure that form fields can’t be manipulated by attackers.
Web applications use a variety of technologies to connect to databases, such as ODBC, OLE DB, and ADO. These technologies create a front-end interface, allowing a Web application to connect to a back-end database.
You can install IIS to test your Web pages in Windows.
Web application vulnerabilities can have damaging consequences for a company. An attacker might be able to deface the company Web site, destroy a critical database, gain access to user accounts, or even gain access to the admin account or root access to other application servers on the network.
When conducting security tests on Web applications, determine whether dynamic Web pages were used, whether the Web application connects to a back-end database, whether a separate server is used for authenticating users, and what platform was used to develop the Web application.
Web applications that interact with databases might be vulnerable to SQL injection exploits. Unicode exploits are possible in older versions of IIS.
Many tools for testing Web application vulnerabilities (and attacking Web servers) are available, such as Wfetch and Wapiti. In addition, OWASP offers open-source software to help security professionals learn about Web application vulnerabilities.