Web Application Hacking

It's a real possibility that the web server is locked down and secured. Going after the web application will separate the script kiddie from the more advanced hacker. Web application hacking requires the attacker to uncover applications and understand their logic. The best way to start is by just clicking through the site and spending some time examining its look and feel. You might have already ripped the entire site and stored it locally, as discussed in the previous section. If so, now's the time to start some serious source sifting to see what you can find. Pay special attention to how input is passed, what types of error messages are returned, and the types of input that various fields will accept.

After you can start to identify the underlying applications, the search for vulnerabilities can begin. If the application is a commercial product, the attacker can check for known vulnerabilities or begin to probe the application. Most application vendors are proud of their products, so a quick check of their sites might list all their clients. For the attacker who successfully finds vulnerabilities, this means that there's a whole list of potential victims.

Hidden Fields

Hidden fields is a poor coding practice that has been known and publicized for some time, although it still continues. It's the practice of using hidden HTML fields as a sole mechanism for assigning a price or obscuring a value. This practice of security by obscurity can be easily overcome by just reviewing the code. The theory is that if end users cannot see it, it is safe from tampering. Many sites use these hidden value fields to store the price of the product that is passed to the web application. An example pulled from a website is shown here:

[View full width]

.pl?db=stuff.dat&category=&search=Mens-Rings&method=&begin=&display=&price=&merchant=">

Finding one of these sites is a script kiddies' dream, as all he must do is save the web page locally, modify the amount, and the new value will be passed to the web application. If no input validation is performed, the application will accept the new, manipulated value. These three simple steps are shown here:

Some poorly written applications will even accept a negative value. Before you get too excited about this, remember that completing the order would be seen as theft and or fraud, depending on local laws. The real problem here is that an application should never rely on the web browser to set the price of an item. Even without changing the price, an attacker might just try to feed large amounts of data into the field to see how the application responds. Values from hidden fields, check boxes, select lists, and HTTP headers might be manipulated by malicious users and used to make web applications misbehave if the designer did not build in proper validation. If you think that there is a shortage of sites with these types of vulnerabilities, think again. A quick Google search for type=hidden name=price returns hundreds of hits.

Web-Based Authentication

Authentication plays a critical role in the security of any website. There might be areas you want to restrict or content that is confidential or sensitive. There are many different ways to authenticate users. Authentication can include something you know, such as a username and a password; something you have, such as a token or smart card; or even something you are, such as fingerprints, retina scans, or voice recognition. The authentication types that will be discussed in this section include

• Basic
• Message digest
• Certificate-based
• Forms-based

Basic authentication is achieved through the process of exclusive ORing (XOR). Basic encryption starts to work when a user requests a protected resource. The Enter Network Password box pops up to prompt the user for a username and password. When the user enters his password, it is sent via HTTP back to the server. The data is encoded by the XOR binary operation. This function requires that when two bits are combined, the results will only be a 0 if both bits are the same. XOR functions by first converting all letters, symbols, and numbers to ASCII text. These are represented by their binary equivalent. The resulting XOR value is sent via HTTP. This is the encrypted text. As an example, if an attacker were to sniff a packet with basic authentication traffic, he would see the following:

Authorization: Basic gADzdBCPSEG1

It's a weak form of encryption, and many tools can be used to compromise it. Cain, which is reviewed in Chapter 7, "Sniffers, Session Hijacking, and Denial of Service," has a basic encryption cracking tool built in. Just Google for base64 decoder to find a multitude of programs that will encode or decode basic encryption.

Tip

Base encryption is one of the weakest forms of authentication. It is not much better than cleartext. Basic is a type of obsufication or security by obscurity.

Message digest authentication is a big improvement over basic. Message digest uses the MD5 hashing algorithm. Message digest is based on a challenge response protocol. It uses the user-name, the password, and a nonce value to create an encrypted value that is passed to the server. The nonce value makes it much more resistant to cracking and makes sniffing attacks useless. Message digest is described in RFC 2716. An offshoot of this authentication method is NTLM authentication.

