Command line option to disable/enable MIG


Author
Message
BGregory
BGregory
Proficient Member
Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)
Group: Awaiting Activation
Posts: 168, Visits: 335
I would like the ability to disable/enable MIG using a command line option.  I am currently using Robocopy to copy my images but I would prefer an alternative which requires temporarily disabling MIG.

Bob Gregory

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)
Group: Forum Members
Posts: 10K, Visits: 65K
I'm curious about this one too.  I wondered if that might have been deliberately disabled to make it harder for malware disable MIG programmatically even if malware had gained elevated permissions.  That would be a bit "security by obscurity" since if malware has elevated privileges, then in theory it could do something like uninstall MIG completely, but maybe that still has value.  Whether that value is worth the convenience penalty incurred in the exact situation that Bob describes is a separate question, though.

On only a somewhat related topic, I wouldn't mind seeing command line support for Consolidate.exe either.  Or if Macrium is feeling especially generous and ambitious, a full suite of PowerShell cmdlets as I requested here would be quite nice.

dbminter
dbminter
Most Valuable Professional
Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)
Group: Forum Members
Posts: 2.9K, Visits: 27K
Yeah, a command line way to disable MIG was probably purposefully left out of the function so it can't be abused by bad actors.  It would be like adding a command line switch to disable your AV application.  Any bad actor could disable your AV package that way and infect you.


I can think of something similar I would like to see.  A command line switch to enable/disable CBT.  The way it currently works, you have to uninstall/install CBT to get it out of the system/put it back in.  A command line switch could disable CBT from starting on a PC and then ask to restart so it can take affect could be just as effective.

BGregory
BGregory
Proficient Member
Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)
Group: Awaiting Activation
Posts: 168, Visits: 335
jphughan - 16 April 2020 9:06 PM
I'm curious about this one too.  I wondered if that might have been deliberately disabled to make it harder for malware disable MIG programmatically even if malware had gained elevated permissions.  That would be a bit "security by obscurity" since if malware has elevated privileges, then in theory it could do something like uninstall MIG completely, but maybe that still has value.  Whether that value is worth the convenience penalty incurred in the exact situation that Bob describes is a separate question, though.

On only a somewhat related topic, I wouldn't mind seeing command line support for Consolidate.exe either.  Or if Macrium is feeling especially generous and ambitious, a full suite of PowerShell cmdlets as I requested here would be quite nice.


Hopefully Macrium will chime in here.  I can see the vulnerability but then this mechanism would have to be known by the "bad guys" in order to do their dirty work.


jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)
Group: Forum Members
Posts: 10K, Visits: 65K
dbminter - 16 April 2020 9:13 PM
I can think of something similar I would like to see.  A command line switch to enable/disable CBT.  The way it currently works, you have to uninstall/install CBT to get it out of the system/put it back in.  A command line switch could disable CBT from starting on a PC and then ask to restart so it can take affect could be just as effective.

What is the use case for needing to toggle CBT frequently and programmatically?  CBT can be disabled without needing a restart to take effect because the driver always loads, even if you've got it configured not to actively track any changes on any volumes.  If you want to be able to disable and enable the loading of the driver entirely rather than CBT's actual function, that would seem to be an even narrower use case.

dbminter
dbminter
Most Valuable Professional
Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)
Group: Forum Members
Posts: 2.9K, Visits: 27K
I was more thinking along the lines that disabling it is "buried" in the Add/Remove function of the software.  That a command line feature might be more "intuitive" for those familiar with command line driven extensions.


Maybe a better suggestion is adding the remove CBT function as a function in the Settings.  That choosing Disable there could call the uninstaller to remove the feature.  That would be a little more "intuitive" to look in the Settings/Options versus having to uninstall the feature to disable it.

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)
Group: Forum Members
Posts: 10K, Visits: 65K
BGregory - 16 April 2020 9:51 PM
Hopefully Macrium will chime in here.  I can see the vulnerability but then this mechanism would have to be known by the "bad guys" in order to do their dirty work.

The counterargument to this is that Reflect is a reasonably popular backup application, and "file container" backups are a particularly attractive target for ransomware authors because if they can encrypt just those files, they've effectively encrypted all of the source files contained in them -- so if the attacker can get those and the original source copies, for a significant chunk of users, that would mean that all of their data was now inaccessible.  Sure, some users will have backups in locations that weren't reachable from their PC, but not everyone.

So if all that stands in a ransomware author's way is Image Guardian, and that can be disabled with a simple command line, then coding their malware to try that command if they detect a Reflect installation is an absolutely trivial amount of effort on their end, for a VERY high potential reward in the form of getting more people who might pay the ransom because you've locked up their backups.

