1710986 - Malicious website can trigger a download on another website and hijack its trust

Status: NEW

(Firefox :: Downloads Panel, enhancement, P5)

Description

[sworddragon2]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

1. In about:preferences#general set Firefox to always ask where downloads should be saved to.
2. Go to https://keepass.info/download.html
   2.1. If affected apply your Cookie/GDPR settings as desired (declining all is sufficient).
3. Click the button do download the newest installer for Windows (currently version 2.48.1).
4. You will be forwarded to https://sourceforge.net/projects/keepass/files/KeePass%202.x/2.48.1/KeePass-2.48.1-Setup.exe/download (or a similar link if the report is already too old).
   4.1. If affected apply your Cookie/GDPR settings as desired (declining all is sufficient).

Actual results:

After 5 seconds without user interaction (assuming Cookie/GDPR settings have already been applied or the steps are done again after applying them) a download was triggered from SourceForge.

Expected results:

See below.

Additional details:

A common action many people do from two websites I personally trust but on doing this today I noticed something is design-wise not right here and I began to think about it. But first to make things easier to understand it might make sense if I explain how a download usually looks here:

• I always setup Firefox to ask where a file shall be saved to.
• On triggering a download I check 2 things: If the URL begins with https[1] and if the domain is trusted.
  • If the URL is only available via http (which is rare) I check manually if it is also available via https. If it isn't the download is rejected as I can't trust enough its integrity anymore.
  • A domain is usually trusted if either the source of the download is known (e.g. if the download is directly triggered on mozilla.org) or if the site the download was triggered on is known (e.g. mozilla.org triggers a download on another domain like a CDN with a very cryptic name (which is not that uncommon)).

Probably most normal users don't care here but this is a simple and minimalistic effort to safely download files as otherwise a malicious executable can make it easily onto the system and getting userspace- or even kernelspace permissions once executed.

But what has this to do with the website of KeePass and SourceForge? Let's assume the website of KeePass would be a malicious one. It would possibly simply try to trigger a direct download to plant malware on its victims PC. But this would usually not work for me and others since any action in those steps would be untrusted/suspicious here.

But here is the thing this ticket is actually about: Since downloads are not bound to tabs and thus foreign downloads can appear on other sites and they can even be layered over each other, the (in this example malicious) website of KeePass on https://keepass.info/download.html could forward with the download button to https://sourceforge.net/projects/keepass/files/KeePass%202.x/2.48.1/KeePass-2.48.1-Setup.exe/download as it currently does. But additionally https://keepass.info/download.html could time the automatic download popup from SourceForge and just trigger another one very shortly after. If timed well (there might be some failure on some users) or if the user blinks/looked away for a moment he would think the download popup would have been triggered by SourceForge. Assuming the user does then safety-checks on the level I described above he might see some URL in the download popup like https://dl.sourceforgecdn114.net and then just think that this is just a common CDN address (which is indeed a pretty common scenario) and since the download (seemingly) got triggered by the host sourceforge.net and even the project URL points to a trusted project all is fine for him. But nothing is fine, as an issue in Firefox's download design caused now a malicious executable to make it on his PC.

Those a very theoretic thoughts and feel free to blame me if I made a mistake here. I wasn't even fully sure if I should post this issue at all but I guess it is better if it gets evaluated even if this should turn out to be a bogus issue.

I'm unsure how this issue could be solved in the most elegant way. Binding download popups visually strictly to the tab it triggered might be a solution - assuming I do not miss another potential way to abuse that. Alternatively the download popup could always show the URL the dowload got triggered from besides the actual Download-URL - but this might confuse non-advanced users.

Also I do not know how and if this issue affects somehow users that do not setup Firefox to ask on file downloads where to save them.

[1] I remember in the past on long URL's (possibly due to long domain names) the URL in the download popup was shortened and it was not visible anymore if the download was on the http- or https-protocol which made things slightly more insecure. A workaround was to just download the file first (without executing it) and then copying the download link from Firefox's Download Manager to check the protocol. I don't know if the bug still exists in current versions of Firefox as I was not able to find a long enough domain/URL to eventually trigger it now - otherwise I would have reported it right before this bug (as non-confident issue).

Comment 1

[Daniel Veditz [:dveditz]]

Lots of the web is built around sites triggering downloads from other sites, such as CDNs. Not sure how to make this clearer to users, but we're not going to be able to change that fact. UI improvement proposals don't need to be hidden.

Comment 2

[sworddragon2]

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

Lots of the web is built around sites triggering downloads from other sites, such as CDNs. Not sure how to make this clearer to users, but we're not going to be able to change that fact.

