通过登录表单和其他发现Cisco Hyperflex RCE漏洞

2021 年 2 月，我们有机会在例行客户参与期间评估思科的 HyperFlex HX 平台。这导致检测到三个重大漏洞。在本文中，我们将讨论我们的发现，并将解释它们为何存在于平台中、如何利用它们以及这些漏洞的重要性。

所讨论的漏洞已被分配了 CVE ID，并在 Cisco 的后续安全公告 ( 1 ,  2 ) 中予以考虑。这些是：

• CVE-2021-1497
  Cisco HyperFlex HX 安装程序虚拟机命令注入漏洞（CVSS 基础分数：9.8）；
• CVE-2021-1498
  Cisco HyperFlex HX 数据平台命令注入漏洞（CVSS 基础分数：7.3）；
• CVE-2021-1499
  Cisco HyperFlex HX 数据平台上传文件漏洞（CVSS 基础分数：5.3）

背景

Cisco HyperFlex HX 是一组将各种网络和计算资源组合到一个平台中的系统。Cisco HyperFlex HX 数据平台（软件定义存储）的主要功能之一是它允许最终用户使用各种存储设备并虚拟化所有元素和流程。这允许用户轻松备份数据、分配资源或克隆资源。这个概念被称为超融合基础设施 ( HCI )。您可以在 Cisco 网站“超融合基础设施 (HCI)：HyperFlex ”和“ Cisco HyperFlex the HX-the Series ”上阅读更多相关信息。

Cisco HyperFlex HX 带有一个 Web 界面，可以轻松进行配置。我们测试的版本是 Cisco HyperFlex HX 数据平台 v4.5.1a-39020。这可以在下面看到：

HyperFlex 平台作为映像部署在 Ubuntu 操作系统上。我们的初步检查显示 nginx 1.8.1 用作前端 Web 服务器。知道了这一点，我们决定查看 nginx 配置文件，看看我们还能学到什么。“springpath”项目的nginx配置位于该/usr/share/springpath/storfs-misc/目录中。Springpath 为超融合开发了分布式文件系统，思科于 2017 年收购了该系统。

我们的首要任务是无需任何身份验证即可访问系统管理。于是我们对配置文件中的每个路由（位置）进行了详细的检查。在对配置文件进行彻底调查后，我们能够确定需要进一步研究的领域的优先级，这可能使我们能够这样做。

发现

CVE-2021-1497：通过密码输入字段的 RCE

身份验证是验证用户是否是他们所说的人的过程。这个过程通常是通过将用户名和密码传递给应用程序来实现的。授权是授予或拒绝访问特定资源的过程。身份验证和授权是密切相关的过程，它们决定了用户或应用程序可以访问的对象和内容。

在我们的测试过程中，我们注意到身份验证过程由第三方服务处理。这显示在下面的配置文件中：

通过查看这个配置部分的内容，可以看到认证过程是由二进制文件处理的/opt/springpath/auth/auth。此服务是一个 64 位 ELF 应用程序。我们注意到它的大小比标准应用程序大。这可能表明二进制文件或大型编译的 Golang 项目中有大量调试信息。后者在使用readelf命令阅读节标题后很快得到确认。

该auth二进制处理多个URL请求：

/auth
/auth/change
/auth/logout
/auth/verify
/auth/sessionInfo

这些请求中的大多数不接受用户输入，但是 URL/auth和/auth/change允许用户通过参数的username、password和进行输入newPassword。该/auth页面处理身份验证。当用户输入他们的用户名和密码时，HTTP 请求发送如下：

对身份验证应用程序的分析表明，凭据是main_loginHandler通过标准函数在函数中检索的net/http.(*Request).ParseForm。接下来，将登录名和密码传递给main_validateLogin函数。此函数从username参数中检索值，并从/etc/shadow文件中检索相应的用户哈希值。如果用户存在，则执行进一步的过程main_validatePassword，使用该main_checkHash功能检查通过该功能输入的密码。

