Perform SSL Stripping with Wifiphisher's 'Without a Spoofer' Option

Introduction

SSL stripping is a type of Man-in-the-Middle (MITM) attack that forces a web browser to connect to a website over an unencrypted HTTP connection, even if the user intended to connect securely via HTTPS. This allows an attacker to intercept and read all the traffic between the user and the website.

In this lab, you will use the Wifiphisher tool to perform an SSL stripping attack. Specifically, you will explore the 'Without a spoofer' option, which relies on intercepting and modifying traffic without using a fake SSL certificate. This hands-on exercise will help you understand the mechanics of this attack in a controlled and safe environment.

Launch the Captive Portal Attack

In this step, you will launch the Wifiphisher tool to create a rogue Access Point (AP) and initiate a captive portal attack. Since the LabEx virtual environment does not have a physical wireless card, we will use specific options to simulate the attack.

First, open a terminal. We will run wifiphisher with sudo because it needs elevated privileges to manage network interfaces and services. We will use the --nojamming option to prevent it from trying to jam real WiFi networks and --essid "Free WiFi" to name our fake network. We also need to specify a captive portal scenario; we'll use firmware-upgrade.

Execute the following command in your terminal:

sudo wifiphisher --nojamming --essid "Free WiFi" -p firmware-upgrade

After running the command, Wifiphisher will start up. It will automatically detect your network interfaces. You may be prompted to select the interface for the AP and the interface for NAT. For both prompts, you can typically press Enter to accept the default choice, which is usually eth0.

You will see output similar to this as the tool initializes:

[*] Starting Wifiphisher 1.4GIT ( https://wifiphisher.org ) at 2023-10-27 10:00
[+] Timezone detected. Setting channel hopping to the appropriate regulatory domain.
[+] Selecting eth0 for the AP interface.
[+] Selecting eth0 for the Internet-connected interface.
...

When Prompted for SSL, Select the 'Without a spoofer' Option

In this step, you will configure the SSL stripping method for the attack. After the initial setup, Wifiphisher will ask you how you want to handle SSL/TLS-protected traffic. This is a critical choice that determines the nature of the man-in-the-middle attack.

Wifiphisher will present a prompt with two main options:

With a spoofer: This method generates a fake SSL certificate on the fly and presents it to the client. This often triggers a security warning in the client's browser.
Without a spoofer: This method attempts to downgrade the connection to plain HTTP without using any certificate. It relies on the client's browser not enforcing a secure connection.

You will see a prompt like this in your terminal:

[?] How do you want to handle SSL/TLS-protected traffic?
1. With a spoofer (Generate a fake cert on the fly and spoof the domain)
2. Without a spoofer (Downgrade to HTTP)
[1/2]:

For this lab, we are exploring the second option. Type 2 and press Enter.

After you make your selection, Wifiphisher will finalize the setup of the rogue AP and the captive portal. It will then be ready to accept client connections. The terminal will display messages indicating that the HTTP and HTTPS proxy servers are running.

[*] Starting the HTTP and HTTPS proxy servers...
[*] Starting AP...

Understand this Relies on Client Browser Vulnerabilities

In this step, we will discuss the mechanism behind the 'Without a spoofer' SSL stripping option. There are no commands to run here; this section is for your conceptual understanding.

The 'Without a spoofer' method is a more subtle form of attack. Here's how it works:

Initial Request: A victim connects to your rogue "Free WiFi" network. They open their browser and try to navigate to a secure site, for example, https://example.com.
Interception: Wifiphisher, acting as the gateway, intercepts this request before it reaches the internet.
Downgrade: Instead of trying to impersonate example.com with a fake certificate, Wifiphisher does something different. It forwards the user's request to the real https://example.com itself, but it serves the content back to the victim over a plain http:// connection.
Content Rewriting: Crucially, Wifiphisher scans the HTML content it receives from the real server and rewrites all links. Any link that was https://... is changed to http://.... This keeps the user within the unencrypted session for as long as possible.

This attack's success depends on two main factors:

The user not noticing that the browser's lock icon is missing.
The target website not using HTTP Strict Transport Security (HSTS). HSTS is a security policy that web servers can use to tell browsers that they should only be communicated with over HTTPS. If a browser has received an HSTS header from a site before, it will refuse to connect over HTTP, defeating this attack.

Connect a Client and Attempt to Browse to an HTTPS Site

In this step, you will simulate a client connecting to the rogue AP and attempting to access a secure website. In a real-world scenario, a victim would connect their device to the "Free WiFi" network. Here, we will simulate this using the curl command in a new terminal.

First, open a new terminal tab. You can do this by clicking the + icon in the terminal panel. This new terminal will act as our "victim client".

In this new terminal, we will use curl to try to access an HTTPS site. We will use httpforever.com, a site designed for testing purposes that does not enforce HSTS. The -v (verbose) flag will show us detailed information about the connection process.

Execute the following command in the new terminal:

curl -v https://httpforever.com

Because Wifiphisher is controlling the network, this request will be intercepted. Instead of reaching the real httpforever.com, it will be handled by our attack tool.

Observe if the Connection is Downgraded to HTTP

In this step, you will observe the results of the attack in both the client and attacker terminals to confirm that the connection was successfully downgraded.

First, look at the output in your client terminal (where you ran curl). The verbose output will show that your request to https://httpforever.com resulted in a redirect. You will see a 302 Found status code and a Location header pointing to an HTTP address, which is the captive portal page.

The output will look something like this:

*   Trying 10.0.0.1:443...
* Connected to httpforever.com (10.0.0.1) port 443 (#0)
...
< HTTP/1.1 302 Found
< Location: http://10.0.0.2:8080/
< Content-Length: 0
< Date: Fri, 27 Oct 2023 10:05:00 GMT
< Server: Python/3.10 aiohttp/3.8.5
...

Notice the Location header redirects you to an http:// address. This confirms the downgrade.

Next, switch back to your first terminal where wifiphisher is running. You will see new log entries showing that a client has connected and that its requests are being handled. It will log the HTTP GET request from the simulated client.

[+] 192.168.1.100 victim-device connected to Free WiFi
[*] Sent a captive portal page to 192.168.1.100
[+] GET 192.168.1.100: http://httpforever.com/

This confirms that the attacker is successfully intercepting the traffic in plain text.

To finish the lab, stop the Wifiphisher tool by switching to its terminal and pressing Ctrl+C.

Summary

In this lab, you successfully demonstrated an SSL stripping attack using the 'Without a spoofer' option in Wifiphisher.

You learned how to:

Launch Wifiphisher to create a rogue AP for a captive portal attack.
Select the 'Without a spoofer' SSL stripping method.
Simulate a client connection using curl in a separate terminal.
Observe the evidence of the connection downgrade from HTTPS to HTTP by analyzing the output from both the client and the attacker's tool.

This exercise highlights the importance of security mechanisms like HSTS in protecting against such downgrade attacks. Congratulations on completing this lab!

Use the 'Without a Spoofer' SSL Stripping Option