1848199 - Malicious Exploitation in Mozilla Firefox SSL Certificate View

Status: RESOLVED FIXED

(Firefox :: Security, defect)

Description

[salah eddine louffidi]

Attachment: bandicam 2023-08-09 22-06-31-672.mp4

Bug Bounty Report - Mozilla Firefox Certificate Vulnerability

Summary:

I have discovered a vulnerability in the Mozilla Firefox browser's "about:certificate?cert=[data]" feature that can potentially lead to malicious exploitation. This vulnerability allows an attacker to create a scenario where a victim is encouraged to click on a link within the certificate details, leading to unintended and potentially harmful actions.

Vulnerability Details:

The vulnerability lies in the "about:certificate?cert=[data]" feature of Mozilla Firefox, which displays SSL certificate information. By manipulating the "data" parameter, an attacker can craft a scenario where a clickable link is presented to the victim in the "Organisation" field of the certificate details.

Impact:

This vulnerability can have severe consequences, as it can trick users into clicking on a malicious link that appears to be from a reputable source. Victims may be more likely to trust the link as it is displayed within the browser's SSL certificate view. The attack is difficult to detect by conventional antivirus solutions, making it a potent vector for social engineering attacks and potentially leading to unauthorized data access, phishing, or malware installation.

Reproduction Steps:

Open Mozilla Firefox browser.

Type "about:certificate?cert=[data]" in the address bar and press Enter.

Observe the SSL certificate details page.

Craft the malicious scenario: Create a clickable link in the "Organisation" field that appears legitimate but leads to a malicious target.

Encourage the victim to view the certificate using the provided link.

Affected Components:

The vulnerability affects the SSL certificate view feature of Mozilla Firefox, specifically the way it displays certificate information and allows manipulation of the "data" parameter.

Technical Evidence:

I have prepared a proof of concept that demonstrates the vulnerability by crafting a scenario where a malicious link is embedded within the "Organisation" field of the SSL certificate details page. Screenshots and code snippets are available upon request.

Recommendation:

To mitigate this vulnerability, I recommend that Mozilla Firefox developers implement proper input validation and sanitization for the "about:certificate?cert=[data]" feature. Additionally, considering the potential severity of the impact, it might be prudent to reconsider generating the "data" parameter in the URL for this purpose.

CVE (Common Vulnerabilities and Exposures):

I suggest assigning a CVE ID to this vulnerability for tracking purposes. CVE-XXXX-XXXXX

Supporting Information:

Additional research and background information related to this vulnerability are available upon request.

Contact Information:

Please feel free to contact me at [your contact details] for further discussion, clarification, or collaboration.

Remember to replace "[data]" with the actual parameter value you used during your testing. Additionally, make sure to include any relevant evidence, screenshots, or code snippets to support your findings. If you have any additional details or information, be sure to incorporate them into the report as well.

Reminder About Attached Video: As a reminder, I have attached a video demonstration showcasing the vulnerability in detail. This video provides a visual walkthrough of the steps to reproduce the issue and highlights its potential impact. Please review the video for a comprehensive understanding of the vulnerability's severity and implications.

Feel free to incorporate these additions into your bug bounty report. If you have any more requests or need further assistance, please let me know!

Comment 1

[Daniel Veditz [:dveditz]]

"can trick users into clicking on a malicious link" is not a "Critical" vulnerability. Users click on links all the damn time and many of them try to be malicious. "Critical" is if that link can give them malware without any interaction after the navigation.

I have prepared a proof of concept that demonstrates the vulnerability

A video is not a PoC, though they can be useful for making sure everyone has the same understanding of what you're claiming.

Reproduction Steps:
Type "about:certificate?cert=[data]" in the address bar and press Enter.

