AAP for files on NAS?

Patrick, I submitted a Support Case #03156937 for this issue and got the following response in conclusion.

Hello Steve, 

Thank you for your email.

I understand your concern. I checked with my team regarding your concern. I would like to inform you that the Acronis True Image application will save the credentials for the SMB connection is saved in the registry of the computer which inturn may allow the access to other applications too as you mentioned. However, this is confirmed to be a design behavior for now. I will share this too as a feedback to our development team and will make sure that they are aware of this. 

Please let me know if there is anything else that I may assist you further. 

Looking forward for your response. 

This was in reply to an early reply I gave as below:

Subject: Re: [03156937] Acronis Active Protection does not protect .tib files stored on NAS 

Hello,
I cannot respond that this issue is resolved because that is not true, 
though I accept that this is a limitation in the current application 
design.  However, as expressed in my previous email, my major concern is 
that the very fact of doing a backup to my NAS drive exposes the files 
on that drive to potential malware attack because the SMB link to the 
NAS which is opened by True Image is not protected from use by any other 
application active in Windows. This in spite of the fact that only 
Acronis True Image has been given the credentials needed to access the 
NAS, and these credentials do not mirror those of any Windows user 
account.  This is a major security exposure in this product.

Hmm.  I'm not sure that person understands the problem.  Of course ATI is designed to use SMB as SMB must be used.  And so of course ATI inherits the security problems of SMB.  That's why it is a security exposure that AAP does not protect the NAS-based .tib files.  (Maybe there is no way AAP can protect those files, but it is still a security exposure.)

I guess I'll continue trying to devise schemes that don't assume protection from AAP.

Patrick, I suspect that they do understand the security exposure here for remote files but have not figured a way to fully protect them via AAP or to render their SMB use private only to ATI.

You are very welcome to open your own Support Case and cross reference my case number and this forum topic if you want to add your voice to this issue.

I have looked at using FTP as an alternative to using SMB with my Synology NAS but ATI does not support using Secure FTP which defeats having that enabled on the NAS.

Patrick,

SMB Encryption Security for SMB versions 2.0 and 3.0 can be set using Windows PowerShell.  This encryption can be set for either an entire server or an individual share.  This is not the same as data encryption but provides a layer of security for NAS shares unless the SMB 1.0 version is enabled as SMB 1.0 does not support SMB encryption.

SMB encryption should prevent any access to the share thus outside attempts would be greeted with an ACCESS DENIED message.  That should be sufficient to protect .tib files on an NAS device as long as SMB 1.0 is not in use.

Refer to the link here

The above link provides more information on SMB security for Server 2012 and SMB 2.0 and 3.0.  This would include Windows 10 Pro  You will also find ways to enable SMB encryption and check for SMB 1.0 being in use.

The (possible) problem with SMB security in Windows is that is opens a connection between a specific Windows userid and the NAS userid.  My impression from earlier tests run by several Acronis MVPs was that the Acronis SMB client is running under a very high level SID and essentially gives all users access to the share once the credentials have been authenticated.   And I recall that the connection remains open after use unless special hoops are jumped through.

I'm not sure if the SMB Encryption Security you mention is for a single transfer or for the duration of the connection.  (I assume the latter.  I don't think Windows has any interaction below the connection level.)  I'm absolutely no expert but I don't think this would protect against a malware attack while the SMB connection is open.

I am also not sure what the effect of enabling share-level security would have.  My NAS devices don't implement share-level authentication of any kind so I don't know what would happen if Windows required it.

Steve, I know we've discussed the FTP problems a little before.  I could live without the secure connection if I had to since my FTP connections would not go beyond my LAN.  Unfortunately, I have NAS - WD MyCloud Generation 2 - whose FTP server is incompatible with the ATI FTP client.  I have a case that is actively being worked on and only occasionally has an Acronis technician been able to get a successful backup.  Almost always ATI reports a connection failure (even though a connection is established and a few administrative exchanges take place).  I'm considering getting a different brand NAS. 

Your LAN should be and probably is a Trusted Network.  SMB Encryption is aimed at SMB traffic over untrusted networks.  It can prevent eavesdropping occurrences.  An attack on data in an SMB encrypted connection would be considered a "man in the middle" attack.  SMB encryption is meant to deal with such scenarios as quoted below:

