sslstripping is missing on the 2.x version

[lvlrt]

I'm missing the sslstrip functionality? Downgrading HTTPS and HSTS is not on by default?

[ghost]

You can do it by running regular sslstrip simultaneously with proper setup of port forwarding and arp.spoof module. P.S. I would be great to have GO version of sslstrip though.

[lvlrt]

The previous bettercap version had a fully functioning sslstrip+ and reverse dns server built in. Don't get me wrong, I use the tool a lot, I want to brag about the new version even more if it would have ported this previous functionality also!

[evilsocket]

sslstripping was not ported to this new version for one simple reason: HSTS ... I don't know your usecases, but in mine sslstrip doesn't work 99% of the times. Is there a good reason to put efforts on that?

[lvlrt]

I use your tool in demos on HTTPS and HSTS. It downgrades 70 procent of my clients sites. It is a great tool to batch-check sites if they are compliant and get awareness up..

I use the legacy version for the time being, but better performance is always nice.

[evilsocket]

Good point actually ... ok, I'll work on it :) it's not that complicated anyway :)

[lvlrt]

For you it is not. You are awesome dude! :p

[evilsocket]

@larsveelaert feature has been implemented and merged into master, it is enabled by default for both http.proxy and https.proxy modules, would you mind testing it a little bit? :)

[leonardoporpora]

I will test it too.

[lvlrt]

It would be an honor

[ghost]

@evilsocket As for me no HSTS bypass and HTTP is being redirected to https. Log says Sending expired cookies
Website for test was http://m.vk.com with http.proxy on

[evilsocket]

@alexmozzhakov I asked @larsveelaert because I need his specific use cases, HSTS is not supposed to be bypassed anymore so as far as I'm concerned your comment is intended behaviour.

[ghost]

@evilsocket regular sslstrip stays on http version. sslstrip+ gives redirect to webm.vk.com PS "specific use cases"? wtf

[evilsocket]

@alexmozzhakov if your browser already cached the HSTS rule for vk.com that's not gonna work

[ghost]

@evilsocket That's why I do it in private mode, omfg

[evilsocket]

@alexmozzhakov I don't remember asking your help for this feature, what's the omfg about?

[ghost]

@evilsocket stop being a dick. U put 👍 to leonardoporpora and didn't say anything to him, so why being rude to me?

[evilsocket]

@alexmozzhakov

Regarding the PS "specific use cases"? wtf:

It downgrades 70 procent of my clients sites.

I was having a conversation with a specific user and asked him to debug this feature with his specific use cases (since he was the one to ask this feature to be ported in the first place).

I'm being "a dick" because this is not the first time you jump in and just give random feedback nobody asked. I politely explained why the feedback is not useful:

I need his specific use cases, HSTS is not supposed to be bypassed anymore so as far as I'm concerned your comment is intended behaviour.

And still you kept adding comments and noise to the whole conversation.

Regarding @leonardoporpora he offered to help, still did not add any noise or unsolicited feedback so i have no reason to pick on him as I'm doing on you.

Not my fault if you just don't seem able to understand what you're supposed to read before talking.

[ghost]

@evilsocket Well, I'm pretty much concerned that such behavior is unintended, that's why I write it. I'm not talking about preloaded HSTS website. I've already written about sslstrip and sslstrip+ behaviors in same conditions. Seems like it's not good enough for you and u just want to take me stupid. Ok, whatever.

[evilsocket]

Regarding That's why I do it in private mode, omfg, most browsers cache HSTS rules on a per-domain basis regardless if you're in incognito mode / private mode, so you're assumption is not just rude, but it's also wrong.

Seems like it's not good enough for you

Yes, exactly, a couple of unsolicited log lines about a use case I'm not interested at the moment is defenitely not good enough, so please stop.

u just want to take me stupid.

I already wasted too much time explaining why you're wrong, I won't anymore, next time i'll just ban you from this repo.

[lvlrt]

Let's get this conversation to a constructive point again please; First testing seems good. I tested the 2 side by side.

