CHAPTER 8

Web-Based Hacking: Servers and Applications

In this chapter you will learn about

Have you ever heard of Alexander the Great? A king of Macedonia (in Northern Greece), he created one of the largest empires in history by the ripe old age of 30. Tutored by Aristotle, he was one of the most intelligent military strategists in all of history. As a matter of fact, he was undefeated in battle and is considered one of the most successful commanders of all time, with his tactics and exploits still being taught in military circles today.

Along the way to creating his empire, Alexander conquered the great Persian Empire, crushing Xerxes in a series of battles across many years. In his march across the empire, Alexander was faced with a conundrum in the city of Persepolis. Considered impenetrable to attack, the city was surrounded by strong, thick walls, and was nearly self-sufficient, able to simply wait out most attackers and their armies. After some time thinking on the subject—dare I say “footprinting” his target?—he noticed one potential weakness: The people of Persepolis liked their commerce, and traded openly just outside the walls of the city.

Alexander maneuvered and manipulated trading until he could finally slip something into one of the carts headed back into the city, which just happened to be headed to the eastern part of the city—the seat of government. The resulting fire, started from inside the walls and causing all sorts of havoc, distracted the city’s defenses enough that Alexander simply pushed through the front door and sacked the once proud enclave.

I know you’re wondering what this story, as interesting as it may be, has to do with hacking. If you think about it, though, it is a microcosm of where you should be focusing a large portion of your pen test hacking attention. Businesses and corporations are like those ancient cities, with so many defenses arrayed against you they seem impenetrable. But most of them—heck, all of them—have some sort of a website facing the exterior world; in short, a way in is always there. It may take some time to figure out how to use that public-facing web server or application to get a fire started inside the gate, but trust me, it’s worth it. This chapter is all about web servers and applications and how you can exploit them. After all, if the target is going to trust them, why not have a look?

Attacking Web Servers

Regardless what your potential target offers to the world—whether it’s an e-commerce site, a suite of applications for employees and business partners to use, or just a means to inform the public—that offering must reside on a server designed to provide things to the world. And let’s just face it: Web servers are unique entities in the virtual world we play in. Think about it—we spend loads of time and effort trying to hide everything else we own. We lock servers, routers, and switches away in super-secure rooms and disguise entire network segments behind NAT and DMZs. Web servers, though, are thrown to the proverbial wolves. We stick them right out front and open access to them. Sure, we try our best to secure that access, but the point still remains: Web servers are open targets the entire world can see. And you can rest assured those open targets will get a strong look from attackers.

Web Services Architecture

At its most basic, a web server acts like any other server you already know about—it responds to requests from clients and provides a file or service in answer. In this case, a request first comes from a client to open a TCP connection on (usually) port 80 (443). After agreeing to the handshake, the server waits for an HTTP GET request from the client. This request asks for specific HTML code representing a website page. The server then looks through a storage area and finds the code that matches the request, and provides it to the client.

This all sounds simple enough, but there’s really a multitude of issues to think about just in that exchange. How does the server validate what the client is asking for? Does the server respond only to specific verbiage in the request, or can it get confused and respond with other actions? Where are the actual files of HTML (and other) code stored, and how are the permissions assigned to them? I could go on and on, but I think you can understand my point.

When it comes to web servers, there are two major players on the block. Yes, I realize that many, many more server products are available to host sites from, and I’m sure they have benefits and drawbacks that make them better choices for specific applications in any unique situation. However, just as we spent most of our time covering Windows hacking, we’re going to concentrate on Internet Information Services (IIS) and Apache servers (see Figure 8-1) for a couple of reasons. First, they simply make up the vast majority of servers out there. Second, they’re the only two mentioned in the CEH objectives. But don’t get too concerned—you won’t be saddled with a lot of minutia on the exam concerning these two web servers. Most of this information is delivered here because I think it’s important for you to know as a hacker. No, we’re not going to dive so far down into scripting that you’ll be bored, but we are going to at least brush the strokes wide enough so you’re familiar with the terminology and the very basics of the servers.

Apache servers (www.apache.org) make up the majority of web hosts on the Internet. Apache is an open source, very powerful, and very fast web server that typically runs on a Unix or Linux platform, although you can load and use it on a wide variety of operating systems. By and large, Apache servers haven’t seemed to display as many, or as serious, vulnerabilities as their Microsoft IIS peers, but this isn’t to say they are foolproof. Several critical vulnerabilities on Apache servers have come to light in the past (check any of the vulnerabilities sites we referenced in previous chapters), making them as easy a target as anything else.

IIS servers are easy-to-manage, Windows-based options for the web provider. Originally, IIS was riddled with security concerns, and finding an IIS 5 or earlier server at your target is cause for wild celebration on the pen test team. However, the later versions have done a much better job of tightening down the security screws. From Microsoft’s own description, “IIS 7.0 includes a new modular design that allows for a lessened attack surface and increased performance. IIS 7.0 introduces a hierarchical configuration system allowing for simpler site deploys, a new Windows Forms–based management application, new command-line management options, and increased support for the .NET framework.”

Figure 8-1 IIS and Apache

NOTE If you really want to learn about web server architecture and how it all works, why not play with it yourself? Apache web servers are relatively easy to install and run, and there’s plenty of assistance and help on the Internet to get you started. Download the server and host a website or two inside your home network—it’s really the best way to learn.