"SMB Encryption should be considered for any scenario in which sensitive data needs to be protected from man-in-the-middle attacks. Possible scenarios include:

• An information worker’s sensitive data is moved by using the SMB protocol. SMB Encryption offers an end-to-end privacy and integrity assurance between the file server and the client, regardless of the networks traversed, such as wide area network (WAN) connections that are maintained by non-Microsoft providers.

• SMB 3.0 enables file servers to provide continuously available storage for server applications, such as SQL Server or Hyper-V. Enabling SMB Encryption provides an opportunity to protect that information from snooping attacks. SMB Encryption is simpler to use than the dedicated hardware solutions that are required for most storage area networks (SANs)."

Scenario two above applies here I believe.  Running SMB encryption however is probably beyond the capability of your NAS solution so may not be an option for you.  

I think in your case the best solution for you is to attach your device to your network when you need to perform a backup and once that completes detach the NAS.  I realize that may not work for you so have you looked into setting up a VPN for our NAS?  A VPN would secure the connection from man in the middle attacks on your LAN. 

I don't think that any kind of encryption scheme is going to address my concern.  I admit my knowledge level is pretty low so I may be worrying about nothing, but I think this is the danger:

1. An SMB connection is established between a pair of userids - one on the Windows platform and one one the remote device.  Once the remote user's credentials are provided and authorized the SMB connection is established and stays open.  Anybody on Windows running under the SID of the Acronis service can use that connection.
2. I believe the ATI backup task runs under the userid "NT AUTHORITY\SYSTEM" which is high enough that just about every service and user on Windows runs under it.  So just about anything on Windows has access to the remote share once the SMB connection is opened for Acronis.  And I believe the connection stays open once ATI is done with it.

This is more of a "man on the side" rather than "man in the middle" problem.  Even if the connection is encrypted it stays open.

I'm not at all worried that someone is going to read the backup data ATI is creating.  I'm worried that someone is going to delete, rename, encrypt, or otherwise modify the .tib files so that system recovery is impossible.

Taking the NAS offline after a backup is finished will certainly lessen the exposure but the contents of the share is vulnerable while a backup is being taken. 

The ideal solution, of course, would be that AAP would protect .tib files on a NAS share.  It could protect the files only from activity on the local Windows, but in my case only Windows PCs access the NAS and ATI 2018 is on them all.

I think your concerns are sound in this.  The current wisdom for backups is to not have backups only on destinations directly connected to a local system.  Cloud and non attached are what are most effective.  Preventative measures go along way as well.  Making sure that your software is fully patched on a continuous basis is paramount here.

Because of the very nature of network shares being just that, shared, it may never be achievable to use something like AAP for such purposes.  What I suspect however is that with AAP on a system actively looking for ransomware patterns, any attempt to gain Admin privileges would result in detection of such pattern prior to any access to LAN locations.  Obviously there is no guarantee of that of course so keeping a copy of your data unattached from your LAN is the obvious best defense. 

Bob, my concern in this matter is that I do not have any direct Windows shares to my NAS and never have had any.  However, when ATI backs up to my NAS using credentials that only exist on the NAS, then the files on the NAS are being left exposed and can be deleted via an Explorer session without any prompting for the credentials!  This is the heart of my support case that I submitted.  The risk may seem to be minimal but the concern is that any malware could take advantage of this security exposure and attack the backup files on the NAS, assuming that such got a foothold on my computer.

I totally agree with Steve and I'm not sure the risk is minimal.  There is already ransomware that targets unmapped remote drives so any remote drive is now at risk.  I'm not aware of any ransomware that targets .tib files but SMB gives ransomware access to those files.

Steve,

I have tried to duplicate your issue but am unable to log onto my Synology while a backup is running.  Could you send me a PM with step by step instructions?

Thanks

Randy, will need to leave the PM till next week as am currently on a break in North Devon so no access to the NAS via my local network.

Edit: See forum topic: Does AAP protect .tib files on unmapped NAS shares? that Patrick raised originally on this issue and that I referenced in my support case - this has some of the steps that I used to show the open access to my Synology NAS where using the PowerShell command Get-SmbConnection shows the connection and this can then be used to access and delete files on the NAS.

