MITM using SSLStrip & Mitigation Methods

Invisible threats and prevention mechanisms.

Manas Krishna .P Asian School of Cyber Laws

Introduction:

We live in a world which is seamlessly connected by the Internet with no limits or boundaries whatsoever. The open and global nature of the Internet, built on open standards, voluntary collaboration, reusable building blocks , permission for free thinking and innovation have led mankind to progress exponentially and achieve social and economic advancement in a way that we never could have imagined.

Advancements in modern internet technology come as blissful surprises to today’s generation. One does not require a graduate degree to be able to operate a computer or a mobile phone. The ease of use and hands-free wireless networks make the prospect even more exciting. However, all these do not come without risks.

Imagine a regular day in your life where you are sitting at the comfort of your home and surfing the web looking for a good deal on e-commerce websites. While you are awaiting delivery, you receive a credit bill which shocks the wits out of you because you certainly did not spend frivolously this month. But your bank statement says otherwise. Maybe your Facebook account has been hacked, but you have been absolutely careful about not using public WiFi's or accessing your mail, social networking accounts in cyber cafes. If you have faced a similar situation then you must realize that your privacy and confidentiality have been compromised to the fullest extent thanks to vulnerabilities in browsers, your webhost and most importantly insecure configuration of your very own WiFi router.

Abstract: This sophisticated attack falls under the class of "Man in the Middle" attacks where a hacker redirects traffic between the user and the communication gateway. One of the most common ways this can be done by singling out a WiFi network is using a combination of techniques known as ARPspoofing and SSLstripping. An HTTP packet that is generated at the application layer of a computer is attached with an SSL (Secure Socket Layer) header for the purpose of security. Which is why, when you are browsing on a secure site, the URL would turn green and display HTTPS instead of plain HTTP.

MITM using SSLStrip & Mitigation Methods

Page 1

MITM using SSLStrip & Mitigation Methods Invisible threats and prevention mechanisms.

An MITM attack works by converting an encrypted communication channel (HTTPS) to plain unciphered text (HTTP). Before we learn how this works, let us understand how SSL works.

Client PC Web Server

Client Hello

Server Hello

Certificate

Server Hello Done

Client Key Exchange

Change Cipher Spec

Finished

Change Cipher Spec

Finished

SSL and its successor TLS are protocols which operate on the top of TCP. While SSL is enabled, a hacker would only be privy to information such as the IP and port you are connected to on the server side, an approximation of data bytes being sent/received

and also the encryption/compression algorithms being used. A hacker would also be able to terminate this connection, but not without notifying both parties that external interference has led to termination of session.

How does SSL work?

A TCP connection needs to be established before a SSL handshake can be initiated by the client. The client would be required to send specifications to the server. This information includes:

1) Version of SSL/TLS.

2) Ciphersuite being used

3) Compression method being used.

Initial Client Message to Server:

Version Number:

The server would check for the highest SSL/TLS version being used by both Version 2 is used for SSL 2.0, version 3 is used for SSL 3.0 and version 3.1 is used for TLS. Also there is a need to note that the IETF RFC for TLS is TLS 1.0, though the protocol is described as 3.1 which indicates that it is at a comparitively better level with newer and better functionality.It then picks a ciphersuite from one of the options provided by the client (if it supports one).

Cipher Suite:

An example of a currently in-use cipher suite would be the TLS_RSA_WITH_DES_CBC_SHA, where TLS is the protocol version, RSA is the algorithm that will be used for key exchange, DES_CBC is the encryption algorithm (using a 56-bit key in CBC mode), and SHA is the hash function.

MITM using SSLStrip & Mitigation Methods

Page 2

Randomly Generated Data:

ClientRandom[32] is a random 4-byte number that consists of information such as client's date and time along with 28-byte randomly generated number that will ultimately be used with a server random value to generate a master secret from which encryption keys will be derived.

Session Identification:

SessionID exists for user convenience. It helps the user continue with their previous session as creating a new session requires processor intensive public key operations. To remedy this, session keys are used to resume existing sessions. Information pertaining to this is stored in the session caches of server and client session caches. When the server sends a response to the client, a session identification field is also added and there could be one of 3 choices:

i) New Session ID

ii) Resume Session ID

iii) Null

Compression algorithm:

Requested compression algorithm (None are currently supported).

The following is an example of a Client Hello Message:

ClientVersion 3, 1

ClientRandom[32]

SessionID: None (new session)

Suggested Cipher Suites:

TLS_RSA_WITH_3DES_EDE_CBC_SHA

TLS_RSA_WITH_DES_CBC_SHA