Whether it’s an Apache or an IIS server, scripting is always a concern. CGI (Common Gateway Interface) is a standard method for web servers to pass a user’s request to an application program and receive data back to forward to the user. In the case of a simple web page, the user clicks a link and the server provides the HTML for the page. However, if the user enters data into a form, that data generally needs to be passed to an application of some sort. This back and forth is known as CGI, and any number of scripts can be written to handle all sorts of data exchanges between the server, the application, and the user.

Exercise 8-1: Determine the Web Server Type

In this exercise you’ll use some banner-grabbing techniques we covered earlier in the book to see which web server your site is being delivered from. I’ve left the actual web address as “anywhere.com,” so you can simply replace it with the website(s) of your choice.

Using Telnet, follow these steps:

If the administrator hasn’t adjusted the banners to protect himself, the results should show which type of server you’re looking at. For example, it may look like this:

HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/5.0
Date: THU, 5 May 2011 20:36:17 GMT
Content-Type: text/html
Content-Length: 87
<html><head><title>Error</title></head><body>
The parameter is incorrect. </body></html>
Connection to host lost.

Using netcat, follow these steps:

GET HEAD / 1.0
CR
CR

nc -vv webserver 80 < testfile.txt

For example, you may have a web page allowing a client to enter data into a form. Suppose you need some work done on the data, and depending on the result, a specific message is sent back to the user. You could create a CGI “application” to accomplish this, call it into action on the form, and give it control. If the code, for example, were to read

<form method="POST" action="http://www.anywhere.com/cgi-bin/anyapplication.pl">

you’d basically be telling the web server for “anywhere.com” to pass the information, and control, over to a CGI application named “anyapplication.pl.”

Because CGI scripts can run essentially arbitrary commands on your system with the permissions of the web server user, they can be extremely dangerous if not carefully checked. Additionally, all CGI scripts on the server will run as the same user, so they have the potential to conflict (accidentally or deliberately) with other scripts (an attacker could, for example, write a CGI script to destroy all other CGI databases).

SSI (Server Side Includes), another scripting-type security concern, involves directives placed in HTML pages that are evaluated on the server while the pages are being served. They let you add dynamically generated content to an existing HTML page, without having to serve the entire page via a CGI program or some other dynamic technology. SSIs are useful for including a common piece of code throughout a site, such as a page header, a page footer, or a navigation menu. However, SSIs can increase the load on the server itself and, probably even more important, they can execute any CGI script or program under the permissions of the user. The httpd.conf file in Apache controls this access.

SSI is very simple, and recognizes only text commands falling into the same basic syntax:

<!--#directive parameter=value parameter=value -->

The most common SSI command is “include,” and to use this in a page, you would use the #include statement. This command tells the server to include another file (one that you can update once and change the content on all pages in your site, for example) and tells it the file name that should be included. For example, you might find the command

<!--#include FILE="somefile.doc"-->

inside the HTML for a page, where somefile.doc would be displayed as part of the page.

SSI commands can include anything from basic documents and formatting instructions (for date and time, for instance) to results of other scripts (CGI). The config parameter allows you set formatting options, whereas the exec parameter will run the script you define in the command. SSI also provides for many conditional directives (such as an if-then) that can be used for a large variety of tasks.

Web Attacks

So we know a little about web server architecture and have a little background information on the terminology, but the question remains: How do we hack them? A good question, and one we’ll tackle in this section. As with many other attack vectors we’ve discussed in this book so far, web server attacks are broad, multiple, and varied. We’ll hit the highlights here, both for your career and for your exam.

Directory traversal is one form of attack that’s very common and very successful—at least on older servers. To explore this attack, think about the web server architecture. When you get down to it, it’s basically a big set of files in folders, just like any other server you have on your network. The server software is designed to accept requests and answer by providing files from specific locations on the server. It follows, then, that there are other folders on the server, maybe outside the website delivery world, that hold important commands and information.

For a very broad example, suppose all of a website’s HTML files, images, and other goodies are located in a single folder (FOLDER_A) off the root of the machine, while all the administrative files for the server itself are located in a separate folder (FOLDER_B) off the root. Usually HTML requests come to the web server software asking for a web page, and by default the server goes to FOLDER_A to retrieve them. However, what if you could somehow send a request to the web server software that instead says, “Mr. Server, I know you normally go to FOLDER_A for HTML requests. But this time, would you please just jump up and over to FOLDER_B and execute this command?” Figure 8-2 shows this in action.

Welcome to directory traversal. In this attack, the hacker attempts to access restricted directories and execute commands outside intended web server directories. Also known as the dot-dot-slash attack, directory climbing, and backtracking, this attack basically sends HTTP requests asking the server to drop back to the root directory and give access to other folders. An example of just such a command might look like this:

http://www.example.com/../../../../directory_of_choicecommand.exe

The dot-dot-slashes are intended to take the shell back to the root and then to execute command.exe in the directory of choice. This may take a little trial and error, and it isn’t effective on servers that take steps to protect input validation, but it’s definitely worth your time.

A major problem with directory traversal is that it’s sometimes fairly noisy. Signature-based IDSs have all sorts of rules in place to look for dot-dot-slash strings and the like. One method for getting around this is to use Unicode in the string to represent the dots and slashes. As you’re probably already aware, several Unicode strings can be used to represent characters and codes. In general, the “%2e” code can represent a dot, whereas “%sf” can represent a slash. Putting them together, your Unicode string would look like this:

