1521377 - universal Firefox Manipulation Through network.captive-portal

Status: RESOLVED DUPLICATE of bug 1479168

(Firefox :: Security, defect)

Description

[bo0od]

Attachment: eti1.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce:

This is an ISP level attack to users of FF, this is confidential , hope you resolve it with care.

There is no steps to produce it because its something happening due to bad configuration in FF.

Actual results:

Network captive portal is enabled in every FF 60.4.0esr (64-bit) i have tested , and there is one issue inside it:

it uses non-encrypted HTTP link:

http://detectportal.firefox.com/success.txt

The ISP that i have tested on , it can manipulate http requests and inject/redirect them to their own websites. So once someone visiting detectiveportal url it will redirect them to this for e.g:

https://onlineservices.etisalat.ae/scp/open/osdpages/billPayment.jsp?internetusername=john&ref=http://detectportal.firefox.com/success.txt

This is the bill request for one of the users.

How the ISP attacking every user of FF?

It seems that manipulating network.captive-portal url , it will request for users or showing them a message that there is something error in their network and they need to login to fix that (check the uploaded image) , and once the user click on that link it will redirect the user to where-ever they want the user to be redirected.

This is very dangerous manipulation , as if the ISP wanted to track or hard any user then it will redirect the user to a malicious URL leading to further attacking method.

Related manipulations of HTTP requests done by the same ISP and reported before:

https://github.com/QubesOS/qubes-issues/issues/4415

Expected results:

Disabling network.captive portal resolving the issue by following this guide:

https://support.mozilla.org/en-US/questions/1157121

But ofcourse every user of FF now in this danger.

Comment 1

[bo0od]

Please use always HTTPS with anything inside FF , encrypt all your traffics.

Comment 2

[:Gijs (he/him)]

Please do not alter the priority field. This isn't a release blocker.

In fact, I think all the arguments about this have already been discussed in bug 1479168, especially bug 1479168 comment 12:

(In reply to Nihanth Subramanya [:nhnt11] from comment #12)

1. Captive portals are a mess.

2. As Gijs has been saying, it's really hard (I'd even say impossible, on a
   philosophical level) to distinguish "good" MITM from "evil" MITM.

I don't see what we can reasonably do about this. Using https for the portal detection URL wouldn't make any difference here - the malicious ISP would just redirect with a fake cert, which is exactly what a "benign" captive portal would do.

Turning off captive portal detection for everyone because some Egyptian/UAE ISPs are being obnoxious doesn't seem like the right response. In any case, these ISPs could do exactly the same for any other URL the user accesses, so I don't really see how that would help even the users of those ISPs.

Unless Valentin and/or Nihanth disagree, I'd suggest removing the sec flag and duping to bug 1479168.

Comment 3

[bo0od]

Please do not alter the priority field. This isn't a release blocker.

sure sorry didnt noticed its for releases stuff.

Using https for the portal detection URL wouldn't make any difference here - the malicious ISP would just redirect with a fake cert, which is exactly what a "benign" captive portal would do.

Well actually using https resolved the problem of manipulation. There havent been records of manipulating ssl/tls connection.

Also leaving captive portal on its http state leading to two things:

• All the ISPs can do the same thing and use this flaw
• Any hacker can do the same thing since its possible to manipulate http easily anyway.

So this is super flaw for everyone in anywhere in the world, just because its recorded in middle east doesnt mean its not going to be used in any country.

Comment 4

[Valentin Gosu [:valentin] (he/him)]

I agree with Gijs. It is impossible for us to prevent ISPs from messing with HTTP requests, and using HTTPS for captive portal detection wouldn't work as some captive portals just block HTTPS until you are logged into the captive portal.

So, unless this poses a different security issue than "ISPs can intercept and modify HTTP requests", I say we dupe it to bug 1479168.

Comment 5

[:Gijs (he/him)]

(In reply to bo0od from comment #3)

Also leaving captive portal on its http state leading to two things:

• All the ISPs can do the same thing and use this flaw

This is just a scarier way of saying the same thing Valentin is saying:

(In reply to Valentin Gosu [:valentin] from comment #4)

"ISPs can intercept and modify HTTP requests"

If your ISP maliciously interferes with your network requests, switch to a different ISP. The browser can't do all that much to protect you from your own ISP (though DNS-over-https might help a tiny bit). An ISP would always be able to redirect to pages they control after http-downgrade/sslstrip for the first non-tls and/or non-hsts outgoing connection, and block all other outgoing traffic. The captive portal detection may present them an earlier opportunity for showing their own content than they would otherwise have had, but doesn't change the ultimate security impact of such an ISP, especially given the user would still have to go ahead and open the page by clicking the relevant button.

• Any hacker can do the same thing since its possible to manipulate http easily anyway.

They'd have to be actively man-in-the-middle'ing your connection, and if someone other than your ISP is doing that, you have bigger problems.

Comment 6

[(inactive) Nihanth Subramanya [:nhnt11]]

Seems like this was resolved; in any case I don't have anything to add at the moment. Thanks folks!