Intercepting SSL Traffic

4.7. Intercepting SSL Traffic

Until now we focused on non-encrypted traffic. This section will go into what is necessary to perform MitM attacks on encrypted traffic.

The most important thing to remember here is how encrypted and SSL Certificates work. Because there is a handshake involved in the SSL protocol, it may be possible to intercept, decrypt, read, re-encrypt, and resend data.

The most common issue you will encounter here is that if you use a tool that generates self-signed certificates, it will more than likely cause a security exception on the victims machine.

Most often than not, we can rely on most users to just bypass that warning. However, recent browsers security features make it much more difficult for users to bypass those errors without further interrogation.

Before studying more advanced techniques, let us see how we can configure some of the previous tools in order to intercept and analyze SSL traffic.

A few slides back, we saw that Ettercap was not able to analyze the clear text of a HTTPS connection.

This happens because with the default Ettercap configuration we do not manipulate the traffic, instead we just intercept it and forward it to the target machine.

What we need to do is to instruct Ettercap to create and use a fake SSL certificate that will be sent to the victim machine every time it tries to establish HTTPS connections.

If the victim user accepts the certificate, Ettercap will be then able to decrypt the traffic.

We can do this by editing a few options in the Ettercap configuration file.

Let us open the file `/etc/ettercap/etter.conf` and edit it as follows. At the very beginning of the file, let us change the `uid` and the `gid` to `0`.

Now, in the `redir_command_on/off` section, let us uncomment the following 2 lines. Notice that if you are using a different OS, you have to uncomment the correct lines in the files, according to the OS you are using.

Once we edit the Ettercap configuration file, we can run our ARP poisoning attack and start sniffing our victim traffic.

Now we should be able to intercept and read some of the HTTPS traffic too. Here Ettercap shows us that it was able to intercept some credentials: GROUP 2 : 172.16.1.10 00:0C:29:24:DD:54 HTTP : 172.16.1.1:443 -> USER:Login PASS: INFO:https://172.16.1.1/ CONTENT:__csrf_magic=sid%SD8FQ48GSDA8G8SD98ASD8F4SDFSA9FS9ADSDFS AS8DF78AS7F98ASF9AS89FSADF4ASFS98F7SD9F&usernamefld=admin&passwordfld=els&login=Login

It is important to know that whenever the victim tries to open a secure HTTP page, the browser will warn the user that the certificate in use is not correct.

4.7.1. SSHStrip

Although most of the users will confirm the certificate exception, enhancements in SSL attack tools have found ways to exploit SSL without the need to inject a self-signed cert.

At BlackHat 2009 Moxie Marlinspike introduced a new method for extracting information form a secure session by attacking HTTP. In order to demonstrate how this works, Marlinspike released a tool named sslstrip

The way SSLStrip works:

  1. Perform MitM attack on HTTPS connection between the victim and the server

  2. Replaces the HTTPS links with HTTP clone links and remembers the links which were changed

  3. Communicates with the victim client over HTTP connection for any secure link

  4. Communicates with the legitimate server over HTTPS for the same secure link

  5. The sslstrip attacker machine transparently proxies the communication between the victim and the server

  6. Favicon images are replaced with the known secure lock icon to provide familiar visual confirmations

  7. SSLStrip logs all traffic passing through. So, passwords, credentials, etc are stolen without the victim knowing.

By using these methods, the attacker is able to provide legitimate traffic to the client over an HTTP connection and provide visual feedback, such as the look icon, without getting the SSL Certificate errors normally associated with MitM attacks on SSL Traffic.

There are some issues that present themselves in this type of attack, for example:

  • Some content encoding, such as gzip, is difficult to parse

  • Cookies that are sent over HTTPS will not be sent over HTTP that has stripped the SSL

  • Any cached pages which did not have the links swapped out

In order to counter these shortcomings, SSLStrip actually strips parts of the requests for this information:

  • Stopping the secure bit on the Set-Cookies statements on the pages

  • Strip the difficult encodings from the client requests

  • Strip the if-modified-since headers to eliminate the cached pages being requested

By default SSLStrip uses port 10000 to listen for incoming connections, but we will instruct the tool to listen to a different port.

Moreover we also need an ARP spoofing tool in order to sniff the traffic from the victim. For the easiest and most reliable results, we will use Ettercap which already been discussed in the previous section.

The following are options that SSLStrip offers: Usage : sslstrip <options> Options:

  • -w <filename>,--write=<filename> Specify file to log to (optioanal)

  • -p , --port Log only SSL PORTs. (default)

  • -s , --ssl Log all SSL traffic to and from server

  • -a , --all Log all SSL and HTTP traffic to and from server

  • -l <port>, --listen=<port> Port to listen on (default 10000).

  • -f , --favicon Substitute a lock favicon on secure requests

  • -k , --killsessions Kill sessions in progress

  • -h Print this help message

In the next part we will use Ettercap to mount an ARP poisoning MitM attack and SSLStrip to capture the encrypted traffic. Before starting be sure to:

  1. Enable the IP forwarding:

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

  2. Set up port redirection using iptables

    iptables -t net -A PREROUTING -p top --destination-port 80 -j REDIRECT --to-port 8080
