1904885 - (CVE-2024-10004) Firefox (iOS) shows https padlock while connecton is http

Status: VERIFIED FIXED

(Firefox for iOS :: Browser, defect)

Description

[Erik van Straten]

Attachment: Firefox (iOS) shows https padlock while connecton is http - screenshots.zip

Steps to reproduce:

1. In Firefox: open at least one tab with an https connection (example: https://mozilla.org)
2. CLOSE Firefox (don't close the tab(s) beforehand)
3. Open an http link (*) in an email, share an http link from another browser to Firefox, or create a shortcut with an http link on your home screen and tap it

(*) Examples: http://http.badssl.com or http://www.example.com

Actual results:

Firefox starts and opens a new tab showing a padlock WITHOUT strike through, as if the connection is using https (server-authenticated and encrypted).

See the screenshots attached to further clarify things.

(I noticed this while -deliberately- clicking on an http phishing link, and was surprised that the padlock suggested an https connection; tapping the paddlock showed info it was actually http).

It affects Firefox v126 for iOS as well. This bug does not show up in Safari.

Expected results:

The padlock should have been shown with a red strike through.

P.S. PLEASE add a "HTTPS Only" setting (preferably ON by default) to FF for iOS (Chrome can do it; it would make FF better than Safari because the latter does not have this option).

Comment 1

[Erik van Straten]

Attachment: 00_Firefox_(iOS)_shows_https_padlock_while_connecton_is_http.png

This screenshot is also included in the ZIP file; it is intended to clarify things quickly

Comment 2

[Erik van Straten]

You can also contact me here: https://infosec.exchange/@ErikvanStraten

IMHO this is a security bug. It could be used by (local) attackers who know that a user is using Firefox on iOS (iPadOS and MacOS were not tested by me) by sending an email with an http link (possibly displayed as an https link) in order to conduct an AitM (Attacker in the Middle) attack. If that is a link to a well-known site that does not (correctly) support HSTS, then such an attack may easily succeed.

It does not seem to be something that will be exploited remotely often (as attackers can easily obtain free https server certificates anyway).

Comment 3

[Erik van Straten]

Just tested Firefox v127.0 (42448) on an older iPad with iPadOS v16.7.8 (up-to-date): same buggy behavior.

Comment 4

[Erik van Straten]

Edited bug: I had accidentally selected Firefox FOCUS for iOS, my apologies: it should be Firefox for iOS.

Unfortunately, now I can't change the Firefox version in the bug.

However, it teproduces in v127.0 and v127.1 (I just updated to that version.

Note: this bug probably does not apply to Focus because it automatically closes all tabs when one closes that browser.

Comment 5

[Erik van Straten]

The issue I described reproduced a few hours ago on an iPad air (iPadOS 17.5.1) with Firefox for iOS freshly downloaded from the Apple App store (I didn't check the version, but presumably it's 127.1).

Comment 6

[Daniel Veditz [:dveditz]]

Agree this should be treated as a security bug.

This rings a bell. Matt: do we already have a bug covering this issue?

Comment 7

[mreagan]

Possibly related to https://bugzilla.mozilla.org/show_bug.cgi?id=1843467

Comment 8

[Daniel Veditz [:dveditz]]

I don't think so; the technique in bug 1843457 continues to show the OLD content, with a new spoofy URL. In this bug the new content DID load (you can see the badssl.com background in the screenshot), the new URL is shown, but the scheme is not what we loaded.

I'm not even sure how we could get that wrong. We do NOT have any "https upgrade" feature in iOS so why would we change the URL we're given after a navigation event from the webview?

CLOSE Firefox (don't close the tab(s) beforehand)

do you really mean "CLOSE" as in shut-down? Or are you just switching to another app? The latter is really common, but how often do people completely close firefox? I guess the OS kills us all the time under memory pressure so maybe the repro steps are just an artificial way to simulate that common condition.

Comment 9

[Erik van Straten]

@Daniel: close Firefox (on iOS) as in swiping the app off screen.

Reasons: I don't like to have many apps open simultaneously, and closing apps causes various (security) things to reset (*).

(*) For example, consider this: in Firefox for Android I have enabled "https only". I open http://http.baddssl.com (at home, a trusted network), manually grant http-permission, then close THAT TAB (not Firefox).

Now I leave my house and use an untrusted network elsewhere. If I now reopen http://http.baddssl.com, it will show the red page - no questions asked.

However, if I close and reopen Firefox in between, it will have forgotten the http exception that was made. And I will be reminded that I'm opening an http connection on an untrusted network.

Also, if I log in to https://security.nl (I'm a regular contributor to that site, otherwise not related to), and close Firefox, I'll be logged out. I like that.

I recently found a couple of bugs in Chrome (for iOS and for Android) related to "https only" that may interest you, see the second half of http://http.baddssl.com

Best regards, Erik

Comment 10

[Erik van Straten]

(In reply to Erik van Straten from comment #9)

I recently found a couple of bugs in Chrome (for iOS and for Android) related to "https only" that may interest you, see the second half of http://http.baddssl.com

My apologies, the last link should have been https://infosec.exchange/@ErikvanStraten/112722589946395167

Comment 11

[Erik van Straten]

Bump: not fixed yet in Firefox for iOS v129.1 (44281).

Has anyone been able to reproduce this?

Comment 12

[Erik van Straten]

I'm going to ask public attention for this vulnerability this coming weekend (a vuln. that has not been resolved). I plan to add at least one attack scenario.

BTW [e-mail] seems to have requested information, but such a request is nowhere to be seen (a least not for me).

Comment 13

[Erik van Straten]

See https://infosec.exchange/@ErikvanStraten/113181487823109378

Comment 14

[mreagan]

Hi Erik, I'm currently investigating a fix for this on iOS, though I'm a bit confused on one point: is this attack also able to spoof the destination URL in the newly-opened HTTP website in Firefox's address bar? In my testing so far it doesn't appear that is the case, and Daniel's comment also appears to indicate the same (unless I'm misunderstanding):

in this bug the new content DID load (you can see the badssl.com background in the screenshot), the new URL is shown, but the scheme is not what we loaded.

This is obviously a bug that needs to be fixed, however to me this seems exceedingly impractical to leverage as an attack vector for a realistic attack that would glean any type of useful traffic from the victim's phone for a few reasons:

1. The attacker would need to somehow ensure (or would already know in advance) that Firefox was terminated and not just backgrounded
2. The user would need to be coerced into clicking an HTTP link
3. The attacker would need to be in a position to intercept traffic to the non-HTTPS website (sniffing, MitM)

The problem is that even with all of the above in place, if the URL is not spoofed then users would immediately see they are not on the website that the attacker's HTTP link purported to take them to. You mention that rather than a fake/spoofed website this could be used on a "well-known site" that does not support HTTPS:

If that is a link to a well-known site that does not (correctly) support HSTS, then such an attack may easily succeed.

However as far as I'm aware in 2024 these are exceedingly rare to the point of being basically unheard of. Just to clarify: I'm not suggesting this isn't an important bug, it needs to be addressed and I'm currently looking into a fix for iOS. However based on what I can see so far it's difficult to imagine a scenario in which this could be leveraged for a realistic and meaningful attack.

Comment 15

[mreagan]

Jira: https://mozilla-hub.atlassian.net/browse/FXIOS-10116

Comment 16

[Erik van Straten]

(In reply to mreagan from comment #14)

Hi Erik, I'm currently investigating a fix for this on iOS, though I'm a bit confused on one point: is this attack also able to spoof the destination URL in the newly-opened HTTP website in Firefox's address bar?

No, but that does not make it less of a risk. Consider, for example, https://www.bleepingcomputer.com/news/security/australian-charged-for-evil-twin-wifi-attack-on-plane/ .

In my testing so far it doesn't appear that is the case, and Daniel's comment also appears to indicate the same (unless I'm misunderstanding):

in this bug the new content DID load (you can see the badssl.com background in the screenshot), the new URL is shown, but the scheme is not what we loaded.

This is obviously a bug that needs to be fixed,

Exactly. Please do so.

however to me this seems exceedingly impractical to leverage as an attack vector for a realistic attack

Unless you're in a team of experienced (ethical) hackers/pentesters and have thoroughly discussed this: please do not underestimate risks because YOU do not see any possibilities for exploits. There are lots of attackers out there who get payed large amounts of money for the ability to attack (specific) internet users. I've not seen Mozilla publish anywhere:

"Please don't use Firefox if you're a VIP - because in our attack scenarios we do not take people like you into account".

[snip]

The problem is that even with all of the above in place, if the URL is not spoofed then users would immediately see they are not on the website that the attacker's HTTP link purported to take them to.

This: https://github.com/kgretzky/evilginx2 is just one example of an "evil proxy". The fake website that the visitor sees looks exactly like the authentic site. MFA using SMS, voice, TOTP or Microsoft "Number Matching" will not help: the AitM (Attacker in the Middle) will immediately forward them to the real website, but intercept the session cookie or whatever is returned by the real server as an authentication token.

For example this article, titled "MFA had failed", was written in 2019 by Alex Weinert, Director of Identity Security at Microsoft: https://techcommunity.microsoft.com/t5/microsoft-entra-blog/all-your-creds-are-belong-to-us/ba-p/855124 .

However based on what I can see so far it's difficult to imagine a scenario in which this could be leveraged for a realistic and meaningful attack.

It is extremely easy to social engineer people. Those that do understand that a padlock means that:
a) The server was authenticated; and
b) The connection is encrypted and data exchanged is checked for integrity (and authenticity because of a)

• will become victims of attacks where the padlock should have been striked through.

On mobile devices the amount of pixels spent for server authenticity -in order to make it harder for impostors- are limited (and seemingly continuously gets reduced all the time: https://infosec.exchange/@ErikvanStraten/113125611232033225 ), so what remains is particularly essential.

I'll wait a bit with publishing a full and detailed PoC. Please keep me informed!

Comment 17

[mreagan]

Exactly. Please do so.

please do not underestimate risks because YOU do not see any possibilities for exploits.

These types of comments are unhelpful. The previous post had several very relevant questions that were being asked in an earnest effort to clarify the security impact of this ticket. Those questions are still pertinent IMO to the security implications of the bug.

There is a fix already in review for this. Based on everything I can see so far, the aforementioned fix should resolve all of the security concerns specific to this ticket since the fundamental issue (the incorrect SSL icon) should be corrected by that update. But if you think there are any other directly-related issues that still need to be addressed please feel free to update.

Comment 18

[mreagan]

Note: fix merged, targeting v132. Currently double-checking whether this may be backported to v131, if so I will update ticket.

Comment 19

[Andrei Bodea[:andrei]]

Verified as fixed on v132 (45901) with iPhone 15 Pro (17.5).

Please note that I followed the next steps:

1. Launch FF and access any **HTTPS **website (Google for example) in the current tab
2. Force close Firefox.
3. Open an **HTTP **link from an external source, such as an email, or a link in Notes (examplehttp://http.badssl.com/)

Every time when I opened the HTTP link in Firefox via email/notes, it was opened correctly, and the lock icon was indicating that the opened site was not a secure one (ETP lock icon crossed with a line).
For more details please check the video.

Comment 20

[mreagan]

Note: backport has been created after team discussion, so the fix should be available in the next iOS release (131.2).

Comment 21

[Andrei Bodea[:andrei]]

Verified as fixed on v131.2 (46395) with iPhone 15 Pro (17.5).

Comment 22

[mreagan]

Attachment: advisory.txt

Comment 23

[Daniel Veditz [:dveditz]]

use CVE-2024-10004 for this issue

Comment 24

[Erik van Straten]

Thank you all who contributed to this fix, and for mentioning my name in https://www.mozilla.org/en-US/security/advisories/mfsa2024-54/ .

In some preliminary tests I conducted using v131.2, the vulnerability did not reproduce.

I've meanwhile posted (in English) https://infosec.exchange/@ErikvanStraten/113316652669640932 and (in Dutch) https://www.security.nl/posting/862244/Firefox+iOS+hangslotje+fix .

Let's make the internet a safer place!