The URL you added to the URL field of the bug is a better "proof of concept" -- I apologize for not seeing it earlier. For convenience and clarity I'll repeat it here: about:certificate?cert=MIIDDDCCAnWgAwIBAgIBADANBgkqhkiG9w0BAQ0FADCBojELMAkGA1UEBhMCbWExCzAJBgNVBAgMAnNhMR4wHAYDVQQKDBVodHRwczovL21hbGljaW91cy5jb20xMjAwBgNVBAMMKUdvIHRvIHRoZSBsaW5rIGluIE9yZ2FuaXphdGlvbiBuYW1lIGZpZWxkMQswCQYDVQQHDAJzYTELMAkGA1UECwwCc2ExGDAWBgkqhkiG9w0BCQEWCXNzQGZmLmNvbTAeFw0yMzA4MDkyMTA0MDdaFw0yNDA4MDgyMTA0MDdaMIGiMQswCQYDVQQGEwJtYTELMAkGA1UECAwCc2ExHjAcBgNVBAoMFWh0dHBzOi8vbWFsaWNpb3VzLmNvbTEyMDAGA1UEAwwpR28gdG8gdGhlIGxpbmsgaW4gT3JnYW5pemF0aW9uIG5hbWUgZmllbGQxCzAJBgNVBAcMAnNhMQswCQYDVQQLDAJzYTEYMBYGCSqGSIb3DQEJARYJc3NAZmYuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4ZVpzGwSgV2pN7f96YlU1Ef%2Bx3vsD9QW%2F1w2YmZfOUsJwYXoZozTb6Im1hacwF2V8L9OTp7yHpDuvHsrxbEkXfDKOSO5ALn5GVsAzRoMHEdblbpTqhKN6fRK5HVWv6WevnZvfmQvNlTFvHxrlhgGy7e5EHVbY6SlMBZwznEOJeQIDAQABo1AwTjAdBgNVHQ4EFgQUTpvkvYgIOx0js43kFLrCk6JVIi0wHwYDVR0jBBgwFoAUTpvkvYgIOx0js43kFLrCk6JVIi0wDAYDVR0TBAUwAwEB%2FzANBgkqhkiG9w0BAQ0FAAOBgQBt1MgEeBOVzeKnMUxALp5gKU0sT5Z25QuJ4PUjsvWdwPgeMqFJXinN7muXMCbmIUsLUjNSCtqTxQ96T8myXpo5O8VuSOoDTK7kxN2ySTx%2FT0VqKp9qx%2B0jpMg2FvvGFgutzMlqbA10D6N7GLMBqOA4%2Fi0rjXwRqLbuBmN2SLRNCw%3D%3D

Create a clickable link in the "Organisation" field that appears legitimate but leads to a malicious target.

When you say "link" you mean "url", right? That's what it looks like in the movie, and I don't see any way to create a spoofy link where the text says one thing but the href= goes somewhere else. The link will always go exactly where it says it goes, but through old-school phishing techniques it might look "similar enough" to something legit.

I recommend that Mozilla Firefox developers implement proper input validation and sanitization for the "about:certificate?cert=[data]" feature.

It's impossible to tell from the movie: what validation and sanitization is missing? The viewer parses and displays the contents of certificates. You appear to have passed it a validly formed certificate, which Firefox correctly parsed and displayed. The movie doesn't appear to show a validation problem such as XSS or HTML injections. The viewer could weed out a lot of badness if we could limit the display to validly signed certificates, of course, but one of the most common uses of that viewer is to take a look when a user encounters a certificate error! By definition we already know it's not going to validate at that point, but we still have to display the contents.

Granting that you could make up a certificate that looks like anything, how do you go from that to a user opening it in some fashion where they're inclined to trust it and the links it contains, and then want to click on those links? There is no way for a web page to open an about:certificate URL. The only way to get there is through Firefox features (which would not give you an opportunity to substitute your fake URL), or getting the user to copy your link, manually paste it into a URL bar, and open it (drag and drop would work, too). It can't be that the link destination contains an exploit, because you could have any page with a "Click here to win a prize" link and collect victims a lot easier. So the destination has to be a scam of some sort that is bolstered because the user thinks it comes from a trusted place. But how do you get people to trust your certificate when they've gotten it in such an unorthodox way? Most users probably don't even know enough about certificates to trust that UI in the first place.

I am not seeing a Firefox vulnerability here. You have claimed a spoofing vector, but you left the actual spoofing part out of your report so it's hard to evaluate.

Comment 2

[Daniel Veditz [:dveditz]]

It might be a good enhancement for the certificate viewer to visually distinguish between certs we were able to validate and certs that have validation errors. Dana: WDYT?

Of course sometimes SSL connection errors happen where the certificate chain is perfectly valid on its own, but it's on the wrong site. That would be a problem because you can't tell that strictly from the certs, but if we pass that in as a parameter in the URL then a spoofer could, too. At least the certificate was valid enough for a trusted CA to have issued it.

Comment 3

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