Suggested Compression Algorithm:

NONE

Next, the server sends a certificate (Check RFC 5280 - Internet X.509 Public Key Infrastructure) that it purchased from an issuing authority (e.g. Verisign) to the client. The certificate must be trusted by the client or a party that the client trusts. For example, if a pre-installed GeoTrust certification exists on the client browser, it would automatically trust certificates from Google, because GeoTrust cryptographically signed Google's certificate.

One might stop to wonder if it makes sense to blindly trust a third party certificate just because a pre-installed CA (Certifying Authority) has signed it previously. In actuality, there are millions of such certificates and to update them regularly would not be feasible. Which is why this chain mechanism has been implemented.

In the next step, to make absolutely sure that communication is taking place with the server and not an attacker, a key is exchanged between both parties. This is usually a public key (in most cases) and this depends on the ciphersuite being used. Both the server and client can now compute the key for symmetric encryption. The client would then establish a secure communication pathway with the server by sending it an encrypted and authenticated message.

The server then verifies the MAC address of the client and that the message can be trusted and decrypted (The field used for this would be a Client Certificate Request usually used by banking websites for authentication before providing sensitive information to the user). It then responds with a similar message, which the client decrypts using the key and verifies as well.

MITM using SSLStrip & Mitigation Methods

Page 3

The following is a Server Hello Message:

ServerVersion 3, 1

ServerRandom[32]

SessionID:

bd608869f0c629767ea7e3ebf7a63bdcffb0ef58b1b941e6b0c044acb6820a77

Use Cipher Suite:

TLS_RSA_WITH_3DES_EDE_CBC_SHA

Compression Algorithm:

NONE

The Alert Sub Protocol:

The connection terminates when a close_notify alert is issued. An attacker would be able to close this connection by injecting a FIN packet, but both parties would be notified of this occurrence. The handshake protocol contains event driven alert messages that either one of the parties can send. After the alert is issued, the session either ends or the client is given an option of session termination. Alerts are mentioned in RFC 2246. Check for list and details in Table 1.

The Record Protocol:

The record protocol receives data from the application layer and:

i) Fragments data into blocks or refragments data.

ii) Some attacks could be used to target data packets and reorder them. To defend against this, the record protocol numbers the sequence of data blocks.

iii) Used to encrypt or decrypt data using handshake generated encryption keys and algorithms.

iv) Applies an HMAC (MAC for SSL 3.0 onwards) for data integrity check. Every message is signed with a message authentication code (MAC).

Once all protocols have completed their operations, the packets are sent to the transport layer for transmission or in case of incoming data, packets are sent to their respective processes for reception.

MITM using SSLStrip & Mitigation Methods

Page 4

The Attack ARP Spoofing and SSL Stripping

Considered an active eavesdropping attack, there are multiple techniques which can be used while performing a Man-in-the-middle attack. Performing a successful MITM attack usually involves establishing a connection to the victim machine and the server with which the victim needs to communicate thereby relaying messages between both parties. The client and server are led to believe that they are communicating with each other whereas the communication pathway is redirected through the attacker machine who can not only intercept sensitive data, but can also inject and manipulate a data stream to gain complete control.

Several methods have come into existence with advancements being made in protocol usage, routing patterns and also, unprotected DNS servers. The following are the most commonly used MITM attack methods:

1) ARP Cache Poisoning

2) DNS Spoofing

3) HTTP Session Hijacking

4) Passing The Hash

In this paper, a highly innovative and effective MITM method known as SSLstrip shall be discussed. SSLstrip came into existence when an individual hacker by the name of Moxie Marlinspike introduced this concept during the BlackHat convention held at Washington D.C. in 2009. This network based attack allows a hacker on the same subnet as its victims to eavesdrop on all network traffic between victims.

To understand how this attack works, we first need to look at ARP Cache Poisoning which is the first step.

ARP Cache Poisoning:

How does ARP work?

The Address Resolution Protocol (ARP) is required to map the IP address of the client to its MAC address. The role of ARP depends on two packets, ARP request and ARP response. These packets are used to locate the MAC address associated with the given IP address so that traffic can reach its destination on a network.

In practice, the ARP request packet is sent to every host on the network with a message containing the transmitting devices (Usually the router) MAC address asking for the target host by displaying host hardware MAC. Once the intended host receives this packet, it responds with an ARP response packet stating its MAC address. Once this process is completed, the transmitting device would update its ARP cache table and a communication pathway is established between the device and the host.

Poisoning

