Moderate VULN - OpenSSH_for_Windows_8.1p1 - Microsoft Office Security Feature Bypass

[danielcunn123]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest version
• Search the existing issues.

Steps to reproduce

Step 1.) Create document.

Step 2.) Generate a random name for the document.

Step 3.) Retrieve document stored on remote device with 'Secure Shell Copy' application.

Step 4.) Open the document.

[PROTECTED VIEW BYPASS SUCCESSFUL]

VIDEO: - https://youtu.be/RN1t5_em8-I

Expected behavior

Documents obtained via the Secure Shell Copy utility open in protected view.

Actual behavior

Documents obtained via the Secure Shell Copy utility open in unprotected view, without a log of the event.

Error details

Documents obtained via web browsers require the end user to explicitly disable the 'protected' view for individual documents, rather than access documents via 'unprotected' view by default - with a 100% success rate.. No matter the file name nor location stored on the device.

Environment data

**REFERED BY secure@microsoft.com**


Tested on three system configurations:
No policy
Microsoft Windows 11 Security Baseline + MSOffice & apps + ADMX
STIG GPO Windows 11 Security Baseline + MSOffice & apps v2r4 + ADMX

Reproduceable with all GPO configurations.
The absolute path of C:\Windows\System32\OpenSSH\scp.exe was used, as it’s the same as typing scp in command/terminal window.

Note, this Document is shared within the same network and no documents are added to the 'Trusted Documents' nor 'Trusted Locations'.

Video demonstrates the generation of two documents on a Ubuntu machine within the same network, both documents with newly generated random file names. As shown, the document obtained via the Web browser on the Windows machine opens in protected view, whereas the Document obtained via Secure Shell Copy results in opening the document in unprotected view.

It is unsure why documents obtained via SSH are default trusted without a log, not requiring user interaction. This affects all Microsoft Office applications and file formats, not limited to Word.

Version

OpenSSH Version OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2 - Office Version 2205 (build 16.0.15225.20172) - Windows 10, 11 (build 17763.253, build 22000.675)

Visuals

[mgkuhn]

Is every command-line tool that downloads a file via any kind of protocol, or unpacks any kind of downloaded file, now supposed to add the Mark-of-the-Web (MOTW) metadata to the files it creates? Even if it's not from “the web”? If so, you would have to add this function not just to scp/sftp, but also to Subversion, Git, Rsync, and a ton of other remote file copying, file sharing, file synchronization and file backup tools. A quite wide interpretation of “the web”.

Is the exact security policy that is meant to be implemented here documented somewhere?

[mgkuhn]

Could also be solved by implementing something like the Biba Integrity Model in the kernel: as soon as a process has received any data via the network, any file that this process writes to from then on is marked accordingly as having potentially been influenced by data received from the Big Bad Internet. And any process that reads from such a file as well.

[tgauth]

MOTW is a defense-in-depth security feature, per documentation at https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria.

[mgkuhn]

per documentation at https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria.

Thanks for the link. The policy is defined just states that the Mark of the Web (MOTW) is a user-safety feature to

Prevent active content download from the web from elevating privileges when viewed locally

However, scp and sftp are not able to “download from the web”, because they do not speak HTTP. In this “security bypass” demonstration, all we have seen is a file transfer between an ssh server and an ssh client.

I guess a case could be made that in case the transferred file had already a Mark of the Web on the server, then it would be nice if scp/sftp were able to preserve that information and copy the Mark of the Web along with the file. That would require an extension of the SFTP protocol used, such that it can also preserve Alternate Data Stream information such as Zone.Identifier when transferring a file.

[mgkuhn]

The proposed patch always adds

[ZoneTransfer]
ZoneId=3

to the NTFS alternate data stream (ADS) Zone.Identifier, independent of where the file came from. And the user has no control over that behaviour. That seems a bit crude and potentially quite disruptive to me. What if I want to use scp within my trusted zone to disseminate legitimate Word documents to different machines?

The way the Mark of the Web was meant to be used is that a web browser queries an API such as IInternetSecurityManager::MapUrlToZone to look up the zone index for a URL. There are existing mechanisms to allow administrators to define what these zones are. However, since scp/sftp have nothing to do with the web, they don't deal with HTTP URLs. I guess one could abuse this mechanism by converting an SCP/SFTP path into a URL, such as ssh://user@192.168.1.10 or sftp://user@192.168.1.10/path/to/file. There even exists a provisional URL scheme registration by @dthaler for ssh:.

[mgkuhn]

Does curl (to pick another file transfer tool shipping with Windows) add a Mark of the Web?

I can't seem to get one:

C:\Users\mgkuhn>curl -O https://datacenter.iers.org/data/latestVersion/16_BULLETIN_C16.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1528  100  1528    0     0   6623      0 --:--:-- --:--:-- --:--:--  6643

C:\Users\mgkuhn>powershell
PS C:\Users\mgkuhn> Get-Content 16_BULLETIN_C16.txt -Stream Zone.Identifier
Get-Content : Could not open the alternate data stream 'Zone.Identifier' of the file 'C:\Users\mgkuhn\16_BULLETIN_C16.txt'.

And (unlike scp) curl is a web tool ...

[mgkuhn]

Overall, I'm not convinced yet that this is actually a vulnerability and that the proposed simplistic fix wouldn't cause more harm than good. The Mark-of-the-Web mechanism was intended for naive GUI users, whereas anyone who can use a command-line tool such as scp/sftp surely can also use PowerShell to edit or delete the ADS Zone.Identifier, right?

Can someone give a full scenario, where always adding the Mark-of-the-Web would actually/realistically prevent an attack? The Youtube video doesn't show anything resembling an actual attack.

