Chapter 12
Session Hijacking

CEH EXAM OBJECTIVES COVERED IN THIS CHAPTER:

I. Background
- C. System technologies
III. Security
- A. Systems security controls
- E. Network security
- P. Vulnerabilities
IV. Tools/Systems/Programs
- G. TCP/IP networking

The concept of session hijacking is fairly simple and can be applied to various scenarios. An interception in the line of communication allows the attacker either to assume the role of the authenticated user or to stay connected as an intermediary, as in a man-in-the-middle attack. Different techniques help the attacker hijack a session. One discussed in Chapter 9, “Sniffers,” is Address Resolution Protocol (ARP) poisoning. We’ll expand on setup techniques in this chapter, and you’ll get your hands dirty with a few examples that illustrate how to accomplish a session hijack.

Understanding Session Hijacking

Session hijacking is synonymous with a stolen session, in which an attacker intercepts and takes over a legitimately established session between a user and a host. The user-host relationship can apply to access of any authenticated resource, such as a web server, Telnet session, or other TCP-based connection. Attackers place themselves between the user and host, thereby letting them monitor user traffic and launch specific attacks. Once a successful session hijack has occurred, the attacker can either assume the role of the legitimate user or simply monitor the traffic for opportune times to inject or collect specific packets to create the desired effect. Figure 12.1 illustrates a basic session hijack.

In its most basic sense, a session is an agreed-upon period of time under which the connected state of the client and server are vetted and authenticated. This simply means that both the server and the client know (or think they know) who each other are, and based on this knowledge, they can trust that data sent either way will end up in the hands of the appropriate party.

If a session hijack is carried out successfully, what is the danger? Several events can take place at this point, including identity theft and data corruption. In other situations session hijacks have made for a perfect mechanism through which someone can sniff traffic or record transactions.

Understanding what constitutes a session makes it easy to see how session hijacking can be extremely effective when all supporting factors are set up correctly. Many of the prerequisite setup factors involved in session hijacking have already been discussed in previous chapters. For example, a specific form of hijacking involves using a sniffer both prior to and during an attack, and you learned about sniffers in Chapter 9. In Chapter 2, “System Fundamentals,” you learned about the TCP three-way-handshake, which will greatly aid your understanding of TCP session hijacking. Before we get too deep into the details of each attack, let’s look at how session hijacking is categorized.

An attacker carrying out a session hijack is seeking to take over a session for their own needs. Once they have taken over a session they can then go about stealing data, issuing commands, or even committing transactions that they wouldn’t be able to otherwise. In this chapter, we will explore the various forms session hijacking can take and identify the methods you can use to thwart a session hijack.

Session hijacks are easy to launch. TCP/IP is vulnerable, and most countermeasures, except for encryption, do not work. The following also contribute to the success of session hijacking:

No account lockout for invalid session IDs
Insecure handling
Weak session ID generation algorithm
Indefinite session expiration time
Cleartext transmission
Small session IDs

Session hijacking typically can be broken down into one of three primary techniques:

Brute-Forcing an ID This is done by guessing an ID; usually the attacker already has some knowledge of the range of IDs available. The attacker may be aided by the use of HTTP referrers, sniffing, cross-site scripting, or malware.

Stealing an ID If they can manage it, an attacker will steal an ID by using sniffing or other means.

Calculating an ID An attacker will attempt to calculate a valid session ID simply by looking at an existing one and then figuring out the sequence.

So what is a session ID? Well, its form can vary a bit depending on whether we are talking an application or a network. However, in both cases it is usually some form of alphanumeric sequence that uniquely identifies a specific connection. A session ID could look like 123456abcdef, for example, but usually with a lot more entropy or randomness sprinkled in. Capturing, guessing, or calculating an ID allows the attacker to take over a connection or session.

Note that session IDs are also known as session tokens.

Spoofing vs. Hijacking

Before we go too far, you should know that spoofing and hijacking are two distinctly different acts.

Spoofing is when an attacking party pretends to be something or someone else, such as a user or computer. The attacker does not take over any session.

