Windows 10: SMB exploitable by malware?

I have some backup software that takes backups to a non-mapped NAS share. While a backup is running the cmdlet Get-SmbConnection shows
Code: ServerName ShareName UserName Credential Dialect NumOpens ---------- --------- -------- ---------- ------- -------- MYBOOKLIVE Public PUGET-116877\Patrick PUGET-116877\Patrick 2.0.2 1 WDMyCloud IPC$ NT AUTHORITY\SYSTEM NT AUTHORITY\private 3.1.1 1 WDMyCloud private NT AUTHORITY\SYSTEM NT AUTHORITY\private 3.1.1 1[/quote] Does that mean that any malware that manages to run under NT AUTHORITY\SYSTEM has access to the data on the WDMyCloud\private share without having to know the share's credentials? The connection ends when the backup is done but the backup can take hours so any exposure that exists is there for quite a while.

:)

 

Windows 10 cannot connect to NAS Drobo 5N2

I turned off SMB 1.0/CIFS File Sharing Support under 'Turn Windows Features on or off' (Windows 10) after an article advised to do so to prevent exploits like WannaCry from abusing a vulnerability in it. After that, I was not able to connect to my DroboFS
anymore via \\<drobo address>, even though I could ping its IP address.

I turned SMB 1.0 back on, which restored connectivity to my DroboFS. I suspect other errors are related to patches or tweaks to Windows SMB 1.0 settings.

 

Merc Zboard keyboards are not working after Windows 10 update KB4038788 (&ever since KB4034674)

WannaCry spread because of people using older unpatched technology - it exploited a SMB vulnerability. Many hospitals were still running XP and did not have the patch for the exploit. It had nothing to do with a patch that was at fault, rather it was system
admins who due to budget issues, decisions made, had not upgrade or paid for XP patches.

This workaround - Steelseries Merc Keyboard driver alpham164.sys disabled after windows 10 creator update why? how to undo/force it? is disabling signed driver enforcement.

The best way to get Microsoft to fix a problem with a security patch is to call 1-800-microsoft and to open up a support case. It is not to disable security features.

 

SMB1 was exploitable yes but all versions of windows were quickly patched or were patched prior to the news breaking. I have set my Cloud MIrror to use SMB 3, so change it in settings.

 

Maybe you answered this and I just didn't understand (because I don't know much about SMB) but my specific question was whether any process running under NT AUTHORITY\SYSTEM had open access to the share while that backup was running. I thought that once a user/server pair was authenticated any number SMB connections could be opened without re-authentication between that userid and that server. I would love to hear I am wrong. (I apologize if you already told me I'm wrong but I didn't understand.)

 

Everything that is created by humans can be exploited. Just make sure that your system is updated, be aware of what websites you go to, do not open emails from unknown senders, especially attachments and keep a good system protection. NT Authority/System has to do with Kerberos. Nothing has open access to anything if the system is not allowed to just run on its own and do things that it is not supposed to.

For every time some exploit gets published about in media and spread through rumors, so many of us would be rich beyond our dreams.

 

I don't disagree with anything you said, but that doesn't answer my question. I think I'm fairly careful but I know I slip up some times. I'm trying to determine if I've found a vulnerability that I (and others) need to avoid. Assume I have backup software that runs under NT AUTHORITY\SYSTEM - SID(s-1-5-18) - and writes to private share on a NAS. (It's a safe assumption. I do.) Assume that the share is not mapped to any drive letter in Windows and that nothing but the backup software has the appropriate credentials to access this share. And assume the backup takes hours to complete. So Windows creates an SMB connection between user s-1-5-18 and the NAS SMB server. If I understand SMB correctly (And I really hope I don't!) any task running under s-1-5-18 can open a new connection to that share without giving the credentials as long as that original connection is open. Is that correct? If so, malware could delete, rename, encrypt, or otherwise mess with files on that share as long as the backup is running if the malware is running under s-1-5-18. And there are a number of web pages explaining how to schedule tasks under NT AUTHORITY\SYSTEM. My hope is that someone will tell me I'm wrong.

 

So do you have a problem with your machine or are you just asking about a process. If you want to know more, I would suggest going to Microsoft's Technet website for that information if you want to know more. Nothing should be asking NT Authority System for anything through a website, unless you have saved a login for Kerberos.

 

No,I have no problem (that I know of). I just happen to have a (valid) service running under that id that opens a a long lived SMB connection with a NAS server. I would like to keep that share isolated from other Windows tasks but I believe any task running under that id has access to the share without having to provide access credentials. I see that as something malware could exploit.

I found the following description of NT Authority\SYSTEM (at least for Win7):
NT Authority\SYSTEM a.k.a LocalSystem account is a built-in Windows Account. It is the most powerful account on a Windows local instance (More powerful than any admin account).

Most of the System level (Windows Services) services and some other 3rd party services run in the account.
Sounds to me like it's a lot more than just related to Kerberos.

 

You are going to see that with SaMBa/CIFS/Kerberos. Nothing unusual about that when you actually look at what it is doing on the network at any given time. If you shut off those items that you do not need, such as backups, network shares, user accounts, you would not see as many and you would break the OS.

 

Good heavens. I think you completely misunderstand what I am trying to ask. I was trying to understand if SMB opened a path exploitable by malware. And the answer seems to be "Yes". On another forum - the Acronis True Image forum - a person was able to run a simple PowerShell script to delete files on a share while a backup (running under NT Authority\SYSTEM) was in progress. If the backup was not running the script got a prompt for credentials. This has been reported to Acronis but is probably an exposure of any product that takes scheduled backups to a NAS.

I'm not thinking about shutting anything off. I am considering not using SMB to communicate with any NAS that I want completely isolated from possible malware running on Windows. My original plan was to use FTP and I'm back to considering that.

BTW, where did you find reference to Kerberos relating to NT Authority\SYSTEM? I found reference to SQL and a number of non-network uses but have not found any reference to Kerberos.

 

No one misunderstands what you are trying to state, other than you think that this is suddenly new and do not have any questions that need to be answered. Anything that has been created by man can be exploited. If there is no question for a problem, then you have been told how to find further information on Microsoft's Technet website.

 

Well, it was new to me and I didn't know if it was real until after I started the thread.

 

It has been known for a long time how Kerberos has everything to do with Samba/CIFS and that you cannot even log into a network without Kerberos tracking user logins. It is the basis and has been since it was created.

 

When I said "Well, it was new to me and I didn't know if it was real until after I started the thread" I wasn't referring to Kerberos (or anything in particular relating to Samba's authentication mechanism). I was referring to the ability of a task to use an existing SMB connection as long as that task is running under the SID used to start the connection. It should have been obvious given the way SMB works but it never occurred to me.

QUOTE=bro67;1176105]It has been known for a long time how Kerberos has everything to do with Samba/CIFS and that you cannot even log into a network without Kerberos tracking user logins. It is the basis and has been since it was created.[/QUOTE]
I'm a bit puzzled by that statement. Kerberos is an authentication protocol. From what I've read (which may not be accurate) Windows uses Kerberos only in a "domain" environment with Active Directory as the Kerberos Key Distribution Center. I am not in such an environment.

In any case, I would expect some sort of "tracking" taking place in a product implementing an authentication protocol. If that tracking is logged, well, that's the software, not the protocol.