The question is how trivial it would ALREADY be for a ransomware author to try to uninstall Image Guardian.  If that's already trivial (I hope not!), then a command line to disable it wouldn't seem to reduce security any further.  But if there are mitigations in place for that scenario even when dealing with malware that might have gained elevated privileges, then offering a simple command line to disable Image Guardian might be a major weakening.  As dbminter says, anti-malware applications typically don't allow themselves to be disabled that way, at least as far as I'm aware (which admittedly isn't all that far since I gave up third-party AV long ago, but I don't think Windows Defender can be disabled that way)

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)
Group: Forum Members
Posts: 10K, Visits: 65K
dbminter - 16 April 2020 10:08 PM
I was more thinking along the lines that disabling it is "buried" in the Add/Remove function of the software.  That a command line feature might be more "intuitive" for those familiar with command line driven extensions.

Maybe a better suggestion is adding the remove CBT function as a function in the Settings.  That choosing Disable there could call the uninstaller to remove the feature.  That would be a little more "intuitive" to look in the Settings/Options versus having to uninstall the feature to disable it.

I guess it depends on what you mean by "disabled".  I consider that to mean that CBT is installed but inactive, i.e. the "Enable Changed Block Tracking" setting in Reflect is unchecked.  By that definition, you don't have to go to Programs and Features to disable it.  I consider the Programs and Features mechanism to be the difference between "installed" and "not installed", which to me is materially different from "enabled" vs. "disabled".  And in fact even if you uninstall it or even if you never chose to install it in the first place, the CBT driver files are still sitting there in the Reflect application directory.

The difference between "disabled" and "not installed" is whether Windows loads the driver.  So basically right now, you can have CBT in the following states:
  • Not installed -- Files present on your system, but Windows never loads the CBT driver
  • Installed and disabled -- CBT driver loads but doesn't track changes
  • Installed and enabled -- CBT driver loads and tracks changes
If you were to get rid of the checkbox in Reflect's settings or replace it with a "Remove CBT" button, you wouldn't be able to switch between States #2 and #3 above -- and I can see why users might want to have the ability to turn tracking off and back on system-wide without having to restart their system to toggle that.  I've used that myself to compare the speed of Incrementals made with and without CBT, for example.  By having Windows always loading the CBT driver when it's installed, even if the user currently has CBT disabled in Reflect, that type of on the fly switching becomes possible.

But then there are also people like me who don't want the CBT driver running on their system at all (outside of testing situations).  So there is ALSO a place for offering a way to remove it (or at least prevent Windows from loading it even if the files themselves are still sitting on my drive).

I don't think it's unreasonable that the interface for completely adding or removing application components is inside Programs and Features.  That's a pretty standard design.  And having the toggle for the STATE of an installed component within the application is also standard design.  I think both are placed in reasonable locations and that both serve important and different purposes.

But I personally don't see a major use case for being able to enable or disable CBT programmatically.  That isn't to say it would be a BAD thing (apart from the fact that everything requires time and effort, both of which are finite resources that could otherwise be devoted to something else), but some use cases benefit more from the ability to do things programmatically than others.  I would argue that being able to toggle MIG this way would be more useful to more people than being able to do so with CBT, setting aside the security considerations of the former for the purposes of this discussion.

Do people really toggle CBT for general usage rather than testing/benchmarking?  People definitely might need to toggle MIG if they want to manually reorganize their backup files or something, but is there a similar use case for doing that with CBT?  And it would seem to me that being able to toggle whether the CBT driver loads at all would be an even narrower use case.

Edited 16 April 2020 10:30 PM by jphughan
BGregory
BGregory
Proficient Member
Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)Proficient Member (263 reputation)
Group: Awaiting Activation
Posts: 168, Visits: 335
jphughan - 16 April 2020 10:08 PM
BGregory - 16 April 2020 9:51 PM
Hopefully Macrium will chime in here.  I can see the vulnerability but then this mechanism would have to be known by the "bad guys" in order to do their dirty work.

The counterargument to this is that Reflect is a reasonably popular backup application, and "file container" backups are a particularly attractive target for ransomware authors because if they can encrypt just those files, they've effectively encrypted all of the source files contained in them -- so if the attacker can get those and the original source copies, for a significant chunk of users, that would mean that all of their data was now inaccessible.  Sure, some users will have backups in locations that weren't reachable from their PC, but not everyone.

So if all that stands in a ransomware author's way is Image Guardian, and that can be disabled with a simple command line, then coding their malware to try that command if they detect a Reflect installation is an absolutely trivial amount of effort on their end, for a VERY high potential reward in the form of getting more people who might pay the ransom because you've locked up their backups.

The question is how trivial it would ALREADY be for a ransomware author to try to uninstall Image Guardian.  If that's already trivial (I hope not!), then a command line to disable it wouldn't seem to reduce security any further.  But if there are mitigations in place for that scenario even when dealing with malware that might have gained elevated privileges, then offering a simple command line to disable Image Guardian might be a major weakening.  As dbminter says, anti-malware applications typically don't allow themselves to be disabled that way, at least as far as I'm aware (which admittedly isn't all that far since I gave up third-party AV long ago, but I don't think Windows Defender can be disabled that way)

I actually get all that and appreciate Macrium's foresight in trying to protect our backups, and yes, I do welcome the feature but I would like to be able to turn it on/off using the command line since all my backups run unattended over night. I'm forced to use Robocopy, and although it works fine, it doesn't fit in nicely with my backup procedures.
 
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search