Attached Storage Forensics: Security Analysis of ASUSTOR NAS

March 25th, 2020 by Oleg Afonin
Category: «General»

ASUSTOR advertises secure AES encryption with a 256-bit key. According to the manufacturer, AES-256 encryption is made available through the entire range of its current NAS devices. Unlike other manufacturers, ASUSTOR is very upfront regarding the type of encryption employed by its NAS devices: “ASUSTOR NAS offers folder based military grade AES 256-bit encryption”. As a result, we’re once again dealing with folder-based encryption running on top of the open-source encrypting file system eCryptfs. We’ve already seen eCryptfs-based encryption in attached storage devices made by Synology and TerraMaster. Does ASUSTOR have any surprises, or will its implementation of folder-based encryption suffer from the many restrictions and limitations? Let’s find out.

Abstract and Summary

ASUSTOR was established as a subsidiary of ASUS, a Taiwanese manufacturer of electronics and computer peripherals. The ASUSTOR name is a combination of “ASUS” and “Storage”. As the name suggests, ASUSTOR manufactures a range of attached storage devices based on ARM64 and Intel processors. ASUSTOR devices run ADM, which in turn is based on the Linux OS.

ASUSTOR implements folder-based AES encryption with a 256-bit key length. The encryption key is produced based on the user-provided password. Users cannot change the encryption key. They are not allowed to change or revoke compromised passwords either. An encryption key file is produced and saved while setting up an encrypted folder. Users can unlock encrypted volumes by either typing the original plain-text password or by uploading the exported encryption key through the ADM user interface. There is no reference to SED (Self Encrypting Drive) support anywhere in the ADM GUI or the official documentation; as a result, we have to conclude that no SED support is available in ASUSTOR consumer NAS models.

ASUSTOR offers sufficient documentation that details the limitations and restrictions of folder-based encryption, and provides several relevant user guides. The company does not attempt to hide or obscure the relevant technical details.

Encrypting existing data: supported. Users can encrypt existing shares containing data.

Decrypting encrypted folders: supported. Users can decrypt encrypted shares.

Revoking compromised keys or changing leaked passwords: not supported. If an encryption key is compromised, users must take the quest of decrypting and re-encrypting the data, which may take many hours or even days.

Encryption key: plain-text password or key file (must be manually exported while the encrypted share is mounted and unlocked).

The original password is used as a Media Encryption Key. The concept of Key Encryption Keys is never utilized here; as a result, users cannot change their encryption password (aside of fully decrypting and re-encrypting the share).

Test Bench

We analyzed an ASUSTOR AS6302T device equipped with an Intel Celeron J3355 Dual-Core CPU and 2GB of RAM. A pair of non-SED WD Red HDD have used to set up the NAS perform the analysis. The NAS was running on the latest version of ADM available at the time of testing.

ASUSTOR NAS: eCryptfs Folder-Based Encryption

ASUSTOR utilizes folder-based encryption based on eCryptfs, an open-source stacked cryptographic file system. Detailed information on eCryptfs is available here. This is the same encryption scheme as used in consumer Synology NAS devices; as a result, ASUSTOR NAS devices have many of the same limitations as Synology devices. Namely, the length of encrypted file names is restricted to 143 Latin characters; storing files with longer file names is not permitted. Using Asian characters makes the possible file names even shorter. Once the encrypted share is created, users cannot change the encryption passphrase.

One limitation that ASUSTOR devices do not have compared to Synology NAS is the ability to use NFS mount for encrypted folders. While Synology explicitly rules out NFS support for encrypted shares, ASUSTOR only has this information in the Knowledge Base: “The encrypted share folder can not be mounted by NFS ( ADM 2.4 or later). The encrypted shared folder used by ADM 2.4 (or later) is eCryptfs, so the NFS mount will not support for encrypted share folder.”

Encrypting

Users can encrypt newly created shares as well as existing shares that already contain data. Folder-based encryption allows users creating multiple shares, each with its own unique password. If there are multiple users, each user can encrypt their home folder with their own password. However, the inability to change the encryption password or to revoke compromised encryption keys makes this approach dubious in the grand scheme of things.

Creating an encrypted share

This is how an encrypted share is created.

Once the user ticks the “Encrypt this shared folder” box, ADM displays a warning message that lists the limitations and restrictions of encrypted shares.

The encryption password may contain 8 to 64 characters.

Users can optionally mount the encrypted folder during startup; this setting can be changed at a later date (which is not a given on some other NAS devices we have tested). If this setting is selected, the encryption key will be stored on the device, which automatically renders any and all protection null and void.

The usual access permissions are configured.

Once created, the encrypted folder is mounted automatically.

Exporting the encryption key

The 32-byte (256-bit) encryption key is automatically exported into a .key file once the user encrypts the folder.

Mounting encrypted shares

The encrypted volumes can be mounted manually or automatically. The “Auto-mount at system startup” setting can be changed at any time by editing the encryption settings.

Mounting encrypted shares through the user interface supports the following two options.

  1. Mounting with the original plain-text password.
  2. Mounting with the exported key file.

Unmounting encrypted shares

Encrypted shares are unmounted automatically once the NAS is powered off or rebooted. Manually unmounting the encrypted share requires accessing the Web UI:

Permanent decryption

ASUSTOR does not utilize the concept of separate Media Encryption and Key Encryption keys. As a result, users cannot change the password or revoke compromised encryption key. In order to do that, users must physically decrypt the entire set of data and re-encrypt it with another password. At very least, ASUSTOR does support the decryption of encrypted shares:

