Palo Alto Networks 下一代防火墙 (NGFW) 是世界各地公司用来防御各种网络攻击的领先企业防火墙之一。
授权 RCE #1
第一个漏洞是在对防火墙 Web 管理界面的黑盒分析期间检测到的,是由于缺乏用户输入过滤而发生的。PHP 脚本处理用户请求,然后将所有相关数据转发到侦听本地端口的服务。它解析数据并将结果返回给 Web 应用程序的用户。
为了利用CVE-2020-2037漏洞,我们首先登录Web管理界面。
防火墙web管理界面的登录页面
在对象选项卡上,转到外部动态列表。
“外部动态列表”部分
现在我们需要添加一个新的列表源并在 Source 字段中输入我们的负载。需要注意的是,此漏洞是一种盲目的操作系统命令注入。需要外部服务或带外有效负载才能查看结果。
利用漏洞
盲命令注入的一步步发现:
有效载荷 | 服务器响应 |
---|---|
http://myServer/ | 网址访问错误 |
http://myServer/' | 不能打开文件 |
http://myServer/'' | 网址访问错误 |
http://myServer/'||' | 网址可访问 |
http://myServer/'`sleep 5`' | URL访问错误(5秒后) |
产品状态
版本 | 做作的 |
---|---|
泛 OS 10.0 | 没有任何 |
泛 OS 9.1 | < 9.1.3 |
泛 OS 9.0 | < 9.0.10 |
泛 OS 8.1 | < 8.1.16 |
授权 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”命令
产品状态
版本 | 做作的 |
---|---|
泛 OS 10.0 | < 10.0.1 |
泛 OS 9.1 | < 9.1.4 |
泛 OS 9.0 | < 9.0.10 |
泛 OS 8.1 | 没有任何 |
未经身份验证的 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;
}
...
在这里我们看到/upload
URL的处理。对这个 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 攻击。
产品状态
版本 | 做作的 |
---|---|
泛 OS 10.0 | < 10.0.1 |
泛 OS 9.1 | < 9.1.4 |
泛 OS 9.0 | < 9.0.10 |
泛 OS 8.1 | < 8.1.16 |
反射型 XSS
最后一个漏洞是在脚本中发现的/unauth/php/change_password.php
。
易受攻击的代码部分
该脚本使用了$_SERVER['PHP_SELF']
用户控制的变量。该变量被插入到表单标签中的属性值中,没有进行任何过滤,从而使得 XSS 漏洞很容易被利用。
成功利用 XSS
产品状态
版本 | 做作的 |
---|---|
泛 OS 10.0 | 没有任何 |
泛 OS 9.1 | 没有任何 |
泛 OS 9.0 | < 9.0.9 |
泛 OS 8.1 | < 8.1.16 |