1483508 - Full URL spoof and/or SSL lock spoof using event handlers and redirect stalling

Status: RESOLVED FIXED

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

Description

[Abdulrahman Alqabandi]

Attachment: votzo.html

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

Steps to reproduce:

I found a way to spoof the green lock icon as well as spoof full URLs (potential uXSS as well, but not confirmed yet). This seems to only work with a little bug i found when firefox tries to handle search queries through the address bar.

The STR are not 100% reliable, spent some time now to get it as reliable as possible. The most common bug that appears is the lock icon spoof. If you click on it it will even say that its a google certificate. 

I want to report this whilst I pinpoint the exact problem. So forgive the messy PoC code, will update you guys when I have some more results. Feel free to help!

 Tested on windows 10 and latest firefox nightly.

1. Host attached PoC to a non https enabled website (I only tested localhost)

2. Copy some sort of text like "mozilla stuff" 

3. As soon as you open the hosted PoC, right click the address bar and click 'paste and go'

If nothing happens, just refresh and repeat steps. I seem to have a ~50% success rate right now.  I have also uploaded a video for you to see it live in action.


Actual results:

https://www.youtube.com/watch?v=hwp6YuRiuVc

Multiple results:

1. When paste and going, sometimes all that is left is the keyword you pasted and nothing else happens. If you press enter, the address bar will change to a google URL with the pasted keyword as a search query, but again, no actual navigation happens.

2. Other times you will spoof the lock icon directly from google.

3. Even rarer, you would end up in the final google search page, but an alert from PoC had popped within it. This leads me to believe in a possible uXSS.

Comment 1

[Ryan VanderMeulen [:RyanVM]]

Johann, would you be able to take a first look at this?

Comment 2

[Abdulrahman Alqabandi]

Attachment: Moz-spoof.png

Comment 3

[Abdulrahman Alqabandi]

One more behavior I noticed. If you copy paste a keyword you get SSL lock spoof. However, if you copy paste a full URL like 'https://www.mozilla.org/en-US/' you instead will spoof the full URL with only an alert showing from the PoC. 

This at least confirms my hunch that the SSL spoof has something to do with the mechanism that deals with keyword searches (which google happens to handle by default.) As I cannot seem to get SSL spoof when pasting a full URL.

See attached screenshot in comment 2

Comment 4

[Abdulrahman Alqabandi]

Attachment: first.php

Alright, so finally managed to get a ~90% success rate and got minimal PoC. Specifically, I was able to pin point the SSL lock spoof. Seems like the onpageshow event handler mixed with some redirect stalling/tricks you can pretty reliably get a SSL lock icon spoof. 

