Chapter 17 SSL TLS Session Attacks

17.1 Introduction

The Secure Sockets Layer (SSL) protocol refers to the communication pro- tocol used to secure any transmission over the Transfer Control Protocol (TCP). It aims at providing privacy and reliability between two communicating applications. Privacy is achieved by encrypting the connection. Identity identification is ensured through the use of certificates. Reliability is main- tained through message integrity checks by performing dependable mainte- nance of the secure connection.

The authentication process involves an SSL / TLS client sending a mes- sage to the SSL / TLS server. The server, in turn, responds with the information that the server needs to authenticate itself. Both the server and the client exchange session keys, which marks the end of the dialog. The process of authenticating and establishing an encrypted channel using certificate-based authentication, shown in Figure 5.1, involves the following steps:

  1. A client requests access to a protected resource.
  2. The server presents its certificate to the client.
  3. The client verifies the server’s certificate.
  4. If successful, the client generates a symmetric key for this session.
  5. The client then sends that symmetric key to the server, encrypted with the server’s public key.
  6. The communication proceeds using the symmetric session key.

Hyper Text Transfer Protocol Secure (HTTPS) uses the SSL/TLS pro- tocol to secure browser communication between clients and servers. When a

17.2 SSL TLS SESSION ATTACKS

Figure 5.1: SSL / TLS Authentication Process

user visits a webpage that is protected using HTTPS, the browser will dis- play a padlock icon in the address bar and sometimes a green bar as shown in Figure 5.2 by Comodo [? ].

In 2009, Marlinspike created two tools called “sslstrip” [? ] and “sslsniff” [? ] which were presented at Black Hat DC [? ]. These tools do not attack the SSL protocol itself, but the transition from non-encrypted to encrypted com- munications. They transparently hijack HTTP traffic on a network, watch for HTTPS links and redirects, and then map those links into either look- alike HTTP links or homograph-similar HTTPS links. In section 5.2, you will implement the SSL/TLS hijack attack using the “sslstrip” [? ] tool.

17.3 The SSL/TLS Session Hijack Attack

In this section, you will implement the SSL/TLS session hijacking attack (sometimes referred to as SSL/TLS Downgrade Attack) using Marlinspike’s “sslstrip” [? ] tool.

17.3.1 Document Your Current Settings

Perform the following actions:

  1. Run the victim’s VM (Win7-Victim)

17.3.2 THE SSL/TLS SESSION HIJACK ATTACK

Browsers using HTTPS

FIGURE 17.1: Browsers using HTTPS

17.3.3 SSL TLS SESSION ATTACKS

  1. Find the IP-address and gateway of the victim and write them down on a piece of paper ( Hint: use the ifconfig command )
  2. Run the attacker’s VM (Kali-Attacker)
  3. Find the IP-address and gateway of the attacker and write them down on a piece of paper ( Hint: use the ifconfig and route -ncommands )
  4. Verify that the IP-addresses are in the 10.10.. representing a NATed address.

Note: If your configurations are incorrect seek help before proceeding. Note: If you are performing this activity at home, you will get different IP addresses than the ones specified above.

IP address
-2*Victim Gateway
lightgray lightgrayIP address lightgray
-2*lightgrayAttacker lightgrayGateway lightgray

17.4 THE SSL/TLS SESSION HIJACK ATTACK

17.4.1 Setip_forward on the Attacker’s Side

The attacker is preparing to intercept the communication between the victim and the gateway. Thus, the attacker should be capable of acting as the gateway. This entails the ability to forward packets, not directed to the attacker, to it’s original destination. In order to do so, the attacker has to enable IP forwarding by performing the following:

  1. On the attacker machine (Kali), open the terminal and find out the current status of ip_forward by running:
cat /proc/sys/net/ipv4/ip_forward
  1. If you get the value 0 , then change it to 1 by running:
echo 1 > /proc/sys/net/ipv4/ip_forward
  1. Check the value and verify that it has been changed to 1 by running:
cat /proc/sys/net/ipv4/ip_forward
Settingip_forward on the Attacker’s VM

FIGURE 17.2: Settingip_forward on the Attacker’s VM

17.4.2 Flush Attacker’s iptables

In Linux-based operating systems, the iptables utility is used to store IP forwarding rules. The attacker should flush the iptables before setting the desired rules by performing the following:

  1. In the current terminal, run:
iptables –-flush
  1. Then run:
iptables –-flush -t nat

17.5 SSL TLS SESSION ATTACKS

Flushing iptables on the Attacker’s VM

FIGURE 17.3: Flushing iptables on the Attacker’s VM

17.5.1 Set iptables on Attacker’s Side

The attacker now sets iptables using the desired routing rules by performing the following:

  1. In the current terminal, run:
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 9000
  1. Then run:
iptables -t nat -A PREROUTING -p udp --destination-port 53 -j REDIRECT --to-port 53
Setting iptables on the Attacker’s VM

FIGURE 17.4: Setting iptables on the Attacker’s VM

You can verify theiptables rules by running:

iptables --table nat --list
Verifying iptables Settings on the Attacker’s VM

FIGURE 17.5: Verifying iptables Settings on the Attacker’s VM

17.6 THE SSL/TLS SESSION HIJACK ATTACK

17.6.1 Set dns2proxy on Attacker’s Side

