Skip to content

Instantly share code, notes, and snippets.

@nu11secur1ty
Last active October 18, 2023 08:39
Show Gist options
  • Save nu11secur1ty/7ee72b357df574703ba4289d5af32b27 to your computer and use it in GitHub Desktop.
Save nu11secur1ty/7ee72b357df574703ba4289d5af32b27 to your computer and use it in GitHub Desktop.
HTTPS and HTTP spoof by ettercap

Why some (major) HTTPS websites cannot easily intercepted

This Wiki page is intended to answer a question, that is raised with increasing frequency.

The issue

Ettercap has three possiblities to try to sneak into HTTPS secured websites

  1. HTTPS interception (should dedicate a Wiki page for that as well)
  2. HTTPS stripping (sslstrip plugin)
  3. DNS spoofing and redirection to an own webserver

The problem is, that with some (and especially the famous ones) none of those techniques work except if one condition can be satisfied:

>>>> Present the browser with a valid certificate for the requested DNS name! <<<<

But that isn't easy in public, since it may be hard to convince a accepted CA issuing a certificate where you cannot prove that you're not the true owner of the domain and website. An exception to that, are Enterprises that are maintaining an own internal PKI their own clients/browsers (have to) trust.

Background

There are multiple enhancement standards that have been developed and experience a increasing adoption rate, whose target is to make a SSL interception for MITM impossible or at least very hard:

  • HTTP Strict Transport Security, a.k.a. HSTS (defined in RFC6797)
  • HTTP Public Key Pinning a.k.a. HPKP (defined in RFC7469)
  • DNS-based Authentication of Name Entities a.k.a. DANE (RFC6698 and RFC7671)

In this Wiki page, I'm just focussing on the first - HSTS, since this is the most case of the described issue.

The goal of HSTS is, that administrators of a secure webserver have a way to instruct the client (browser) to only use HTTPS for future connections. It provides a way to signal the browser through special HTTP response headers, that for a certain life-time, browsers must apply security (HTTPS). Even when the user types in the addressbar http://www.website.com, the browser internally makes the http:// to https://.

Another important part of the concept is the no-user-recourse. What's meant by that is, that the browser forbids the user to circumvent the security warning in case of a invalid certificate. It will not be possible for the user, to "add" or "accept" a exception. That means, if you cannot provide a valid certificate to the browser that has been instructed for HSTS, TLS handshake won't ever complete.

You may have seen two issues with that.

  1. The browser must support this standard, but only very old and unpopular browsers do not yet support this.
  2. The first attempt using HTTP trying to redirect to HTTPS and signaling the HSTS HTTP header is the weakness. If you are able to intercept this moment, HSTS isn't yet effctive, and user-recourse is still possible.

But there is a little caveat with that: The most famous browser maintain a build-in list of domain-names that are considered for HSTS by default. You guess what:

  • facebook.com
  • youtube.com
  • google.com
  • many others

Conclusion

1. HTTPS interception

If the browser doesn't allow for user-recourse, the browser forbids to proceed (if the intercepted HTTPS stream presents a self-signed or just untrusted certificate). The only way around this is to on-demand sign by a CA-certificate that the browser trusts. This can be provided to ettercap using the --certificate and --private-key parameter.

2. HTTPS stripping

This plugin relies on HTTP connections, to suppress attempts to upgrade to HTTPS through links or redirects. However, once a browser is briefed for HSTS or build-in, the browser never attempts to open a connection using HTTP - it will attempt HTTPS only.

3. DNS spoofing

DNS spoofing acts on a different stage. Spoofing the forged DNS reply most probably works out, but if your fake webserver isn't able to present a certificate that the browser trust, you're back with number 1.

Look ahead

I've not yet found a reliable way to circumvent this. Let me know when you have an idea.

@svarogaden
Copy link

I don't want to downgrade HTTPS to HTTP. How to use a self-signed SSL certificate in Ettercap?
how to do it ?

@nu11secur1ty
Copy link
Author

@svarogaden
Copy link

I ran Ettercap in spoof mode, but it doesn't work.
Redirect doesn't work.
the browser loads the original page, not the phishing page
Here is the program log:

34 plugins
42 protocol dissectors
57 ports monitored
28230 mac vendor fingerprint
1766 tcp OS fingerprint
2182 known services
Lua: no scripts were specified, not starting up!
Starting Unified sniffing...

Randomizing 255 hosts for scanning...
Scanning the whole netmask for 255 hosts...
7 hosts added to the hosts list...
Host 192.168.0.1 added to TARGET1
Host 192.168.0.30 added to TARGET2
Activating dns_spoof plugin...

ARP poisoning victims:

GROUP 1 : 192.168.0.1 3C:ED:FB:45:19:54

GROUP 2 : 192.168.0.30 A9:5E:75:11:24:46
dns_spoof: A [site.com] spoofed to [192.168.0.233] TTL [3600 s]
dns_spoof: A [aa.google.com] spoofed to [192.168.0.233] TTL [3600 s]

@nu11secur1ty
Copy link
Author

You must check whats updated in Ettercap =)
Sorry about that, I don't have enough time...
KR

@slavadba
Copy link

I've not yet found a reliable way to circumvent this. Let me know when you have an idea.

Did you check this advices?
Ettercap/ettercap#765 (comment)

@faidfadjri
Copy link

when we using managable switch let say mikrotik for example is it can be protect from MITM ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment