Session Hijacking
Conceptually, session hijacking is quite simple. The goal is to find an authentic TCP session and to take over that session. This is possible because, generally speaking, the session is authenticated at the beginning. Clearly, session hijacking is easier with some systems than with others.
Several factors can make a system more vulnerable to session hijacking. Having a weak session ID generation algorithm is a common issue. This makes predicting or guessing session IDs much easier. Having no expiration or having a very long expiration on a session also increases the possibilities for an attacker.
There are two types of session hijacking:
Active: In active session hijacking, the attacker identifies an active session and takes over that session.
Passive: In passive hijacking, the attacker just sniffs the traffic. This is not true session hijacking but is identified as passive session hijacking by the CEH exam.
The Session Hijacking Process
The CEH exam defines a process of five steps for session hijacking. An attacker won’t always follow this process, but you should know it for the CEH exam:
Sniff the traffic going to the target so you can learn about how sessions are handled. This involves using a packet sniffer such as Wireshark or tcpdump (discussed in Chapter 2, “Enumeration and Vulnerability Scanning”) to see what is being sent between a client and a server.
Monitor the traffic to determine if you can predict the next valid sequence number or session ID.
Break the connection to the legitimate client.
Take over the session, posing as that client using a session and/or sequence ID that will appear legitimate to the target server.
Perform command injection, or inject packets into the target server.
Specific Session Hijacking Methods
There are a number of mechanisms for getting a session token in order to take over a session. If data is unencrypted, you may be able to derive this information through packet sniffing. Or if the target uses a simple session ID, such as a date/time stamp, it is easy to predict the next session ID. However, there are other methods, as described in the following subsections.
Web Session Hijacking
If the target is a web server, cross-site scripting (XSS) might be able to derive a token. XSS uses malicious JavaScript. The most typical method of XSS is to insert the JavaScript into a website in a place where users normally enter text for other users to read, such as product reviews. However, it is also possible to send malicious scripts as part of an email. Or a phishing email may be able to get a user to a website that has malicious JavaScript built in.
Cross-site request forgery (CSRF) attacks an active session with a trusted site. The attacker might have a malicious link on some compromised site. Often users have more than one browser open at a time. If a user visits a compromised site and clicks on the link while they also have an active session open, the attacker can get the user’s session ID for the target site. Then the attacker sends requests to the target website, posing as the user. Both XSS and CSRF are listed as OWASP (Open Web Application Security Project) top 10 vulnerabilities.
Session fixation is another method of session hijacking. The attacker tries to get the user to authenticate to the target server, using a session ID prechosen by the attacker. This works only if the server has a very weak session ID generation scheme—one that the attacker can readily emulate to produce a session ID that appears legitimate to the server.
Session replay attacks are still covered on the CEH exam, but they rarely work today. Such an attack involves simply intercepting authentication packets and re-sending them to the target. Although modern authentication methods make such attempts ineffective, you should be aware of this type of attack for the CEH exam.
Variations of the man-in-the-middle attack work whether the target is a web server or not. The attacker sits between the client and server, via a fake access point, a fake website, or using one of many other methods. One variation of the man-in-the-middle attack is the forbidden attack. This is targeted to older, flawed implementations of TLS. Older TLS versions would sometimes reuse a nonce (short for number only used once) during the TLS handshake, which made them vulnerable. The attacker would sniff the nonce and then use it to authenticate to the server. (Remember that TLS [Transport Layer Security] is the successor to SSL [Secure Sockets Layer] since 1999. However, many people still simply say SSL when they mean TLS.)
With a man-in-the-browser attack, malicious software is on the client machine and behaves like a software library or component that the browser uses. Then that malware intercepts data going out from the browser. This is a variation of a man-in-the-middle attack. A number of malicious Chrome extensions and Firefox add-ins have been man-in-the-browser malware.
Other attacks specifically target flaws in protocols such as SSL/TLS. CRIME (Compression Ratio Info-Leak Made Easy) is one such attack. Essentially, the compression used in earlier versions of TLS was flawed and could lead to data leaks. There have been similar issues such as the BREACH attack. BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) is an improvement over CRIME that attacks an issue with the gzip compression algorithm.
Network Session Hijacking
TCP/IP hijacking is the process of taking over a TCP connection between a client and a target machine. It often uses spoofed packets. If the attacker can cause the client machine to pause or hang, the attacker can pretend to be the client and send spoofed packets. To do this, the attacker must know the packet sequence number and be able to use the next sequence number. Modern authentication methods periodically re-authenticate, often rendering this type of attack unsuccessful.
RST hijacking is another method. The attacker uses an RST (reset) packet to spoof the client’s IP address, but also uses the correct sequence number to cause the connection to reset. This resets the connection and allows the attacker to take over that session. A number of tools help craft custom packets, such as Packet Builder from Colasoft.
Some attackers simply inject forged packets into a data stream, spoofing the source IP address. With this method, the attacker cannot see the response, and it is thus called blind hijacking.
UDP hijacking is similar to TCP/IP hijacking, but using UDP packets. The attacker spoofs the server, sending the client a forged UDP reply, so the client connects to the attacker’s machine.
There are a number of tools that can help perform any of these attacks. One of the most widely used—and heavily emphasized on the CEH exam—is Burp Suite. Burp Suite can be downloaded from https://portswigger.net/burp. There is a free community edition, and there are professional and enterprise editions. Using the default settings, the main screen of the Burp Suite community edition looks as shown in Figure 6.5.
FIGURE 6-5 Burp Suite
The CEH exam won’t test you on all the uses of Burp Suite, but it is probably a good idea to get familiar with this tool as it is very helpful in conducting penetration tests. Fortunately, the internet is replete with tutorials for Burp Suite.
There are other tools that can accomplish similar tasks:
OWASP ZAP: A tool often touted as a website vulnerability scanner, which also allows you to intercept and alter packets, available at www.owasp.org
WebSploit Framework: A tool explicitly designed for man-in-the-middle attacks, available at https://sourceforge.net/projects/websploit/
Bettercap: A tool that is also useful for Bluetooth hacking, available at https://www.bettercap.org
DroidSheep: A session hijacking tool that runs on Android, available at https://droidsheep.info
DroidSniff: An Android tool designed for security scanning that can also be used for man-in-the-middle attacks, available at https://github.com/evozi/DroidSniff
Countermeasures for Session Hijacking
There are many different methods for mitigating session hijacking. One of the easiest is to encrypt all data in transit. This includes using SSH for any secure communications. In addition to ensuring that communications are encrypted, you should ensure that you are using up-to-date methods. Earlier in this chapter, we discussed attacks against TLS vulnerabilities. Using the latest TLS version (which is 1.3 as of this writing) will mitigate or eliminate most of them.
Never use session ID numbers that are easy to predict. They should be random numbers generated by a robust random number generation algorithm. Also ensure that session IDs are transmitted securely and that sessions time out.
Strong authentication techniques such as Kerberos will prevent at least some session hijacking attacks. Also ensure that you are using the normal antimalware protections, such as antivirus and intrusion prevention systems.
Web developers can combat session hijacking attacks on their websites by using a variety of additional techniques. For example, cookies with session information should be stored securely (encrypted), and a website should use the HTTPOnly attribute. HTTPOnly means the cookie can only be accessed with the HTTP protocol; any script or malware on the client computer cannot access it.
Websites should check to see that all traffic for a given session is coming from the same IP address that initiated the session. This will at least detect many session hijacking techniques. Always have timeouts for cookies, sessions, and so on. The shorter, the better—but, of course, it is important to keep user satisfaction in mind.
HTTP Strict-Transport-Security (HSTS) can also help mitigate session hijacking attacks. HSTS is a server setting that requires browsers to connect with HTTPS rather than HTTP. This makes all traffic encrypted. HTTP Public Key Pinning (HPKP) allows a web client to associate a specific public key with a specific server, so it is harder for an attacker to spoof a legitimate web server.
Always use secure protocols. Table 6.1 summarizes them.
TABLE 6.1 Secure Protocol Replacement
Insecure Protocol |
Secure Replacement |
---|---|
HTTP |
HTTPS |
Telnet, rlogin |
SSH |
Any TCP/IP traffic |
Encrypt with a VPN |
FTP |
SFTP or FTPS |