Oracle DBs and ransomware attacks

By Clemens Bleile

I had a discussion with a customer recently about the risk of running into an issue with ransomware encrypting data of Oracle databases. Just to quickly recap on what ransomware is:

Wikipedia: Ransomware is a type of malware from cryptovirology that threatens to publish the victim’s personal data or perpetually block access to it unless a ransom is paid. While some simple ransomware may lock the system without damaging any files, more advanced malware uses a technique called cryptoviral extortion. It encrypts the victim’s files, making them inaccessible, and demands a ransom payment to decrypt them.

In the last years ransomware has become more perfidious by
– searching for backups to encrypt them as well, because restoring non-infected backups were the only resolution in the past to ransomware encrypted data if you do not want to pay the ransom
– stealing sensitive data and then blackmail the victim to publish the stolen data if no ransom is paid

So how can you protect your database proactively to prevent becoming a victim of a ransomware attack?

The following list is not complete, but should give an idea on what an Oracle DBA may proactively do:

1. Protecting the data from becoming encrypted

It is very unlikely that a ransomware uses Oracle functionality to connect to a database. In almost all cases the ransomware tries to find data on filesystems or on block devices to encrypt it through normal reads and writes.
My customer actually uses Automatic Storage Management (ASM) and I proposed to use the ASM Filter Driver as a first protection against ransomware, because access to ASM-disks is only allowed using Oracle-Database-Calls then. You may e.g. check Blogs which show that even a dd or fdisk as root is not possible on the devices holding the data when the ASM Filter Driver is installed:

https://franckpachot.medium.com/asm-filter-driver-simple-test-on-filtering-2a506f048ee5
https://www.uxora.com/unix/admin/42-oracle-asm-filter-driver-i-o-filtering-test

Here an example trying to delete a partition, which is an ASM-device with fdisk:

[root@ol8-21-rac1 ~]# fdisk /dev/sdc
...
Command (m for help): p
Disk /dev/sdc: 2 GiB, 2147483648 bytes, 4194304 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb7b98795

Device     Boot Start     End Sectors Size Id Type
/dev/sdc1        2048 4194303 4192256   2G 83 Linux

Command (m for help): d
Selected partition 1
Partition 1 has been deleted.

Command (m for help): p
Disk /dev/sdc: 2 GiB, 2147483648 bytes, 4194304 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb7b98795

Command (m for help): w
The partition table has been altered.
Failed to remove partition 1 from system: Device or resource busy

The kernel still uses the old partitions. The new table will be used at the next reboot. 
/dev/sdc: close device failed: Input/output error

[root@ol8-21-rac1 ~]# 

In /var/log/messages I can see this:

Mar 22 22:18:51 ol8-21-rac1 kernel: F 4299627.272/220322221851 fdisk[98385] oracleafd:18:1012:Write IO to ASM managed device: [8] [32]
Mar 22 22:18:51 ol8-21-rac1 kernel: Buffer I/O error on dev sdc, logical block 0, lost async page write

2. Protecting backups from becoming encrypted

Besides storing backups on different servers it’s a good idea to use backup-solutions which make the backup immutable (read only) after it has been written. So you should check that your database backups are immutable. A NFS-location is usually not a good backup medium for that (there are measures to help for NFS as well though. Check here).

3. Protecting data so that it cannot be stolen

Encrypting your data using e.g. Oracle Transparent Data Encrpytion is a good idea, because stealing that data is useless without the key.

Depending on your configuration several other methods to protect against ransomware attacks are available. Here a couple of links concerning the subject:

https://phoenixnap.com/kb/immutable-backups
https://blogs.oracle.com/maa/post/protect-and-recover-databases-from-ransomware-attacks-with-zero-data-loss-recovery-appliance
https://ronekins.com/2021/06/14/protecting-oracle-backups-from-ransomware-and-malicious-intent/#more-7955

Summary: Ransomware may also affect database servers. A DBA should protect the databases he’s responsible for. Despites ASM Filter Drivers (AFD) issues (dependency on the Linux kernel, Bugs) the AFD could be a measure to protect your databases against ransomware attacks. Interestingely I haven’t seen any Blog or information yet about using AFD as a protection against ransomware.

REMARK: You may check the following MOS Note concerning the dependency of the AFD to the Kernel:
ACFS Support On OS Platforms (Certification Matrix). (Doc ID 1369107.1)
Even if the MOS-Note-title is about ACFS only, the AFD is covered as well.