1653041 - autocomplete & history poisoning

Status: RESOLVED DUPLICATE of bug 1491452

(Toolkit :: Places, task, P3)

Description

[Enrique]

Attachment: PoC - PhisHistory.mp4

Operation System: MS Windows 10 (All Versions)
Mozilla Firefox 75.0 / 78
Tool: Own tool. Programming language: nodejs for proof of concept (Phishistory).

Impact: The attacker can manipulate or poison the history and auto-completion of the web browser to perform phishing, force visit a web page with malicious javascript, etc.
For the example, the attacker wants to do a gmail.com phishing.

Attack Description:

1. The user visits a malicious web page.
2. The web page loads a javascript that visits n times a web page with title, favicon and URI similar to the page to spoofing. For example: favicon from gmail.com, title: GMAIL.com, PART URI: GMIAL.COM /GMAIL.com
   (The entire process is done transparently for the user.)
3. At another time, when the user types part of the legitimate URL (gmail.com) in the navigation bar, the autocomplete will show him the URL of the malicious domain with the favicon.
4. When the user visits this malicious domain, they will believe that they are visiting the legitimate domain (they have not clicked on any email, forum, private message, etc.).
5. The user inserts his credentials on the phishing website.
6. The user is redirected to the legitimate domain.

The attack may have other objectives, for example, forcing you to visit a website that loads malicious javascript (simulating a poisong cache attack).

The bug:
The problem is not to block a high number of visits to a certain domain using for example: location.href

Example code:
for (i = 0; i <n; i ++) {
location.href = location.origin + "#";
}

This allows a malicious domain to be positioned in the history due to the large number of registered visits.

Other web browsers (Google Chrome, Internet Explorer, Edge, Opera, Safari, etc.) block a high number of requests. Firefox, no.

Requirements

• The user uses Firefox
• The user visit a malicious URL with Phishistory.
• The attacker must use:
  • a favicon similar to the legitimate domain to spoof.
  • a title with the name of the legitimate domain to spoof.
  • part of the url, it must have a web-like name to spoof.
• The attacker must know when to do the poisoning attack and when to load the phishing (another attacks). For example, using cookies.
• The user enters part of the legitimate domain and uses the autocomplete or the dropdown with the suggestions.

NOTE:
Please, if you have any questions, ask me.