ARP cache poisoning is possible because of the insecure nature of the protocol. Unlike a few other protocols such as DNS that are usually configured to only accept secured dynamic updates, ARP updates can be forced on any device at any given point in time. It is possible to force any device on a subnet to update its ARP cache even when it does not send a request. Sending an ARP response while no request has been made is known as sending a gratuitous ARP. These gratuitous ARP packets are used to confuse the host and transmitting device into thinking that they are securely communicating with each other, but in actuality they are communicating with a listening attacker.

MITM using SSLStrip & Mitigation Methods

Page 5

Normal Traffic Pattern:

Victim Router

Poisoned Cache:

Victim Attacker Router

---------------------------------------------------

ARP Cache Poisoning can cause:

i) Denial of Service

ii) MITM

iii) MAC Flooding (Switch-Hub conversion)

SSLStrip:

SSLStrip does not target vulnerabilities in the SSL protocol or the underlying cryptographic trust model itself but is intended to deceive an inexperienced user into using an insecure communication pathway. SSL, as explained before, works by creating a secure channel between the client and server. Suppose one needs to access gmail, he or she would simply type gmail in the search engine or type in www.gmail.com in the address bar. Most websites would redirect the user to an SSL enabled webpage login. This is where SSLstrip would intercept the redirect information and strip away SSL enabled features and send the user to

an SSL-disabled version of the website. Since data is already being routed through the attackers machine (ARP cache poisoning convinces the host that the attackers MAC address is the router's MAC address), the attacker can simply capture form data in plain-text format. Most users do not check for "HTTPS" or the padlock (Certificate Verification) on the browser.

The Operating System being used to carry out MITM in the following example is Kali Linux v 1.1.0 (Pre-installed with ARPSpoof and SSLStrip). 'WireShark' is a network protocol analyzer which can also be optionally installed for further traffic analysis.

Steps to be followed:

Enable IP Forwarding:

IP forwarding needs to be enabled (Most Linux distros do not have IP forwarding enabled by default) to allow traffic to flow through our machine.

This can be done by running the following command in a terminal:

echo '1' > /proc/sys/net/ipv4/ip_forward

IPTable Rules:

IPTable rules need to be added so that our machine understands how to handle and redirect incoming traffic to SSLstrip. The following command(rule) will redirect traffic originally intended for port 80(HTTP web traffic) and redirect it to port 8080 on which we will listen to incoming traffic.

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

HTTPS traffic uses 443, but interception and redirection is taking place at port 80 in this case. It needs to be understood that SSLstrip does not attack SSL itself, but the transition from non-encrypted to encrypted communication.

MITM using SSLStrip & Mitigation Methods

Page 6

Identification of Target and Gateway IP Address:

The next step would require us to know the subnet IP address of the victim and the gateway (usually, the router). A network mapping tool such as 'nmap' can be employed for this purpose.

For internal testing purposes, a ping-sweep of the subnet needs to be carried out. On a regular /24 network, the preferable command would be as follows:

nmap -sP -T4 192.168.1.1/24

Where 192.168.1.1 is the IP Address of the gateway.

ARP Spoofing:

First, we need to convince the victim that our MAC is the gateway MAC:

arpspoof -i <interface> -t <target IP> <gateway IP>

Then, we need to convice the gateway that our MAC is the victim MAC:

arpspoof -i <interface> -t <gateway IP> <target IP>

SSLStrip:

After installing SSLstrip(if not available by default), simply open a new terminal and type in the following command:

sslstrip -k -l 8080 -w /root/Desktop/sslstrip.log

-k : Kill - This flag will attempt to kill any current HTTPS sessions that the victim is using by setting expiry parameters on saved cookies and sessions. This would force the victim to reconnect to the website which makes it easier for us to capture the credentials.

-l : Listen - Port on which SSLstrip will listen to (8080).

-w : Write - Will write output to the specified file.

The output gets written to a file which we will call sslstrip.log.

SSLStrip will intercept the redirect first and request a new connection from the webserver. Then SSLstrip will strip all the SSL enabled features of this new connection and send the victim an HTTP version of the website. While traffic is being monitored, the attacker would look for references to HTTPS in the location headers and downgrades them to HTTP.

For e.g. < a href="https://www.example.com/"> is changed to < a href="http://www.example.com/"> before the victim receives the webpage.

All the HTTP requests that have been stripped from the victim’s machine are now proxied onto the server over HTTPS. This means, that the traffic between the victim and the attacker is in HTTP whereas the attacker communicates with the server over HTTPS on behalf of the victim. No HTTP rules are broken during this process and hence, browsers also do not throw out warnings. The only indicator would be the abscence of 's' after HTTP.

The setup is now complete. To be able to tail incoming traffic and view it in real time, we can use the following command.

tail -F /root/Desktop/sslstrip.log

This attack can also be used in combination with a few other tools such as 'urlsnarf' and 'driftnet'.

Open a new terminal and type:

urlsnarf -i <interface>

to be able to view connections to websites being made by victim machine.

In another terminal, type:

driftnet -i <interface> -S

to be able to view unencrypted images and to capture audio streams from victim machine.

MITM using SSLStrip & Mitigation Methods

Page 7

Mitigation Techniques The following are some of the notable mitigation methods to this specific attack:

1) Bookmarking HTTPS websites:

