Introduction

Within this post session hijacking & credential harvesting will be investigated, allowing the reader to understand what each of these attacks are as well as the vulnerability which allows them to occur. Technical details will be provided as well as a step by step tutorial enabling the reader to test these attacks within their own lab environment. References will also be detailed to enable the reader to verify the information provided as well as conduct further research. Within ‘The Lab’ section there is a tutorial available which will allow the reader to create their own sandboxed environment ensuring that laws are not broken during the process.

Session Hijacking

Lawson defines Session Hijacking aka Sidejacking as the act of monitoring network traffic in order to capture a users HTTP (Hypertext Transfer Protocol) session cookie allowing an attacker to inject the cookie into their browser permitting authenticated access to the users session (LAWSON, 2013). As shown within the below Figure an attacker sniffs the session cookie which is transmitted by the victim over the wireless network and then retransmits the session cookie gaining authenticated access to the web server.

Session hijacking is most prominent when websites which have authentication mechanisms utilise HTTP rather than its secure counterpart HTTPS (Hypertext Transfer Protocol Secure). HTTP is a stateless protocol therefore the user is not constantly authenticated during a session. The session cookie is used to hold the authentication details of the user and is sent within the HTTP header during each transmission re-authenticating the user each time. If the session cookie was not used the user would have to enter their authentication details each time they communicate with the desired website. Yet this cookie creates ease of use for users, it creates the issue of enabling malicious actors to capture and replay the cookie granting them authentication to the session (Toussain, 2013). When web sites provide authentication using the SSL / TLS protocol (HTTPS) session hijacking cannot occur due authentication details being encrypted, this protocol will be discussed later within this post.

Credential Harvesting

Credential harvesting occurs through the same means as session hijacking, utilising the unencrypted communication of the session cookie. Due to these details being sent in plain text tools are available which allow the attacker to obtain the credentials, allowing access to the victim account whenever desired. Once again if authentication has occurred using the SSL / TLS protocol (HTTPS) these details are encrypted mitigating this attack. (A vulnerability can be exploited to allow this attack and session hijacking to take place, this will be discussed later on within the post)

Man In The Middle Attack (MITM)

The MITM attack is where the attacker places themselves between the victim and the network allowing all data being sent by the victim to be viewed by the attacker, which can be seen within the Figure below. Wagner discusses that the attack exploits the vulnerability within ARP (Address Resolution Protocol) which translates IP addresses to the hardware MAC (Media Access Controller) address. In order for devices to communicate across a network an ARP table is created which stores the hardware MAC address and IP address of each of the devices. ARP requests are made by each device within the network in order to learn the devices which are connected to the network, generating a table which is referred to when transmitting data. ARP poisoning is where an attacker replaces the contents of an legitimate ARP table, masquerading themselves as different devices on the network (Wagner, 2001). As shown within the Figure below the ARP cache tables of the victim and the router have been replaced with the attackers MAC address, each time either the victim or router communicates to each other, their data is transmitted via the attacker creating a MITM attack.

SSL / TLS Protocol

SSL is a stateful security protocol which was designed by Netscape during 1994 (SSL v1), updating later that year to version 2 with version 3 released during 1995. In order to decrease process overheads SSL uses both asymmetric and symmetric encryption through communication. Asymmetric is used to establish the secure communication channel whilst symmetric is used throughout further communications (Thomas, 2000). The advantage of SSL is that it is separate from the application protocol allowing any application to utilise it increasing security when communicating, which can be seen within the Figure below.

(Thomas, 2000)

As with any computer communication a handshake is performed in order to establish how further communication will occur. It is this process which enables SSL to be a stateful protocol, ensuring that both the client and the server operate consistently (Oppliger, 2009).

The first stage of the handshake is where the client sends a “Hello” message to the web server which can be seen within the Figure below. During this transmission the client provides the server with the key exchange method, cipher standard, the hash which it can accept and SSL version number (Thomas, 2000).

The server will cross reference the key exchange method, cipher standard, the hash and SSL version of the client and determine the most secure way of communication relaying these details back to the client which can be seen within the Figure below.

The server sends the client the x.509 digital certificate.

The client cross references the received x.509 certificate against the browsers trusted CA’s, if the CA is not within the list an alert is presented to the client. Once this process is complete the client generates a random symmetric key, encrypts it using the servers public key and transmits it to the server.

Both the server and the client will use the symmetric key for further encrypted communication (Thomas, 2000).