• Performance improvement on throughput, great.
• HTTPS sites get downgraded
• Some sites that used to be downgraded (HSTS-level?) with a change in dns, respond differently (ex. norton.com)

Commands used for both versions: Legacy version: sudo bettercap -T 10.3.2.232 -I en8 --proxy Awesome version: sudo bettercap-ng -iface en8 -eval "set arp.spoof.targets 10.3.2.232; http.proxy on; https.proxy on; arp.spoof on"

Note: Tested on a single target, will continue testing in a controlled enviroment with multiple targets for a measured throughput difference/issues on scale

[evilsocket]

@larsveelaert I'd be great if you could indicate me some HTTP page against which the old implementation of th sslstrip still works, so I can compare until I get it working.

[evilsocket]

Meanwhile :D

[leonardoporpora]

Omg 😎🔝👍 really GJ

[evilsocket]

since we have the basic functionality I'll close this issue to signal it has been implemented, guys feel free either to keep writing here or open new issues if bugs n stuff come out, thanks for the feedback and help ^_^

[lvlrt]

I agree, basic functionality is there, so we can improve from here. Did you change anything in regards to the HSTS? (I gave as example norton.com).

Will investigate further now

[lvlrt]

Just realized I forgot the embed the info about norton.com in my original comment. My apologies sir

[lvlrt]

Redownloaded from source. Behavior on "norton.com" is different. New version:

Old version:

[evilsocket]

@larsveelaert what is the page which originally contains norton.com https link?

[lvlrt]

I just type in a couple of domains, manually typing "norton.com" into the addressbar will give different results in favour of the old version

[lvlrt]

Were you able to confirm this behavior / locate the issue?

[evilsocket]

@larsveelaert not really, given I just don't use this feature I'll leave it as basic as it is until either I'll have more requests or someone more interested than me will send a PR :)

[ghost]

I've captured regular (302 redirect) vs sslstrip (http) and http.proxy (https) behavior. Hope this will help understand what's going on and fix an issue. If not, I'll try fixing it myself because despite that this version is very good. http.proxy regular_vs_sslstrip

[lvlrt]

Checked this behavior on the sites I was targeting, and I think you are right. They all start with a redirect (301 or 302).

[ghost]

Digging a bit deeper, currently, bettercap doesn't do sslstripping for links, which begin with http:// For example, example.com website links to http://www.iana.org/domains/example, but then iana redirects to https version, so relying on an http:// link isn't just enough. As for HSTS bypass it could be replaced by wwww (or wwwww), so I tried changing link regex to https?://[^"'/]+, but I got [err] Could not resolve http://www.iana.org: lookup http://www.iana.org: no such host (-debug option gives the same output which is related to an issue) @evilsocket could you please try to address an issue, given the information above?

[lvlrt]

@alexmozzhakov Would handling the redirect (3**) solve the complete issue? I've been thinking about writing a filter to handle it myself but haven't got around doing it.

Did you find cases where the HSTS bypass did not work? (was unclear from your previous post)

[evilsocket]

If that's the probelm, I believe here a check should be added, if the response is a 3** redirect to a HTTPS url ( by inspecting the Location header ), that url needs to be stripped as well like others found in HTML pages.

[ghost]

@evilsocket yes, I was able to get to this part of the code but haven't looked for a Location header yet. I was stuck thinking that it gets into a response body and should've been anyway replaced. I will try to address it by inspecting Location header, as you've told. Thanks 🙇. @larsveelaert As I already told, HSTS it could be bypassed by adding wwwww to a link, but http links don't get parsed, which, I guess, should be fixed too. I will try to handle redirects and see if it works.

[lvlrt]

@alexmozzhakov Awesome, I'm going to practice my Go-skills so I can contribute to the project

[ghost]

