Affected devices:

Probably all QNAP devices running the QNAP modified 3.12.6 kernel with
firmware older than 4.1.4 Build 0804.

Verified on TS-453S Pro and TVS-471, both with Firmware 4.1.4 Build
0522.

Probably fixed with Firmware 4.1.4 Build 0804 (incriminating message
gone, though there is no notice by QNAP that this security problem did
ever exist or that is was fixed, no kernel source available for
verification).

Severity:

Total compromise of disk access keys of encrypted volumes.

Just offline-copy the disks to gain instant full access to all
encrypted data.

Details:

QNAP is using modified linux kernels. The 3.12.6 kernel includes the
following modification in GPL_TS/src/linux-3.12.6/drivers/md/dm-table.c
function dm_table_add_target line 752 (from GPL_TS-20150505
-4.1.3.tar.gz, downloads via http://sourceforge.net/projects/qosgpl/):

#ifdef CONFIG_MACH_QNAPTS
printk(KERN_ALERT "dm_table_add_target start %s, start=%lu,
len=%lu, param=%s, type=%lu…\n", type, start, len, params, tgt
->type);
#endif

Now, if an encrypted device is unlocked, the following happens:
The GUI password is transformed to a LUKS password using a transform
similar to: mkpasswd --hash=MD5 --salt=YCCaQNAP

Then cryptsetup is called to decrypt the disk access key with the
password generated above and then to establish a dm-crypt target with
the disk access key. This leads to dm_table_add_target() being called
for the dm-crypt target. And the disk access key is then logged to the
kernel message ringbuffer.

Examples (actual keys obfuscated by X sequence):

[ 41.026684] dm_table_add_target start crypt, start=0,
len=3900772344, param=aes-cbc-plain
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0
/dev/md0 2056, type=18446744071589635488…

[139023.266397] dm_table_add_target start crypt, start=0,
len=9083850752, param=aes-cbc-plain
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0
/dev/mapper/cachedev1 4096, type=18446744071588529984…

This information is enough just to call dmsetup from a shell to gain
instant access to the encrypted volume. No knowledge of the user
supplied key is required. Changes of the user supplied key don't matter
as the disk access key stays the same.

To make this even worse QNAP devices log the kernel messages to an
unencrypted hard disk partition and rotate them there. Just look for
the location in /etc/init.d/klogd.sh - the on disk location is actually
a raid 1 device which uses (at least for 4 bay devices) all configured
disks. These log files as well as the kernel ring buffer are world
accessible.

And even when the log files are "deleted" due to rotation there is a
high probability to find the disk access key(s) with a standard
forensics tool.

Conclusion:

To easily access all encrypted data of a QNAP storage device running
the affected kernel one just needs an offline copy of the QNAP disks.
One could think of a variety of online attacks, too.

Every QNAP device running or having run the affected kernel should be
assumed to be fully compromised with regard to encrypted volume keys.

Disks of affected devices should be considered not being encrypted when
being disposed of and thus additional security measures may have to be
taken.

After installing a corrected firmware there are probably only two ways
of regaining confidentiality, both of which require a prior backup of
all encrypted data:

1. Use cryptsetup-reencrypt for a new disk access key from a shell.
   You will have to bring your own version including all required
   libraries as this utility is not included by QNAP.

2. Delete all encrypted volumes from the GUI and the recreate them.
   This implies to recreate all additional configuration as required.

Timeline:

2015/07/12 vendor notified
2015/07/13 receipt of notification acknowledged by vendor
2015/07/24 vendor contacted again

No further information from vendor since last contact attempt.
– Andreas Steinmetz SPAMmers use [email protected]