[mgkuhn]

Another concern with the proposed patch is that it prevents/deletes the entire download if no Mark-of-the-Web can be added to the downloaded file. That effectively blocks any download onto a non-NTFS filesystem, right? Some legitimate users might be quite surprised by this, e.g. if they try to use scp to download a file directly onto a FAT32 USB stick, to install it elsewhere.

[NoMoreFood]

For what it's worth, agreed with @mgkuhn on this one on all counts.

[danielcunn123]

Is the exact security policy that is meant to be implemented here documented somewhere?

Are you referring to what's mentioned in the report?

If so these are the security profiles/GPOs available from Microsoft and DoD Security Technical Implementation Guide.

Such policies harden an environment, preventing potential zeroday attacks, compared to a system without an enforced security profile.

Microsoft Windows 11 Security Baseline + MSOffice & apps + ADMX
STIG GPO Windows 11 Security Baseline + MSOffice & apps v2r4 + ADMX

[mgkuhn]

Can confirm MOTW is not preserved with documents obtained via secure copy & curl, even though documents have existing MOTW.

That is not surprising, because both scp and curl were originally Unix tools, and in Unix a file is little more than just a single sequence of bytes, without any “alternate data streams” (ADS) or similar free-form metadata stores. (Although many Linux file systems have now extended attributes, these are rarely used beyond configuring the filesystem itself.) ADS were introduced into NTFS originally to mirror Apple's resource forks (later extended attributes) for the purpose of Windows NT being able to act as a file server for macOS clients. Windows XP SP2 and Internet Explorer then introduced the Zone.Identifier feature, making use of these extended attributes to mark files as having been downloaded from the Internet, and Apple then added to Safari a similar facility to add an com.apple.quarantine attribute to files downloaded from the Internet in Mac OS X 10.5 (2007), and in 10.7 (2012) added a “gatekeeper” that warned users about executing files downloaded with a web browser. I've not seen anything similar on Linux, although the existing mandatory-access-control labelled-security facilities of SELinux probably provide more than enough mechanics to implement something like that in a rather thorough way.

But all of this has so far not been of any concern to Unix tools such as scp, sftp, ftp, curl, wget, rsync, git, subversion, etc., probably for several reasons:

• Command-line tools are targeted at a quite different user audience than GUI-web-browser user nudges designed to protect inexperienced users from themselves.
• While Windows, macOS, BSD and Linux all have extended attributes, there is no cross-platform standardization on how these are used, and therefore there has been little effort so far to add support for preserving extended attributes in such cross-platform file transfer tools.

Is it possible to apply patch specifically to remote documents with existing MOTW located on the sftp server rather than client-side patch – add MOTW to intranet origin documents?? Linux servers are N/A right..

Some more recent drafts of the SSH File Transfer Protocol (SFTP) had added a flag SSH_FILEXFER_ATTR_EXTENDED that probably was meant to enable communicating the content of extended attributes during SFTP sessions, but I don't know if this ever has been implemented and used in practice. I've not followed SFTP standardization in detail, but I got the impression that it stalled sometimes around 2006, and that many of the facilities added at the time to a flurry of drafts where never implemented by OpenSSH. I don't know if the existing, very brief SSH_FILEXFER_ATTR_EXTENDED spec is actually useable in practice. We could always have a look if there is a strong use case.

[tgauth]

Thanks for all the feedback!

The way the Mark of the Web was meant to be used is that a web browser queries an API such as IInternetSecurityManager::MapUrlToZone to look up the zone index for a URL. There are existing mechanisms to allow administrators to define what these zones are. However, since scp/sftp have nothing to do with the web, they don't deal with HTTP URLs. I guess one could abuse this mechanism by converting an SCP/SFTP path into a URL, such as ssh://user@192.168.1.10 or sftp://user@192.168.1.10/path/to/file. There even exists a provisional URL scheme registration by @dthaler for ssh:.

We will work on incorporating MapUrlToZone, rather than assuming the file comes from the Internet Zone.

Does curl (to pick another file transfer tool shipping with Windows) add a Mark of the Web?

I can't seem to get one:

C:\Users\mgkuhn>curl -O https://datacenter.iers.org/data/latestVersion/16_BULLETIN_C16.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1528  100  1528    0     0   6623      0 --:--:-- --:--:-- --:--:--  6643

C:\Users\mgkuhn>powershell
PS C:\Users\mgkuhn> Get-Content 16_BULLETIN_C16.txt -Stream Zone.Identifier
Get-Content : Could not open the alternate data stream 'Zone.Identifier' of the file 'C:\Users\mgkuhn\16_BULLETIN_C16.txt'.

And (unlike scp) curl is a web tool ...

Curl is owned by Windows Terminal if you'd like to open an issue there.

Another concern with the proposed patch is that it prevents/deletes the entire download if no Mark-of-the-Web can be added to the downloaded file. That effectively blocks any download onto a non-NTFS filesystem, right? Some legitimate users might be quite surprised by this, e.g. if they try to use scp to download a file directly onto a FAT32 USB stick, to install it elsewhere.

Good point - it seems like behavior from other tools is to silently fail and still write the file in this case, so we will do the same.

[matso42]

I'm a little afraid what this change will have for impact.
A non-domain joined machine may now need manual config of it's zone settings breaking the functionality it had with earlier versions. Multiply this with 1000 nodes in an environment and it's a potential nightmare

It also makes SSH on Windows a little less "SSH" since it doesn't behave in the same way on Windows and Linux.

Therefore I at least would like a config option to simply disable this change and keep the current behavior . We use SSH for deployment and automation and simply don't care about Office but I do care about keeping existing functions in my network