深入分析Palo Alto PAN-OS中的多个安全漏洞

2021-02-26 12,607

原文地址: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管理界面。

 1.png

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

 

在Objects选项卡上,进入External Dynamic Lists。

 1.png

External Dynamic Lists

 

现在,我们需要添加一个新的列表源,并在Source字段中输入payload。需要注意的是,这是一个操作系统命令盲注漏洞,因此,我们需要借助于外部服务或带外payload来查看结果。

 1.png

利用该漏洞

 

逐步发现命令盲注漏洞:

QQ截图20210226134200.png

 

2.png

 

授权用户RCE漏洞 #2

 

另一个漏洞的成因也是对用户输入的过滤不够严格所致。

 

在详细检查网页目录后,我们发现/var/appweb/htdocs/php/rest文件夹中含有许多PHP文件。其中,文件RestApi.php中包含了一个描述客户端通过RestApi请求(XML查询)与PAN-OS交互的类。在进一步检查该脚本后,发现RestApi类的execute方法。

 1.png

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

 

通过身份验证是使用该方法的先决条件。满足所有的先决条件后,用户就可以使用不同类型的请求了。我们在Palo Alto Networks的官方文档中找到了这些请求的相关描述,这些信息极大地促进了我们的分析过程。

 

我们主要感兴趣的是op(操作模式命令)请求,它将调用buildOpRequest(私有方法)处理程序,并允许执行某些诊断类型的系统调用。同时,还会检查请求内容中是否存在所需的cmd参数。

 1.png

类RestApi:构建一个op命令请求

 

据推测,该方法将组装一个XML请求,并发送给第三方服务器执行。通过对PAN-OS内部的分析,可以确定接收方为mgmt服务。这个服务负责我们请求的后续处理。

 

通过查看官方文档并在二进制文件中查找相应的字符串,我们就能够找到负责解析和分析系统命令的库。现在,我们知道了相应的处理程序。接下来,我们需要确定的事情是:xml中的命令参数值是否被原封不动地提取出来,并在格式化字符串的帮助下插入到传给/bin/sh -c <сmd>命令中以供执行。

 

然而,事情要比预期的要更加棘手。正如我们后来发现的那样,在某一时刻,请求内容经过了过滤并检查其正确性。这使得我们无法直接执行我们发送的命令,尽管它们仍然可以无限制地提取出来。

 

我们最终克服了这一障碍,这要归功于XML内容处理中的某些微妙之处,最终让我们能够调用任意的系统命令。


1.png

执行“id”命令

 

3.png

 

无需身份验证的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。这些特殊的代码不会触发删除上传的文件。

 1.png

上传测试文件

 

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

 1.png

攻击前磁盘的可用空间

 

在发动攻击后,磁盘空间被占满了。

1.png

磁盘没有可用空间


我们尝试打开Web管理界面,但无法登录。这很可能是因为PHP由于缺乏可用的磁盘空间,但是无法在磁盘上创建会话文件所致。

 

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

2.png


反射型XSS

 

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

 1.png

含有漏洞的代码

 

该脚本使用了$_SERVER['PHP_SELF']变量,而该变量是由用户控制的。这个变量在没有任何过滤的情况下被插入到表单标签的属性值中,从而使XSS漏洞很容易被利用。

 1.png

成功利用该XSS漏洞

 

2.png


本文作者:mssp299

本文为安全脉搏专栏作者发布,转载请注明:https://www.secpulse.com/archives/153905.html

Tags:
评论  (0)
快来写下你的想法吧!

mssp299

文章数:51 积分: 662

安全问答社区

安全问答社区

脉搏官方公众号

脉搏公众号