All,  I think that everyone here should check to see if SMB1.0 is enabled on their machines (on by default usually).  SMB 1.0 has vulnerabilities that will allow an attack.  SMB 2.0 and 3.0 have measures in place to prevent this.  There are valid reasons for leaving SMB 1.0 enabled on a system so users should proceed with caution here.  

Check this link for more on the subject.

HERE

I still see the potential for issue here.  The malware threat posed by file-less attack is very troublesome in this area.  A MITM attack could be run by one of the new variants of ransomware which are now able to use PowerShell itself to launch attacks!

Keep multiple backups in multiple locations including unattached to your local network if you can.

Bob, thanks for the link ref SMB1 - have disabled on my laptop but will have to wait to test until am back home on my local network with the NAS.

I did a little more checking into this and found the exposure not quite as great as I had remembered.  A Windows user has no direct visibility into this ATI SMB connection.  "Net Use" shows nothing and access via File Explorer requires the user to enter the share's credentials.  But the Powershell command (or cmdlet) Get-SmbConnection shows the connection and the user name ( NT AUTHORITY\SYSTEM ) that opened the connection.  Any task with Admin authority can schedule a task under that id to access the share with no additional presentation of credentials.  I assume any task that can perform ransomware activity already has Admin authority.

The  connection goes away shortly after the backup ends but that is not necessarily a small window of time.  I killed my NAS backup test after 18 hour.  ATI estimated it had another 17 hours to go for the backup.  (I'm very puzzled about that.  That's twice as long as the ATI backup using FTP took.  I can't believe a backup using SMB should take twice as long as using FTP.  I may have something else wrong somewhere.)

And by the way, that was using SMB2.  I have SMB1 disabled.

Steve,

Your welcome.  You can view SMB server side properties in PowerShell get-smbserverconfiguration Look for EnableSMB1Protocol : False     EnableSMB2Protocol : True

Patrick,

SMB 2 enabled also enables SMB 3 becuse they both use the same stack.

You do have a problem with your network I would say as that much time to backup your system as specified in your signature above is way to slow unless your running wireless?

Bob, I see the following for SMB1

PS C:\Windows\system32> Get-SmbServerConfiguration

AnnounceComment                 :
AnnounceServer                  : False
AsynchronousCredits             : 64
AuditSmb1Access                 : False
AutoDisconnectTimeout           : 15
AutoShareServer                 : True
AutoShareWorkstation            : True
CachedOpenLimit                 : 10
DurableHandleV2TimeoutInSeconds : 180
EnableAuthenticateUserSharing   : False
EnableDownlevelTimewarp         : False
EnableForcedLogoff              : True
EnableLeasing                   : True
EnableMultiChannel              : True
EnableOplocks                   : True
EnableSecuritySignature         : False
EnableSMB1Protocol              : False
EnableSMB2Protocol              : True
EnableStrictNameChecking        : True
EncryptData                     : False
IrpStackSize                    : 15
KeepAliveTime                   : 2
MaxChannelPerSession            : 32
MaxMpxCount                     : 50
MaxSessionPerConnection         : 16384
MaxThreadsPerQueue              : 20
MaxWorkItems                    : 1
NullSessionPipes                :
NullSessionShares               :
OplockBreakWait                 : 35
PendingClientTimeoutInSeconds   : 120
RejectUnencryptedAccess         : True
RequireSecuritySignature        : False
ServerHidden                    : True
Smb2CreditsMax                  : 2048
Smb2CreditsMin                  : 128
SmbServerNameHardeningLevel     : 0
TreatHostAsStableStorage        : False
ValidateAliasNotCircular        : True
ValidateShareScope              : True
ValidateShareScopeNotAliased    : True
ValidateTargetName              : True

Bob, determining the state of SMB1 support in Win10 appears to be a bit less straightforward than you imply - at least on one of my PCs.  For me a "Get-SmbServerConfiguration" shows EnableSMB1Protocol : True. 

But "Get-WindowsOptionalFeature –Online –FeatureName SMB1Protocol" shows
FeatureName      : SMB1Protocol
DisplayName      : SMB 1.0/CIFS File Sharing Support
Description      : Support for the SMB 1.0/CIFS file sharing protocol, and the Computer Browser protocol.
RestartRequired  : Possible
State            : Disabled

Under Programs and Features I have "SMB 1.0/CIFS File Sharing Support" unchecked so I was a bit panicked when I saw "EnableSMB1Protocol : True".  Maybe that means the ability to enable it is enabled.  (And boy!, is that giving Microsoft the benefit of the doubt!)

I realize that SMB 2 and SMB 3 support go together under the same option.  I mentioned only SMB2 because the NAS I'm testing with is old and does not have SMB3 support.

The test I was running did use a wireless connection but that doesn't explain everything.  The last full backup from that PC to the NAS in question - using FTP - took between 3 and 4 hours.  I'll do some diagnosis.

Boy, got a bit of a fire storm started here, Lol.

Basically what you have to know is that with SMB you have two sides to consider.  There is the Server side and there is the Client side.  The server side of the equation has been present since Microsoft started using NT as the basis for the Windows OS.  The Enterprise, Ultimate, Pro, etc. versions of these systems are basically slimmed down server versions.  Microsoft Server 2008 up corresponds to Windows 7 up in the simplest form.  In enabling/disabling SMB versions you must do so on both sides.  The easiest way to do this is with PowerShell.  There are other ways, Group Policy, Registry modification, can be used as well.

Steve,

Your screenshot shows that the SMB 1.0 Server is in deed disabled as indicated by the False statement.  For the Client side of SMB 1 looking at the link I provided earlier at the bottom of the article:

Disable SMB version 1.0 Client Configuration

By disabling the server side configuration as shown above, our Windows 10 system will no longer offer SMB v1 shares. The SMB client however is still able to attempt to connect to an external SMB v1 share on another server, unless we also disable the SMB v1 client. This is done by running the following commands in either PowerShell or Command Prompt with administrative privileges.

sc.exe config lanmanworkstation depend= bowser/mrxsmb20/nsi
sc.exe config mrxsmb10 start= disabled

This shows the steps necessary to disable the Client side of SMB 1.0  Both side need to be disabled here for SMB 1.0 to be rendered unusable.  As you can see the PowerShell commands entered for disabling the Client side show SUCCESS when executed properly.

Patrick,

Now for the Programs and Features SMB1.0 /CIFS File Sharing Support.  You may have noticed that this feature in the Programs and Features of Windows 8 - 10 can be expanded as shown below. 

Notice in my screenshot I have both Client and Server checked.  As you may recall earlier I stated that there are some good reasons to have SMB 1.0 on your PC.  When Windows 10 first hit the scene and the 10586 release came out in the Preview channel many users, including myself, found that they could no longer see other networked devices on their LAN in Explorer.  The fix was to enable SMB 1.0.  This of course exposed the type of vulnerability we are discussing here.  Be that as it may I needed to enable SMB 1.0 at that time to fix this issue.  About a year later Microsoft finally fixed that problem but to do so apparently you must have the SMB 1.0 features turned on in the the Program and Features settings or else you loose the ability to see networked devices (at least some of them) in Explorer.  This is the situation I have.  I am confident that SMB 1.0 is not working on my system as I can verify using the PowerShell commands talked about here that it is not.  Having said that if I turn off the settings in Programs and Features then I loose the ability to see some other network devices in my LAN.  I am confident of this as on my NAS which is a FreeNAS server machine I have the ability to set both minimum and maximum SMB Protocols used.  I have them set at minimum SMB 3.0 maximum set at 3.11.  So I know that no traffic gets to the device unless its running at least SMB 3.0.

Interesting / scary.  My Programs and Features SMB1.0 /CIFS File Sharing Support is not expandable.  It is just the single option.

The "Get-WindowsOptionalFeature –Online –FeatureName SMB1Protocol"  display shows "State: Disabled" so I'm guessing that is both client and server but I have no way of telling for sure. 

I need to keep SMB 2 turned on for now because 2 of my 3 NAS drives - the only ones I am successfully using - don't have SMB 3 support.

Patrick,

You must keep SMB 2.0 enabled or you will not have SMB/CIFS file sharing.  Since your Features option is not expandable my guess is that SMB 1.0 is not installed on your machine.  That is strange as it should be because that is the default.

What version of Win 10 Pro are you running?

In an Admin PowerShell run the following command:

Get-WindowsOptionalFeature -Online 

This will show all features and their status of your Windows installation.  You should see SMB1Protocol - Server - Enabled, SMB1Protocol - Client - Enabled, SMB!Protocol - Enabled.

If you do not see those then you have something else beyond what I know at this point going on.  The only thing I can think of is that SMB1 is not installed on your system but like I said, to the best of my knowledge that is the default.

I'm running Win10 version 1703 build 15063.726.

The only SMB info I see from a "Get-WindowsOptionalFeature -Online" command is 

FeatureName : SMB1Protocol
State       : Disabled

I'll go try it on another PC - the one I've been testing with.

I am running Windows 10 Pro version 1709.  My view may be new to this version.  I have checked on 2 different machine with same Windows version and both are the same view.

What does Get-SMBServerConfiguration  show for SMB1 and SMB2?

PS C:\WINDOWS\system32> Get-SMBServerConfiguration

AnnounceComment                 :
AnnounceServer                  : False
AsynchronousCredits             : 64
AuditSmb1Access                 : False
AutoDisconnectTimeout           : 15
AutoShareServer                 : True
AutoShareWorkstation            : True
CachedOpenLimit                 : 10
DurableHandleV2TimeoutInSeconds : 180
EnableAuthenticateUserSharing   : False
EnableDownlevelTimewarp         : False
EnableForcedLogoff              : True
EnableLeasing                   : True
EnableMultiChannel              : True
EnableOplocks                   : True
EnableSecuritySignature         : False
EnableSMB1Protocol              : True
EnableSMB2Protocol              : True
EnableStrictNameChecking        : True
EncryptData                     : False
IrpStackSize                    : 15
KeepAliveTime                   : 2
MaxChannelPerSession            : 32
MaxMpxCount                     : 50
MaxSessionPerConnection         : 16384
MaxThreadsPerQueue              : 20
MaxWorkItems                    : 1
NullSessionPipes                :
NullSessionShares               :
OplockBreakWait                 : 35
PendingClientTimeoutInSeconds   : 120
RejectUnencryptedAccess         : True
RequireSecuritySignature        : False
ServerHidden                    : True
Smb2CreditsMax                  : 2048
Smb2CreditsMin                  : 128
SmbServerNameHardeningLevel     : 0
TreatHostAsStableStorage        : False
ValidateAliasNotCircular        : True
ValidateShareScope              : True
ValidateShareScopeNotAliased    : True
ValidateTargetName              : True

That's that odd display showing "EnableSMB1Protocol : True" even though it is disabled.

I checked the other PC.  Same lack of expandable SMB1options.  However, if showed that I had not disabled SMP1.  I have done that now.

Some day I may be brave enough to go to 1709 but not yet.

I agree with the oddity of what this shows.  I assume that the SMB1 Protocol is present and available but is disabled.  The PowerShell commands that have been discussed here are a hard code way of dealing with SMB1 as a default installed feature.  The basics are that the SMB version used during a server/client transfer is negotiated between the devices upon connection.  If the client request an SMB2 session the server will  use SMB2.  So as I said before, in my case since I can specify the minimum level of Protocol used I set that at a static 3.0 and maximum 3.1.1.  I checked this to verify that when I run a backup or transfer data from my computers to my NAS it is actually using SMB 3.1.1 because they are both supported on the server and the client.  So it is obvious that the highest level of Protocol available on both the server and the client is what is used during a connected session. 

I did some checking on the differences in Features view we found but I have nothing definitive yet.

I have confirmed that the view of SMB1.0/CIFS in Windows 10 Programs and features - Turn Windows features on or off is a single entry for versions prior to Win 10 1709

This has changed in Win 10 1709 to Apps and features - Programs and Features - Turn Windows features on and off and is expandable as shown in the screenshot I posted earlier in this thread.

Just to add to the Windows Features discussion, mine show as:

I see the same as Steve Win 10 Pro 1709.

Ian

If your Windows features show as Steve's above, none checked, and you have not lost the ability to see network attached devices then all is well.

If however you have lost the ability to see one or more devices enabling the Server and Client sides here will solve that issue.  At least that is what I have found.  Devices that report themselves during device discovery via NetBIOS are what I have found are prone to this issue.

After enabling here use the PowerShell commands discussed previously to check that SMB1 is in fact disabled.

Ian, Steve, thanks for posting.