Title:
    Multiple 'authorized_keys' entries in multiple QNAP products

Discovery Date:
    28 Jun 2013 - Discovery
    08 Aug 2013 - Secunia notified
    16 Aug 2013 - Secunia Vulnerability Coordination Reward Program (SVCRP) discontinued
    16 Aug 2013 - Trying to contact vendor
    23 Oct 2013 - CVE requested
    31 Oct 2013 - Vendor provides security/product contact
    31 Oct 2013 - Report sent to vendor
    05 Nov 2013 - Vendor responds as "Will not fix". See Vendor comments.


Author:
    Andrei Costin of "FIRMWARE.RE" project
    andrei@firmware.re
    andrei@andreicostin.com
    Vulnerability discovered using "FIRMWARE.RE" platform/service

Security advisory numbering:
    ACSA-2013-002
    
    CVE-2013-6276 (a procedure for building an image
sometimes results in the rsa-key-20020513 and rudy@mars keys remaining
in authorized_keys)
    
    CVE-2013-6277 (a different procedure for
building an image sometimes results in those keys plus three
@localhost.localdomain keys remaining in authorized_keys)
    

Vendor:
    QNAP / QNAP Security
    http://www.qnapsecurity.com/PressContact.asp
    http://www.qnap.com/


Product(s):
    VioCard-30 MPEG-4 Network DVR Card - Home, SOHO, Enterprise Video Surveillance Solutions
    VioGate-340(340A) - 4-channel network DVR server using the advanced MPEG-4 image encoding video chip to support 4-channel
    VioCard-100/300 - Digital network surveillance server


Product version(s) affected:
    F_VioCard30_2312_2.1.0.img
    F_VioGate340_2308_2.1.0.img
    VioCard300-RS_B4631/VioCard300-RS_B3722
    NOTE: Potentially other products affected as well. This list should be updated afterwards.


CWE categories:
    CWE-489: Leftover Debug Code
    CWE-798: Use of Hard-coded Credentials
    CWE-259: Use of Hard-coded Password


Vulnerability details:
    'authorized_keys' present in multiple QNAP products. This exposes the device users to the risk of being accessed in a 'backdoor' fashion by the owners of the private keys associated with the public keys listed in the 'authorized_keys' files. This also makes the owners of those keys good targets for private key theft.

    It is advised to remove the authorized_keys in a fixed update firmware. Also, it is advised for the private_key owners to change associated private keys and destroy all copies of private keys that might be of potential use to access the devices in a 'backdoor' fashion.

    Also, consult CWE listed above for more solutions advise.

    1) F_VioCard30_2312_2.1.0.img contains the following authorized_keys entries:
'80:aa:ed:ee:c0:63:68:09:eb:18:64:15:9d:d7:bf:03', '(RSA1)', 'rsa-key-20020513'
'ee:79:7c:6c:79:b7:9c:06:9d:fe:6c:e7:b2:c0:55:47', '(RSA1)', 'rudy@mars'

    2) F_VioGate340_2308_2.1.0.img contains the following authorized_keys entries:
'80:aa:ed:ee:c0:63:68:09:eb:18:64:15:9d:d7:bf:03', '(RSA1)', 'rsa-key-20020513'
'ee:79:7c:6c:79:b7:9c:06:9d:fe:6c:e7:b2:c0:55:47', '(RSA1)', 'rudy@mars'

    3) VioCard300-RS_B4631/VioCard300-RS_B3722 contains the following authorized_keys entries:
'80:aa:ed:ee:c0:63:68:09:eb:18:64:15:9d:d7:bf:03', '(RSA1)', 'rsa-key-20020513'
'ee:79:7c:6c:79:b7:9c:06:9d:fe:6c:e7:b2:c0:55:47', '(RSA1)', 'rudy@mars'
'40:1b:39:07:e5:92:ec:b2:b0:b0:14:a5:85:22:2b:f0', '(RSA1)', 'hugo@localhost.localdomain'
'98:a8:62:1c:35:67:c1:41:88:a9:b9:39:e5:54:e5:93', '(RSA1)', 'jasper@localhost.localdomain'
'04:86:8a:40:19:2d:4b:91:5f:c1:d3:c1:bf:5c:4c:2e', '(RSA1)', 'meiji@localhost.localdomain'
'80:aa:ed:ee:c0:63:68:09:eb:18:64:15:9d:d7:bf:03', '(RSA1)', 'rsa-key-20020513'
'ee:79:7c:6c:79:b7:9c:06:9d:fe:6c:e7:b2:c0:55:47', '(RSA1)', 'rudy@mars'

    Even thought vendor dismissed as "will not fix", we still thinkg there 
    might be user who can be exposed, hence will find this report helpful
    Please consider upgrading from affected models.
    

Vendor comments:
    1. The issues only happened in the the specific old models (7 year ago). 
    All the other models (at least for the recent 5 years) do not have this 
    kind of issues.
    
    2. We no longer keep the authorized keys.  We conducted a check to make 
    sure these keys are not kept on any of our servers. And we did not find 
    any of these keys.
    
    3. QNAP attaches great importance to information security and network 
    security. We would value it highly if customer still has security concern. 
    They can contact us by nvr@qnap.com.

CVE@MITRE comments:
A single CVE can be used for multiple firmware images only if the
observed security problem is identical. We cannot assign a CVE for a
general business-process problem such as "QNAP does not clear out
authorized_keys files as part of their release engineering." Here,
item 3 is different. For purposes of CVE, we will model this as two
issues. The first issue is that a procedure for building an image
sometimes results in the rsa-key-20020513 and rudy@mars keys remaining
in authorized_keys. The second issue is that a different procedure for
building an image sometimes results in those keys plus three
@localhost.localdomain keys remaining in authorized_keys. Please see
the two CVE assignments below.

In the future, if you find additional images with different
combinations of keys, please ask for separate CVEs for those also.

About the author/project:
    Firmware.RE is part of the Firmware Genome Project.        
    Firmware.RE is a free online service that:
        - unpacks, scans and analyzes almost any firmware package and facilitates the quick detection of vulnerabilities, backdoors and all kinds of embedded malware.
        - facilitates firmware mounting, modification, loading and emulation.
        - facilitates firmware vulnerability and backdoor discovery.
        - helps secure your embedded and internet-of-things devices.