In hijacking, the attacker takes over an existing active session. In this process, the attacker waits for an authorized party to establish a connection to a resource or service and then takes over the session.

The process of session hijacking looks like this:

Step 1: Sniffing This step is no different than the process we explored when we discussed sniffing in Chapter 9. You must be able to sniff the traffic on the network between the two points that have the session you wish to take over.

Step 2: Monitoring At this point your goal is to observe the flow of traffic between the two points with an eye toward predicting the sequence numbers of the packets.

Step 3: Session Desynchronization This step involves breaking the session between the two parties.

Step 4: Session ID Prediction At this point, you predict the session ID itself (more on that later) to take over the session.

Step 5: Command Injection At this final stage as the attacker you are free to start injecting commands into the session targeting the remaining party (most likely a server or other valuable resource).

It is important for you to understand that session hijacking can take place at two entirely different levels of the Open Systems Interconnection (OSI) model, so it is very important to pay attention to details. A session hijack can take place at the Network layer or at the Application layer—that is, an attack can target the TCP/UDP protocols or the much higher protocols at the Application layer, such as HTTP or FTP.

Active and Passive Attacks

You can categorize a session hijacking attack as either an active attack or a passive attack. Let’s look at both.

Active Attack A session hijacking attack is considered active when the attacker assumes the session as their own, thereby taking over the legitimate client’s connection to the resource. In an active attack the attacker is actively manipulating and/or severing the client connection and fooling the server into thinking they are the authenticated user. Additionally, active attacks usually involve a DoS result on the legitimate client. In other words, they get bumped off and replaced by the attacker. Figure 12.2 shows what this kind of attack looks like.

Passive Attack A passive attack focuses on monitoring the traffic between the victim and the server. This form of hijacking uses a sniffer utility to capture and monitor the traffic as it goes across the wire. (Refer to Chapter 9 for a more in-depth description of sniffer use.) A passive attack doesn’t “molest” the session in any way. Unlike an active attack, the passive attack sets the stage for future malicious activity. An attacker has a strategically advantageous position when in a passive session hijack; they can successfully capture and analyze all victim traffic, and progress to an active attack position with relative ease. Figure 12.3 shows a passive attack.

Session Hijacking and Web Apps

Session hijacking at the application level focuses on gaining access to a host by obtaining legitimate session IDs from the victim. Essentially, a session ID is an identifier that is applied to a user’s session that allows the server or web resource to identify the “conversation” it is having with the client. So, for example, say that you’ve logged into a merchant site and are browsing the site for a book. With each page you browse to, the web server receives the request and forwards you to the next page without requiring you to repeatedly log in. The server is able to do this because it has identified your session ID and assumes it knows who you are at this point. Let’s take a look at session IDs in greater depth to gain a better understanding of the part they play in hijacking applications.

Session IDs, for our purposes, come in three flavors:

Embedded in a URL A web app uses the GET request to follow links embedded in a web page. An attacker can easily browse through the victim’s browsing history and many times gain access by simply entering the URL of a previously browsed web app.

Embedded as a Hidden Field Forms for inputting user data many times include a hidden field that is used for sending a client’s session ID. The ID is sent via the HTTP POST command when the information is submitted.

Cookies Cookies have been a potential avenue of exploit for quite some time, and they have recently taken the rap for privacy issues such as tracking shopping activity or storing users’ sensitive data. An attacker can obtain session information from cookies residing on the victim machine.

Vulnerabilities of lingering cookies or sessions from subpar coding or easier customer access are something we’ve probably all seen at one time or another. Consider, for instance, pulling up an “authenticated” web page from your browser’s history, only to find that you’re conveniently still logged in days later—something to be aware of for sure.

Types of Application-Level Session Hijacking

When attempting to hijack a session at the application level, a hacker can choose from among handful of attacks: session sniffing, predicting session tokens, man-in-the-middle, and man-in-the-browser. Let’s look at each.

Session Sniffing