During 1999 the IEFT (Internet Engineering Task Force) acquired the development of SSL, through an attempt of standardising the protocol TLS was born creating TLS v1 also known within the community as SSL v3.1 (Oppliger, 2009). Backward compatibility issues with SSL v2 were arising due to inefficient security within the protocol allowing MITM attacks to occur due to the handshakes not being protected allowing an attacker to downgrade the cipher suite as well as by terminating TLS connections with the use of sending TCP FIN. The IEFT released RFC6176 during 2011 stating the issues of security and amendments which had to be adopted to ensure the confidentiality and integrity of the communications. They stated that during the ‘Client Hello’ message of the handshake that TLS must not send any compatibility with SSL v2, if the server did receive compatibility with SSL v2 then it must respond with SSL v3, if the client could not function at that protocol version level then the communication would be terminated (Turner, Polk, 2011). During April 2014 the IEFT released a new internet draft document stating that the RSA algorithm will be removed from the updated TLS v1.3 due to released documents by Ed Snowden stating that RSA was influenced by the US NSA (National Security Agency) to ensure security of the users of TLS. It is stated within the document that that RSA certificate would still be allowed but only when the key exchange was via DHE (Diffie–Hellman Key Exchange) or ECDHE (Elliptic Curve Diffie–Hellman). It is also stated that IDEA (International Data Encryption Algorithm) and DES cipher suites will also be removed from the TLS v 1.3 due to their deprecation (Dierks, Rescorla, 2014).

x.509 Certificate

In order to provide the public key within SSL / TLS during asymmetric encryption communication digital certificates are used for the exchange and can be provided either by self signed certificates or signed by a certificate authority (Microsoft Corporation, 2007). When a user attempts to communicate to a web server utilizing asymmetric encryption the user is provided with a digital certificate holding the public key used for encryption as well as other information. As shown within the Figure below the certificate also stores the name in which the certificate is issued to, serial number, the issuer and validity each of these fields are then hashed to create MD5 / SHA1 digital fingerprints. It is this data which allows the browser to validate if the certificate is authentic by comparing the visited website address and the address within the certificate (McDowell, Lytle, 2010).

HTTPS

As previously stated SSL/TLS are protocols within their own right and function at separate layers allowing different applications to utilize the protocols to increase security. HTTP can be secured using this method by sending data down the stack through the SSL / TLS protocol creating HTTPS through port 443 (Thomas, 2000). Many websites where sensitive information is being transmitted now utilize this method to reduce the risk of session hijacking and credentials being harvested in plain text by an malicious actor. The move from websites using HTTP for authentication came after Firesheep made the public aware of the unsecure practices by website which held confidential information such as Amazon, Facebook and Hotmail to name a few (Ducklin, 2011). The Figure below depicts the difference between HTTP and HTTPS communication through the stack.

(Thomas, 2000)

302 Redirect

Servers which provide HTTPS can allow HTTP connections to be redirected automatically using the ‘HTTP 302 Redirect’, enabling the client to input values within the address bar such as ‘amazon.com’ instead of the need to type ‘https://amazon.com’. This is accomplished by editing the ‘HTTP 302 Redirect’ from providing a page which has the redirect link which uses the POST function to automatically redirect using the GET function. This enables the user to be automatically redirected to the secure page without the need of typing the full URL.

Exploiting HTTPS Utilising 302 Redirect

Web developers / web browsers constantly use the 302 redirect incorrectly where RFC 1945 states that ‘3xx: Redirection – Further action must be taken in order to complete the request’. Meaning that a link for redirection should be provided, not automatic redirection, it is because of this the 302 redirect can be used to exploit users allowing session hijacking and credential harvesting to occur. By utilising a MITM attack, the attacker can stop the redirection from occurring where the user will then enter authentication details using the unsecure HTTP protocol.

Tutorial

During the tutorial the attacks which have been discussed will be orchestrated, allowing the reader to utilise the information above within practical application.

The tools used within this exercise are:

• Cookie Manager, Grease Monkey & Cookie Injection Script (Firefox Add-ons)
• Ettercap
• IP Tables
• SSL Strip
• Wireshark

Victim device will be Windows 7 & Android

Victim accounts used are Amazon & Outlook.

Machines to be loaded:
• Captive Portal Server Running.
• Attack Platform Authenticated to Captive Portal.
• Victim Devices Authenticated to Captive Portal.

