{"uuid": "90b8f0b2-a9c1-4d2e-a394-e75352453b4d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2021-36195", "type": "seen", "source": "https://t.me/hacking_Attack/3429", "content": "Black Hat Ethical Hacking\nLegacy QNAP NAS Devices Vulnerable to Zero-Day Attack\n\nhttps://www.blackhatethicalhacking.com/wp-content/uploads/2017/11/black-hat-locks-and-electronics.jpg Legacy QNAP NAS Devices Vulnerable to Zero-Day AttackPost Views: 63 \nstyle=\"display:block\"\n data-ad-client=\"ca-pub-6620833063853657\"\n data-ad-slot=\"8337846400\"\n data-ad-format=\"auto\"\n data-full-width-responsive=\"true\"> \nReading Time: 1 Minute\nTwo critical zero-day bugs affect legacy QNAP Systems storage hardware, and expose devices to remote unauthenticated attackers.\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\nPatches for current model QNAP devices need to be downloaded from the QNAP download center and applied manually. Zero-Day DisclosureBoth bugs were disclosed on Wednesday by SAM Seamless Network researchers, 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\nSee Also: Apple, Google Both Track Mobile Telemetry Data, Despite Users Opting Out\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 Breaking Down QNAP Bug OneTracked 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 (ZIP) and QTS 4.5.1.1495 (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[...]", "creation_timestamp": "2026-09-02T01:03:25.415796Z"}