```

Step on SSLStrip:

  1. Now we can start SSLStrip and instruct it to listen on port 8080 Moreover, we use the -w option to save the logs into a specific file, but we also use the -f option to instruct SSLStrip to substitute the favicon on secure requests.

Our command will look like the following: sslstrip -a -f -l 8080 -w els_sslt

  1. The last step is to configure Ettercap in order to mount an ARP MitM attack between victim and gateway.

Once everything is up and running, we can move into the victim machine and execute a secure web session. In this case we will use a Windows Live login. As we can see, the URL contain HTTP and the favicon has been substituted with a lock icon.

Now, as soon as we try to log into the portal, Ettercap will display the request and credentials sent by the victim.

Similarly to Ettercap, other tools can also be used in conjunction with SSLStrip. Bettercap already implements SSLStrip, thus we can run the whole attack in just one command by using the --proxy-https option.

Let us suppose the target gateway is 192.168.102.2, while the victim is 192.168.102.135. Our command will be: bettercap -G 192.168.102.2 -T 192.168.102.135 --proxy-https As we can see in the tool output (see image), the https-proxy feature and sslstrip are now enabled. From this moment on, if the victim tries to open an HTTPS link, it will be automatically stripped down to HTTP.

Let us try to navigate some pages from the victim machine and see what we get in out terminal.

As we can see (see image), when the victim tries to load HTTPS page, such as `https://live.com`, ssltrip intercepts the request and strips down the request to HTTP. Notice that it does this for each link or request it finds.

Something that you will notice during your test is that this technique does not work anymore with some websites and with newer web browser. In the following screenshot we can see that opening the Facebook login page from Internet Explorer and Google Chrome gives our different results.

This happens because the HTTP Strict Transport Security (HSTS) policy mechanism in place. HSTS is a security enhancement specifies by the web application and that prevents the protocol downgrade from HTTPS to HTTP.

If the browser supports this features, it forces the communications t o HTTPS, by redirecting HTTP requests to HTTPS. Here you can see the list of browsers that support this feature.

It is important to know that this attack works fine if the victim tries the connection to the web site for the first time. This happens because the web browser does not know whether or not to use a secure connection, since it never received the HSTS header.

In order to defeat this issue, web browser implemented the so called (preload list)[https://code.google.com/p/chromium/codesearch#chromium/src/net/http/transport_security_state_static.json], which contain sites that have to be accessed with a secure connection, even if it is the first time.

Here you can find more references about HSTS and loaded lists:

4.7.2. HSTS Bypass (MITMf)

In order to (partially bypass this security feature, Leonardo Nve Egea) presented at (Black Hat 2014)[http://www.slideshare.net/Fatuo__/offensive-exploiting-dns-servers-changes-blackhat-asia-2014] a new version of sslstrip named (sslstrip+)[https://github.com/singe/sslstrip2]

Many MitM tools started implementing sslstip+ in order to bypass HSTS. The one we are going to see in this section is called MITMf

Before seeing the tool in action, let us get a better idea of how the attack works: In addition to the modified version of sslstip, we now need to run a DNS server too. In this way, we will be able to intercept and edit the victim's DNS requests, and bypass HSTS.

The following summarizes the attack in action:

  1. The victim goes to google.com (not in the HSTS preload list)

  2. We (attacker) intercept the traffic and change the links in the web page. For example, we change accounts.google.com to acccount.google.com (notice three 'ccc')

  3. The victim makes a DNS request for that domain acccount.google.com

  4. We intercept the request, forward the real DNS request and respond to the victim with a fake domain and the IP address

The victim web browser will now search if the domain should be accessed securely (HTTPS). This can be done by checking the HSTS preloaded list or by checking if the domain has already been visited, and then has the HSTS header already set (not expired)

Since the domain is different (it is acccounts with three 'c') the browser will continue the communication via HTTP.

If you want to know more about how the attack works, we suggest you watch the Black Hat 2014 talk here

Now that you know how the attack works, let us see how tools such as MITMf implements it and are able to bypass the HSTS security feature.

Once you install the tool, be sure to check the manual by running the python mitmf.py -h command (see image).

As you will see from the output, the tool offers a lot of options and plugins that allow you to highly configure your attacks. The options and plugins that we are going to use for our test are the following:

  • -i Interface to listen on

  • --spoof Load plugin 'Spoof' - This allows to redirect traffic using ARP, ICMP, DHCP, or DNS spoofing

  • --arp Redirect traffic using ARP spoofing

  • --dns Proxy/Modify DNS queries

  • --hsts Load plugin 'SSLstrip+'

  • --gateway Specify the gateway IP

  • --targets Specify host/s to poison (if ommited, default to subnet)

Example: In this scenario, the target IP address is 192.168.102.149, while the gateway IP address is 192.168.102.2.

In order to run our attack, our command will look like the following one: python mitmf.py -i eth0 --spoof --arp --dns --hsts --gateway 192.168.102.2 --targets 192.168.102.149

Now that the attack is working in the background, we can try to log into Google Services from our victim machine. We will use Internet Explorer in the first test. (See output on image)

The following is what we are able to sniff while trying to log into Google Services. We can see we are able to get the victim username (email) and password. (See image)

The following, instead, is the output that we obtain using Google Chrome on the victim. As you can see, the tool tries to change the domain name and uses wwww instead of www.

PreviousAttacking ToolsNextReferences

Last updated