If you change the target SSL to spoof (in this case, google) to something else, seems to not work as well. So it does not look like copy pasting keywords is the culprit here. Hope someone can test this new minimized PoC and see if it works for them just as well for me. (if it doesn't, try to increase the setTimeout ms wait)


STR SSL spoof only:

1. Host both first.html and second.html in non-https localhost or other.
2. Open first.html
3. Click button

Repeat 10 times to get a rough idea of success rate.

Comment 5

[Abdulrahman Alqabandi]

Attachment: second.php

Comment 6

[Abdulrahman Alqabandi]

Attachment: second.php (full url spoof w/ ssl)

To achieve full URL spoof (plus ability to get data) use the attached 'second.php' here with the original 'first.php' unchanged. 

In this instance, all we have to do is add a second event handler 'onfocus' and for some reason instead of spoofing just SSL we end up spoofing all of the URL.

Not sure if this requires a separate report, though seems like both cases rely on the same buggy behavior. I think its safe to assume both will be fixed if one is.

Finally, according to https://wiki.mozilla.org/Security_Severity_Ratings

"Spoofing of full URL bar or bypass of SSL integrity checks" is a sec-high, and I'm fairly certain this bug satisfies both cases.

Comment 7

[Johann Hofmann [:johannh]]

Alright, sorry for the delay and thank you for uploading a much better POC. I originally looked at the first document and really couldn't reproduce this, but the second one works well enough for me (sometimes better, sometimes worse).

This is remarkably similar to bug 1481994 in that it uses event handler stalling in combination with a timeout to achieve a URL bar spoof. Hence I'm moving this to document navigation, although it might end up being a bug in how we display things in the front-end.

qDot, can you put this one on the list, too? I'm still a bit too busy to give this a deeper look right now, though I may be able to later.

> Finally, according to https://wiki.mozilla.org/Security_Severity_Ratings
> 
> "Spoofing of full URL bar or bypass of SSL integrity checks" is a sec-high,
> and I'm fairly certain this bug satisfies both cases.

If I understand your POC correctly, you rely on timing (making this a little brittle to reliably reproduce) and the dialog needs to be shown to the user? I would consider a spoof "full" when you can spoof the URL bar while having complete control over the content area. With that said, this is still a high-quality submission and there's really a thin line between sec-moderate and sec-high here.

Comment 8

[Abdulrahman Alqabandi]

> If I understand your POC correctly, you rely on timing (making this a little brittle to reliably reproduce) and the dialog needs to be shown to the user? 

The timing aspect is only used to navigate the opened window as soon as it commits to serving 'second.php', so as the PoC is now it could fail with slower internet users. However, I'm pretty sure I can stop relying on timing and just detect when the opened window successfully and fully transitioned from about:blank to 'second.php' and then quickly redirect. I will test more and explore this issue of reliability.

I'm on another computer now and I seem to be getting 100% success rate with the setTimeout set to 111ms for the SSL spoof. 

> I would consider a spoof "full" when you can spoof the URL bar while having complete control over the content area. With that said, this is still a high-quality submission and there's really a thin line between sec-moderate and sec-high here.

I agree, the reason I think it is sec-high is because the bar was 'full spoof OR bypass of SSL integrity checks' I am assuming here that the SSL lock spoof is a bypass of SSL integrity check, correct? if so, then I have half a spoof + full SSL integrity bypass which in my head means I satisfied the clause.

As I said before, I will be looking into the success rate more and will reply once I can guarantee success rate on both (or if i find that I cannot.)

Comment 9

[Abdulrahman Alqabandi]

Attachment: new-pocs.zip

After looking into the issue of reliability, after some testing it looks like we can perform both bugs with 100% reliability.

New PoC files are attached, the archive contains two archives within it. One deals with the SSL spoof and the other deals with the full url spoof.

Video:

URL spoof reliability test: https://www.youtube.com/watch?v=RhoSN9zIOiA

With the URL spoof I can spoof any URL but so far I can only manage to pop a prompt and extract data using that. 

SSL spoof reliability test: https://www.youtube.com/watch?v=NN7m1eeyOxs

The only times SSL spoof failed was when I changed the URL to something unexpected. Google search URL seems to be 100% reliable but if I change it to anything else then there is potential for failure. See video.

I think what's happening is that the response from the provided URL matters here somehow. But that doesn't matter since we have a 100% reliable way to do it which is with "https://www.google.com/search?q=*" urls.

Comment 10

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

This looks similar to other bugs we're working on right now but I still don't want to dupe it quite yet, as I think the SSL Lock Icon issue is new. I *think* most of this revolves around loads not getting

Comment 11

[Abdulrahman Alqabandi]

The SSL spoof doesn't seem to work on latest nightly anymore. URL spoof still works.

Comment 12

[Abdulrahman Alqabandi]

Friendly ping for an update. Is it possible to fix stable release with whatever fixed the SSL spoof bug on nightly?

If that was unintentional I'll be happy to run mozregression and find out so we could at least fix the bigger bug of the two on stable.

Comment 13

[:Gijs (out for now; he/him)]

(In reply to Abdulrahman Alqabandi from comment #12)

If that was unintentional I'll be happy to run mozregression and find out so we could at least fix the bigger bug of the two on stable.

I think either way (ie intentional or not) it'd be helpful to figure out what fixed this, so if you have time to do that that'd be great. I'm a little confused because comment #11 was 5 months ago so any "normal" changes on nightly should at least be on beta right now if not release (and I'm assuming, per your comment, that 65 on beta/release/rc is still vulnerable)... so yes, running mozregression with --find-fix might be illuminating here.

Comment 14

[Abdulrahman Alqabandi]

Ok it does not work on stable 64.0.2 (64-bit) I think when i first updated, it updated to 63.x where it worked or i just made a wrong assumption. So never mind comment 12!

Seems to be fixed on stable.

Comment 15

[:Gijs (out for now; he/him)]

(In reply to Abdulrahman Alqabandi from comment #14)

Seems to be fixed on stable.

OK, to be clear, you mean the lock spoof is fixed, but this still leaves the URL spoof, right?

Comment 16

[Abdulrahman Alqabandi]

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

(In reply to Abdulrahman Alqabandi from comment #14)

Seems to be fixed on stable.

OK, to be clear, you mean the lock spoof is fixed, but this still leaves the URL spoof, right?

Yes, the URL spoof still works on latest nightly and 64.0.2 (64-bit). Though the only content that can be shown to extract any useful data from potential victim is a pompt().

Comment 17

[Abdulrahman Alqabandi]

Also, I will look for the bug responsible for fix. Will update soon.

Comment 18

[Abdulrahman Alqabandi]

Attachment: mozreg logs

Looks like this was fixed by bug 832834, will attach logs from mozregression in case its useful.

Comment 19

[Abdulrahman Alqabandi]

Perhaps I should file a new bug to handle the full url spoof and consider this bug as the SSL spoof?

Thoughts?

Comment 20

[:Gijs (out for now; he/him)]

(In reply to Abdulrahman Alqabandi from comment #19)

Perhaps I should file a new bug to handle the full url spoof and consider this bug as the SSL spoof?

Thoughts?

I'd prefer to keep it together, though I wonder if we could write an automated testcase for the ssl spoof so we don't inadvertently break it again... Dana, looks like you "accidentally" fixed this by making the nsSecureBrowserImpl stuff much more sane. Interested in doing a testcase in a separate bug?

I also just realized that:

(In reply to Kyle Machulis [:qdot] [:kmachulis] (if a patch has no decent commit message, automatic r-) from comment #10)

This looks similar to other bugs we're working on right now but I still
don't want to dupe it quite yet, as I think the SSL Lock Icon issue is new.
I think most of this revolves around loads not getting

this looks like the comment got cut off. :qdot, any more you remember about this, and esp. if the url spoof is covered somewhere else if the ssl spoof is now taken care of?

Comment 21

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

I think this is yet another load stall/cancellation issue similar to bug 1263100. URL spoof in particular looks like bug 1481994, which also looks like bug 1263100.

Comment 22

[Dana Keeler (she/her) (use needinfo) [:keeler]]

(In reply to :Gijs (limited availability until Tue 29; he/him) from comment #20)

I'd prefer to keep it together, though I wonder if we could write an automated testcase for the ssl spoof so we don't inadvertently break it again... Dana, looks like you "accidentally" fixed this by making the nsSecureBrowserImpl stuff much more sane. Interested in doing a testcase in a separate bug?

Sure - I can have a look. I filed bug 1522681 with a vague title/summary.

Comment 23

[Neha Kochar [:neha]]

Paul, can you please test and confirm if the URL spoof is fixed now with the latest modal changes?

Comment 24

[Paul Zühlcke [:pbz]]

I've tested the PoCs in new-pocs.zip. The only spoofing issue I can reproduce is that the prompt is showing when the page content and urlbar already switched to google.com. Which is an improvement over the issue shown here https://www.youtube.com/watch?v=RhoSN9zIOiA where the content area still shows the localhost page when the urlbar has already updated.

Comment 25

[Paul Zühlcke [:pbz]]

Attachment: spoof-url-new-prompts.png

Comment 26

[:Gijs (out for now; he/him)]

(In reply to Paul Zühlcke [:pbz] from comment #24)

I've tested the PoCs in new-pocs.zip. The only spoofing issue I can reproduce is that the prompt is showing when the page content and urlbar already switched to google.com. Which is an improvement over the issue shown here https://www.youtube.com/watch?v=RhoSN9zIOiA where the content area still shows the localhost page when the urlbar has already updated.

Uh, why does the screenshot disagree about the origin of the dialog and the origin you're giving permission to keep prompting?!

Comment 27

[Paul Zühlcke [:pbz]]

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

(In reply to Paul Zühlcke [:pbz] from comment #24)

I've tested the PoCs in new-pocs.zip. The only spoofing issue I can reproduce is that the prompt is showing when the page content and urlbar already switched to google.com. Which is an improvement over the issue shown here https://www.youtube.com/watch?v=RhoSN9zIOiA where the content area still shows the localhost page when the urlbar has already updated.

Uh, why does the screenshot disagree about the origin of the dialog and the origin you're giving permission to keep prompting?!

That's odd....
I suspect that they somehow end up with two different principals. The principal which is used to create the checkbox label comes from here:
https://searchfox.org/mozilla-central/rev/9c9f2f85d00aef1943cb521ac95c72bae932ebc5/dom/base/nsGlobalWindowInner.cpp#3722
The principal used for the content prompt title comes from here: https://searchfox.org/mozilla-central/rev/9c9f2f85d00aef1943cb521ac95c72bae932ebc5/toolkit/components/prompts/src/Prompter.jsm#1196
Given the nature of this bug it seems plausible that the principals would be out of sync. I'm not sure why this.browsingContext.window?.document.nodePrincipal; would lead to the "old" principal though. It makes sense that the checkbox label is correct, given that it directly comes from the SubjectPrincipal.

Anyway, we shouldn't show this prompt at all.

Comment 28

[Andrew McCreight [:mccr8]]

Is this still an issue? It looks like the related bug was closed about a month ago. Thanks.

Comment 29

[Paul Zühlcke [:pbz]]

Seems to be fixed! Can't reproduce the issue anymore with the PoC code in new-pocs.zip.