Closed Bug 1689192 Opened 4 years ago Closed 4 years ago

Redirect http://https:// to malicious website

Categories

(Fenix :: General, defect)

Unspecified
Android
defect

Tracking

(firefox86 wontfix, firefox87 fixed, firefox88 fixed)

RESOLVED DUPLICATE of bug 1643789
Tracking Status
firefox86 --- wontfix
firefox87 --- fixed
firefox88 --- fixed

People

(Reporter: ginobiervliet, Unassigned)

References

Details

(Keywords: reporter-external, sec-low, Whiteboard: [reporter-external] [client-bounty-form] [verif?][adv-main87-])

This is not a obvious bug. Maybe just a simple if statement that needs to be fixed?

When navigating to a url using the http prefix following an extra https prefix (e.g. http://https://mozzila.org) you will be redirected to https://https.com. https.com will redirect you to a malicious site. In the Netherlands I get an advertisement with false bitcoin statements. This is a phishing site. Sometimes it will redirect to http://iyfnzgb.com which is blocked by the ISP for being malicious.

Steps to reproduce:

I found this error while browsing a personal medical page (mijngezondheid.net). They have a link that looks normal but (probably because of an error in their CMS) it anchored to http://https://www.serviceapotheek.nl/lindeholt.

I have tried to reproduce it in other internet browsers but I could only reproduce it in FireFox.

I can reproduce this on multiple devices

  • 2x macbook pro 2018 with big sur (FireFox version: 84.0.1 (64 bit version)
  • Huawei p30 pro with Android 10 (84.1.4)
  • and multiple windows devices (unknown specs)
Flags: sec-bounty?

This is odd. When I try Firefox, Chrome, and Safari on my Mac I get essentially the same behavior: the "//https:/" in the middle is parsed as a domain with an emptystring port, which is odd but appears to be allowed by the spec (==default port). I then get the equivalent of "server not found" for the domain "https" on all three browsers.

Since there is no terminating dot (e.g. https.) in theory my local resolver could apply a default assumed domain, like ".com". I have seen ISPs try to be "helpful" and correct an domain lookup that fails ("no TLD? probably meant .com"). But then I would expect you to see that consistently with other browsers on the same network/ISP as well.

I have seen cases when entering URLs directly into the addressbar where something like this happens. Due to a typo that makes the string an invalid URL it gets interpreted as a "search", and back in the day Google would sometimes take people to the "best" match directly rather than show search results if it was certain enough. Or maybe it was a setting to do that, can't remember. Anyway, typo-ing "http;//something.com" (note semi-colon" could send you to https.com, which back then also tended to redirect to "interesting" places. That can't be this case, though, because that didn't apply to links, and Google isn't doing the "I feel lucky" behavior any more (they want the search ad money?).

If it were just the one device I'd ask about your web extensions -- it could be you have a search hijacker in there. But that wouldn't explain the same behavior on your Android device. Still worth checking, though.

Steps to reproduce:

I get the expected "We can’t connect to the server at https." error page. Not sure what the next steps should be from here since I don't see a problem in Firefox. Can you open the Network tab in Dev Tools before following the link and see what domains it's attempting? For me I see a request for "https" that just stops. Maybe you've got a more local https that is sending you a redirect? Then try the same thing in Chrome with their dev tools and see what's different about it.

(note: I can definitely confirm that https.com is an redirector. All the attempts I've tried end up blocked by uBlock Origin (adblocker) so I don't know if the site is just a cash grab redirecting to low quality ads (some of which are malicious) or if it's actively malicious itself. I don't know why https.com itself isn't blocked.)

Flags: needinfo?(ginobiervliet)

Pretty sure this is a duplicate of bug 1643789. The "correction" only happens for middle clicked links for some reason.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Flags: needinfo?(ginobiervliet)
Resolution: --- → DUPLICATE

Oh, though perhaps it's worth keeping this open for android? I don't know what they do here, and the other bug is desktop-only.

Group: firefox-core-security → mobile-core-security
Status: RESOLVED → REOPENED
Type: task → defect
Component: Security → Security: Android
Ever confirmed: true
Product: Firefox → Fenix
Resolution: DUPLICATE → ---

We use a regex currently :-/. Probably depends on bug 1685152 being fixed so that Fenix can normalize URIs consistently with Gecko expectations.

Similar to bug 1670725

I've tried looking at the network data in FireFox and Chrome. it looks like FireFox changes http://https://testing.nl to http://https.com//testing.nl Chrome doesn't.

Chrome removes the second ":" while Firefox replaces it with ".com". Strange huh?

(In reply to ginobiervliet from comment #5)

I've tried looking at the network data in FireFox and Chrome. it looks like FireFox changes http://https://testing.nl to http://https.com//testing.nl Chrome doesn't.

Chrome removes the second ":" while Firefox replaces it with ".com". Strange huh?

So the first step is that everyone removes the colon - as indicated in comment #1 this is standard URL parsing behaviour (you can try going to https://mozilla.org:/ - it will just load the actual mozilla.org website without any issue). So both Chrome and Firefox end up with http://https//testing.nl. Chrome stops there because there is no https server (unless one exists on your network, or your ISP redirects, as indicated in comment #1.

At least on desktop Firefox, when the DNS lookup for https indicates there is no such server, the switch from https to https.com is a function of "alternate" fixup (controlled in about:config via browser.fixup.alternate.enabled). It's a very old behaviour that was used so you could just type "google" and hit enter and go to google.com (before searching with a search engine directly from the address bar was a thing, or when users disabled that for privacy reasons). This behaviour shouldn't be applied for link clicks (and at least on desktop, I only see it happening for middle clicks, not for "normal" left-clicking a link).

The patch I'm about to put up in bug 1643789 fixes the desktop issue, but I suspect it may fix the android one, too - I'm just not in a position to check.

Keywords: sec-low

(In reply to :Gijs (he/him) from comment #7)

The patch I'm about to put up in bug 1643789 fixes the desktop issue, but I suspect it may fix the android one, too - I'm just not in a position to check.

:kbrosnan, when fenix picks up the m-c changes from bug 1643789 (landed just over 2 days ago), can you check if this is fixed on fenix nightly?

Flags: needinfo?(kbrosnan)

It now fast fails to the network error page using an up to date Nightly. In 85 I see the network timeout page for http://https//testing.nl and http://https//mozilla.org

Flags: needinfo?(kbrosnan)

It looks like it is fixed now. Tested it on macbook and Android device.
Both are in a loading state when trying to navigate to http://https://test.com and timeout eventually.

Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED
Depends on: 1643789
Group: mobile-core-security
Flags: sec-bounty? → sec-bounty-
Resolution: FIXED → DUPLICATE
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][adv-main87-]
Component: Security: Android → General
OS: Unspecified → Android
You need to log in before you can comment on or make changes to this bug.