Figure 8-2 Directory traversal

%2e%2e%2f

Additionally, don’t be afraid to mix up your Unicode in different variations: %2e%2e/ and ..%2f are examples.

EXAM TIP This dot-dot-slash attack is also known as a variant of “Unicode” or unvalidated input attack. Unicode is a standard for ensuring consistent encoding and text representation, and can be accepted by servers for malicious purposes. Unvalidated input means the server has not been configured to accept only specific input during an HTTP GET, so an attacker can craft the request to ask for command prompts, to try administrative access passwords, and so on.

Another attack that sometimes involves a lot of trial and error is called parameter tampering (a.k.a. URL tampering). In this attack, the hacker simply manipulates parameters within the URL string in hopes of modifying data—such as permissions and elevation of privileges, prices and quantities of goods, and credentials. The trick is to simply look at the URL and find parameters you can adjust and re-send.

Suppose, for example, you’re surfing on a weak banking site, transferring money from one account to another, and the URL appears like this:

http://weakbank.com/sample?Toacct=1234&Fromacct=5678&credAmnt=50

Some interesting parameters in this URL might be the “From” and “To” accounts, as well as (what appears to be, anyway) the credit amount of the transfer. Suppose you changed the “Fromacct=5678” parameter to another account number at the bank (one that’s not yours) and sent that to the server? For that matter, if you’re going to change the URL, aim high and change the “Amnt=50” parameter to something really worthwhile—say 5000 or so?

For another example, suppose you’re tracking orders on a website for a target business, and your order shows like this in the URL:

http://example.com/orderdetail.asp?orderID=101

The page displays your name, address, phone number, and the order details. Well, what if you changed the orderID field to 102? Perhaps you could gain information on other orders and build some solid intelligence to aid your attacks.

You could even use this to affect pricing on poorly built shopping cart sites. For example, consider this URL:

http://example.com/add.asp?ItemID=513&Qty=1&Price=15

Maybe you consider it offensive to pay $15 for the volleyball you’re adding to the cart. So why not change the “Price” parameter to something a little more palatable—such as 5? Again, these parameter manipulations are innumerable and don’t necessarily work on everything—in fact, even the most basic of security on sites should prevent most of this—but they’re definitely worth a shot.

	NOTE Despite the ease with which these parameter-manipulation attacks can be carried out, and the full knowledge of administrators of their existence, you’d be surprised how many sites are vulnerable to this very thing. These types of attacks are extremely common—even on “secure” sites.

