How secure are the Macrium Reflect encrypted backups?

Ah, never mind. I found a naughty way to get the password: dump the process memory and extract all the strings with the given length.

Recognised it instantly after going through all the possibilities! Haha!

Click to expand...

Glad that worked for you, although I'm not thrilled to hear that it was apparently that relatively easy. I realize that Macrium recommends that XML be stored in a locked down location and that sensitive information has to live in memory at least for a while, but I'd still hope that there might be something that could be done so that discovering a cleartext password from the ciphertext version in an XML file would take someone more than an hour from asking the question to having the answer.

Click to expand...

Hello @john.p, thanks for weighing in. And just to clarify, I don't deserve credit for these findings. That belongs to Spatial here.

But speaking here as an observer and an IT consultant who has implemented Reflect for some of his clients, my concern is your last sentence that "If a the xml file can be accessed, so can the data to be protected." Before you wrote that, I would not have suspected that was so clearly the case. I certainly acknowledge the importance of storing definition files in a secure location to prevent unauthorized tampering, e.g. changing the source data selection, redirecting backups to a different location, configuring a malicious retention policy, etc. In fact I even delved into those types of threat scenarios in another thread where someone else brought to light that at the time, Reflect made it possible for regular users to launch Reflect interactively with SYSTEM-level privileges and also to leverage its pre-and post-VSS commands capability to do things such as starting an interactive PowerShell session. In short, Reflect back then could be used as a vector for a low-effort but high-impact privilege escalation attack.

However, even then I would not have guessed that an attacker who somehow gained access to an XML file containing an encrypted version of a backup password would be able to gain access to the cleartext so easily. I knew that Macrium would be able to do that trivially by virtue of having the key that Reflect uses to encrypt and decrypt that password -- although due to the risk of social engineering, I would hope that Macrium would have a blanket policy against providing that "service" to customers who might request -- but I would not have guessed that the plaintext password would be stored in memory in such a way that a user could get to it within an hour.

In terms of mitigations, I haven't attempted to reproduce Spatial's work myself and therefore don't know all of the technical details, but if this isn't already being done, would it be possible to purge the plaintext password from memory after it has been used to derive the actual AES key that will be used to encrypt the backup? That would at least limit the time during which the plaintext password is there to be retrieved in memory. Or would an attacker still be able to use software tools to capture data that was in memory even only briefly? (Note: I do realize that the AES key is a valuable bit of data in its own right, but since that must be available for the duration of the operation, I don't see as much opportunity to protect that. And I also realize that this risk isn't unique to Reflect, since whole disk encryption solutions for example must keep in memory the key for the unlocked disk.)

Click to expand...

glasskuter said:

When you ask "how secure", I would think that no one could put any kind of percentage number on "how" secure such backups would be. Encrypting backups is just one thing a user can do but other things in one's backup plan are more important than whether a backup is encrypted or not. (None of mine are, by the way, nor or any of my drives but that's just me.) Keeping multiple backups using multiple drives, testing that recovery media works and that the backups one makes are restorable, keeping at least one image stored in an off site safe place such as a safety deposit box or the cloud, and NEVER keeping the drive where your images are stored connected to the computer.

Click to expand...

CSharpDev said:

I'm more interested in how malware can actually decrypt the password-encrypted backup?

Click to expand...

glasskuter said:

It depends on how sophisticated a piece of malware is and exactly what the thieves are after.

Some of these criminals may not be interested in what's inside the files, but their goal is to extort money from the user. This type malware doesn't decrypt anything that is encrypted but adds it's own layer of encryption on top of yours, thereby holding backup files hostage along with everything else the ransomware code has access to. Once the attacker is paid, he may or may not provide the code to unlock his layer of encryption.

Other attackers want what's inside a users files. If a hacker manages to obtain the users encryption key or crack the encryption algorithm, then they can gain access to the data itself. He will then either use the data for nefarious purposes himself and/or sell that data to other criminals.

If a hacker is sophisticated enough he can do both, add his own layer of encryption to prevent the user from accessing his files AND crack whatever encryption protects the files to gain its contents.

Encryption isn’t foolproof. It’s possible for hackers to break an encryption code. They can also use malware and other attack vectors to gain access to our devices and networks. So, while encryption is a good tool to protect users, it’s not the end all be all silver bullet that will protect us from every threat.
Thus my last rule above, NEVER keep the drive where your images are stored connected to the computer. If it's not connected, attackers cannot get to the images.

Click to expand...

CSharpDev said:

Why do companies store images online then? They do have offsite backups too but they store them online too

Click to expand...