Session sniffing is a variation of sniffing, which you learned about in Chapter 9. In this variation, you have a specific target you are looking for, which is a session token (also known as a session ID). Once you, as the attacker, have found this token, you use it to gain access to the server or other resource. This is sort of like stealing the keys to a car that someone else rented; they are the authorized driver, but since you have the keys you can drive it, though unauthorized.

Predicting Session Tokens

The second way of getting a session ID is to predict or make an educated guess as to what a valid one will be. How do you do this? Well, the easiest and most effective way is to gather a few session IDs that have been used already.

In this list of URLs, you focus on the portion after the last slash:

www.ceh.net/app/spo22022005131020
www.ceh.net/app/spo22022005141520
www.ceh.net/app/spo22022005171126
www.ceh.net/app/spo22022005213111

Let’s assume these are all valid but expired session IDs that we have collected and we want to predict or calculate a new one. If we look at them carefully we may be able to determine a valid ID to use. In this case I made it easy—well, at least I think so. Can you see the pattern? I’ll break each of them into four pieces, as shown in Table 12.1.

TABLE 12.1 Dissected IDs

Segment 1	Segment 2	Segment 3	Segment 4
spo	22022005	1310	20
spo	22022005	1415	20
spo	22022005	1711	26
spo	22022005	2131	11

Look at the IDs in Table 12.1 and you should be able to determine the pattern, or at least how they were generated. You see that the first three letters stay the same. In Segment 2, the numbers stay the same as well. The third segment changes, and if you look closer you might be able to tell something. In this case the segment gives time in 24-hour format, which in turn gives you insight into segments 2 and 4. Segment 4 is the time in seconds.

If you look back at segment 2 you can see that it is actually the date, which in this case is the 22nd of February 2005, or 22022005.

Man-in-the-Middle Attack

A third way to get a session ID is the man-in-the-middle attack, which we will discuss later in this chapter when we discuss network attacks; see the section “Man-in-the-Middle.”

Man-in-the-Browser Attack

A fourth form is the man-in-the-browser attack, which is a particularly interesting form of attack. The three most common forms are cross-site scripting, Trojans, and JavaScript issues. We discussed Trojans in Chapter 8, “Trojans, Viruses, Worms, and Covert Channels,” but let’s talk about cross-site scripting and JavaScript.

Cross-site scripting (XSS) is a type of attack that can occur in one of many forms, but generally they can be said to occur when data of some type enters a web application through an untrusted source (in the majority of cases, a web request). Typically this data is included as part of dynamic content that has not gone through validation checks to ensure it is all trustworthy.

In many cases the content that causes the attack to occur comes in the form of JavaScript, but it is not restricted to this format. In fact, it could come in the form of HTML, Flash, or another form of executable code. Because of the vast amounts of code that can be executed by a web browser, the variations that this type of attack can assume are almost boundless. Some of the most common goals include reading or stealing cookies, interfering with session information, redirecting to a location of the attacker’s choosing, or any number of other tasks.

Stored and reflected XSS attacks are the two main forms of this attack, so let’s take a look at each:

Stored XSS Attacks These are attacks where the hacker will place code on a target server where the victims they wish to target will access the content. When the victim makes a request from the server, they will execute the script, which will in turn carry out its dirty work.

Reflected XSS Attacks These are a little more complicated attack in which injected code is bounced or reflected off a web server in the form of something such as an error message or other result. Typically these attacks make their way to the victim in the form of an e-mail, or via a different web server. A user may be tricked into clicking a link in a web page or message. Once clicked, the link would then cause the user to execute code.

XSS attack consequences typically are the same no matter the form the attack takes: disclosure of the user’s session cookie, or allowing an attacker to hijack the user’s session and take over the account. Other damaging attacks include disclosing end-user files, installing Trojan horse programs, redirecting the user to another page or site, or modifying presentation of content.

Getting Fixated

Another type of session hijack is the session fixation attack. This type of attack is targeted specifically at web applications; it exploits vulnerabilities in the way these packages manage their session IDs. The vulnerability exists when an application fails to create a new session ID when a new user authenticates to the application. The attacker must induce a user to authenticate using a known session ID and then hijack the session.

