Your backup system is under constant attack, more so than at any time in history. As discussed in last month’s blog about why your backups need to be immutable, there are several factors that can damage backup data once it has been written. It could be encrypted, corrupted over time, deleted outside of the backup interface (e.g. rm -r or DEL *.*), or deleted within the backup interface (i.e. expiring backups in the backup UI).
This blog will focus on the ways in which this damage could occur. In most cases, we will be discussing some kind of attack vector, such as social engineering, or the exploiting of a vulnerability in the operating system. But this will not always be true, as we will also be discussing damage caused by disasters or bit rot.
Social engineering
Social engineering is when a bad actor uses psychology to get someone to do something they should not do. The most well-known type of social engineering happening today is phishing, which is the primary method ransomware uses to infect your system. A bad actor gets you to download a file or fill out a form, and voilà – you have ransomware. If it’s not a ransomware attack, they may use phishing to gain your login information and execute some other kind of attack.
Operating system exploits
This attack vector can be divided into two subcategories: exploiting how something works, or exploiting a bug. An example of exploiting known functionality is how ransomware products use the Remote Desktop Protocol (RDP) to spread ransomware within a data center once a single system has been infected. The initial infection typically happens via social engineering, but spreads in the data center using RDP. Exploiting a bug would include things like using a zero-day vulnerability, which can be used to gain login access, execute commands, or escalate privileges. Once someone is able to escalate their privileges to superuser or administrator, all bets are off.
Backup application exploits
Just like operating system exploits, this can be divided into two categories: using the backup application as it is designed, and leveraging a bug/exploit. An example of using the system as designed would be the many backup applications that do not support multi-factor authentication, and where you log in to the application as root or administrator. Someone gaining the administrator password can log in, do a lot of damage, and log out without ever being detected. There are also occasionally exploits to the backup application itself that behave very similar to these operating system exploits.
Disgruntled employees
The previous three exploits involve a bad actor using their skills to gain unauthorized access to your system. The problem with a disgruntled employee is that they already have the access they need to cause damage. There have been many disgruntled employee attacks throughout history, and many more that went unreported. System and backup system administrators are human beings who sometimes get upset and may take out their anger on their employer. A disgruntled employee can be quite hard to stop, as they often have high levels of access to very sensitive data.
Physical exploits
Nothing can stop a bad actor that has physical access to your systems. This is why I said in the first blog post that there is no such thing as a 100 percent immutable system, because a blowtorch, gun, or explosive device doesn’t really respect the immutability flag on your file. Some physical exploits can be protected against, such as disabling USB boot, and the use of a bios password to prevent changing that, but if the attacker simply wants to wreak havoc – there is not much you can do.
Disasters
The same things that could damage your data center and computing environment can do the same to your backups. If your backup system is in the same data center as your production system, any disaster such as a flood, hurricane, or terrorist action will damage both systems. This is what happened in the OVH fire, where both the production and backup systems of that cloud provider were destroyed in the blaze.
Bit rot
The final thing that can do damage to your backups over time is referred to as magnetic degradation, or bit rot. This is a real thing that I have discussed in multiple blog posts and podcasts. There is no question that magnetic media degrades over time, and magnetic grains flip polarity and become a one when they used to be a zero – and vice versa. Some of this damage will be caught using higher-level error correction systems, but not all of it.
Types of damage and danger
The following table summarizes the four different ways that your backup can be damaged (discussed in the part one), and correlates that damage to the ways in which that damage can occur (discussed in this blog post). Social engineering, operating system exploits, and disgruntled employees are the most dangerous, because if they happen, they can do just about anything. They can encrypt your backups, delete them inside or outside of your backup system, or corrupt the files in a minuscule way that makes them unusable. If someone successfully exploits a feature of your backup application, it will typically only be able to affect data within that application. Someone with physical access to your backup system probably will not use it to encrypt your data, but could use it to delete or prematurely expire the data. Disasters can either corrupt or delete all of your backups, such as what happened in the OVH fire. Finally, bit rot can silently corrupt your backup data over time.
