New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users
Status: WontFix
Owner:
Closed: Sep 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: ----
Type: Bug-Security

Blocking:
issue 595834



Sign in to add a comment
Windows SmartScreen Filter Bypass
Project Member Reported by infe...@chromium.org, Mar 17 2016 Back to list
Windows SmartScreen filter bypass
Windows SmartScreen filter reacts differently based on the content of the file. For example, the
following bat file does not trigger the filter:
File name: exp.bat
Contents: f
Using this fact, we can bypass SmartScreen filter.
First, we prepare 2 bat files: f.bat which contains arbitrary code to execute, and exp.bat
that contains "f" as its content (like an example above). Now when we try to download and run
the bat files, f.bat gets filtered but exp.bat gets executed, eventually running f.bat .
We can simply test it. When the following javascript is run, two files are automatically
downloaded. We can see that f.bat doesn't get executed, but via exp.bat , f.bat gets run,
which spawns a cmd.exe .
f = document.createElement("a");
f.href = URL.createObjectURL(new Blob(["echo new
ActiveXObject('WScript.shell').run('cmd'); > cmd.js & wscript cmd.js"]));
f.download = "f.bat";
f.click();
exp = document.createElement("a");
exp.href = URL.createObjectURL(new Blob["f"]));
exp.download = "exp.bat";
exp.click();
 
This may not be our bug - waiting on confirmation from MS.
Status: ExternalDependency
Keeping external dependency for now.
Comment 3 by wfh@chromium.org, Mar 17 2016
the code in #0 actually wasn't used as part of this exploit, that is a generic way of running any command.

the code in question is inside original poc and is:

registerHandler("download", function (s) {
            var a = document.createElement("a");
            a.href = URL.createObjectURL(new Blob(["cmd"]));
            a.download = "exp.bat";
            a.click();
        }, true);

running this from download page creates exp.bat in download's directory, and smartscreen (or something) is marking the file with

[ZoneTransfer]
AppZoneId=4

this causes the file to open with no warning.
Comment 4 by creis@chromium.org, Sep 22 2016
Cc: awhalley@chromium.org timwillis@chromium.org wfh@chromium.org
What's the status of this one?  Has it been resolved?  I'm wondering if it's still a blocker for  issue 595834 .
Comment 5 by wfh@chromium.org, Sep 22 2016
Owner: asanka@chromium.org
I think we are planning on not asking SmartScreen for reputation of downloads.  asanka can you comment on these plans?
Labels: OS-Windows
I believe this issue should be resolved "Fixed"

This bug lacks some important context found in https://bugs.chromium.org/p/chromium/issues/detail?id=595834#c11 and #c12.

To summarize: This isn't a Windows SmartScreen Filter Bypass; this is more appropriately titled "Windows SmartScreen (By-Design) May Bypass Windows Shell Warnings." Microsoft made this change on purpose to reduce the number of warning dialogs users would see in day-to-day operation of their systems. However, the change also means that if Windows SmartScreen makes bad decisions, risk to users increases.

Regarding #5: I believe you're referring to the plan to potentially stop calling IAttachmentExecute to write the Mark-of-the-Web in favor of writing the MotW directly; this proposal is tracked in  issue 601187 , but it will not mitigate this issue. 

What happens here is:

1. Chrome writes the download to the disk and a MotW is attached (either via IAttachmentExecute or direct write of the Zone.Identifier alternate data stream, it does not matter).

2. When the file is executed via ShellExecute, Windows notes that it has a MotW. In Windows 7 and earlier, this will trigger the legacy Windows "Dangerous File" dialog box. In Windows 8 and later, if the OS-wide SmartScreen feature is enabled, SmartScreen will send the file's hash to a webservice and inquire as to whether or not it is "known safe", "unknown" or "unsafe". 

3a. If the file is known unsafe or unknown, execution is blocked with a modal prompt. 
3b. If the file is "known safe", then Windows bypasses the "Dangerous File" dialog and executes the file without additional prompts; in parallel, the Zone.Identifier Alternate Data stream is rewritten to replace the "ZoneId=3" value (meaning "Internet Origin") with "AppZoneId=4" (an undocumented value meaning that either SmartScreen deemed the file safe or the user chose to ignore SmartScreen warnings).

The exploit chain took advantage of the fact that the Windows SmartScreen service in step #2 was returning "Known safe" for files whose content hash indicated that the file contained the literal character "f". As a consequence, the downloaded batch file was deemed exempt from "Dangerous File" warnings and thus ShellExecute will invoke it with no prompts. The batch file containing the letter "f" then invokes another file containing malicious code; cmd.exe does not care that the other file has a MotW because MotW is only checked by the Windows Shell, not by the command processor or direct CreateProcess calls.

As far as I can determine, Microsoft no longer has the dangerous "Any file containing only 'f' is Known-Safe" hash rule in place. Even if the rule was still around, there's little Chrome can do about it other than complain and ask them to stop, because Windows itself owns the interpretation of the MotW and the resulting security dialogs. 

Chrome *could* do disruptive things like download every download into a subfolder with a randomized name (so that each download's execution context is "clean" and cannot take advantage of latent exploit content). 

Chrome's change (adding batch files to the list of types requiring user confirmation before storing on disk) would have mitigated this attack because the user would have to confirm the write of both f.bat and malware.bat.


Comment 7 by asanka@chromium.org, Sep 26 2016
Status: WontFix
In addition to #6, the current proposals that are on the table for mitigating current-directory attacks are only planned for execute-and-forget targets like installers. If the user is using something like "Save as..." then they can still place multiple disparate downloads in the same directory.
Project Member Comment 8 by sheriffbot@chromium.org, Jan 3 2017
Labels: -Restrict-View-SecurityTeam allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Sign in to add a comment