ID CVE-2020-2509 Type cve Reporter security@qnap.com Modified 2021-04-23T14:30:00
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
{"attackerkb": [{"lastseen": "2021-05-06T15:15:47", "bulletinFamily": "info", "cvelist": ["CVE-2020-2509"], "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: 4\n", "modified": "2021-04-24T00:00:00", "id": "AKB:D9826725-69EA-420F-9AB1-F16E3F0FDD68", "href": "https://attackerkb.com/topics/blXTLRqfIu/cve-2020-2509", "published": "2021-04-16T00:00:00", "type": "attackerkb", "title": "CVE-2020-2509", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}], "threatpost": [{"lastseen": "2021-04-05T19:23:45", "bulletinFamily": "info", "cvelist": ["CVE-2020-2509", "CVE-2020-9922", "CVE-2021-36195"], "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", "modified": "2021-04-01T19:53:04", "published": "2021-04-01T19:53:04", "id": "THREATPOST:050AFD1CCD4C82226651D8587E31824F", "href": "https://threatpost.com/qnap-nas-devices-zero-day-attack/165165/", "type": "threatpost", "title": "Legacy QNAP NAS Devices Vulnerable to Zero-Day Attack", "cvss": {"score": 4.3, "vector": "AV:N/AC:M/Au:N/C:N/I:P/A:N"}}]}