IP Addresses:
• Attack: 192.168.2.191
• Victim: 192.168.2.121

Please note that your IP addresses maybe different, I have provided mine to enable the reader to understand what the addresses relate to further within the tutorial.

***For lab environment details please see ‘The Lab’ section***
***Ensure your attack machine is running as ‘root’***

Initiating Attack

Here we will be using the tools mentioned above in order to start the attack. The tools will be discussed as well as a guide on how to configure them.

Part 1: IP Tables

IP Tables is a firewall application installed on Linux distros, as we will be routing data through the attack platform we must set rules to allow the data to be redirected to a tool which will allow us to exploit SSL / TLS communication. The command below should be entered into the Terminal, this will direct all traffic from port 80 to alternative HTTP port 8080.

Iptables -t nat -A PREROUTING -p tcp –destination-port 80 -j REDIRECT –to-port 8080

Part 2: Initiate Cookie Sniffing with Wireshark

Wireshark is a packet analysing application, this will allow us to capture the session cookies which are being transmitted throughout communication of the victims web session. Enter the command below into the terminal to open Wireshark.

wireshark

Once Wireshark has opened you will be provided by the following window.

Next the network adapter which shall be used to sniff the data traffic must be selected, within this example the network adapter being used is ‘wlan0’, this is the adapter which the attack machine is connected to the captive portal network. ‘Start’ must then be pressed to initiate the capture of network traffic. As shown within the Figure below data packets being transmitted across the network have been captured which will allow data packet analysis to be performed.

Part 3: MITM Attack with Ettercap

Ettercap will be used to perform the MITM attack. Within the terminal enter the command below, within this tutorial we will be using the GUI which is denoted by the ‘-G’ flag.

ettercap -G

You will then be presented with the window shown within the below Figure.

Within Ettercap click the ‘Sniff’ tab and select ‘Unified Sniffing’.