Finally, URL obfuscation can be used to bypass basic ACLs. Very often, ACLs block on IP addresses (and occasionally on the text string itself). To get around this, change the IP address of the site you’re attempting to attack to an encoded binary equivalent. In other words, don’t send a text URL (http://www.badsite.com) or an IP address (http://200.58.77.66). Instead, change the IP to its equivalent and try that. Here are the steps involved:

EXAM TIP You will definitely see, somewhere on your exam, a question or two involving binary equivalents. My advice to you is to save those for the end of the exam. For me, math is easy but takes a while to do. Don’t bog yourself down trying to figure out what 3359264066 equates to in binary so you can convert it back to the IP address. After you’re done with the other questions, come back and take a look. Sometimes a shortcut (such as noticing that an even number always ends with the last bit set to 0, whereas an odd number ends with the last bit set to 1) is the key to solving it quickly.

Another version of parameter tampering (trust me) involves manipulating the hidden field on the source code itself. See, back in the day, web developers simply didn’t think users would bother looking at the source code (assuming they were too stupid) and they relied on poor coding practices. The thought was that if the users didn’t see it displayed in their browsers, they wouldn’t know it was there. To take advantage of this, developers used an HTML code attribute called “hidden.” Despite the fact that it’s a very well-known vulnerability, especially on shopping sites, and it’s a generally accepted fact that the web page itself shouldn’t be holding this information, the use of the hidden attribute for pricing and other options is still pretty prevalent. To see how it works, check out the following code I took from a website I found today:

<INPUT TYPE=HIDDEN NAME="item_id" VALUE="SurfBoard_81345" 
<INPUT TYPE=HIDDEN NAME="price" VALUE="659.99" 
<INPUT TYPE=HIDDEN NAME="add" VALUE="1"

Suppose I really wanted a surfboard, but really didn’t want to pay $659.99 for it. I could simply save the code from this page to my desktop (be sure to check for Unicode encoding if prompted to), change the “price” value to something more reasonable, such as 9.99, save the code, and then open it in a browser. The same web page would appear, and when I clicked the “Add to Cart” button, the surfboard would be added to my cart, with a cost to me of $9.99. Obviously, this amounts to theft, and you could get into a world of trouble trying this, so please don’t be ridiculous and get yourself in trouble. The idea here isn’t to show you how to steal things, it’s to show you how poor coding can cost a business. Not to mention that the hidden field can carry all sorts of other things too. For example, might the following line, which I found on another forum website earlier, be of interest to you?

<INPUT TYPE=HIDDEN NAME="Password" VALUE="Xyc756r"

Another web server attack vector we just can’t pass on talking about deals with passwords themselves. After all, somebody has login credentials to this big machine to affect configuration changes, don’t they? So doesn’t it follow that, were we to somehow steal this password, we would be able to effect changes to the server? You can use a tool such as Brutus (www.hoobie.net) to try brute-forcing web passwords over HTTP, or THC-Hydra, which is a pretty fast network logon cracker. Of course, any of the other password-cracking options we’ve already discussed in Chapter 6 may be applicable here as well.

Finally, don’t overlook the all-in-one attack frameworks, such as Metasploit (shown in Figure 8-3), that can make short work of web servers. Metasploit will cover lots of options for you, including exploitation of known vulnerabilities and attacking passwords over Telnet, SSH, and HTTP. A basic Metasploit exploit module consists of five actions: Select the exploit you wish to use, configure the various options within the exploit, select a target, select the payload (that is, what you want to execute on the target machine), and then launch the exploit. Simply find a web server within your target subnet, and fire away!

Figure 8-3 Metasploit

Web Applications

Web applications are another issue altogether, although many of the same attacks and lines of reasoning will bleed over here from the web server side. A web application, in terms of your CEH exam, fills an important gap between the website front end and the actual database performing the work. Users interact with the website to affect database or other dynamic content instances, but it’s the web app that’s actually performing the magic. Web applications are increasingly becoming an attack vector of choice, due in large part to their sheer numbers and the lack of standardization across the board. Many web apps are created “in house” by the business and, as a result, usually have vulnerabilities built in, due to a lack of security oversight during their creation. This section is all about the attacks you might see and use in hacking web applications.

Application Attacks

Web applications are most often hacked due to inherent weaknesses built into the program at inception. Developers might overlook known vulnerabilities, forget to patch security flaws, or leave default passwords and accounts open for exploitation. A patient hacker can scratch away at the application looking for these vulnerabilities, eventually finding their way in. It’s obviously impossible to cover every single one of these vulnerabilities and the attacks that work on them, because each is dependent on the circumstances and the individual application. Just know, for now, that this is probably how a lot of successful web hacks are eventually going to work.

One very successful web application attack deals with injecting malicious commands into the input string. The objective is much like that of the URL-tampering methods discussed earlier in this chapter: to pass exploit code to the server through poorly designed input validation in the application. This can occur using a variety of different methods, including file injection (where the attacker injects a pointer in the web form input to an exploit hosted on a remote site), command injection (where the attacker injects commands into the form fields instead of the expected test entry), and shell injection (where the attacker attempts to gain shell access using Java or other functions). The most common of these, though, and the one you’ll definitely see on your exam, is a very specialized form of injection attack involving the database language itself.

SQL Injection

Because this is such an important topic in the world of hacking and web security, we need to set some ground rules and expectations first. SQL injection is, by far, the most common and most successful injection attack technique in the world. This attack leads to credit card theft, identity theft, and destruction of data across the Internet. It pops up nearly everywhere—the next big credit card theft story you read will, most likely, be due to an SQL injection attack of some sort. All of this should lead you to believe, then, that learning and mastering SQL is a skill you will want to hone as a successful ethical hacker. And although that is true, it’s not what we’re going to do here.

Becoming an SQL master is not what this book is about, nor do we have the space or time to cover every facet of it—or even most of them, for that matter. Our job here is twofold. Primarily it’s to help you pass the test, and secondarily it’s to assist you in becoming a true ethical hacker. You’re going to get the basics here—both for your exam and your career—but it’s going to be just enough to whet your appetite. If you really want to become a seasoned master at this, study SQL and learn all you can about how it works. For now, though, let’s cover the basics and what you need to know.

Structured Query Language (SQL) is a computer “language” designed for managing data in a relational database system. The relational database itself is simply a collection of tables (consisting of rows, which hold individual fields containing data) tied together using some common field (key) that you can update and query. Each table has a name given to it that is referenced when you perform queries or updates. SQL comes into play when you are adding, deleting, moving, updating, or viewing the data in those tables and fields. It’s not too overwhelmingly complicated to do the simple stuff, but the SQL queries can, eventually, get pretty complex.

For example, let’s consider the SELECT command. SELECT is used to choose the data you’d like to perform an action on. The statement starts, amazingly enough, with the word “SELECT,” followed by innumerable options and elements to define what you wish to act upon and what that action will be. A command of

SELECT * FROM Orders

says, “Database, I’d like you to pull all records from the table named Orders.” Tweaked a little, you can get more granular. For example,

SELECT OrderID, FirstName, LastName FROM Orders

will pull everything in the OrderID, first name, and last name columns from the table named “Orders.” When you start adding other command options such as WHERE (setting up a conditional statement), LIKE (defining a condition where something is similar to a given variable), AND, and OR (self-explanatory), you can get even crazier. For example,

SELECT OrderID, FirstName, LastName FROM Orders WHERE LastName = 'Walker'

will pull all orders made by some dude with the last name of Walker.

In addition to SELECT, there are a bunch of other options and commands of great interest to a hacker. For example, can you—with no other SQL experience or knowledge—probably figure out what the command “DROP TABLE tablename” does? Any of you that didn’t respond with “Delete the table tablename from the database,” should immediately start taking Ginkoba to improve your cognitive and deductive skills. How about the commands INSERT or UPDATE? As you can see, SQL in and of itself isn’t rocket science. It is, though, very powerful and commands a lot of respect. Researching command language syntax for everything SQL can offer will pay off dividends in your career—trust me on this.

So, we know a little about SQL databases, and have a basic understanding of how to craft query commands, but the big question is, “So what? Why is this so important?” In answer, pause for just a moment and consider where a database might reside in a web server/application arena you’re trying to hack, and what it’s there to do. The front end takes input from the user through the web server and passes it through an application or form to the database to actually adjust the data. And what, pray tell, is on this database? Maybe items such as credit card account numbers, personally identifiable information, and account numbers and passwords don’t interest you, but I promise you can find all of that and more in a web-serviced database.

SQL injection occurs when the attacker injects SQL queries directly into the input form. Properly constructed, the SQL command bypasses the intent of the front end and executes directly on the SQL database. For example, consider Figure 8-4 and the sample SQL shown there. The form is constructed to accept a user ID and password from the user. These entries are placed into an SQL query that says, “Please compare the username given to the password in its associated field. If this username matches this password, allow access.” What we injected changed the original query to say, “You can compare whatever you’d like, but 1=1 is a true statement, so allow access please.”

Figure 8-4 SQL injection

	NOTE You can also try SQL injection up in the URL itself. For example, you can try to pass authentication credentials by changing the URL to read something like this: http://www.example.com/?login=‘OR 1=1- -.

Of course, knowing this isn’t any good to you if you can’t figure out whether the target site is vulnerable to SQL injection in the first place. To find out, check your target for a web login page, and instead of entering what’s asked at the web form, simply try a single quote (‘) and see what kind of error message, if any, you receive. If that doesn’t work, try entering anything’ or 1=1- - and see what you get. If you receive an error message like the one shown in Figure 8-5, you’re more than likely looking at a site vulnerable to SQL injection.

Most developers are familiar with this little SQL “test,” and lots of things have been done to prevent its use. Many C++ and .NET applications now simply explode with errors when they are sent a single quote (or some variant thereof) and other special characters, and this input never even gets processed by the application. Another effort involves the so-called “Magic Quotes” in Apache, which filters out (escapes) the characters before the application ever sees them. Of course, use of “fuzzing attack” tools such as Burp can make use of the error messaging itself to point out the underlying potential vulnerabilities on the system.

To see SQL in action, consider a website that has a “Forgot your password? Click here and we’ll send it to you” message. After clicking the button, you get a pop-up window asking you to insert your e-mail address. You type it in, hit ENTER, and your password is e-mailed to your account on file. Well, what if you send an SQL command in the form instead and ask the database to create (INSERT) a new record in the user and password table just for you? The command

Figure 8-5 SQL error message

anything' ; INSERT INTO cust ('cust_Email', 'cust_Password', 'cust_Userid',

'cust_FirstName', 'cust_LastName') VALUES ( '[email protected]',

'P@ssw0rd', 'Matt' , 'Matthew', 'Walker') ; - -