哈希值是通过调用一行 Python 脚本来计算的os/exec.Command：

python -c "import crypt; print(crypt.crypt(\"OUR_PASS\", \"$6$$\"));"

然后提取生成的哈希值并与 中的值进行比较/etc/shadow。

这种从 Python 执行命令的方法的一个大问题是允许命令注入。这是一个重大漏洞；没有输入验证，任何用户输入都会在输入时传递给os/exec.Command。此外，命令是使用应用程序的权限执行的，在这种情况下是 root。因此，恶意执行系统命令是微不足道的。例如，我们在密码字段中输入以下内容，导致系统重新启动：

123", "$6$$"));import os;os.system("reboot");print(crypt.crypt("

此漏洞允许恶意用户仅使用一个 HTTP 请求以 root 权限调用远程反向 shell：

处理用户输入的另一个 URL/auth/change也提供了一种执行任意代码的方法。
密码更改由main_changeHandler 函数处理。这与登录过程非常相似/auth。使用相同的过程检查用户的存在，并使用相同的函数计算密码哈希main_checkHash。在新密码的值中，newPassword我们能够传递相同的输入，导致系统重新启动：

123", "$6$$"));import os;os.system("reboot");print(crypt.crypt("

我们找到了两种触发任意代码远程执行的方法，使用/auth和/auth/change端点。但是，由于password和newPassword参数使用相同的功能，main_checkHash为了执行外部命令，供应商只发布了一个 CVE。在 python 中执行外部命令的一种更安全的方法是使用 sub-process 模块并在执行前验证从用户输入中获取的参数。

CVE-2021-1498：Cisco HyperFlex HX 数据平台命令注入漏洞

我们分析了 nginx 配置文件，注意到/storfs-asup端点将所有请求重定向到 TCP 端口 8000 的本地 Apache Tomcat 服务器。

然后我们查看了Apache Tomcat的配置文件web.xml，我们发现：

从这个文件中可以清楚地看出/storfs-asupURL 是由StorfsAsup位于/var/lib/tomcat8/webapps/ROOT/WEB-INF/classes/com/storvisor/sysmgmt/service/StorfsAsup.class.

public class StorfsAsup extends HttpServlet {
...
  protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    String action = request.getParameter("action");
    if (action == null) {
      String msg = "Action for the servlet need be specified.";
      writeErrorResponse(response, msg);
      return;
    } 
    try {
      String token = request.getParameter("token");
      StringBuilder cmd = new StringBuilder();
      cmd.append("exec /bin/storfs-asup ");
      cmd.append(token);
      String mode = request.getParameter("mode");
      cmd.append("  ");
      cmd.append(mode);
      cmd.append("  > /dev/null");
      logger.info("storfs-asup cmd to run : " + cmd);
      ProcessBuilder pb = new ProcessBuilder(new String[] { "/bin/bash", "-c", cmd.toString() });
      logger.info("Starting the storfs-asup now: ");
      long startTime = System.currentTimeMillis();
      Process p = pb.start();
      ...
    }
    ... 
  }
}

在分析这个类时，我们注意到从用户那里收到的参数没有以任何方式过滤或以任何方式验证。它们被传递给一个字符串，该字符串随后作为操作系统命令执行。基于这些信息，我们可以形成一个恶意的 GET 请求，该请求将作为操作系统命令执行。

GET /storfs-asup/?Action=asd&token=%60[any_OS_command]%60 HTTP/1.1
Host: 192.168.31.76
Connection: close

这会导致未经身份验证的用户在服务器上执行任意命令。

值得注意的/storfs-asup是，只有在外部可以访问 80 端口时，Web 路径才可用。要通过443端口利用该漏洞，需要修改请求以使用路径/crossdomain.xml/..;/storfs-asup/。这是有效的，因为 nginx 配置文件指定所有以 开头的请求/crossdomain.xml都被代理到 Tomcat 并使用众所周知的目录遍历 tomcat 技术“ ..;/”，我们可以访问 tomcat web 服务器上的任何 servlet。