Once the HTTPS version of a website is bookmarked, the browser directly connects to the HTTPS version without relying on any HTTP login source.

2) Static ARP Tables:

Small networks could make use of static ARP tables to prevent ARP cache poisoning whereas large networks would require installation of tools such as arpwatch, xARP or arpalert to monitor network traffic for multiple MAC addresses assigned to each physical port of a switch.

Static ARP can be set up on Windows machines by typing 'arp -s' on the command prompt. This is a strenuos process and must be done under supervision or guidance but will achieve guaranteed results if configured with care. A tool named "ARPFreeze" makes this process easier.

3) HTTP Strict Transport Security (HSTS):

"HTTP Strict Transport Security (HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications

from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers."

The specification has been released and published as RFC 6797 (HTTP Strict Transport Security (HSTS)) by IETF.

Example of HSTS usage*:

Simple example, using a long (1 year) max-age:

Strict-Transport-Security: max-age=31536000

If all present and future subdomains will be HTTPS:

Strict-Transport-Security: max-age=31536000; includeSubDomains

If the site owner would like their domain to be included in the HSTS preload list maintained by Chrome (and used by Firefox and Safari), then use:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Also if the security of a connection is not ensured, the client receives an error message and is not allowed to access the site. This usually happens in the case of webpages which are served with self-signed certificates.

4) Only-SSL:

Websites must go entirely with SSL to prevent such attacks. However, it is not easy as it sounds. Though this method sounds like a valid option, designing webpages that run solely on HTTPS would be difficult. Websites usually allow caching of contents so that they can speed up loading time, but with HTTPS enabled completely, the website would run very very slowly because caching has been disallowed.

Server software can also be configured to make all authenticated content SSL only.

MITM using SSLStrip & Mitigation Methods

Page 8

5) A paper from George Mason University called

“Prototype System to Protect against SSL-Stripping Attacks” suggests SSLstrip attacks can be defeated by forcing secure HTTP traffic using a special proxy. It sits in-between users and a web-site to prevent network traffic from redirection and interception by a rogue proxy like SSLstrip.

The client-side tool needs to be installed on all hosts to be secured on the business’ or organization’s LAN, and the client’s browser will be configured to route all HTTP traffic through our system. As mentioned above, the routing of HTTPS traffic is not modified. Whenever the client host starts up, the client and server use public key encryption to establish a shared secret key.

When the user makes an HTTP request, the client tool generates a random number to prevent replay attacks, encrypts it along with the HTTP request using the shared secret key, and forwards them to the proxy server

(i) The proxy server stores the random number and forwards the HTTP request to appropriate web server

(ii). When a response is received, the proxy server computes a Hash-based Message Authentication Code (HMAC) of the response, using the HMAC-MD5 algorithm

(iv) The server then appends the HMAC and the original random number to the HTTP response, encrypts it all and sends it back to the client

(v) The client verifies both the HMAC and the random number

(vi) If both match, the message was not modified in transit. If they do not match, the tool alerts the user to possible tampering.

Also, using free security tools such as URLScan would notify users of any redirection or possible tampering of the data channel. In essence, human awareness and vigilance plays a vital role in trying to mitigate these attacks. SSLStrip has been bettered over the past few

months and right now is capable of bypassing even HSTS when combined with an NTP (Network Time Protocol) manipulation attack. I will discuss that in my next paper.

References:

http://simon.net.nz/articles/protecting-mysql-sql-injection-attacks-using-php/

http://www.slideshare.net/pankajkumarjha2010/20364810-networksecurityresearchpaper

http://security.stackexchange.com/questions/20803/how-does-ssl-tls-work

https://technet.microsoft.com/en-us/library/cc785811(v=ws.10).aspx

http://www.grin.com/en/e-book/170676/man-in-the-middle-attack-focus-on-sslstrip

http://robospatula.blogspot.in/2013/12/man-in-the-middle-attack-arpspoof-sslstrip.html

https://www.owasp.org/index.php/HTTP_Strict_Transport_Security