Changing the password: impossible

Decades ago, manufacturers came up with a brilliant idea of separating the binary encryption keys that are used to encrypt and decrypt the data, and secrets that are used to unlock the encryption keys. This wonderful concept allows many things such as using any one of the several different passwords (or multiple types of authentication credentials, such as a smart card or a password) to unlock encrypted volumes. Sadly, this concept is rarely used by NAS manufacturers. ASUSTOR is no exception; users cannot change the password because the password itself is the Media Encryption Key.

Automatically Mounting Encrypted Folders

If the user had specified that the encrypted volumes are to be mounted automatically, they will be decrypted when the NAS starts up. You may reset the root password in /etc/shadow to gain access to the content of the NAS.

Manually Decrypting Encrypted Shares

Since ASUSTOR utilizes eCryptfs, accessing encrypted folders from another computer is easily available. Please refer to our Synology and TerraMaster guides for detailed instructions and the list of commands.

ADM keeps encrypted files in folders using the following naming convention:

/volume1/.@encdir/Test

“Test” would be the name of the encrypted share. The encrypted share is mounted as /share/Test

Encrypted share “Test” mounted:

root@Asustor:/volume1/.@encdir/Test # df -h
Filesystem              Size  Used Avail Use% Mounted on
rootfs                  874M   56M  819M   7% /
tmpfs                   914M   20K  914M   1% /tmp
/dev/md0                2.0G  384M  1.5G  21% /volume0
/dev/loop0              951K  9.0K  922K   1% /share
/dev/md1                5.5T  495M  5.5T   1% /volume1
/volume1/.@encdir/Test  5.5T  495M  5.5T   1% /share/Test

Encrypted share unmounted:

root@Asustor:/volume1/.@encdir/Test # df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs          874M   56M  819M   7% /
tmpfs           914M   20K  914M   1% /tmp
/dev/md0        2.0G  384M  1.5G  21% /volume0
/dev/loop0      951K  8.0K  923K   1% /share
/dev/md1        5.5T  495M  5.5T   1% /volume1

The encrypted folder was mounted with the following parameters:

/volume1/.@encdir/Test on /volume1/Test type ecryptfs (rw,relatime,ecryptfs_fnek_sig=704b798b4658aa6a,ecryptfs_sig=704b798b4658aa6a,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_unlink_sigs)
/volume1/.@encdir/Test on /share/Test type ecryptfs (rw,relatime,ecryptfs_fnek_sig=704b798b4658aa6a,ecryptfs_sig=704b798b4658aa6a,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_unlink_sigs)

To mount the encrypted share, execute the following commands.

Insert the passphrase into the keyring (you will need to provide the encryption passphrase):

ecryptfs-add-passphrase –fnek

Create a folder where you’ll be mounting the encrypted file system to:

mkdir /volume1/Test

Mount the encrypted folder in interactive mode:

mount.ecryptfs /volume1/.@encdir/Test /volume1/Test

While mounting, specify cipher: “aes”, key bytes: “32”, plaintext passthrough: n, filename encryption: y. Confirm filename encryption key by pressing “Enter”.

What Risks Are Covered by ASUSTOR Security Model

Similar to other implementations of NAS encryption, the security model employed by the ASUSTOR is stripped down to the bare essentials. I have the following remarks about the ADM security model.

  1. The possibility to store the encryption key on-device if the user enables the automatic mount option completely negates the protection of folder-based encryption. The lack of SED or full volume encryption makes gaining access to the NAS easy.
  2. This encryption model does not properly protect the data if one needs to send it out for repair/replacement or simply wants to sell the disk. The encryption metadata is duplicated in every file in the encrypted folder. As a result, the attacker can obtain a single file and run a (fast) attack on the encryption key.
  3. Unlike volume encryption schemes, folder-based encryption with encryption metadata duplicated in every file. “eCryptfs stores cryptographic metadata in the header of each file, so that encrypted files can be copied between hosts; the file will be decrypted with the proper key in the Linux kernel keyring.” (source) This makes secure erase of encrypted data impossible. To securely erase data encrypted with eCryptfs, one must either wipe (overwrite) encryption metadata in each and every encrypted file; wipe the full content of every file; or wipe the entire disk.
  4. Neither the encryption nor the password can be changed. Enough said.

Conclusion: ASUSTOR Folder Encryption

When it comes to attached storage encryption, we are still in the Stone Age. The lack of basic features, many of which we accept as a given, makes ASUSTOR encryption barely acceptable by modern standards. The functional restrictions and encryption metadata duplicated in every file makes this type of encryption hardly useful. ADM does not separate Media Encryption Keys and Key Encryption Keys, which makes password changes impossible. Security wise, the data would be impossible to decrypt without knowing (or breaking) the user’s encryption password (or, alternatively, without access to the exported encryption key).

Compared to Synology, ADM offers fewer options for storing and protecting the encryption keys. While Synology offers the ability to store the auto-mount encryption key on the device itself or on a USB drive (the latter using a separate passphrase to protect the key), ADM only offers the first way without any sort of additional protection.

At the same time, ADM encryption implementation is straightforward enough to appeal to some users. However, those same users may be put off by the need of re-entering their encryption password in the Web interface every time they power on or reboot the NAS. Should they opt to automatically mount encrypted shares on startup, they immediately sacrifice the protection.