While it is true that many sites use CDN's here there is no reason at all to try changing this fact - because the issue here still lies in Firefox's Download-Design as described in the startpost.

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

UI improvement proposals don't need to be hidden.

Except if knowledge of the "UI improvement proposal" allows others to exploit this issue if they want to. Even I could not fully guarantee not falling for this exploit despite knowing how it works - the only really reliable workaround I could figure out so far would be avoiding having any other tabs open when a download gets triggered - or closing all other tabs and restarting the download.

Comment 3

[Sergey Galich [:serg]]

(In reply to sworddragon2 from comment #0)

...KeePass on https://keepass.info/download.html could forward with the download button to https://sourceforge.net/projects/keepass/files/KeePass%202.x/2.48.1/KeePass-2.48.1-Setup.exe/download as it currently does. But additionally https://keepass.info/download.html could time the automatic download popup from SourceForge and just trigger another one very shortly after. ...

:sworddragon2 thanks for filing this bug!

If we assume that KeePass is the malicious actor in this example, there is nothing to stop it from downloading malicious file without relying on Sourceforge or even having it located on Sourceforge. Timing second download seems like redundant effort when attacker can simply download bad.exe on the first try.

Once user trust some web site, they trust to any redirect that web site can do.

Moving this bug to give it visibility to folks working on download panel.

Comment 4

[sworddragon2]

(In reply to Sergey Galich from comment #3)

Once user trust some web site, they trust to any redirect that web site can do.

But the issue is the user might actually not trust the website while they trust the redirect (as in this example it should be usually very unlikely that malware will be unnoticed for a long time on SourceForge).

Comment 5

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

As said, this behavior is very common on the Web, thus the problem is we need a UI proposal on how we could improve users understanding of what is happening.
Without that proposal this isn't much actionable, so I'm adding a blocked-ux tag.
What do you think would help you figuring out what is happening, should the downloads panel show additional information? Note that things like showing the download url or domain wouldn't help, again because of CDNs.

Comment 6

[sworddragon2]

(In reply to Marco Bonardo [:mak] from comment #5)

What do you think would help you figuring out what is happening, should the downloads panel show additional information? Note that things like showing the download url or domain wouldn't help, again because of CDNs.

• With the new download panel improvements we skip now a dialog and see immediately the modal one that asks where to store the file. If the OS API's give us control over the title of this filepicker dialog we could show the origin of the tab triggering the download here (we probably do not need the full URL and could remove the target after the host (download.html in this example)). E.g. the title could be "https://keepass.info wants to download a file, please choose the destination...". That simple change should do the trick as the user would now see that the download was actually not the one from SourceForge that he expected to trigger and thus can abort the malicious download.

  • On my test it was possible to have the modal filepicker dialog and the download panel open at the same time so alternatively this URL could also be shown in the download panel but from the other ticket I remember space is a concern and I think showing this information in the filepicker title might be the better choice here (e.g. future changes with Firefox's download panel could more easily require a new evaluation of this issue).

• Another idea I had that might also be a neat improvement in general out of this ticket but also will on its own only mitigate this issue and not fully fix it is showing a download symbol on tabs who triggered a download (similar to the sound symbol where you can mute a tab). The remaining issues here are:

  • The filepicker dialog is always drawn on the very top of the screen with only a little offset to the left of the screen. For this specific improvement it would be helpful if the filepicker dialog would never draw over tabs which might be quite tricky to solve assuming we have control about the position of that dialog.
  • Then the user could have multiple tabs open so he might not even see the download symbol on a tab that triggers a malicious download - so we probably would always have to switch to tabs triggering a download. But this might also be difficult since we could have multiple windows open.
  • And then this would also only be useful if we would delay additional filepicker dialogs instead of stacking them on top of each other if multiple requests are done.

Maybe a download symbol in tabs would be the way to go here as well but making this foolproof with the follow-ups thoughts I listed above is difficult as those examples seem to be not a good solution. But I still think showing the URL that triggered the download in the filepicker title is the simple answer here.

Comment 7

[santosh kumar]

https://www.reliableresearchreports.com/world-decylalcohol-market-r5758
The Internet has become an integral part of our lives, providing access to information, services, and entertainment. However, it also presents significant risks, as cybercriminals continuously devise new methods to exploit unsuspecting users. One such method is the use of malicious websites to trigger downloads on other legitimate websites, thereby hijacking their trust and compromising user security. In this article, we explore the dangers posed by these malicious websites and the implications they have for user trust and online safety.