says to the database, “Database, you have a table there named cust. I think that probably stands for customers. So if you would, please enter into the fields labeled Email, Password, Userid, FirstName, and LastName these new values I’m supplying for you. Thank you, and hack ya later.”

For that matter, if you’re at a site requiring login, why not just try bypassing the authentication altogether? Try logging in using SQL statements. For example,

admin ' - - or admin ' /*

might be beneficial. You can also try the old standby

' or 1=1 - -

or some variation thereof, such as

')

or

('1'='1- -

In any case, you can find bunches of these types of SQL strings to try on the Internet. One cautionary note, though: Brute forcing SQL this way isn’t the quietest means of gaining access. If you’re banging away with 10,000 variations of a single open quote, you’re going to get noticed.

There are tons and tons of SQL injection examples, and just as many names given for the attacks. We can’t cover them all here, but I will be kind enough to provide you a couple of attack names and definitions for your study (please keep in mind that anything other than basic SQL will have some significant semantic differences, so always Google the database version you’re trying):

As always, you can peck around with this stuff and learn it manually, or you can take advantage of tools already created to make your job easier. sqlmap and sqlninja are both automated scanners designed to look specifically for injection vulnerabilities. Another one I’ve seen in play is called Havij, which allows all enumeration, code execution on the target, file system manipulation, and all sorts of madness over SQL connections. SQLBrute is a tool that, amazingly enough, allows you to blast through predefined SQL injection queries against a target. Others include, but are not limited to, Pangolin, SQLEXEC, Absinthe, and BobCat.

	NOTE Protection against SQL injection usually comes down to securityminded web and database design in the first place. However, you can make use of tools and signatures to at least monitor for attempts; for one example, you can check the Snort signatures for pre-built SQL rules and then block or monitor for attempts using the signatures.

Cross-Site Scripting

Second in our romp through web applications and server attacks are cross-site scripting (XSS) attacks. This can get a little confusing, but the basics of these attacks come down to website design and dynamic content. Usually when a web form pops up, the user inputs something and then some script dynamically changes the appearance or behavior of the website based on what has been entered. XSS occurs when the bad guys take advantage of that scripting (Java, for instance) and have it perform something other than the intended response.

For example, suppose a pen-test member discovers a website at the target that appears to be vulnerable to XSS. He puts together an e-mail message that, of course, looks official and sends it to internal users. The link embedded in the e-mail contains naughty code written to take advantage of the website. The user, unknowingly, clicks the link while logged on and sends the bad code to the web server. The server then does what it’s supposed to—it processes the code sent from an authorized user. Wham! Hack city.

	EXAM TIP You’ll need to know what XSS is and what you can do with it. Also, be able to recognize that a URL such as the following is an indicator of an XSS attempt: http://IPADDRESS/”;!- -” <XSS>=&{()}.

XSS can be used to perform all sorts of badness on a target server. In addition to simply bringing it down in a good old DoS attack, XSS can also be used to steal users’ cookies, to upload malicious code to users connected to the server, and to send pop-up messages to users. One of the classic attacks of XSS involves getting access to “document.cookie” and sending it to a remote host. That variable typically contains all the session information stored on a user’s browser. So what about that PHP session ID that identifies the user to the website? Well, the attacker has it now and can masquerade as the user all day, plugged into a session. XSS attacks can vary by application and by browser, and can range from nuisance to severe impact depending on what the attacker chooses to do. They represent the second largest attack vector online today (SQL still being #1).

	NOTE RSnake and http://ha.ckers.org/xss.html are authoritative sources for XSS attacks.

Buffer Overflows

A buffer overflow attack is one that should never be successful in modern technology, but still remains a great weapon in your arsenal, due to poorly designed applications. To truly use this attack, you’re probably going to have to become a good computer programmer, which I’m sure just excites you to no end. The good news on this, though, is twofold. First, many Metasploit-like tools make this much easier for you to attempt. Second, you only need to know the basic mechanics of the attack for your CEH exam.

The most basic definition of a buffer overflow is an attempt to write more data into an application’s pre-built buffer area in order to overwrite adjacent memory, execute code, or crash a system (application). In short, you input more data than the buffer is allocated to hold. The result can be anything from crashing the application or machine to altering the application’s data pointers, allowing you to run different executable code.

The buffer overflow attack categories are as follows:

In addition to good coding techniques, to avoid allowing the overflow in the first place, sometimes developers can make use of “canaries” or “canary words.” The idea comes from the old mining days, when canaries were kept in cages in various places in a mine. The canary was more susceptible to poison air and would, therefore, act as a warning to the miners. In buffer overflow and programming parlance, canary words are known values placed between the buffer and control data. If a buffer overflow occurs, the canary word will be altered first, triggering a halt to the system. Tools such as StackGuard make use of this for stack protection.

Figure 8-6 NOP sled code example

Cookies

A cookie is a very small, text-based file that is stored on your system for use by the web server the next time you log in. It can contain all sorts of information, including authentication details, site preferences, shopping cart contents, and session details. Cookies are sent in the header of an HTTP response from a web server and may or may not have an expiration date. The original intent was to provide a continuous, stable web view for customers, and to make things easier for return surfers.

The problem, of course, is that seemingly everything designed to make our technological life easier can be co-opted for evil. Cookies can definitely prove very valuable to the hacker, and a tool such as the Cookie Editor add-on for Firefox opens up all sorts of parameter-tampering opportunities. Cookies themselves aren’t executable—they’re just text files, after all—however, they can be manipulated to use as spyware (cookies can be used to track computer activity), change pricing options, and even to authenticate to a server. For example, an entry in a cookie reading “ADMIN=no” can be changed to read “ADMIN=yes,” thus providing administrative access to site controls.

Passwords can sometimes also be stored in cookies, and although it’s a horrible practice, it’s still fairly prevalent. Access to a target’s physical machine and the use of a tool to view the cookies stored on it (such as Karen’s Cookie Viewer) might give you access to passwords the user has for various websites. And, if they are like most people, it’s nearly a guarantee that the password you just lifted is being reused on another site or account. Additionally, don’t be thrown off by cookies with long, seemingly senseless text strings beside the user ID sections. On a few, you may be able to run them through a Unicode (or Base64) decoder to reveal the user’s password for that site.

Exercise 8-2: Cookie Editing

Editing parameters on a cookie can lead to substantive gains for an attacker. This exercise introduces you to the Cookie Editor add-on (you’ll see it again, trust me). You’ll have to experiment more on your own to see the true results. Here are the steps to follow:

Note the fields you can alter. Try several cookies on the machine to see unique differences. Over time, you may find some interesting tidbits (such as the “ADMIN=no” example) to play with.

Figure 8-7 Firefox cookie editor

Figure 8-8 Editing a cookie

	NOTE A few web application scanning tools are Whisker (an older tool), N-Stealth, WebInspect, AppDetective, and Nikto. If you have the means to use them, go for it.

One final thought on web application testing isn’t actually a hack at all, but it sure is productive. A very common method of security testing (hacking) a web application is to simply try using it in a manner in which it wasn’t intended to be used. This isn’t applying some groovy hacker tool or scripting code to inject through some James Bond type of ploy, it’s just trying different things out with an application—sometimes even by accident. As many a tester will say, with a chuckle in his voice, “It’s not a hack, it’s a feature.”

Protecting Your Web Resources

Web servers are successfully attacked for a variety of reasons. Bugs in the software, misconfiguration of settings, and unpatched security flaws are some of the more common reasons, but securing an Apache or an IIS server really comes down to the same things you’d check on with any server. Keep it up to date with the latest versions and patches, and ensure permissions are set appropriately (especially anything “default” that could be exploited by an attacker). As always, you should control administrative access as much as possible, and keep a sharp eye on your logs, to monitor against badguy influence. Lastly, keep a sharp eye on vulnerability research and trends, and never run the web server as a user with any elevated privileges. If you’re having problems with Apache and just run everything in root because it’s easier, or your IIS permissions are all amok so you run it as admin, all your apps are also running with root/admin privileges. As a friend of mine said a few days ago, “We in IT security have to be right 100 percent of the time—the hackers only have to be right once.” Don’t make it easy for them.

Identifying Web Server Vulnerabilities

We’ve already covered some of the “10,000-foot view” footprinting efforts that will help you identify the web servers themselves. The use of whois and, more intimately, banner grabbing can help with valuable information you’ll need along the way. To get a little bit closer in, use some tools and actions that are more specialized for web servers themselves. For example, Netcraft can provide some great high-level information. httprecon and ID Serve work really well in identifying, reliably, the web server architecture and OS, and httprint provides lots of really cool information. Other tools such as Burp Suite can give you insight into content on the site the owner probably didn’t want disclosed. And don’t discount a method already mentioned earlier in this book—tools such as BlackWidow and HTTrack can make a copy of the website on your system for your review.

In addition, if you have a means to get it running against the web server, a vulnerability scanner will practically give you everything you need to gain access. Nessus is probably the most common vulnerability scanner available, but it’s certainly not the only option. Nikto is a vulnerability scanner more suited specifically for web servers (see Figure 8-9). An open source tool, Nikto scans for virtually everything you can think of, including file problems, script errors, and server configuration errors. It can even be configured within Nessus to kick off a scan automatically when a web server is discovered! Plug-ins and signatures are numerous and varied, and update automatically for you. The only drawback is that it’s a relatively noisy tool, so you won’t be running it stealthily.

In any case, a good vulnerability scan against a web server is about as close to a guarantee as anything we’ve talked about thus far. By their very design they’re open to the world, and many—not all, but many—will have something overlooked. Take your time and be patient; eventually your efforts will pay off.

Figure 8-9 Nikto web banner

Countermeasures and Hardening

Hardening a machine, as we’ve already discussed, involves applying all the appropriate and practical security measures to secure it against known vulnerabilities and attacks. And as stated earlier, most of this should be common sense and will apply whether we’re talking about a web server or a file server inside the organization. However, hardening is an explicit objective within CEH, so we’ll definitely take the time here to cover the highlights:

There are also a few steps you can take specific to the web server type you choose. Apache, for example, requires someone with a nice Linux/Unix touch to truly secure. A couple of basics include, but aren’t limited to:

Finally, more than a few tools are available to help you in hardening your machine. A quick Internet search will show you exactly what I mean. A couple of note include IIS Lockdown and MBSA. IIS Lockdown is a tool designed to secure an IIS server based on the parameters you provide; the steps to secure a file server are different than for a web server, for instance. A quick note of caution here: Be really careful with this tool, because you may wind up securing yourself out of the machine!

Microsoft Baseline Security Analyzer (MBSA) is a good tool to see your patching levels on Microsoft machines (see Figure8-10). It’s easy to use and provides a pretty easy-to-understand report on the security of your machine. Of course, most vulnerability scanners (Nessus, Core Impact, GFI LANguard, and others) will also tell you what’s missing on the machine, but MBSA is easy to use, free, and designed specifically for Windows systems.

Figure 8-10 MBSA

Chapter Review

A web server acts like any other server you already know about, but it responds to TCP connection requests on port 80 or 443. The server waits for an HTTP GET request from the client and responds with specific HTML code representing a website page. The server then looks through a storage area and finds the code that matches the request, and provides it to the client.

Apache servers (www.apache.org) make up the majority of web hosts on the Internet. Apache is an open source, very powerful, and very fast web server that typically runs on a Unix or Linux platform. Internet Information Services (IIS) servers are easy-to-manage Windows-based options for the web provider.

Common Gateway Interface (CGI) provides a standard method for web servers to pass a user’s request to an application program and receive data back to forward to the user. Because CGI scripts can run essentially arbitrary commands on your system with the permissions of the web server user, they can be extremely dangerous if not carefully checked. Additionally, all CGI scripts on the server will run as the same user, so they have potential to conflict with other scripts (an attacker could, for example, write a CGI script to destroy all other CGI databases).

Server Side Includes (SSIs) are directives placed in HTML pages, and they are evaluated on the server while the pages are being served. They let you add dynamically generated content to an existing HTML page without having to serve the entire page via a CGI program, or other dynamic technology. SSIs are useful for including a common piece of code throughout a site, such as a page header, a page footer, or a navigation menu. The httpd.conf file in Apache controls this access.

Directory traversal is a web attack whereby the attacker manipulates the URL parameters to navigate the directory structure on the server itself. This can lead to file access and even command shell operation. This is also known as the dot-dot-slash attack, directory climbing, and backtracking. Attackers basically send HTTP requests asking the server to drop back to the root directory and give access to other folders. An example of just such a command might look like this:

http://www.example.com/../../../../directory_of_choice/command.exe

The dot-dot-slashes are intended to take the shell back to the root and then to execute command.exe in the directory of choice. A Unicode version of this attack might appear as %2e%2e%2f.

Parameter tampering (a.k.a. URL tampering) occurs when the hacker manipulates parameters within the URL string in hopes of modifying data—such as permissions and elevation of privilege, prices and quantities of goods, and credentials.

Brutus (www.hoobie.net), THC-Hydra, and Metasploit are all useful tools in attacking web servers and applications.

A web application fills an important gap between the website front end and the actual database performing the work. Users interact with the website to affect database or other dynamic content instances, but the web application actually performs the work. Web applications are most often hacked due to inherent weaknesses built into the program at inception. Developers might overlook known vulnerabilities, forget to patch security flaws, or leave default passwords and accounts open for exploitation.

One very successful web application attack deals with injecting malicious commands into the input string. The objective is much like the URL-tampering methods discussed in this chapter: to pass exploit code to the server through poorly designed input validation in the application. This can occur using a variety of different methods, including file injection (where the attacker injects a pointer in the web form input to an exploit hosted on a remote site), command injection (where the attacker injects commands into the form fields instead of the expected test entry), and shell injection (where the attacker attempts to gain shell access using Java or other functions).

SQL injection is, by far, the most common and most successful injection attack technique in the world. Structured Query Language (SQL) is a computer “language” designed for managing data in a relational database system. The relational database itself is simply a collection of tables (consisting of rows, which hold individual fields containing data) tied together using some common field (key) that you can update and query. Each table has a name given to it that is referenced when you perform queries or updates. SQL comes into play when you are adding, deleting, moving, updating, or viewing the data in those tables and fields.

SQL queries generally begin with the SELECT command. SELECT is used to choose the data you’d like to perform an action on. In addition to SELECT, there are several additional options and commands of great interest to a hacker. For example, “DROP TABLE tablename” will delete the table tablename from the database. INSERT and UPDATE are also easy to understand.

SQL injection occurs when the attacker injects SQL queries directly into the input form. Properly constructed, the SQL command bypasses the intent of the front end and executes directly on the SQL database. To find out if a site is susceptible to SQL injection, check your target for a web login page, and instead of entering what’s asked for on the web form, simply try a single quote (‘) and see what kind of error message, if any, you receive. If that doesn’t work, try entering anything’ or 1=1- - and see what you get. The attack names and definitions for SQL are union query, tautology, blind SQL injection, and error-based SQL injection.

sqlmap, Havij, and sqlninja are all automated scanners designed to look specifically for injection vulnerabilities. SQLBrute is a tool that allows you to blast through predefined SQL injection queries against a target. Others include, but are not limited to, Pangolin, SQLEXEC, Absinthe, and BobCat.

Cross-site scripting (XSS) attacks take advantage of dynamic content on sites. XSS occurs when hackers take advantage of that scripting (Java, for instance) on the server and have it perform something other than the intended response. An example might look like

http://IPADDRESS/";!- -"<XSS>=&{()}

or using a

'<script>something</script>'

entry in a web form. In addition to a DoS attack, XSS can be used to steal users’ cookies, to upload malicious code to users connected to the server, and to send pop-up messages to users. XSS attacks represent the second largest attack vector online today.

A buffer overflow attack is an attempt to write more data into an application’s prebuilt buffer area in order to overwrite adjacent memory, execute code, or crash a system (application). The result can be anything from crashing the application or machine to altering the application’s data pointers, allowing you to run different executable code. Buffer overflow attack categories include stack, heap, and NOP sled.

In addition to good coding techniques, sometimes developers can make use of “canaries” or “canary words.” In buffer overflow and programming parlance, canary words are known values placed between the buffer and control data. If a buffer overflow occurs, the canary word will be altered first, triggering a halt to the system. Tools such as StackGuard make use of this for stack protection.

A cookie is a very small, text-based file that is stored on your system for use by the web server the next time you log in. It can contain all sorts of information, including authentication details, site preferences, shopping cart contents, and session details. Cookies can definitely prove very valuable to the hacker, and a tool such as the Cookie Editor add-on for Firefox opens up all sorts of parameter-tampering opportunities. Cookies themselves aren’t executable; however, they can be manipulated to use as spyware (cookies can be used to track computer activity), change pricing options, and even to authenticate to a server.

Web servers are successfully attacked for a variety of reasons. Bugs in the software, misconfiguration of settings, and unpatched security flaws are some of the more common reasons, but securing an Apache server or an IIS server really comes down to the same things you’d check on with any server. Keep it up to date with the latest versions and patches, and ensure permissions are set appropriately (especially anything “default” that could be exploited by an attacker). As always, you should control administrative access as best you can, and keep a watch on your logs, to monitor against bad-guy influence. Lastly, keep a sharp eye on vulnerability research and trends. As a friend of mine said a few days ago, “We in IT security have to be right 100 percent of the time—the hackers only have to be right once.”

A vulnerability scanner will attempt to provide the necessary hardening, and hacking, information on a web server. Nessus is probably the most common vulnerability scanner available, but it’s certainly not the only option. Nikto is an open source vulnerability scanner suited specifically for web servers. It can even be configured within Nessus to kick off a scan automatically when a web server is discovered.

Questions

http://www.example.com/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/windowssystem32cmd.exe

Mar 30 10:31:07 [1123}: IDS1661/NOPS-x86: 64.118.55.64:1146-> 192.168.119.56:53

Answers