Select the network interface as shown within the below figure (As previously stated I will be using ‘wlan0’.

Select the ‘Hosts’ tab and ‘Scan for hosts’. This will allow the discovery of hosts connected to the network.

Select the ‘Hosts’ tab and ‘Hosts List’. This will show you the hosts connected to the network.

Now that the hosts of the network have been discovered we can initiate the MITM attack.
Select the victim IP address (In my example this is 192.168.2.121) and click ‘Add to Target 1’.
Select the captive portal IP address (In my example this is 192.168.2.1) and click ‘Add to Target 2’.
Next Select the ‘MITM’ tab and ‘ARP Poisoning’.

You will then be presented with the window below, select ‘Sniff Remote Connections’ and click ‘OK’. ARP poisoning will now take place, creating the MITM attack.

Next select the ‘Start’ tab and ‘Start Sniffing’, Ettercap will then start sniffing for credentials being sent through the MITM transmission.

Part 4: Exploiting 302 Redirect with SSL Strip

Moxie Marlinspike’s SSL Strip will be used to exploit the 302 redirect. Within the terminal enter the command below, here ‘-l’ denotes the port to listen for communication ‘port 8080’, which was designated when setting the IP Table.

sslstrip -l 8080

Exploitation

On the victim machine open the web browser and authenticate to the test accounts (Amazon & Outlook). Ensure when visiting the web sites you use e.g. ‘amazon.com / outlook.com’ within the address bar, we will be exploiting the 302 redirect.

Part 1: Cookie Harvesting for Session Hijacking

Go a back to ‘Wireshark’, you should see a lot of data packets have been collected. It would be very time consuming analysing each packet, since we are cookie harvesting we can apply a filter for cookies, by entering the command below within the ‘Filter’ input box.

http.cookie

Now that all the captured cookies are being shown, search for the Amazon cookie. Once you have found it, click on the ‘Hypertext Transfer Protocol’ section within the packet. As shown within the Figure below you will be able to see the cookie details (highlighted in blue).

As shown within the image below:
• ‘right click’ on the cookie.
• Select ‘Copy’, ‘Bytes’, ‘Printable Text Only’.
This will copy the cookie data.

Injection Script for Grease Monkey will be used to inject the victims cookie into our browser. Both of these tools are add-ons for Firefox / Iceweasel (Please see ‘The Lab’ section for installation details).

Next visit Amazon and press ‘Alt-C’, this will use ‘Injection Script’ to allow us to inject the stolen cookie into our browser. Click ‘OK’ and then refresh the page.

The image below shows that we have successfully session hijacked the Amazon account, we could cause a lot of financial damage spending on the victims account. But obviously that would be illegal!

Now find the Outlook cookie and session hijack the account, you will find you will also obtain access.

If the victim logs out of the account the session will finish and the cookie will be terminated.

Part 2: Credential Harvesting

The only issue with session hijacking is that once the victim logs out of their account the session cookie becomes invalid, therefore you will not retain access. In order to circumvent this we can now view the users credentials in plain text since the HTTPS session did not occur.

Go back to ‘Ettercap’, you will find that within the bottom part of the application data is being shown. Go through this data and you will find the user credentials ready for harvesting, allowing you to log onto the victim accounts whenever you like (as long as they do not change password).

Try these attacks on other web sites which use authentication, ensure that these are test accounts which you have created doing these attacks in the wild is illegal!

Exploitation of Accounts Authenticating with Mobile Applications?

Next attempt to authenticate using an Android device using the web browser, you will discover that these attacks still work. If you then attempt these attacks using the mobile applications you will find that they are not successful. This is since the application is written to use HTTPS within the source code, due to this there is no 302 redirect therefore SSL Strip does not enable the attack to harvest the details. It can be said that it is safer to use mobile applications for authentication to these web sites when using Wi-Fi hotspots, but using mobile applications can open another can of worms with the system privileges which are granted during their installation.

Possible Mitigation Methods

• Do not use Wi-Fi hotspots for authenticating to web sites.
• Ensure when browsing to web sites where authentication is needed the whole URL is typed or stored within a Bookmark, e.g. https://www.amazon.com
• Use mobile applications when possible.
• Use a VPN. (These will be discussed in detail later on within the posts)

Conclusion

As demonstrated throughout this post using Wi-Fi hotspots leave the users vulnerable to attack, allowing sensitive information to be gathered which could results in ID theft & fraud from taking place. Users need to be made aware of these vulnerabilities to ensure the scope of the attack is decreased. Yet using these unsecure systems does provide a large threat to its users there are mitigation strategies available which can be used, reducing the risk of becoming victim to such attacks.

Disclaimer

To reiterate, this blog is not a hacking site nor does the author condone blackhat attacks on organisations, establishments or individuals. This blog is provided for educational purposes only ! Enabling computer security enthusiasts / students to further their research and provide practical guides to help individuals. The author does not take any responsibility for any actions taken from individuals who have read information within this blog and used the knowledge for malicious use.

Penetration testing / ethical hacking should only be conducted on systems where consent has been granted. It is illegal within many countries around the world to gain access to system without authorisation.

References
DIERKS, T. and RESCORLA, E. 2014. The Transport Layer Security (TLS) Protocol Version 1.3 draft-ietf-tls-tls13-01. USA: IETF.

DUCKLIN, P. 26/10/2010, 2010-last update, secure websites are insecure – ask firesheep [Homepage of Naked Security, Sophos], [Online]. Available: http://nakedsecurity.sophos.com/2010/10/26/secure-websites-insecure/ [31/03/2014].

LAWSON, K. 2013. There Is No Vacation from Cybercrime at WiFi Hotspots. USA Today Magazine, 142(2818), 60-62.

MCDOWELL, M. and LYTLE , M. 23/06/2010, 2010-last update, understanding web certificates [Homepage of USA Department of Home Security], [Online]. Available: https://www.us-cert.gov/ncas/tips/ST05-010 [17/04/2014].

MICROSOFT CORPORATION 26/10/2007, 2007-last update, description of symmetric and asymmetric encryption [Homepage of Microsoft], [Online]. Available: http://support.microsoft.com/kb/246071 [31/03/2014].

OPPLIGER, R. 2009. SSL and TLS: Theory and Practice (Information Security and Privacy). 1st edn. USA: Artech House.

SHIELDS, C. and TOUSSAIN, M. 10/04/2012, 2012-last update, subterfuge: the MITM framework [Homepage of Subterfuge], [Online]. Available: http://subterfuge.googlecode.com/files/Subterfuge%20-%20White%20Paper.pdf [20/04/2014].

THOMAS, S. 2000. SSL and TLS Essentials: Securing the Web. 1st edn. Canada: Wiley Computer Publishing.

TURNER, S. and POLK, T. 2011. RFC 6176. USA: IEFT.

WAGNER, R. 2001. Address Resolution Protocol Spoofing and Man-in-the-Middle Attacks. USA: SANS Institute.