There are several techniques to execute the attack, which vary depending on the application. Here are some common techniques:

The session ID is sent to the victim in a hyperlink and the victim accesses the site through the malicious URL.
The victim is tricked into authenticating in the target web server, using a login form developed by the attacker. The form can be hosted in the web server or directly in HTML-formatted e-mail.
The attacker uses code injection, such as the cross-site scripting (XSS), to insert malicious code in the hyperlink sent to the victim and fix a session ID in its cookie.
Using the <META> tag is also considered a code injection attack, although it’s different from the XSS attack, where undesirable scripts can be disabled or the execution can be denied.
HTTP header response uses the server response to fix the session ID in the victim’s browser. Including the parameter Set-Cookie in the HTTP header response, the attacker is able to insert the value of the session ID in the cookie and send it to the victim’s browser.

A Few Key Concepts

Here are a few concepts that come up in many session hijacking topic discussions:

Blind Hijacking Blind hijacking describes a type of session hijack in which the attacker cannot capture return traffic from the host connection. What this means is that the attacker is “blindly” injecting malicious or manipulative packets without seeing confirmation of the desired effect through packet capture. The attacker must attempt to predict the sequence numbers of the TCP packets traversing the connection. The reason for this prediction goes back to the basic TCP three-way handshake. We’ll dig more into this later in the section “Network Session Hijacking.”

IP Spoofing IP spoofing refers to an attacker’s attempt at masquerading as the legitimate user by spoofing the victim’s IP address. The concept of spoofing can apply to a variety of attacks in which an attacker spoofs a user’s identifying information. Let’s draw a line in the sand here, and definitively agree that spoofing is a different approach and attack from session hijacking; however, they are related in that both approaches aim at using an existing authenticated session to gain access to an otherwise inaccessible system. Figure 12.4 shows the spoofing approach.

Source Routing In contrast to normal packet routing, source routing (Figure 12.5) ensures that injected packets are sent via a selected routing path. By using source routing, an attacker chooses the routing path that is most advantageous to the intended attack. For example, an attacker attempting to spoof or masquerade as a legitimate host can use source routing to direct packets to the server in a path identical to the victim’s machine.

DNS Spoofing DNS spoofing is a technique in which an attacker alters a victim’s IP address mappings in an effort to direct the victim machine’s traffic to an address the attacker specifies. This is a fairly simplified explanation, but the concept and intent are the same in all variations of this technique. Later in the section “Network Session Hijacking,” you’ll see how DNS spoofing also applies to hijacking vulnerable web applications.

ARP Cache Poisoning ARP cache poisoning was covered in Chapter 9, but here’s a brief review. ARP is responsible for translating MAC addresses to IP addresses, or vice versa (known as reverse ARP, or RARP). An ARP cache poisoning attack overwrites a victim’s ARP cache, thereby redirecting traffic to an inaccurate physical address mapping, usually the attacker’s machine. This in turn puts the attacker’s machine in the logical middle of all communications between the victim’s machine and the authenticated host. ARP cache poisoning, as you’ve probably already deduced, is conceptually very similar to DNS spoofing. The goal is to manipulate the traffic flow based on directional data stored in the host.

Desynchronizing the Connection Referring once again to our TCP three-way handshake, when a client and a host are initializing a connection, they exchange packets that set the sequence for further data transfer. Each packet in this continuous transfer has a sequence number and subsequent acknowledgment numbers. TCP connections begin their sequencing of packets with what is known as an initial sequence number (ISN). The ISN is basically a starting point on which all following packets can increment and sequence themselves accordingly. Desynchronizing a connection (Figure 12.6) involves breaking the linear sequence between the victim and the host, thereby giving the attacker the opportunity, at least sequence-wise, to jump in and take over the connection to the host. For example, suppose an attacker setting up a session hijacking attack has been tracking the sequence of the connection and is ready to launch an attack. To make the job easier, and at the same time remove the victim from the picture, the attacker can inject a large volume of null packets directed at the host machine. This in turn increments the sequence numbers of the host packets without the acknowledgment or purview of the victim machine. Now the attacker has successfully desynchronized the connection and has staged the host packet sequence numbers to a predictable count based on the number of null packets sent.

