Resolving a man-in-the-middle attack (3/4)---session hijacking

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

　　Introduction

In the previous two articles we discussed the ARP cache poisoning and DNS spoofing separately, as shown in the previous example, we can see that the man-in-the-middle attack is a very effective form of attack and more and more difficult to detect. In this article, we will explore the theory and demonstration of session hijacking attacks, and discuss related detection and defense techniques.

　　Session Hijacking

We often hear session hijacking, and in general, any attack that involves a session between devices is session hijacking, a conversation here that refers to a connection between devices that exist in the state.

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

Figure 1: Normal session

As mentioned in the previous article, everything that goes through the internet is unsafe, and so is the session data. The principle behind most forms of session hijacking is that if you can intercept some part of the data that has been established, you can use that data to impersonate any participant involved in the communication to obtain session information. In the example above, this means that if we are able to obtain a cookie to maintain the state of the session between the browser and the site, we can send the cookie to the Web server and impersonate the session connection. From an attacker's point of view, this sounds like a great, but it is true.

Figure 2: Session hijacking

Now that we have some theoretical basis for session hijacking, let's continue in-depth research from the examples.

　　Stealing cookies

In our demonstration example, we will perform a session hijacking attack by intercepting the communication that the user logged into the Gmail account. With this intercepted communication we are able to impersonate the user and log in to the user account from our attacker.

In order to perform this attack, we will use a tool called Hamster and ferret, and you can download both tools here, both of which are command-line tools so that the Hamster folder can be extracted to an easily accessible location.

Or you can download and use the Backtrack 4,BT4 is a Linux portable system designed for attack and penetration testing, which contains many pre-assembled and precompiled tools, hamster and ferret are one of them. You can find hamster in the/pentest/sniffers/hamster folder. An example of the screen in this article is from BT4.

The first step involved in this form of a session attack is to intercept the victim's communication while browsing Facebook, which can actually be implemented using any packet sniffing application (such as tcpdump or Wireshark), but in order to intercept the correct packet, You will need to deploy techniques such as ARP cache poisoning (the attack form discussed in the previous article).

Figure 3: Interception of traffic to users accessing Gmail accounts

After intercepting the traffic to the user accessing the Gmail account, you need to store the interception file in the Hamster directory, and in our case we put the Intercept file in a folder named Victim_gmail.pcap, and we'll use ferret to process the file. This procedure is implemented as follows: Browse the Hamster folder and run the command "Ferret–r Victim_gmail.pcap", Ferret will process this file and create a hamster.txt file, which will be used for hamster to initiate a real session hijacking attack.

Figure 4: Handling interception files with Ferret

With the interception of HTTP data, we can use hamster to initiate an actual attack. The hamster itself is run as a proxy server, providing an interface for browsing and using stolen session cookies. In order to start the Hamster Proxy server, you simply need to perform a hamster without a command line option.

Figure 5: Start Hamster

After successful execution, you need to open your browser and configure its proxy settings to conform to the settings provided by the hamster output. By default, this means that you need to configure your proxy settings to use the local loopback address 1234 port of 127.0.0.1. To access this setting in IE, you can do this by selecting Tools, Internet Options, connections, LAN settings, and by checking "Use a proxy server for your local area network."

Figure 6: Configuring proxy settings for using hamster

Now that the proxy settings are configured, you can enter Http://hamster in your browser to access the hamster console. Hamster will use the file created by ferret to generate a list of IP addresses (session information blocked IP addresses) and display these IP addresses in the right pane of the browser, and we create files that contain only one victim's IP address, so we can click on the left pane to find more sessions that can be hijacked.

Figure 7:hamster User Interface

As shown, we see that facebook.com is also in the list, and if you click on the link, you will see a new window that successfully landed on the victim's Facebook account.

Figure 8: Successfully hijacking a Gmail account

　　How to defend against session hijacking attacks

There are many different kinds of session hijacking attacks, so the defense method is different. Unlike the other man-in-the-middle attacks we evaluated earlier, session hijacking is difficult to detect and more difficult to resist because session hijacking attacks are essentially passive attack forms. Unless a malicious user performs some obvious action when accessing a hijacked session, we will never know that the account has been hijacked. However, the following suggestions can help you protect against session hijacking attacks to some extent:

Protect network bank accounts in your home network-attackers are far less likely to intercept a home network than to intercept a work network. This is not because the home network is more secure (in fact, the home network may be more insecure), but if you have only one or two computers in your home and you don't need to worry about session hijacking, the most you need to worry about is when your young kids start watching online attack videos. In the enterprise network, you can not know the network or branch network situation, so the potential attack resources more. One of the biggest goals about session hijacking is online bank accounts, but this also makes all attacks a primary goal.

Perspicacious-Smart attackers will not leave any evidence that they have entered your security account, but even the most sophisticated attackers can make mistakes. Be careful when you log in to a session-based service to make sure that there is no hijacking object that is an attacker. Observe the anomalies carefully and note the last login time to ensure safety.

Secure internal devices-like these man-in-the-middle attacks are usually performed from the internal network, and if your network device is secure, the chances of the device being exploited to initiate session hijacking are low.

　Conclusion

We have discussed three very deadly types of man-in-the-middle attacks that, if successfully executed, could have very serious consequences for the victims. Attackers who have malicious intent to exploit session hijacking attacks may access users ' online banking, e-mail, or even important internal applications. In the next article in the Middle man attack series, we'll look at another well-known middleman attack, SSL spoofing.

Note: Transferred from the IT specialist network

Resolving a man-in-the-middle attack (3/4)---session hijacking