Palo Alto PAN-OS 漏洞

Palo Alto Networks 下一代防火墙 (NGFW) 是世界各地公司用来防御各种网络攻击的领先企业防火墙之一。

授权 RCE #1

第一个漏洞是在对防火墙 Web 管理界面的黑盒分析期间检测到的，是由于缺乏用户输入过滤而发生的。PHP 脚本处理用户请求，然后将所有相关数据转发到侦听本地端口的服务。它解析数据并将结果返回给 Web 应用程序的用户。

为了利用CVE-2020-2037漏洞，我们首先登录Web管理界面。

防火墙web管理界面的登录页面

在对象选项卡上，转到外部动态列表。

“外部动态列表”部分

现在我们需要添加一个新的列表源并在 Source 字段中输入我们的负载。需要注意的是，此漏洞是一种盲目的操作系统命令注入。需要外部服务或带外有效负载才能查看结果。

利用漏洞

盲命令注入的一步步发现：

产品状态

授权 RCE #2

另一个漏洞涉及对用户输入的过滤不足。

对 Web 目录的详细检查显示该文件夹/var/appweb/htdocs/php/rest包含 PHP 文件。该文件RestApi.php包含一个描述客户端通过 RestApi 请求（XML 查询）与 PAN-OS 交互的类。通过对脚本的彻底检查，发现了RestApi类的execute方法。

类 RestApi。执行请求的主要方法

身份验证是使用此方法的先决条件。满足所有先决条件使用户能够处理不同类型的请求。我们在PAN-OS XML API 请求类型和操作以及运行操作模式命令 (API) 的帕洛阿尔托网络官方文档中找到了这些请求的描述。这些信息极大地促进了我们的分析。

我们的主要兴趣是op调用buildOpRequest（私有方法）处理程序并允许执行某些诊断系统调用的（操作模式命令）请求。检查请求内容是否需要cmd参数：

类 RestApi。构建一个操作命令请求

据推测，该方法组装了一个发送到第三方服务器执行的 XML 请求。泛 OS 内部分析允许识别接收者：管理服务。该服务负责我们请求的后续处理。

通过查看官方文档并在二进制文件上运行字符串，我们能够找到负责解析和分析系统命令的库。现在我们知道了感兴趣的处理程序。然后确定 xml 中命令参数的值按原样提取，并在格式字符串的帮助下插入到传递给/bin/sh -c <сmd>执行的命令中。

然而，事情变得比预期的要棘手。正如我们后来发现的那样，有一次请求内容被过滤并检查了正确性。这阻止了我们直接执行我们发送的命令，尽管它们仍在不受任何限制地被提取。

我们最终克服了这一挫折，这要归功于处理 XML 内容的某种微妙之处，最终允许我们调用任意系统命令。

执行“id”命令

产品状态

未经身份验证的 DoS

以下漏洞允许任何未经身份验证的用户进行 DoS 攻击。因此，Palo Alto Networks NGFW 网络管理面板可能完全不可用。

防火墙使用 nginx Web 服务器。主要的 nginx 配置文件位于/etc/nginx/nginx.conf.

...

upstream backend_mgmt {
      server 127.0.0.1:28250;
    }

...

     set $gohost "backend_mgmt";
     set $devonly  0;
     set $gohostExt  "";

...
  
 include conf/locations.conf;
 include conf/server*.conf;

主要配置包括额外的配置文件。我们对文件特别感兴趣/etc/nginx/conf/locations.conf。

...

location /upload {
    error_page 402 =200 @upload_regular; return 402;
}

...

location @upload_regular {
    upload_pass @back_upload_regular;
    include conf/upload_default.conf;
}

location @back_upload_regular {
    proxy_intercept_errors on;
    include conf/proxy_default.conf;
    proxy_pass http://$gohost$gohostExt;
}

...

在这里我们看到/uploadURL的处理。对这个 URL的请求在内部被重定向到命名的 location upload_regular。请求正文被传递给back_upload_regular并包含/etc/nginx/conf/upload_default.conf配置文件，我们将在稍后讨论。最后，请求被代理到 http://$gohost$gohostExt (http://127.0.0.1:28250)，结果是本地 Apache Web 服务器。现在让我们upload_default.conf更仔细地看一下。

    upload_pass_args on;

    # Store files to this directory
    # The directory is hashed, subdirectories 0 1 2 3 4 5 6 7 8 9 should exist
    upload_store /opt/pancfg/tmp;

    # Allow uploaded files to be read only by user
    upload_store_access user:rw;

    # Set specified fields in request body
    upload_set_form_field "FILE_CLIENT_FILENAME_${upload_field_name}" "$upload_file_name";
    upload_set_form_field "FILE_CONTENT_TYPE_${upload_field_name}" "$upload_content_type";
    upload_set_form_field "FILE_FILENAME_${upload_field_name}" "$upload_tmp_path";

    # Inform backend about hash and size of a file
    upload_aggregate_form_field "FILE_MD5_${upload_field_name}" "$upload_file_md5";
    upload_aggregate_form_field "FILE_SIZE_${upload_field_name}" "$upload_file_size";

    upload_pass_form_field "(.*)";

    upload_cleanup 400 404 499 500-505;

该文件配置nginx-upload-module. 该模块从用户那里获取文件并将它们存储在系统上。在我们的例子中，模块可以通过 URL 访问/upload。请注意该upload_cleanup指令，如果返回代码 400、404、499 或 500-505，则该指令将删除上传的文件。

通过向 发送 POST 请求/upload，我们可以看到 Apache 以代码 301（在响应正文中可见）响应，而 nginx 代理以 200 响应。这些特定代码不会触发删除上传的文件。

上传测试文件

为了验证该漏洞，我们尝试向服务器上传大量文件。最初，主磁盘有 15 GB 的可用空间。

攻击前磁盘上的可用空间

在我们的攻击之后，它是 100% 满的。

磁盘没有可用空间

我们尝试打开 Web 管理界面，但无法登录。这很可能是因为 PHP 无法在磁盘上创建会话文件，因为可用磁盘空间不足。

因此，我们能够以未经身份验证的用户身份对 Palo Alto NGFW 组件进行 DoS 攻击。

产品状态

反射型 XSS

最后一个漏洞是在脚本中发现的/unauth/php/change_password.php。

易受攻击的代码部分

该脚本使用了$_SERVER['PHP_SELF']用户控制的变量。该变量被插入到表单标签中的属性值中，没有进行任何过滤，从而使得 XSS 漏洞很容易被利用。

成功利用 XSS

产品状态