New vulnerabilities discovered allow access to user data and complete takeover - SAM Seamless Network
New vulnerabilities discovered allow access to user data and complete takeover
By Yaniv Puyeski|31.03.21|Blog News
SAM’s security research team is actively looking for vulnerabilities in IoT devices that have yet to be discovered in order to ensure our network security coverage is as accurate and up to date as possible.
SAM’s engine subsequently blocks such vulnerabilities from the first day of finding sometimes even prior to the vendor resolving it.
Below is a summary of two recent vulnerabilities and their potential impacts that our research team discovered in a specific kind of NAS device (network-attached storage that is used by both organizations and consumers) made by QNAP.
It‘s standard practice to report the discovered vulnerabilities to the vendor and allow for a 90-120 day grace period for them to resolve it prior to notifying the public. As seen in the timeline below, we followed the responsible disclosure procedure and immediately reported it to the vendor especially as the impacts of their exploitation are significant.
These vulnerabilities are severe in nature as they allow for full takeover of device from the network including access to the user’s stored data, without any prior knowledge.
Below is a more detailed technical description of the vulnerabilities including our process for discovering and the steps we took to report them to the vendor, and also ensure our agent protected our users.
Unauthenticated Remote Code Execution + Arbitrary file write
We discovered two critical vulnerabilities in QNAP TS-231’s latest firmware (version 4.3.6.1446 – 2020/09/29).
Web server: allows a remote attacker with access to the web server (default port 8080) to execute arbitrary shell commands, without prior knowledge of the web credentials.
DLNA server: allows 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.
These may affect other models and firmware versions as well.
We reported both vulnerabilities to QNAP with a 4-month grace period to fix them. Unfortunately, as of the publishing of this article, the vulnerabilities have not yet been fixed.
Due to the seriousness of the vulnerabilities, we decided not to disclose the full details yet, as we believe this could cause major harm to10s of thousands of QNAP devices exposed to the internet.
In the following terminal recording we use 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’s stored on the QNAP storage. Any file stored can be accessed similarly.
Technical Details
Vulnerability #1 – RCE vulnerability: affects any QNAP device exposed to the Internet.
This vulnerability resides in the NAS web server (default TCP port 8080).
Previous RCE attacks on QNAP NAS models relied on web pages which do not require prior authentication, and run/trigger code in server-side. We’ve therefore inspected some cgi files (which implement such pages) and fuzzed a few of the more relevant ones.
Most of the cgi files that are available through the web server reside at /mnt/HDA_ROOT/home/httpd/cgi-bin directory on the TS-231 file system.
During the inspection, we fuzzed the web server with customized HTTP requests to different cgi pages, with focus on those that do not require prior authentication. We’ve been able to generate an interesting scenario, which triggers remote code execution indirectly (i.e., triggers some behavior in other processes).
Process for solving vulnerability
The vendor can fix the vulnerability by adding input sanitizations to some core processes and library APIs, but it has not been fixed as of this writing.
Disclosure timeline:
October 12, 2020 – Full disclosure reported to QNAP security team.
October 23, 2020 – Sent another e-mail to QNAP security team.
October 31, 2020 – Automatic reply from “QNAP support” with a ticket number.
January 26, 2021 – Sent a notification to QNAP about end of the grace period (which is planned to end on February 12).
January 26, 2021 – Reply from QNAP Helpdesk: the problem is confirmed but still in progress.
February 12, 2021 – Grace period has elapsed.
March 31, 2021 – Initial blog post published.
Vulnerability #2 – Arbitrary file write vulnerability:
This vulnerability resides in the DLNA server (default TCP port 8200).
The DLNA server is implemented as the process myupnpmediasvr, and handles UPNP requests on port 8200.
We discovered the vulnerability during investigation of the process’s behavior and communication both externally and internally.
We’ve been able to elevate that vulnerability to remote code execution on the remote NAS as well.
Disclosure timeline:
November 29, 2020 – Full disclosure reported to QNAP security team. No reply from QNAP has been received yet for this specific disclosure.
March 29, 2021 – Grace period has elapsed.
March 31, 2021 – Initial blog post has been published.
——-
Update 04/04/2021: A day after our publication we were contacted by QNAP about the security issues mentioned. They have clarified that the issues were already fixed for newer QNAP models (which run QTS version 4.5), but not for legacy models which include the TS-231 and other popular models. According to QNAP, due to the severity of the issues, they are working on a fix for legacy platforms as well, which will be available in the coming weeks.
By Yaniv Puyeski|31.03.21|Blog News
SAM’s security research team is actively looking for vulnerabilities in IoT devices that have yet to be discovered in order to ensure our network security coverage is as accurate and up to date as possible.
SAM’s engine subsequently blocks such vulnerabilities from the first day of finding sometimes even prior to the vendor resolving it.
Below is a summary of two recent vulnerabilities and their potential impacts that our research team discovered in a specific kind of NAS device (network-attached storage that is used by both organizations and consumers) made by QNAP.
It‘s standard practice to report the discovered vulnerabilities to the vendor and allow for a 90-120 day grace period for them to resolve it prior to notifying the public. As seen in the timeline below, we followed the responsible disclosure procedure and immediately reported it to the vendor especially as the impacts of their exploitation are significant.
These vulnerabilities are severe in nature as they allow for full takeover of device from the network including access to the user’s stored data, without any prior knowledge.
Below is a more detailed technical description of the vulnerabilities including our process for discovering and the steps we took to report them to the vendor, and also ensure our agent protected our users.
Unauthenticated Remote Code Execution + Arbitrary file write
We discovered two critical vulnerabilities in QNAP TS-231’s latest firmware (version 4.3.6.1446 – 2020/09/29).
Web server: allows a remote attacker with access to the web server (default port 8080) to execute arbitrary shell commands, without prior knowledge of the web credentials.
DLNA server: allows 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.
These may affect other models and firmware versions as well.
We reported both vulnerabilities to QNAP with a 4-month grace period to fix them. Unfortunately, as of the publishing of this article, the vulnerabilities have not yet been fixed.
Due to the seriousness of the vulnerabilities, we decided not to disclose the full details yet, as we believe this could cause major harm to10s of thousands of QNAP devices exposed to the internet.
In the following terminal recording we use 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’s stored on the QNAP storage. Any file stored can be accessed similarly.
Technical Details
Vulnerability #1 – RCE vulnerability: affects any QNAP device exposed to the Internet.
This vulnerability resides in the NAS web server (default TCP port 8080).
Previous RCE attacks on QNAP NAS models relied on web pages which do not require prior authentication, and run/trigger code in server-side. We’ve therefore inspected some cgi files (which implement such pages) and fuzzed a few of the more relevant ones.
Most of the cgi files that are available through the web server reside at /mnt/HDA_ROOT/home/httpd/cgi-bin directory on the TS-231 file system.
During the inspection, we fuzzed the web server with customized HTTP requests to different cgi pages, with focus on those that do not require prior authentication. We’ve been able to generate an interesting scenario, which triggers remote code execution indirectly (i.e., triggers some behavior in other processes).
Process for solving vulnerability
The vendor can fix the vulnerability by adding input sanitizations to some core processes and library APIs, but it has not been fixed as of this writing.
Disclosure timeline:
October 12, 2020 – Full disclosure reported to QNAP security team.
October 23, 2020 – Sent another e-mail to QNAP security team.
October 31, 2020 – Automatic reply from “QNAP support” with a ticket number.
January 26, 2021 – Sent a notification to QNAP about end of the grace period (which is planned to end on February 12).
January 26, 2021 – Reply from QNAP Helpdesk: the problem is confirmed but still in progress.
February 12, 2021 – Grace period has elapsed.
March 31, 2021 – Initial blog post published.
Vulnerability #2 – Arbitrary file write vulnerability:
This vulnerability resides in the DLNA server (default TCP port 8200).
The DLNA server is implemented as the process myupnpmediasvr, and handles UPNP requests on port 8200.
We discovered the vulnerability during investigation of the process’s behavior and communication both externally and internally.
We’ve been able to elevate that vulnerability to remote code execution on the remote NAS as well.
Disclosure timeline:
November 29, 2020 – Full disclosure reported to QNAP security team. No reply from QNAP has been received yet for this specific disclosure.
March 29, 2021 – Grace period has elapsed.
March 31, 2021 – Initial blog post has been published.
——-
Update 04/04/2021: A day after our publication we were contacted by QNAP about the security issues mentioned. They have clarified that the issues were already fixed for newer QNAP models (which run QTS version 4.5), but not for legacy models which include the TS-231 and other popular models. According to QNAP, due to the severity of the issues, they are working on a fix for legacy platforms as well, which will be available in the coming weeks.