**FIGURE 12.6** Desynchronizing a connection

Network Session Hijacking

Network-level session hijacking is a hijacking method that focuses on exploiting a TCP/IP connection after initialization or authentication has occurred. There are some specific hijacking techniques that are in this category of attack. Some common ones we will discuss are TCP/IP hijacking, man-in-the-middle attacks, and UDP session hijacking.

TCP/IP Session Hijacking

TCP/IP session hijacking is an attack on a TCP session. The attacker attempts to predict the sequence numbers of the packets flowing from the victim’s machine to the connected resource. If successful, the attacker can then begin to inject packets that are “in sequence” with the packet sequence of the legitimate user’s traffic.

As shown in Figure 12.7, once the initial handshake process is complete, the subsequent packets stay in a general sequence between the victim and the resource. Each packet in an ongoing conversation over TCP is incremented by 1. This rule applies to both SYN and ACK sequence numbers.

Implementation of this kind of attack first begins with the attacker sniffing the traffic between the victim’s machine and the host machine. Once the attacker successfully sniffs the connection and predicts (to the best of their ability) the packet sequence numbers, they can inject custom packets onto the wire that have a spoofed IP of the victim machine as well as a sequence number incremented appropriately based on previously captured packets. An attacker spoofs the IP address of the victim’s machine to try to assume the identity of the victim by hijacking the connection and the current session. From the server’s or host’s perspective, packets coming from a legitimate IP address, as well as having a properly incremented sequence number, are deemed legitimate traffic. Figure 12.7 outlines what this would look like.

Before we move on, let’s go through the basic steps of a TCP session hijack attack. You don’t have to memorize these steps for the exam, but understanding their sequence and what each step accomplishes will help you apply common sense to the challenging scenarios you’ll face. We’ve already covered a few of these, so we’re ahead of the game! Just pay attention to the sequence and relate it to what you’ve already learned.

Referring back to Chapter 9 once more, you must have a means of sniffing or capturing the traffic between the victim machines. This places you in the position required to perform the hijack.
Predict the sequence numbers of the packets traversing the network. Remember that null packets can be used to increment the host sequence numbers, thereby desynchronizing the victim’s connection and making sequence number prediction easier.
Perform a denial-of-service attack on the victim’s machine, or reset their connection in some fashion so you can assume the victim’s role as the legitimate client. Remember that in a passive hijacking, the victim connection is not necessarily severed; the traffic between the victim and the host is simply monitored, and you wait for the opportune time to act.
Once you take over the victim’s session, you can start injecting packets into the server, imitating the authenticated client.

Let’s go back to blind hijacking for a moment. As we discussed earlier, in blind hijacking the attacker is not able to see the result of the injected packets, nor are they able to sniff the packets successfully. This creates a major challenge for the attacker because sequencing packets properly is a critical step in launching a successful TCP-based session hijacking. Referring back to Chapter 9, recall that there is a logistical challenge in sniffing traffic from other networks or collision domains. This is because each switchport is an isolated collision domain. An attacker attempting to perform a session hijack attack on a victim machine outside the attacker’s network or network segment creates a challenge similar to the one you faced in sniffing traffic in Chapter 9. The attacker will be going in “blind” because they will not be able to receive a return traffic confirmation of success.

Hacker on the Run

The infamous hacking saga of Kevin Mitnick is always a good read for ethical hackers as well as Tom Clancy fans. Mr. Mitnick’s hacking activities finally landed him in prison in 1995, but the events leading up to the arrest read like a suspense novel. The noteworthy portion of the story is the fact that Mitnick used IP spoofing and a form of TCP session hijacking to gain access to the resources that inevitably landed him in hot water. This is not to say that all session hijacking leads to prison time, but rather to demonstrate that session hijacking has a usable presence in the real world. It’s equally amazing to see just how real things can get when someone succeeds at hacking high-profile corporations with such a conceptually straightforward attack. Check out www.takedown.com for some details on the Kevin Mitnick story.

