Qnap NAS关键错误披露延迟到期

SAM的安全研究团队正在积极寻找尚未发现的IOT设备的漏洞，以确保我们的网络安全覆盖率尽可能准确，最新。

SAM的发动机随后阻止了在甚至在供应商解析它之前发现的第一天的漏洞。

以下是最近漏洞的两个漏洞及其潜在影响，即我们的研究小组在特定的NAS设备（由QNAP和消费者使用的网络附加存储器使用的网络附加存储器）中发现。

向供应商报告DI括号漏洞的标准做法，并允许其中90-120天的宽限期，以便在通知公众之前解决它。如下面的时间表所示，W E遵循负责任的披露程序，并立即向供应商报告，特别是因为他们的E XPloitation的影响很大。

这些漏洞本质上是严重的，因为它们允许从网络中完全收购设备，包括访问用户的存储数据，而无需任何先验知识。

以下是漏洞的更详细的技术描述，包括我们发现的过程和我们将M向供应商报告M的步骤，并确保我们的代理保护我们的用户。

我们在QNAP TS-231最新的固件中发现了两个关键的漏洞IES（版本4.3.6.1446 - 2020/09/29）。

Web服务器：允许远程攻击者访问Web服务器（默认端口8080）以执行任意shell命令，而无需先验知识的Web凭据。

DLNA服务器：允许远程攻击者访问DLNA服务器（默认端口8200）以在任何（不存在）位置的任意文件数据上，无需任何先前的知识或凭据。它也可以提升到远程NAS上执行任意命令。

我们向QNAP报告了一个4个月的宽限期漏洞，以解决它们。遗憾的是，正如本文的e发布，漏洞尚未修复。

由于脆弱性的严重性，我们决定不透露完整的细节，因为我们认为这可能会造成暴露于I internet的成千上万的Qnap设备的重大危害。

在以下终端记录中，我们使用我们编写的Python脚本来破解设备。我们通过使用简单的反向外壳技术来实现完全收购设备。之后，我们访问存储在QNAP存储器上的文件。存储的任何文件都可以类似地访问。

以前的RCE攻击QNAP NAS模型在Web页面上不需要先前身份验证，并在服务器端中运行/触发码。因此，我们检查了Some CGI文件（实现这些页面）并模糊了一些更相关的文件。

通过Web服务器可用的大多数CGI文件都驻留在TS-231文件系统上的/mnt / hda_root / home / httpd / cgi -bin目录。

在检查期间，我们将具有自定义HTTP请求的Web服务器模糊到不同的CGI页面，专注于那些不需要先前认证的CGI页面。我们已经能够生成一个有趣的方案，它间接触发远程代码执行（即，触发其他进程中的某些行为）。

THE HE供应商可以通过向某些核心进程和库API添加输入Sanitiz ation来解决漏洞，但它尚未修复此撰写。

10月31日，2020年 - 使用票号的“QNAP支持”自动回复。

2021年1月26日 - 向QNAP发出通知，即宽限期结束（计划于2月12日结束）。

1月2日6日，2021年 - Qnap帮助台的回复：问题得到确认但仍在进行中。

DLNA服务器实现为进程MyupnpMediasVR，并处理端口8200上的UPnP请求。

我们在外部和内部调查过程的行为和通信时发现了这种脆弱性。

我们也能够提升远程NAS上的远程代码执行的漏洞。 11月29日，2020年 - 全部披露向QNAP安全团队报告。 尚未收到QNAP的回复尚未收到此具体披露。 更新04/04/2021：我们出版后的一天我们被QNAP联系了关于所提到的安全问题。 他们澄清说，该问题已经修复了新的Qnap模型（运行QTS 4.5版），但不适用于包括TS-231和其他流行型号的遗留模型。 根据QNAP的说法，由于问题的严重性，他们也在处理遗留平台的修复，这将在未来几周内提供。