Certificate-based authentication is the strongest form of authentication discussed so far. When users attempt to authenticate, they present the web server with their certificates. The certificate contains a public key and the signature of the Certificate authority. The web server must then verify the validity of the certificate's signature and then authenticate the user by using public key cryptography. Certificate-based authentication uses public key cryptography and is discussed at length in Chapter 12, "Cryptographic Attacks and Defenses".

Forms-based authentication is widely used on the Internet. It functions through the use of a cookie that is issued to a client. After being authenticated, the application generates a cookie or session variable. This stored cookie is then reused on subsequent visits. If this cookie is stolen or hijacked, the attacker can use it to spoof the victim at the targeted website.

Web-Based Password Cracking

An unlimited number of tools are available for the attacker to attempt to break into web-based applications. If the site does not employ a lockout policy, it is only a matter of time and bandwidth before the attacker can gain entry. Password cracking doesn't have to involve sophisticated tools; many times password guessing works well. It can be a tedious process, although human intuition can beat automated tools. The basic types of password attacks include

• Dictionary attacks A text file full of dictionary words is loaded into a password program and then run against user accounts located by the application. If simple passwords have been used, this might be enough to crack the code.
• Hybrid attacks Similar to a dictionary attack, except that hybrid attacks add numbers or symbols to the dictionary words. Many people change their passwords by simply adding a number to the end of their current password. The pattern usually takes this form: First month's password is Mike; second month's password is Mike2; third month's password is Mike3; and so on.
• Brute force attacks The most comprehensive form of attack and the most potentially time-consuming. Brute force attacks can take weeks, depending on the length and complexity of the password.

Tip

Understand the different types of password cracking.

Some of these password cracking tools are

• WebCracker A simple tool that takes text lists of usernames and passwords and uses them as dictionaries to implement basic authentication password guessing.
• Brutus Brutus can perform dictionary or brute force attacks against Telnet, FTP, SMTP, and web servers.
• ObiWan Another web password cracking tool.

With logging enabled, you should be able to detect such tools. Following are a few entries from the Winntsystem32LogfilesW3SVC1 folder. They should look familiar:

192.168.13.3 sa HEAD /test/basic - 401 Mozilla/4.0+(Compatible);Brutus/AET 192.168.13.3 administrator HEAD /test/basic - 401 Mozilla/4.0+(Compatible);Brutus/AET 192.168.13.3 admin HEAD /test/basic - 401 Mozilla/4.0+(Compatible);Brutus/AET

Finding log information that leads directly to an attacker is not always so easy. Sometimes attackers will practice URL obfuscation. This allows the attacker to attempt to hide his IP address. Attackers will also attempt to use cookies to further their hold on a system. You might be surprised to know how much information they maintain. Sometimes they are even used to store passwords. Cookies are our next topic.

Cookies

Cookies have a legitimate purpose. HTTP is a stateless protocol. For example, this presents real problems if you want to rent a car from rent-a-car.com and it asks for a location. To keep track of the location where you want to rent the car, the application must set a cookie. Information, such as location, time, and date of the rental, are packaged into a cookie and sent to your Web browser, which stores it for later use. A couple of tools that can be used to view cookies include

• CookieSpy Allows cookie viewing
• Karen's Cookie Viewer Allows you to view cookies

If the attacker can gain physical access to the victim's computer, these tools can be used to steal cookies or to view hidden passwords. You might think that passwords wouldn't be hidden in cookies, but that is not always the case. It's another example of security by obscurity. Cookies used with forms authentication or other remember me functionality might hold passwords or usernames. Here's an example:

Set-Cookie: UID= bWlrZTptaWtlc3Bhc3N3b3JkDQoNCg; expires=Fri, 06-Jan-2006

The UID value appears to contain random letters, but more than that is there. If you run it through a Base64 decoder, you end up with mike:mikespassword. It's never good practice to store usernames and passwords in a cookie, especially in an insecure state.

URL Obfuscation

It is possible to hide addresses in URLs so that they can bypass filters or other application defenses that have been put in place to block specific IP addresses. Although web browsers recognize URLs that contain hexadecimal or binary character representations, some web filtering applications don't. Here is an example of an encoded binary IP address: http://8812120797/. Does it look confusing? This decimal address can be converted into a human readable IP address. Convert the address into hexadecimal, divide it into four sets of two digits, and finally convert each set back into decimal to recover the IP address manually.