Man-in-the-Middle

Man-in-the-middle (MITM) attacks take the cake as one of the best-known versions of a session hijack attack. Essentially, an MITM attack places attackers directly between a victim and host connection. Once attackers have successfully placed themselves in the middle of the connection via a technique such as ARP poisoning, they have free rein to passively monitor traffic, or they can inject malicious packets into either the victim or the host machine. Let’s continue with ARP poisoning for our example. The attacker will first sniff the traffic between the victim and host machine, which places them in a passive yet strategic position. From here, the attacker can send the victim phony or “poisoned” ARP replies that map the victim’s traffic to the attacker’s machine; in turn, the attacker can then forward the victim’s traffic to the host machine. While in this forwarding position, the attacker can manipulate and re-send the victim’s sent packets at will. Take a look at Figure 12.8, and then proceed to Exercise 12.1, which shows a basic MITM attack in action.

EXERCISE 12.1 Performing an MITM Attack

In this exercise, you’ll learn the fundamentals of an MITM attack. This demonstration will help you understand the background processes at work. For this demo you will have three client systems; you’ll be using Windows XP, Windows 7, and Backtrack. Let’s take a look.

First step, you need to throw a little traffic on the wire. You will use a continuous ping from one target host to another so you can see the redirection of traffic. Let’s get that going on the Windows 7 client and direct it to the Windows XP client.
Next pull up your sniffer on Backtrack to ensure you are in position to capture all traffic and perform your MITM attack.
Now you’re good to go on the traffic capture. You are able to capture the ICMP packets traversing the network and are ready to have some fun. Use the arpspoof utility in your Backtrack distribution to poison the victim’s ARP cache. The syntax for the command is arpspoof [-i interface] [-t target] host. Recall that with an MITM attack, you are attempting to funnel all traffic through your machine. With that in mind, you will use arpspoof on your Windows XP client. The command is arpspoof -i eth0 −t 192.168.1.4 192.168.1.5.
Now you have your Windows XP client thinking you are the Windows 7 client. Now, take a quick look at your Wireshark screen to see what kind of traffic is being captured. You should see some ARP broadcasts with some interesting mappings.
So far you have poisoned the ARP cache of the Windows XP client and have verified that your broadcasts are being sent via Wireshark. Excellent; now move to the Windows 7 client and perform the same process, just in reverse. The command is arpspoof −i eth0 −t 192.168.1.5 192.168.1.4.
Awesome! Now you have ARP-poisoned both victim machines, and your attack machine is in the middle of the traffic flow. Take a look at that ping traffic, and see what the status of the ping is now that it’s being redirected.
So it looks like your ping is no longer working, and in this scenario, that’s actually a good thing. What this confirms for you is that all traffic between the two victim machines is in fact being directed through your machine first. You must now enable IP forwarding on your Backtrack client to allow the ICMP packet to flow through you. (Although you could have completed this step before the exercise, keeping IP forwarding off initially allows you to confirm that you are receiving the ping traffic.) The command you will use is echo 1 > /proc/sys/net/ipv4/ip_forward.
Forwarding traffic isn’t a very eventful command, but it’s important to what you are trying to accomplish here. So now go back to your ping string and see what’s changed.
Perfect; you can see that your ICMP packets are “normally” flowing across the wire without a hitch. You are now successfully in the middle of the victim’s traffic flow and are passing traffic along with no one the wiser. From here, you can steal the client session, perform a denial of service, or sniff passwords.

UDP Session Hijacking