The attacker’s machine should act as a DNS as well by running the dns2proxy.py script. To do so, perform the following:

  1. In the current terminal, navigate to:
cd /root/Downloads/dns2proxy-master/
  1. Then run the dns2proxy.py script:
python dns2proxy.py
  1. Keep that terminal open :)
Running dns2proxy.py on the Attacker’s VM

FIGURE 17.6: Running dns2proxy.py on the Attacker’s VM

17.6.2 Runsslstripon Attacker’s Side

The attacker should run the sslstrip script which converts HTTPS requests into HTTP in order to obtain the victim’s credentials in plaintext! To see how that works, perform the following:

  1. Open a new terminal and run:
sslstrip -l 9000
You will get a message saying:
sslstrip 0.9 by Moxie Marlinspike running...
  1. Keep that terminal open, too :)
Running ssl stripon the Attacker’s VM

FIGURE 17.7: Running ssl stripon the Attacker’s VM

NOTE: sslstrip and dns2proxy.py are running simultaneously 
in two different terminals as shown in the following figure.
Running dns2proxy and sslstrip in two different terminals

FIGURE 17.8: Running dns2proxy and sslstrip in two different terminals

17.6.3 Attacker performs a Man-in-the-Middle (MITM)

Up until now, the attacker was setting up the environment, but no real attack has taken place yet! The attacker is now ready to get in the middle between the victim and the gateway to intercept the communication. This happens by arpspoofing the victim and the gateway. Arpspoofing tricks the victim into believing that the attacker is the gateway and tricks the gateway into believing that the attacker is the victim. This puts the attacker in the middle! To see how that works, perform the following:

  1. Open a new terminal and run:

    arpspoof -i eth0 -t Gateway-IP-address Victim-IP-address
You will get a flow of messages showing up
  1. Keep that terminal open :)
  2. Open a new terminal and run:
arpspoof -i eth0 -t Victim-IP-address Gateway-IP-address
You will get a flow of messages showing up
  1. Keep that terminal open :) Notice that you now have four terminals running different actions as shown in the figure below.
Running arpspoof on the Attacker’s VM

FIGURE 17.9: Running arpspoof on the Attacker’s VM

NOTE: You can gain a good understanding of ARP and ARPSPOOFING through Wikipedia:https://en.wikipedia.org/wiki/Address_Resolution_
Protocol.

17.6.3.1 Victim Falls to the Attack

Now, switch to the Metasploitable VM and open the Firefox Web Browser using the following steps:

Start Xterm on the Metasploitable VM with the command 'startx' and click ENTER.
Starting Xterm on the Metasploitable VM

FIGURE 17.10: Starting Xterm on the Metasploitable VM

Xterm will launch and you should get a screen that looks like this:
Xterm on Launch

FIGURE 17.11: Xterm on Launch

Right-click on the screen and navigate the the Firefox Web Browser (Applications->Network->Web Browsing->Firefox Browser)
Launching Firefox on Xterm

FIGURE 17.12: Launching Firefox on Xterm

Now that you have Firefox up and running, type gmail.com in the address bar as shown in Figure 11.13 then click ENTER. The gmail website looks legit, but does the address start with https? Enter a fake username and click NEXT

Notice that the attacker’s dns2proxy and sslstrip scripts are processing the victim’s request in the attacker’s VM as shown in Figure 11.14.

Victim visits gmail.com on the Victim’s VM

FIGURE 17.13: Victim visits gmail.com on the Victim’s VM

Attacker’s Scripts Processing Victim’s Request

FIGURE 17.14: Attacker’s Scripts Processing Victim’s Request

On the victim’s VM, enter a fake password (say: “averysecurepassword”) as shown in Figure 5.13 then click on SIGN IN.

ATTENTION: Don’t use real usernames and passwords!
Victim Entering Password in an Insecure Connection

FIGURE 17.15: Victim Entering Password in an Insecure Connection

Since the connection is http, the victim’s password will be transmitted in plain-text. The sslstrip script on the attacker’s side will store the plain-text username and plain-text password in a file namedsslstrip.log.

At this point, you are welcome to visit other websites, like facebook or linkedin, and enter a fake username and a fake password. As long as the connection is http, the usernames and passwords you enter on the victim’s VM will be logged in the sslstrip.log file on the attacker’s VM. Oops!

17.6.4 Inspecting thesslstrip.logfile on the attacker’s VM

Now, switch back to the attacker’s VM. Press CTRL+C in every opened terminal to quit the attack as shown in Figure 5.14.

Quitting the attack on the Attacker’s VM

FIGURE 17.16: Quitting the attack on the Attacker’s VM

Click on the blue folder icon in the toolbar (at the left of the screen)
to view the attacker’s home directory. Right-click the sslstrip.log file
and click Open With Text Editor. Inspect the sslstrip.log file (which
is shown in Fig. 5.15).
The sslstrip.log file on the Attacker’s VM

FIGURE 17.17: The sslstrip.log file on the Attacker’s VM

Can you see any interesting information?

Since the attacker is no longer arpspoofing, if you go to the victim’s VM again and type gmail.com in the address bar of Internet Explorer then click ENTER, you will be directed to a HTTPS webpage as shown in the following figure.

TVisiting a HTTPS website

FIGURE 17.18: TVisiting a HTTPS website