To convert an IP address to its binary equivalent, perform the following steps.

Tip

You will need to understand URL obfuscation before attempting the CEH exam.

Cross-Site Scripting

Cross-site scripting (XSS) is a computer security exploit that occurs when a web application is used to gather data from a victim. Sending the victim an email with an embedded malicious link is the way to commit an attack. Victims who fall for the ruse and click on the link will have their credentials stolen. Sites running PHPnuke have been particularly hard hit by this attack. The steps required to complete this attack include

XSS can be prevented if vulnerable programs are patched and input is validated from a dynamic web page. Prevention also requires that the users remain leery of embedded links.

Intercepting Web Traffic

One of the best ways to understand how a web application actually works is to observe it. Although a sniffer is one possible choice, a proxy is another available tool that can make the job a little easier. The following are two proxies that will be discussed:

• Burp Proxy www.portswigger.net/proxy
• Achilles www.mavensecurity.com/achilles

Web proxies allow the penetration tester to attack and debug web applications. These tools act as a man-in-the-middle. They allow you to intercept, inspect, and modify the raw contents of the traffic, as explained in the following:

• Intercept Allows you to see under the hood and watch the traffic move back and forth between the client and the server.
• Inspect Allows you to enumerate how applications work and see the mechanisms they use.
• Modify Allows you to modify the data in an attempt to see how the application will respond; for instance, injection attacks.

These tools make it possible to perform Structured Query Language (SQL) injection, cookies subversion, buffer overflows, and other types of attacks. Let's take a look at Achilles to get a better idea how this works. Figure 8.6 shows how Achilles sets in the middle of the communication channel to capture traffic.

Figure 8.6. Web proxy configuration.

To run Achilles, you need to set your web proxy to your loopback address and port 5000, as shown on Figure 8.7.

Figure 8.7. Achilles setup.

After that setting has been made, you can start Achilles. Achilles has several settings you can play with: But as a basic configuration, just set it to capture client data and to ignore .jpg files. The first look at Achilles will be of an authentication attempt, as shown in Figure 8.8.

Figure 8.8. Basic authentication.

Notice the line that says Authorization: Basic bWlrZTpzdXBlcnNlY3JldA== identifies the type of authentication that is being used by the application. In this case, it is basic authentication. Plugging this value into a base64 decryptor will reveal mike:supersecret. This value could be used by an attacker to reply or decrypt to attempt to login later. Now let's look at a second example of an interception between a client and Yahoo! mail, as shown in Figure 8.9.

Figure 8.9. Message digest authentication.

Take a close look up three lines from the bottom. See the phrase textMD5=&.hash? This identifies that a type of message digest authentication is being used. You should see the username of Uberhacker, although the password is a challenge. They are much more difficult for an attacker to crack, as they are composed of a MD5 value and a random nonce, which is quite interesting. Hopefully, this demonstrates the value of this tool so that you can better understand how a web application actually works. Although a deeper understanding of these techniques is not needed for the exam, it is recommended that you to read up on how such protocols as message authentication work. You can find out more in RFC 2716. This knowledge can help bring you above the skill level of the script kiddie.

Password Hacking Preteen Style

Statistics indicate that computer crime is generally committed by people under 25and we often see people much younger getting in trouble online.

In one incident, 9- and 10-year-old children were stealing passwords from other kids on an online virtual pet community to gain access to their pets, food, and points by falsifying email. They would send email to other members pretending to be the site's administrator and demand their account information.

From a legal standpoint, these kids were in possession of stolen passwords, sending fraudulent and threatening email, and causing a denial of access to computer services. In some states, all these are felonies.

When interviewed, these kids did not understand that what they had done was wrong. They compared it to game cheatsspecial codes, which when entered into some games, give extra lives or more power. Their view of computer and online games clouded the fact that their actions had an impact on other people. Not until the victims were discussed, as well as how they would feel if this had happened to them, did the gravity of the event become real.

Everyone who uses online services needs to practice good password habits. Using the same password for your email account and your 401(k) account isn't such a good idea. Regardless of the talk that advanced authentication passwords are here for the long haul, good password practices are imperative.

This "in the field" segment was contributed by Donald L. Pipkin, CISM and CISSP author of Halting the Hacker.