UDP session hijacking is conceptually simpler than its TCP brethren because UDP doesn’t use sequencing for its packets. As you’ll recall, UDP is a connectionless protocol, meaning it doesn’t establish a verifiable connection between the client and the host. For an attacker, this means no packet sequence is needed. The aim of a UDP hijack is to fool the victim into thinking the attacker’s machine is the server. The attacker must try to get a response packet back to the client before the legitimate host, thereby assuming the role of the server. Different techniques can be used to intercept legitimate server traffic prior to its response to the victim, but the basic goal is the same.

Exploring Defensive Strategies

Session hijacking relies, in part, on many of the prerequisites needed to successfully sniff a network. For instance, session hijacking attacks increase in complexity for external and switched networks. In other words, sitting on the local LAN (for example, as a disgruntled employee) is a much better strategic position for an attack than sitting outside the gateway. Aside from its relationship with sniffing, let’s take a look at methods you can use to help prevent session hijacking:

Encrypting network traffic is a viable and effective preventive technique against hijacking attacks, both from internal and external sources. As you’ll recall from previous chapters, encryption hampers your legitimate efforts to monitoring your own network traffic.
Using network-monitoring appliances such as an IPS or IDS can help in detecting and preventing network anomalies such as ARP broadcast traffic. These anomalies can be indicators of potential session hijacking attacks in progress.
Configure the appropriate appliances, such as gateways, to check and filter for spoofed client information such as IP addresses.
Be aware of local browser vulnerabilities such as extended history logs and cookies. Clearing temporary browsing information can help in preventing the use of old session IDs.
Stronger authentication systems such as Kerberos will provide protection against hijacking.
The use of technologies such as IPSec and SSL will also provide protection against hijacking.
Defense-in-depth, or the use of multiple defensive technologies to slow or deter an attacker, provides protection as well.

Pen testing to discover vulnerability to session hijacking depends on the defensive strategies of the client. Encryption should be implemented for sensitive network traffic to resources such as servers. Additionally, implementing policies that limit the generation of unique session tokens to intranet resources can reduce the probability of an attacker’s stealing an active session. Putting protective network appliances such as IPSs and IDSs to the test exposes critical weaknesses in identifying and preventing successful session hijacking attempts.

Summary

In this chapter we focused on session hijacking and what constitutes an attack. You learned the difference between active and passive hijacking and looked at network-level and application-level attacks. We discussed TCP session hijacking and emphasized the importance of understanding packet sequencing for the exam. We also looked at different sources of session IDs and touched on web application hijacking. We also explored man-in-the-middle attacks and walked through the basic setup.

Exam Essentials

Know what makes up a session hijacking. Make sure you can pick up on a session hijack attack easily. The exam is fairly straightforward on session hijacking questions. Most of the time the image will give it away, or it will become obvious in the question discussion that a session hijacking has either occurred or is about to.

Know your TCP sequencing. Knowing the sequencing of TCP packets is important for you as an ethical hacker and is extremely important for the exam. Understand the TCP three-way handshake as well.

Remember the difference between an active attack and a passive attack. An active attack is one in which the attacker is injecting packets or manipulating the connection in some fashion. In a passive attack, the attacker only monitors the traffic between client and host machines.

Know the steps of a session hijack. Familiarize yourself with the steps of a TCP session hijacking attack.

Be able to define ARP poisoning and DNS spoofing. Understand both concepts, and keep a lookout for scenario-driven questions that begin with ARP poisoning or DNS spoofing as supporting factors for the attack. This is a signal that the question is talking about a session hijacking attack.

Understand web application hijacking. Remember the three sources of session IDs: embedded in a URL, hidden in an embedded form, or in a session cookie. Your focus is not necessarily in knowing all the nuances of each source, but to recognize what the exam question is asking you to recognize. The exam will usually give you ample evidence and explanatory material in each question, so your job as the test taker is to sleuth out exactly what is important and pertinent to answer the question.

Recognize flexibility in terminology. Session hijacking is a category of attack in which the exam presents the topic in many varied ways. A web app session hijacking may be called something like session fixation. Or the possible answers to a diagram-based question may sound unfamiliar, but one or two of them have session in the answer. Stay focused on the big picture, and use common sense. If it looks like a session hijacking question, and sounds like a session hijacking question, well, it’s a session hijacking question! Answer accordingly.