CVE-2021-1499：Cisco HyperFlex HX 数据平台文件上传漏洞

对 nginx 配置文件的仔细检查向我们展示了以下文件上传位置：

要请求此 URL，不需要授权并且可以从外部访问该路径。与漏洞 CVE-2021-1498 一样，这是以类似的方式设置的。对在端口 8000 上侦听传入连接的代理应用程序的请求。

作为实验，我们发送了一个多部分的目录遍历请求并被接受。

结果，passwd9在指定目录中为用户“tomcat8”创建了具有名称的文件：

完全没有身份验证意味着我们可以使用“tomcat8”用户权限将任意文件下载到文件系统上的任何位置。这是对开发人员部分的重大疏忽。

在发表这篇论文的过程中，我们对允许我们执行任意代码的漏洞有了更广泛的了解。与以前相比，该漏洞现在似乎没有那么无害。详情请见以下链接。

不是每个错误都是漏洞

nginx 配置文件中的默认路由也引起了我们的注意。此路由处理所有不符合配置文件中任何其他描述规则的 HTTP 请求。这些请求被重定向到端口 8002，该端口仅在内部可用。

与auth二进制文件一样，此路由由installer64 位 ELF 应用程序处理，并且也是用 Golang 编写的。

评估表明，该应用程序是一个已编译的 64 位 Golang 项目。此应用程序用于处理 /api/* 请求。要使用 API 接口，必须有一个授权令牌。该installer二进制处理以下端点：

/api/run
/api/orgs
/api/poll
/api/about
/api/proxy
/api/reset
/api/config
/api/fields
/api/upload
/api/restart
/api/servers
/api/query_hfp
/api/hypervisor
/api/datacenters
/api/logOnServer
/api/add_ip_block
/api/job/{job_id}
/api/tech_support
/api/write_config
/api/validate_ucsm
/api/update_catalog
/api/upload_catalog
/api/validate_login

尽管这项研究的最初要求是发现不需要先决条件或身份验证的漏洞，但这一发现要求用户登录到 Cisco HyperFlex Web 界面。我们分析了端点处理程序并发现了两个与文件系统一起工作的请求。在/api/update_catalog和/api/upload路线使我们能够任意文件上传到指定的目录。负责处理 URL 数据的处理程序是main_uploadCatalogHandler和main_uploadHandler。

在第一种情况下，我们传输的文件被写入/opt/springpath/packages/目录。使用简单的路径遍历攻击，我们能够在该目录之外的系统任意位置写入一个文件。

因此，我们可以将文件写入系统上的任何位置，因为这些请求是使用 root 权限发出的。

请求的第二个示例导致/var/www/localhost/images/从 Web 界面将文件写入目录。通过更改 HTTP 多部分 POST 请求中的文件名，其工作方式与前一个请求类似。这允许恶意用户在文件系统的任何位置创建文件。

思科不认为这些是漏洞，假设如果攻击者知道客户凭据，就可以通过启用的 SSH 服务器登录。然而，我们仍然认为这段代码的实现很差。

结论

该研究项目是在常规客户参与期间作为一个机会开始的。我们发现了三个重要的漏洞。这些漏洞是缺乏输入验证、身份验证和授权管理不当以及依赖第三方代码的结果。这些可以通过遵循安全编码最佳实践并确保安全测试是开发过程的一个组成部分来缓解。

尽管开发了 SSDLC（安全软件开发生命周期）等最佳实践，但命令注入漏洞仍然是行业中的一个重要问题。这可以分两部分解决。首先，如果业界有意愿通过标准将最佳实践作为一项要求。其次，如果实施外部测试来评估是否遵守标准 两个。

最后，应该注意的是，第三方产品通常达不到现有产品线中实施的严格安全标准。第三方产品的收购和整合是一条难以管理的道路。每次收购都应包括对编码实践和安全测试的彻底审查。在某些情况下，他们可能会受益于完整的整体，以确保在组件之间以安全的方式一致地处理数据。

from