I think it would be neat to have a sort-of visual certificate linter that detects and highlights problems with certificate chains (I think we actually already do some of this with e.g. expiration), but I would be wary of having the certificate viewer ever say "this certificate chain is good". Currently the certificate viewer is merely informative - it's not a security boundary, and I would be wary of making changes that alter that distinction.

That said, currently the certificate viewer linkifies any field it determines is an http(s) url (hence this bug), which doesn't seem that useful to me. For example, the OCSP URI is linkified, but clicking that link will never do anything useful. These fields are already selectable, so if the user wants to visit a URL in a certificate, they can copy/paste it themselves.

Comment 4

[Daniel Veditz [:dveditz]]

Fair point. I wasn't thinking it would say "this chain is good", but that it could say "this cert's signature is broken". But you're right that's not better. When you get to this page in the product, the chain we show is what we got from the site. But Firefox's determination about the validity of the site's certificate could be built on a completely different chain identified through PKIX. If we say "this is good" people could infer that all part of what's shown are good when, for example, the specific intermediate served by the site is actually invalid. If we say "this is bad" but then Firefox loads the site without complaints anyway because we found a good chain through a renewed intermediate, people who didn't understand—and who understands PKIX?—might start to distrust Firefox.

Better to leave this a simple viewer

And also turn off the auto-linkification of url-shaped text.

Comment 5

[Daniel Veditz [:dveditz]]

auto-linkification was added in bug 1573133.

Comment 6

[salah eddine louffidi]

Hello,

the bug is confirmed or not ?

Comment 7

[Daniel Veditz [:dveditz]]

The "needinfo" flag (you should have received email about it) meant that we were waiting on you to answer our questions, but you cleared it without answering. I asked several specific questions in comment 1 to make sure I was understanding your claim and that I was not underestimating the ability of a clever spoof. But at this point we are left in the same unsure state:

I am not seeing a Firefox vulnerability here. You have claimed a spoofing vector, but you left the actual spoofing part out of your report so it's hard to evaluate.

we agree that the certificate viewer turns url-like strings into links (intentionally: see comment 5). A couple of us agree it's not useful and should be removed. What we're missing is how you would get that page in front of a victim in a way they would trust and want to click on those links. It seems way more difficult than using some social media click-bait to get someone to click on your fake https://bard.google.com/q=How+do+I+get+someone+to+click+on+a+link or whatever site you use as bait, and any webpage can already do that.

So our question is: can you demonstrate how you would fool a user using this (a step by step scenario), for a user who wouldn't be fooled by creating a random page like https://crt.sh/?id=5759164956 with booby-trapped links in it.

Comment 8

[Daniel Veditz [:dveditz]]

Dana removed the linkification in bug 1848471

https://hg.mozilla.org/mozilla-central/rev/ebd5d95f8205

Comment 9

[salah eddine louffidi]

I'm happy to know that issue is resolved :)

Comment 10

[salah eddine louffidi]

Do you consider this as Cve as you made correction for the bug???

Comment 11

[Frederik Braun [:freddy]]

To be completely honest, this a very useless spoof. We will not issue a CVE and we will not pay a bounty, but we're happy to include you in our bug bounty hall of fame. We usually work on the HoF per quarter, so it may take some time until your name shows up.

Comment 12

[salah eddine louffidi]

Thank you for your prompt response and for considering my report. I understand your decision not to issue a CVE or pay a bounty for the reported issue. I appreciate the opportunity to be included in your bug bounty hall of fame, and I'm honored to have my efforts acknowledged in this way.

I'm committed to improving my skills and contributing to the security community. In the coming days, I will continue my research and strive to identify and report valid vulnerabilities that meet your criteria. I'm eager to collaborate with you further in the future and help enhance the security of your systems.

Comment 13

[salah eddine louffidi]

I appreciate the opportunity to be included in your bug bounty hall of fame, and I'm honored to have my efforts acknowledged in this way.

Comment 14

[salah eddine louffidi]

(In reply to Frederik Braun [:freddy] from comment #11)

To be completely honest, this a very useless spoof. We will not issue a CVE and we will not pay a bounty, but we're happy to include you in our bug bounty hall of fame. We usually work on the HoF per quarter, so it may take some time until your name shows up.

hello can i know if my name "(SALAH EDDINE LOUFFIDI )(https://www.linkedin.com/in/salah-eddine-louffidi/)" is shows up

Comment 15

[Daniel Veditz [:dveditz]]

Bulk-unhiding security bugs fixed in Firefox 119-121 (Fall 2023). Use "moo-doctrine-subsidy" to filter