Review Questions

Which statement defines session hijacking most accurately?
1. Session hijacking involves stealing a user’s login information and using that information to pose as the user later.
2. Session hijacking involves assuming the role of a user through the compromise of physical tokens such as common access cards.
3. Session hijacking is an attack that aims at stealing a legitimate session and posing as that user while communicating with the web resource or host machine.
4. Session hijacking involves only web applications and is specific to stealing session IDs from compromised cookies.
Julie has been sniffing the Wi-Fi traffic at a local coffee shop in an effort to learn more about sniffing tools and reading packet captures. She is careful not to inject packets, or to perform malicious activities; she just received her CEH credential, so she wants to stay white hat. What would Julie’s activities be categorized as?
1. Passive
2. Monitoring
3. Active
4. Sniffing
Based on the diagram, what attack is occurring?
1. Session splicing
2. Denial-of-service
3. Source routing
4. MITM
Jason is a junior system administrator for a small firm of 50 employees. For the last week a few users have been complaining of losing connectivity intermittently with no suspect behavior on their part such as large downloads or intensive processes. Jason runs Wireshark on Monday morning to investigate. He sees a large amount of ARP broadcasts being sent at a fairly constant rate. What is Jason most likely seeing?
1. ARP poisoning
2. ARP caching
3. ARP spoofing
4. DNS spoofing
Which of the following is not a source of session IDs?
1. URL
2. Cookie
3. Anonymous login
4. Hidden login
Which kind of values are injected into a connection to the host machine in an effort to increment the sequence number in a predictable fashion?
1. Counted
2. Bit
3. Null
4. IP
An ethical hacker sends a packet with a deliberate and specific path to its destination. What technique is the hacker using?
1. IP spoofing
2. Source routing
3. ARP poisoning
4. Host routing
Network-level hijacking focuses on the mechanics of a connection such as the manipulation of packet sequencing. What is the main focus of web app session hijacking?
1. Breaking user logins
2. Stealing session IDs
3. Traffic redirection
4. Resource DoS
A public use workstation contains the browsing history of multiple users who logged in during the last 7 days. While digging through the history, a user runs across the following web address: www.snaz22enu.com/&w25/session=22525. What kind of embedding are we seeing?
1. URL embedding
2. Session embedding
3. Hidden form embedding
4. Tracking cookie
Julie has sniffed an ample amount of traffic between the targeted victim and an authenticated resource. She has been able to correctly guess the packet sequence numbers and inject packets, but she is unable to receive any of the responses. What does this scenario define?
1. Switched network
2. SSL encryption
3. TCP hijacking
4. Blind hijacking
Session hijacking can be performed on all of the following protocols except which one?
1. FTP
2. SMTP
3. HTTP
4. SSL
Which technology can provide protection against session hijacking?
1. IPSec
2. UDP
3. TCP
4. IDS
Session fixation is a vulnerability in which of the following?
1. Web applications
2. Networks
3. Software applications
4. Protocols
Session hijacking can be thwarted with which of the following?
1. SSH
2. FTP
3. Authentication
4. Sniffing
XSS is typically targeted toward which of the following?
1. Web applications
2. E-mail clients
3. Web browsers
4. Users
A man-in-the-browser attack is typically enabled by using which mechanism?
1. Virus
2. Worms
3. Logic bombs
4. Trojans
A man-in-the-middle attack is an attack where the attacking party does which of the following?
1. Infects the client system
2. Infects the server system
3. Insert themselves into an active session
4. Insert themselves into a web application
A session hijack can happen with which of the following?
1. Networks and applications
2. Networks and physical devices
3. Browsers and applications
4. Cookies and devices
A session hijack can be initiated from all of the following except which one?
1. E-mails
2. Browsers
3. Web applications
4. Cookies and devices
Session hijacking can do all of the following except which one?
1. Take over an authenticated session
2. Be used to steal cookies
3. Take over a session
4. Place a cookie on a server