1415553 - Firefox shows alerts and allows you to modify content on certificate validation error pages

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect, P3)

Description

[Jose María Acuña]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36

Steps to reproduce:

1- access to http://createcharts.esy.es/permission-prompt-link.html
2- click on the link
3- press the "Go Back" button that appears in blue on the screen
4- Watch video in https://bugzilla.mozilla.org/attachment.cgi?id=8925509

At that time, a popup with a false message that can deceive the user is displayed.
In addition, you can modify the title of the page and the favicon and add iframes type elements with information not related to the page.

(This bug is directly related to the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1407574 but I thought it convenient to divide it into two because they are different cases)

Comment 1

[Jose María Acuña]

Some type of advance?

Comment 2

[:Gijs (he/him)]

(In reply to Jose María Acuña from comment #0)
> (This bug is directly related to the bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=1407574 but I thought it
> convenient to divide it into two because they are different cases)

Can you clarify what is different about them? I don't see any difference. I think this is just a dupe of the other bug. I also cannot reproduce any change to the original error page (or its title or favicon), I only see the alert.

Comment 3

[Jose María Acuña]

For me the difference is obvious.

In the first example, it shows the alert but previously the url has changed to "about:blank" which indicates that the page that launches the message is different from the source domain.

In this bug, the url does not change so the possibility of spoof is very high.

Comment 4

[Jose María Acuña]

The result is the same with pages whose request returns errors of type Server Not Found

Sample html code:

<iframe src="" style="border:0" onload="t=this;t.contentDocument.body.innerHTML+='<s'+'cript>setTimeout(function(){parent.location=\'https://www.mozilla.ar/\';},0);</s'+'cript>';location='javascript:try{parent.document.body.innerHTML=t.contentWindow.document.body.innerHTML}catch(e){open(\'https://docs.google.com/drawings/u/0/jserror\',\'_top\');alert(\'spoof\');}'"></iframe>

I imagine there will be other pages with error codes that can be exploited

Comment 5

[Jose María Acuña]

Attachment: bug-mozilla-12042018.webm

Comment 6

[Jose María Acuña]

Retaking this vulnerability,
I think the scope can be much greater.

If we redirect to a phishing page, the first thing the user will do is go back to the page where he was.
Not only can I display an alert message but also, from the domain itself marked as malware, I can open a window with a complaint form with which I would obtain personal information from the user. (The Google Form domain gives a lot of credibility)

Steps to follow:

1- I access to http://createcharts.esy.es/link-mozilla.html
2- I click on Test (redirects to https://phishing.safebrowsingtest.com)
3- I press the back button of the browser
4- A message is displayed
5- A window opens for the user to enter confidential information

Attached video with the demonstration

Comment 7

[Jose María Acuña]

The web server createcharts.esy.es is out of use.
Now the test pages are hosted at https://www.finanser.es/test/

Comment 8

[Jose María Acuña]

Attachment: firefox shows modal dialogues

I attach this video because the previous one is not visible

Comment 9

[Jose María Acuña]

Hello,
I reported this vulnerability about a year ago and I am sure they are working hard to correct it.

After a long time, I returned to do some more checks and I have seen that you can inject html code into unauthorized pages.

Example: https://www.finanser.es/test/html-injection.html

Video: https://drive.google.com/file/d/1bRRpG6THsSJXsIm4wfqPZ_9VMiw_-ezB/view

I hope you can find a solution soon.
Regards!

Comment 10

[:Gijs (he/him)]

(In reply to Jose María Acuña from comment #9)
> After a long time, I returned to do some more checks and I have seen that
> you can inject html code into unauthorized pages.

That's not really an accurate description of what your testcase does. It shows HTML and we neglect to update the address bar, but the HTML is injected in attacker-controlled content, so there's no possibility for XSS or similar, as there would be if you actually "injected" HTML somewhere.

Comment 11

[Jose María Acuña]

At this time, the bug is not reproducible in:

1- Firefox Nightly 68.0a1 (2019-03-27) (64-bit) for Windows 10
2- Firefox Quantum 66.0.1 (64-bit) for Windows 10

Test: https://www.finanser.es/test/html-injection.html

Comment 12

[:Gijs (he/him)]

Like bug 1407574, I can still reproduce some level of confusion here, on current nightly.

Comment 13

[Jose María Acuña]

I have tried pressing the Back button several times and the the bug is not reproducible:
Video attachment: https://drive.google.com/file/d/1iSVfMMazIq_5XKUszNZrM72FjBxbC6BM/view

Comment 14

[Jose María Acuña]

(In reply to Jose María Acuña from comment #11)

At this time, the bug is not reproducible in:

1- Firefox Nightly 68.0a1 (2019-03-27) (64-bit) for Windows 10
2- Firefox Quantum 66.0.1 (64-bit) for Windows 10

Test: https://www.finanser.es/test/html-injection.html

Hi,
I just did the test in the latest version of Firefox Developer Edition for Windows 10 and the bug is not reproducible either:

Video attachment: https://drive.google.com/file/d/1dmcLNAq_BPmTgGAYh5aGgakcdgHoLv4R/view

3- Firefox Developer Edition 67.0b6 (64-bit) for Windows 10

Comment 15

[Jose María Acuña]

In summary,

this bug it does not reproduce in:

1- Firefox Nightly 68.0a1 (2019-03-27) (64-bit) for Windows 10

2- Firefox Quantum 66.0.1 (64-bit) for Windows 10

3- Firefox Developer Edition 67.0b6 (64-bit) for Windows 10

Comment 16

[Daniel Veditz [:dveditz]]

The original bug showed the attacker's content with the wrong domain--with a valid security lock--in the address bar. That's a pretty good goal for phishing, marred by the need for the victim to press back (how would they think to do that? If you tell them ahead of time won't they find it suspicious?). It's gotten better and now the spoofed content shows an "about:blank" in the addressbar and takes an insane number of clicks on the back button to trigger -- effectively useless in an attack.

It's still the same kind of attack as bug 1407574 though. Is the bug different, or just the payload? Since it's mostly-fixed like that other bug it probably is depending on the same underlying code paths so for bounty purposes we are combining these bugs.

Comment 17

[Jose María Acuña]

(In reply to Daniel Veditz [:dveditz] from comment #16)

The original bug showed the attacker's content with the wrong domain--with a valid security lock--in the address bar. That's a pretty good goal for phishing, marred by the need for the victim to press back (how would they think to do that? If you tell them ahead of time won't they find it suspicious?). It's gotten better and now the spoofed content shows an "about:blank" in the addressbar and takes an insane number of clicks on the back button to trigger -- effectively useless in an attack.

It's still the same kind of attack as bug 1407574 though. Is the bug different, or just the payload? Since it's mostly-fixed like that other bug it probably is depending on the same underlying code paths so for bounty purposes we are combining these bugs.

Yes, I think the payload is different but the error is basically the same

Comment 18

[Neha Kochar [:neha]]

Gijs, can you please confirm that bug 836567 has fixed this too? Some of us tried and weren't able to reproduce it on latest nightly.

Comment 19

[:Gijs (he/him)]

(In reply to Neha Kochar [:neha] from comment #18)

Gijs, can you please confirm that bug 836567 has fixed this too? Some of us tried and weren't able to reproduce it on latest nightly.

It appears that way, yes.