PS: Excuse my English, it is not very good. I am Spanish. :(

Comment 1

[:Gijs (he/him)]

(In reply to Enrique from comment #0)

Operation System: MS Windows 10 (All Versions)
Mozilla Firefox 75.0 / 78
Tool: Own tool. Programming language: nodejs for proof of concept (Phishistory).

Did you intend to attach code you're using for this exploit? I just see a video.

1. The user visits a malicious web page.

Why not just phish immediately? Why bother with all the rest and hope that the user picks the wrong thing in autocomplete?

Other web browsers (Google Chrome, Internet Explorer, Edge, Opera, Safari, etc.) block a high number of requests. Firefox, no.

I'm aware of other browsers doing request blocking, but I don't think this is the reason for doing so. Otherwise I suspect this is a duplicate of bug 1317573, bug 1314912, bug 1573736 or similar...

Comment 2

[Enrique]

Hello:

No. I just uploaded the video. The source code of the tool is not important to explain the bug, it is only necessary to carry out this attack.

Why not just phishing right away? Why bother with everything else and wait for the user to choose the wrong thing to autocomplete?

This is an example of how to take advantage of this bug to make an attack, in this case of pishing.

In my opinion, it shouldn't be possible to manipulate or poison history with so many requests in such a short time. So I think it is a bug. Then it can be exploited for other attacks, such as phishing, persistent malicious javascript, etc.

Answering your question:

Why not just phishing right away? Why bother with everything else and wait for the user to choose the wrong thing to autocomplete?

For several reasons:

1. There are security systems, email client plugins, AI, etc. that detect phishing. In this way, it would not be detected.

2. A user with average knowledge would not be tricked by a phishing email. Or you could go directly to the service without clicking on the link.

3. The attack seeks to obtain the credentials of those domains most visited by the user. Gmail is one of the most used email services in the world, currently users check their emails daily and several times, that's why I have used it in the PoC ... On a business level, maybe office365? ... It is indifferent.

The autocomplete feature has been introduced precisely for usability ... So from my point of view it is more effective. I personally use it a lot.

4. At any time and only when the user wants to connect to the service and use autocompletion will phishing be carried out ... Which is, in my opinion, less suspicious, don't you think? I think this is what's interesting and important.

Thanks for the questions.
A greeting.

PD: In my opinion, from what I have seen, the posts you indicate have nothing to do with this.

Comment 3

[Marco Bonardo [:mak]]

More than a security problem, that I don't find too much convincing, I suspect this is indeed a bug related to history pollution.

Reload requests (loading the same url multiple times) are already ignored by history, thus I'd appreciate further details about how history is polluted, is the simple loop you suggested as example working? In the video what I see is a pretty much empty profile for which even just a visit may be enough to generate enough score. In a normal profile with history it would be harder to reach the top.

For current flooding protection see:
https://searchfox.org/mozilla-central/rev/82c04b9cad5b98bdf682bd477f2b1e3071b004ad/toolkit/components/places/History.cpp#1920-1936

We were also debating about multiple refs in bug 661590, see https://bugzilla.mozilla.org/show_bug.cgi?id=661590#c7 and https://bugzilla.mozilla.org/show_bug.cgi?id=661590#c12
I think this directly depends, or is even a duplicate, of bug 661590, but if it can be reproduced even without a ref it may deserve staying separate. That's why I'd love more details about which URIs work and which don't in a more populated history.

Comment 4

[Enrique]

Hi:

Using the tool for the Windows OS BrowsingHistoryView v2.40 (https://www.nirsoft.net/utils/browsing_history_view.html) it can be seen that the counter increases considerably. It does not inject just one visit to the history. Generate hundreds of them. In the example, around 150/300. There is not limit. The greater the number of visits, the longer the loading time, obviously.

More than a security problem, that I don't find too much convincing, I suspect this is indeed a bug related to history pollution.

I would like you to clarify this before continuing. If it is not going to be taken as a security problem and you do not think it is too convincing and there is not going to be any recognition, I will not waste time going into more details.

Simply, consider an ideal scenario (as I present), tell me what impact it would have. Although later it does not meet expectations.

What I am not going to do is make a detailed explanation when it will not be taken into account and waste my time. On other occasions I have not obtained recognition but they have ended up correcting the bugs. So it doesn't seem fair to me.

Comment 5

[Marco Bonardo [:mak]]

It's the security team doing the assessment, and they will do soon. Me and Gijs just gave a developers opinion, and of course we'd like to fix the bug regardless.

Comment 6

[Daniel Veditz [:dveditz]]

What I am not going to do is make a detailed explanation when it will not be taken into account and waste my time. On other occasions I have not obtained recognition but they have ended up correcting the bugs. So it doesn't seem fair to me.

One issue here is that without details it sounds similar to other issues we do know about (see various bugs mentioned above). Is this a distinct case? We can't say without knowing more, or you waiting for us to fix those other bugs.

Does look pretty slick. It's not just filling the dropdown suggestions, but the prefilled "best choice" that makes this somewhat different from what we've seen before.

Comment 8

[Marco Bonardo [:mak]]

This is worth investigating. The ref part was covered (from a perf point of view) by bug 661590, but there is a bit more to consider.
Because we autofill origins, it would be possible to force a lot of visits to different pages (not just different refs) in a specific origin, to push up the score for that origin. The anti-flooding system theorized for bug 661590 (track recent urls without the ref) would not prevent this, because these urls can have completely different paths too.
It would be necessary to somehow track pages visited in the last N minutes per-origin, and just disallow storing more than N visits in the timeframe (further visits are completely ignored).
Even doing that, nothing would prevent a site to add those visits with a delay, it should just find a way to stay in background long enough, and I'm not sure there's some kind of prevention we can do without actually harming normal user history functionality. Maybe something like password-guessing systems where the time between visits keeps increasing, but it wouldn't survive the browser session.

tl;dr: Mitigations are possible, but I'm not sure we can completely prevent the problem without changing how autofill works.

Comment 9

[Enrique]

Hi:

Does look pretty slick. It's not just filling the dropdown suggestions, but the prefilled "best choice" that makes this somewhat different from what we've seen before.

Thanks for your opinion.

Because we autofill origins, it would be possible to force a lot of visits to different pages (not just different refs) in a specific origin, to push up the score for that origin.

Right!. This is one of the important points for the attack.

Comment 10

[Enrique]

Hello:

Still no news about it?

Thank you.
A greeting.

Comment 11

[Marco Bonardo [:mak]]

(In reply to Enrique from comment #10)

Still no news about it?

We have limited resources. I proposed a possible history-side approach to Gijs, though we also discussed whether there should be a protection on the Web side, like actually requiring a user action to register the visit. Unfortunately the risk of breaking user experience of the Web, by not recording valid visits, is high; there's many valid ways for websites to redirect the user and not necessarily a direct action could be linked to those (for example doing some action that causes a remote request and depending on the answer a different redirect).
Due to how the scoring algorithm works, there's no silver bullet that will solve all of the cases, one could always add visits on a timer to bypass any kind of time-based protection, thus we can surely land some improvement, but we don't have a complete solution yet.
It may also be interesting to evaluate how other browsers manage this matter, even if they likely don't have autofill of origins and it's easier to protect the score of a single url compared to an origin, where one can just keep generating random urls.

Comment 12

[Enrique]

Hello, I do not have access to the link. you told me that the security department would soon give an answer. to see if it was viewed as a security breach. When will i know something about it?

Thanks!

Comment 13

[Marco Bonardo [:mak]]

Comment 6 was the sec audit, the link is just a proposal, not yet approved or anything, I can open it later after discussing it with some other dev.

Comment 14

[Daniel Veditz [:dveditz]]

We're still waiting for a testcase that might distinguish this example from the earlier bugs. Without that we will tend to assume it's a duplicate and leave this bug to re-check later after we've done something about those. The bounty committee is declining to award a bounty for this bug on that basis. If we do get a testcase please email us so we can get this back on our radar to re-evaluate.

Comment 15

[Enrique]

Thanks for the reply.

Could you send me an email to send you a PoC?

Comment 16

[Mark Banner (:standard8)]

We're going to look into the dependant performance issue first (bug 661590) which may use the approach in the attached document. That will hopefully at least partially fix this issue and then we can re-assess if a fuller fix is needed.

Comment 17

[:Gijs (he/him)]

(In reply to Mark Banner (:standard8) from comment #16)

We're going to look into the dependant performance issue first (bug 661590) which may use the approach in the attached document. That will hopefully at least partially fix this issue and then we can re-assess if a fuller fix is needed.

Per the last few comments in bug 661590 (which I think should already be fixed), can we re-test this and check again what needs to happen?

Comment 18

[Mark Banner (:standard8)]

Redirecting to Marco as he's most familiar with everything here.

Comment 19

[Marco Bonardo [:mak]]

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

Per the last few comments in bug 661590 (which I think should already be fixed), can we re-test this and check again what needs to happen?

For this specific bug, I don't think bug 1314912 solves all the cases, I suspect global history could still be poisoned by a specially crafted page (I imagine doing a mix of location, pushstate, and redirects across 2 different origins, or just using an appropriate timer between changes). I think we still want to improve global history protection from the current very simple approach. It surely reduces the likelihood of this happening but doesn't solve it.

For bug 661590, it's probably matter of testing if there's leftover cases that may happen through common Web API calls, and check if the rate limit is sufficient. There's not many details in those landed revisions commit message, but I assume it's limiting to max 200 calls in 10s, that would still be high for global history performance, imo.

Comment 20

[Enrique]

It has been over 4 years and I still have no news about whether it has been classified as a vulnerability.

I have reported this bug to participate in the bug bounty system and to be recognized for the discovery.

Could you give me feedback on this? Will it be classified as a vulnerability? Do I have the right to recognition through the Bug Bounty program?

I think I have waited long enough without publishing anything about it.

Comment 21

[:Gijs (he/him)]

(In reply to Enrique from comment #20)

It has been over 4 years and I still have no news about whether it has been classified as a vulnerability.

I think comment 14 tried to address some of this; it looks like your request for an email address in comment 15 was either missed or responded to privately (so either way I have no access to a PoC). If you have a PoC that addresses comment 14, can you attach it to the bug or link to it?

Comment 22

[Enrique]

You have only focused on solving the problem without giving me any feedback and drawing your own conclusions.

What do you want me to do? If the discovery of the vulnerability is not going to be recognized, it makes no sense for me to contribute anything else.

Comment 23

[Daniel Veditz [:dveditz]]

(In reply to Enrique from comment #20)

It has been over 4 years and I still have no news about whether it has been classified as a vulnerability.

It was confirmed as a vulnerability in comment 6.

I have reported this bug to participate in the bug bounty system and to be recognized for the discovery.

We have been unable to confirm this was distinct from previously reported bugs, which is required for recognition in our bug bounty program. In comment 14 we took it off our list of bugs to consider for a bounty (indicated by the sec-bounty- setting) because it didn't seem like we were going to get any more information to clarify the situation. I can put it back on the list for now.

I didn't see the question in comment 15 because I'm not a developer working on this bug and it was no longer on the bounty nomination list. We'd prefer any PoC be added as an attachment to this bug since Bugzilla uses a secure TLS connection. Plaintext email is insecure. If you must use encrypted mail you can find our key at https://www.mozilla.org/security/#pgpkey—but then we're just going to add it to this bug because the developers working on it still will need to see it.

Comment 24

[Enrique]

It is not clear to me. So what exactly do you need to validate it?

After 4 years, I don't even know where I'll have that code...

Comment 25

[Daisuke Akatsuka (:daisuke)]

Attachment: Bug 1653041: Avoid storing too frequent access as history

Comment 26

[Marco Bonardo [:mak]]

We are moving development to a separate public bug, as it's a new feature that requires separate enabling and some time to bake in Nightly.
We'll return to this bug report at a later time once we can confirm we're able to ship a fix that will reach Release.

Comment 27

[Marco Bonardo [:mak]]

Development of an anti-flooding feature moved to public Bug 1891145.
The plan is to enable it in Nightly and let it bake for a bit. We can then use Nightly to test these related bugs.
If things look good, we can then enable it in Release, and finally mark these bugs as Resolved, or evaluate next steps.

I'm unassigning the bug for now, as development happens elsewhere.

Comment 28

[Marco Bonardo [:mak]]

History flooding prevention will be enabled from next Nightly, and will bake in Nightly for at least one version. so we should be able to use Nightly to verify the effect on these bugs (see places.history.floodingPrevention.enabled pref in about:config).
We can probably further improve in bug 661590, when the repeated hashes are effectively caused by a user action, as flooding prevention would likely let it go through seeing user interactions.
Another step in the right direction will be when in the future we'll bump up page rankings using effective interaction data, so the number of visits won't have such a predominant effect on the score.