@evilsocket I'm still getting [err] Could not resolve m.vk.com/: lookup m.vk.com/: no such host The code I've tried:

    urls := make(map[string]string, 0)
    if res.StatusCode == 301 || res.StatusCode == 302 {
        log.Info("[%s] Stripped redirect to %s", core.Green("sslstrip"), core.Bold(res.Header.Get("Location")))
        var strippedRedirect = s.processURL(res.Header.Get("Location"))
        urls[res.Header.Get("Location")] = strippedRedirect
        res.Header.Set("Location", strippedRedirect)
    }

The website is being redirected to wmobile.vk.com, as expected, but no data spoofing done, so I get 404. Any suggestions?

PS. As for example.com example, seems to work, but not as well to others links on the iana website. While an output looks like

[sys.log] [err] Could not resolve https://www.iana.org/domains/reserved: lookup https://www.iana.org/domains/reserved: no such host
[sys.log] [inf] [sslstrip] Replacing host wwwww.iana.org with www.iana.org in request from IP:PORT
[sys.log] [inf] [sslstrip] Replacing host wwwww.iana.org with www.iana.org in request from IP:PORT
[sys.log] [inf] [sslstrip] Replacing host wwwww.iana.org with www.iana.org in request from IP:PORT
...

[evilsocket]

You also have to patch the Host header back to its original, dude just check the rest of the logic

[ghost]

@evilsocket Since I've added it to urls, like so urls[res.Header.Get("Location")] = strippedRedirect it should be added, and as u may see it does, for instance, replace host wwwww.iana.org with www.iana.org, but somehow DNS lookup fails. Could you help, please?

[evilsocket]

The host also needs to be added to the HostTracker in order for the DNS resolution of the stripped domain to work.

The idea is:

1. Strip a domain to something.domain.tld
2. Add something.dmain.tld to the HostTracker for resolution.
3. Check Location header and patch it if needed.
4. At this point, all DNS requests to something.domain.tld will be handled by the DNS resolver of the module itself.

[ghost]

@evilsocket The thing is, you do track to range urls, and by the time I've added it to urls already (You can see it in the code above)

[evilsocket]

Dude, I linked you the code, you need to do this, not just adding it to urls ...

[ghost]

@evilsocket you do "this" inside

    for url, stripped := range urls {

But ok, I will try anyway.

[ghost]

@evilsocket Nope still returns Could not resolve https://www.iana.org/domains/reserved: lookup https://www.iana.org/domains/reserved: no such host

[ghost]

What I did was

    urls := make(map[string]string, 0)

    if res.StatusCode >= 301 && res.StatusCode <= 308 {
        log.Info("[%s] Stripped redirect to %s", core.Green("sslstrip"), core.Bold(res.Header.Get("Location")))
        strippedRedirect := s.processURL(res.Header.Get("Location"))
        originalRedirect := res.Header.Get("Location")
        s.hosts.Track(originalRedirect, strippedRedirect)
        urls[originalRedirect] = strippedRedirect
        res.Header.Set("Location", strippedRedirect)
    }

here

[evilsocket]

@alexmozzhakov again, I'm not interested in developing this feature further than this as I already explained. This means I'm not investing time or efforts in it, because I'd rather invest it in other, IMO more important features.

You're basically asking for an interactive, one on one debug and coding session (since a few days now), don't push me to be rude as usual, understand what I'm saying and respect it.

[evilsocket]

@alexmozzhakov check this last commit, it's a start but needs some debugging and fixing.

[ghost]

@evilsocket thanks so much. as for now, it doesn't seem to work as expected. I will compare your changes to my local GIT repo and try to work it out.

What I also think is that the redirect change should be done by checking whether Location is empty, not by response code (for whatever strange server response configs, it also may not work with clients3.google.com/generate_204, for example, as expected). In addition, 201 response uses location header for a different reason, according to RFC 7231 and it can cause some problems https://github.com/bettercap/bettercap/blob/ea31346e3e700858fa755c7638d1db1d0aba6498/modules/http_proxy_base_sslstriper.go#L327 That's why I argue it should be the != 201 check.

I will refactor the code and submit the PR as soon as it will be stable enough for general usage.