Resolution mitm attack-session hijacking

In this article, we will discuss the theory and demonstration of session hijacking and discuss related detection and defense techniques.

Introduction

In the previous two articles, we discussed ARP cache poisoning and DNS Spoofing respectively. From the examples shown above, we can see that man-in-the-middle attacks are very effective forms of attacks, and is increasingly difficult to detect. In this article, we will discuss the theory and demonstration of session hijacking attacks, and discuss related detection and defense techniques.

Session hijacking

We often hear session hijacking. In general, any attack involving sessions between devices is session hijacking. The session here refers to the connection between devices in the active state.

In this article, we will discuss session hijacking from the perspective of cookie Theft (involving HTTP sessions. You can often see websites that require logon verification information. These websites are connected by session. First, the visitor must enter the user name and password to obtain the website's identity authentication, that is, formally establish a session, and then the website will maintain some form of session tracking to ensure the visitor's login status, and allow visitors to access website resources (usually through cookies ). When the session ends, the login information is cleared before the session ends. This is a common form of session. Although we are not aware of this kind of session, the session is always happening, and most of the communication is dependent on some form of session or status-based activity.

Figure 1: normal session

As mentioned in the previous article, things over the Internet are insecure, so are session data. The principle behind most forms of session hijacking is that if you can intercept some part of the data of a established session, you can use the data to impersonate any participant involved in the communication, to obtain the session information. In the above example, this means that if we can obtain a cookie used to maintain the session status between the browser and the login website, we can send the cookie to the network server and impersonate a session connection. From the attacker's point of view, this seems great, but it does.

Figure 2 session hijacking

Now we have some theoretical basis for session hijacking, so we can continue to study it in depth from the instance.

Cookie Theft

In our demonstration instance, We will intercept user login to Gmail account communication to perform session hijacking attacks. With the intercept communication, we can impersonate a user and log on to the user account from our attacker.

To execute this attack, we will use tools named Hamster and Ferret. You can click here to download these two tools, both of which are command line tools, in this way, the Hamster folder can be extracted to a location that is easy to obtain.

Alternatively, you can download and use Backtrack 4. BT4 is a Linux portable system designed for attack and penetration testing. It contains many pre-installed and pre-compiled tools. Hamster and Ferret are among them. You can find hamster in the/pentest/sniffers/Hamster folder. The screen example in this article is from BT4.

The first step involved in this form of session attack is to intercept communication when the victim browses Facebook. This interception can actually be achieved using any data packet sniffing application (such as TCPDump or Wireshark, however, to intercept correct data packets, you will need to deploy technologies such as ARP cache poisoning (attack forms discussed in the previous article.

Figure 3: intercept traffic of users accessing the Gmail account

After intercepting the traffic of the user accessing the Gmail account, you need to store the interception file in the Hamster directory. In our example, we put the interception file in the folder named victim_gmail.pcap, then we will use Ferret to process the file. This operation is implemented in this way: browse the Hamster folder and run the command "ferret-r victim_gmail.pcap.pdf, ferretwill process this file and create a hamster.txt file, which will be used by Hamster to initiate a real session hijacking attack.

Figure 4: Using Ferret to process intercepted files

After using the intercepted HTTP data, we can use Hamster to initiate actual attacks. Hamster runs as a proxy server and provides an interface for browsing and using stolen session cookies. To start the Hamster proxy server, you only need to simply execute the Hamster without the command line option.

Figure 5: Start Hamster

After the preceding operation is successful, you need to open your browser and configure its proxy settings to conform to the settings provided by Hamster output. By default, this means that you need to configure your proxy to use 127.0.0.1 of the local loopback address port 1234. To access this setting in IE, you can select Tools, Internet Options, connections, and LAN Settings, and select "use proxy server for LAN.

Figure 6: Configure proxy settings for Hamster

Now that the proxy settings are configured, you can enter http: // hamster in your browser to access the Hamster console. Hamster uses the File Created by Ferret to generate a list of IP addresses (IP addresses intercepted by session information) and displays these IP addresses in the right pane of the browser, the file we created contains only one IP address of the victim, so we can click the left pane to find more sessions that can be hijacked.

Figure 7: Hamster user interface

As shown in, facebook.com is also in the list. If you click this link, you will see a new window for successfully logging on to the victim's facebook account.

Figure 8: successfully hijacked a Gmail account

How to defend against session hijacking

Currently, there are many different session hijacking attacks, so the defense methods are also different. Unlike other man-in-the-middle attacks we have evaluated earlier, session hijacking is difficult to detect and defend against, because session hijacking is basically a form of passive attack. Unless a malicious user performs an explicit operation when accessing a hijacked session, we will never know that the account has been hijacked. However, the following suggestions can help you defend against session hijacking to a certain extent:

Protect network banking accounts in the home network-the chances for an attacker to intercept the home network are much lower than the chances of intercept the work network. This is not because the home network is more secure (in fact, the home network may be more insecure). However, if the home has only one or two computers, you do not need to worry about session hijacking, what you need to worry about most is when your young child starts watching online attack videos. In the enterprise network, you cannot know the network conditions in the network or the branch network, so there are many potential attack resources. One of the biggest targets of session hijacking is online bank accounts, but this also makes all attacks the main targets.

Bright-smart attackers will not leave any evidence to prove that they have entered your security account, but even the most sophisticated attackers will make mistakes. When you log on to a session-based connection service, be careful to ensure that the service is not hijacked by attackers. Observe the exception situation carefully and pay attention to the last logon time to ensure security.

Protect the security of internal devices-generally, man-in-the-middle attacks are performed from the internal network. If your network device is safe, the chances of the device being used to initiate session hijacking is relatively low.

Conclusion

We have discussed three very critical man-in-the-middle attack types that, if successfully executed, can have very serious consequences for victims. Attackers who use session hijacking for malicious purposes may access users' online banking, emails, or even important internal applications. In the next article in the man-in-the-middle attack series, we will look at another well-known man-in-the-middle attack, namely SSL spoofing.