原文地址：https://swarm.ptsecurity.com/swarm-of-palo-alto-pan-os-vulnerabilities/
Palo Alto Networks下一代防火墙（NGFW）是世界各地的企业用来防范各种网络攻击的领先企业防火墙之一。它运行在自己的操作系统上，该系统名为PAN-OS 。
在本文中，我们将分析与该系统相关的多个安全漏洞：
-
授权用户任意执行操作系统命令——CVE-2020-2037和CVE-2020-2038。
-
未授权用户的DoS攻击——CVE-2020-2039。
-
反射型跨站点脚本攻击（XSS）——CVE-2020-2036。
利用这些漏洞，攻击者可以访问敏感数据，破坏防火墙组件的可用性或访问内部网络段。
授权用户的RCE漏洞 #1
第一个漏洞是在对防火墙Web管理界面进行黑盒分析时发现的，发生该漏洞的原因是用户输入缺乏相应的过滤处理。在这里，PHP脚本用于处理用户请求，然后将所有相关数据转发给一个在本地端口监听的服务。该服务会对数据进行解析，并将结果返回给Web应用程序的用户。
为了利用CVE-2020-2037漏洞，我们首先需要登录Web管理界面。
防火墙Web管理界面的登录页面
在Objects选项卡上，进入External Dynamic Lists。
External Dynamic Lists
现在，我们需要添加一个新的列表源，并在Source字段中输入payload。需要注意的是，这是一个操作系统命令盲注漏洞，因此，我们需要借助于外部服务或带外payload来查看结果。
利用该漏洞
逐步发现命令盲注漏洞：
授权用户RCE漏洞 #2
另一个漏洞的成因也是对用户输入的过滤不够严格所致。
在详细检查网页目录后，我们发现/var/appweb/htdocs/php/rest文件夹中含有许多PHP文件。其中，文件RestApi.php中包含了一个描述客户端通过RestApi请求（XML查询）与PAN-OS交互的类。在进一步检查该脚本后，发现RestApi类的execute方法。
RestApi类中执行请求的主要方法
通过身份验证是使用该方法的先决条件。满足所有的先决条件后，用户就可以使用不同类型的请求了。我们在Palo Alto Networks的官方文档中找到了这些请求的相关描述，这些信息极大地促进了我们的分析过程。
我们主要感兴趣的是op（操作模式命令）请求，它将调用buildOpRequest（私有方法）处理程序，并允许执行某些诊断类型的系统调用。同时，还会检查请求内容中是否存在所需的cmd参数。
类RestApi：构建一个op命令请求
据推测，该方法将组装一个XML请求，并发送给第三方服务器执行。通过对PAN-OS内部的分析，可以确定接收方为mgmt服务。这个服务负责我们请求的后续处理。
通过查看官方文档并在二进制文件中查找相应的字符串，我们就能够找到负责解析和分析系统命令的库。现在，我们知道了相应的处理程序。接下来，我们需要确定的事情是：xml中的命令参数值是否被原封不动地提取出来，并在格式化字符串的帮助下插入到传给/bin/sh -c <сmd>命令中以供执行。
然而，事情要比预期的要更加棘手。正如我们后来发现的那样，在某一时刻，请求内容经过了过滤并检查其正确性。这使得我们无法直接执行我们发送的命令，尽管它们仍然可以无限制地提取出来。
我们最终克服了这一障碍，这要归功于XML内容处理中的某些微妙之处，最终让我们能够调用任意的系统命令。
执行“id”命令
无需身份验证的DoS攻击
以下漏洞允许任何未经身份验证的用户进行DoS攻击。因此，可以导致Palo Alto Networks NGFW web管理面板可能完全不可用。
实际上，该防火墙使用了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的请求，将在内部重定向到命名位置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，则会删除上传的文件。
通过向/upload发送POST请求，我们可以看到Apache的响应代码为301（在响应正文中可见），而nginx代理响应代码为200。这些特殊的代码不会触发删除上传的文件。
上传测试文件
为了验证该漏洞，我们可以尝试向服务器上传大量文件。最初，主磁盘有15GB的可用空间。
攻击前磁盘的可用空间
在发动攻击后，磁盘空间被占满了。
磁盘没有可用空间
我们尝试打开Web管理界面，但无法登录。这很可能是因为PHP由于缺乏可用的磁盘空间，但是无法在磁盘上创建会话文件所致。
因此，我们能够以未经认证的用户身份对Palo Alto NGFW组件进行DoS攻击。
反射型XSS
最后一个漏洞是在脚本/unauth/php/change_password.php中发现的。
含有漏洞的代码
该脚本使用了$_SERVER['PHP_SELF']变量，而该变量是由用户控制的。这个变量在没有任何过滤的情况下被插入到表单标签的属性值中，从而使XSS漏洞很容易被利用。
成功利用该XSS漏洞
本文作者：mssp299
本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/153905.html
如有侵权请联系:admin#unsafe.sh