皮皮网

1.SaltStack远程执行代码多个高危漏洞透析（CVE-2021-25281/25282/25283）
2.记一次VMware vCenter渗透过程（主要是漏洞踩坑分享）
3.VUL.AI华云安一周PoC回顾NO.10
4.CVE-2022-22980 表达式注入漏洞分析
5.烽火狼烟丨VMware vCenter Server远程代码执行漏洞（CVE-2021-21972）的安全影响力评估
6.CVE-2022-22980 Spring​ Data MongoDB SpEL表达式注入漏洞分析

SaltStack远程执行代码多个高危漏洞透析（CVE-2021-25281/25282/25283）

       SaltStack是一个由VMware子公司开发的运维管理工具，拥有广泛的源码使用基础，支持数万台服务器，虚拟其强大的机漏配置文件管理和远程执行命令功能使其在github上获得了.4k的star。SaltStack基于Python开发，漏洞采用C/S架构，源码cq源码安装Master与Minion之间通过轮询机制进行消息传递与监控数据交换。虚拟系统总称为SaltStack，机漏包含了salt、漏洞salt-master、源码salt-minion、虚拟salt-api等多个组件，机漏其中salt-master与salt-minion主要负责从指定路径读取配置文件并启动服务。漏洞salt-master监听和端口，源码分别用于消息发布和监控数据接收。虚拟

       SaltStack程序能够调用大量函数，并支持指定Minion或一组Minion作为目标。salt-api则提供了对外的REST接口，通常使用cherrypy或tornado框架实现。

       本文主要关注salt-master与salt-api的安全性。

       通过分析，发现SaltStack存在多个高危漏洞，包含CVE--、、养龙源码。其中，CVE--与未授权访问相关，涉及对SSH方法的权限认证处理存在漏洞。具体来说，salt/salt/netapi/init.py:NetapiClient.run()方法通过getattr动态调用NetapiClient类中的方法，并接收可控制参数。而其中的wheel_async方法存在未授权调用，该方法异步调用wheel包中的方法，通过salt/salt/client/mixins.py:AsyncClientMixin.asynchronous()函数实现。进一步分析，发现wheel_async的调用链涉及salt/salt/wheel/init.py:WheelClient.cmd_async()与salt/salt/client/mixins.py:SyncClientMixin.low()，最终实现未授权远程代码执行。

       CVE--则揭示了SaltStack中的有限制任意文件写漏洞，涉及salt/salt/wheel/pillar_roots.py:write()方法。然而，该方法的利用需要__opts__["pillar_roots"]中的路径存在，且文件读取无法被利用，因异步调用特性。

       CVE--则揭示了SaltStack的模板注入漏洞。通过开启debug模式，定位到master自动加载逻辑，发现salt/salt/master.py:Maintenance.run()方法中的公寓出租源码自动加载问题。通过分析，找到salt/salt/minion.py:MasterMinion.init()方法中对minion配置文件的读取操作，进而通过salt/salt/config/init.py:minion_config()方法实现自动加载。最终定位到salt/salt/sdb/rest.py文件中的salt/salt/sdb/rest.py:query()方法，以及salt/salt/template.py:compile_template()方法中的模板注入风险。通过深入分析，可以发现存在未授权RCE的可能性，需要对自动加载的逻辑进行修复。

       对于以上漏洞的修复建议，请参考SaltStack官方发布的修复指南和安全通告。

记一次VMware vCenter渗透过程（主要是踩坑分享）

       总体流程分为三个步骤：获取webshell、获取登录Cookie、获取域控账号密码或哈希值。以下为详细步骤：

       获取webshell：

       - 指纹识别：识别目标资产的端口和协议信息。

       判断版本：

       - 通过访问/vimServiceVersions.xml获取版本信息。

       CVE--漏洞利用：

       - 利用此漏洞上传webshell。影响范围覆盖特定版本的vCenter Server。使用cve--漏洞的exploit脚本上传webshell。注意，这里可能遇到协议或端口问题，图标排序源码需使用HTTPS上传。

       接着进行以下操作：

       获取vCenter Cookie登录：

       - 存储关键身份验证信息的位置：Linux下为/data.mdb，Windows下为C:\ProgramData\VMware\vCenterServer\data\vmdird\data.mdb。

       - 利用脚本下载并解密data.mdb文件，获取Cookie信息。

       生成Cookie：

       - 通过脚本生成Cookie，将Cookie添加至浏览器，以实现登录vCenter。

       获取域控账密或哈希值：

       - 进入vCenter控制台，若存在域控机器，可使用生成快照并分析快照文件抓取哈希值。注意避免使用克隆虚拟机等操作。

       具体步骤包括生成快照、在数据存储中查找快照文件、分析快照以获取哈希值。可使用工具如volatility或Vmss2core进行分析。

       log4j2注意事项：

       - 使用正确的URL格式访问，避免跳转到错误的域名。正确格式为/threedr3am/l...），我们进行了复现分析。首先，我们检查了DemoController构造的请求路径为/demo，请求参数为keyword。美女资讯源码根据diff（github.com/spring-proje...）记录，漏洞的主要修复位置在ParameterBindingJsonReader类的bindableValueFor函数。

       我们通过在org.springframework.data.mongodb.util.json.ParameterBindingJsonReader#bindableValueFor函数处设置断点，并在环境运行起来后开启debug模式。使用burp抓包并传入payload后，立即触发断点。在初步跟进时，我们发现并未成功触发payload。

       继续深入调试，我们发现在org.springframework.data.mongodb.util.json.ParameterBindingJsonReader#readBsonType函数中对token的Type属性进行判断后，进入到UNQUOTED_STRING，在这里进行setCurrentName操作，value为id。随后回到bindableValueFor函数，对value进行处理后，value由id变为了:#{ ?0}。

       在value为:#{ ?0}后，再次进入org.springframework.data.mongodb.util.json.ParameterBindingJsonReader#bindableValueFor函数。在bindableValueFor函数中，首先对tokenValue进行了赋值，随后对tokenValue进行PARAMETER_BINDING_PATTERN和EXPRESSION_BINDING_PATTERN规则匹配。EXPRESSION_BINDING_PATTERN只能匹配 ?#{ } 或者：#{ }形式的字符串。接着，将赋值交给binding，通过substring取出占位符?0。接下来通过for循环将占位符和传入的payload进行替换。当PARAMETER_BINDING_PATTERN规则匹配成功后，即认为是spel表达式格式，此时expression为传入payload，执行this.evaluateExpression。最终进入org.springframework.data.mongodb.repository.query.DefaultSpELExpressionEvaluator#evaluate函数，使用的是 StandardEvaluationContext 类型，包含了 SpEL 所有的功能。此时的SpEL表达式为恶意攻击载荷，可成功实现命令执行。

       漏洞复现

       为了验证这个漏洞，我们利用了threedr3am师傅提供的代码（github.com/threedr3am/l...），成功复现了攻击流程。

       修复建议

       受影响的用户应该尽快升级至官方修复版本，以修复此漏洞。推荐版本包括：Spring Data MongoDB 3.4.1或更高版本；Spring Data MongoDB 3.3.5或更高版本。官方提供了升级链接（github.com/spring-proje...），用户可以前往下载并更新。

       参考材料

       为了解决此漏洞，用户可以参考以下资源：

       - tanzu.vmware.com/securi...

       - xz.aliyun.com/t/

       - spring.io/blog//...

烽火狼烟丨VMware vCenter Server远程代码执行漏洞（CVE--）的安全影响力评估

       前言

       年2月日，VMware官方发布安全更新，修复了vCenter Server中的远程代码执行漏洞（CVE--），此漏洞可能允许攻击者在操作系统上执行任意命令。VMware vCenter Server是提供集中式管理的虚拟化和服务器软件，攻击者可通过访问web管理端发送构造请求实现漏洞利用。

       同时，VMware修复了VMware ESXi中的堆溢出漏洞（CVE--）以及VMware vSphere的SSRF漏洞（CVE--）。

       WebRAY烽火台实验室将持续关注此漏洞，为您提供最新信息。

       网络基本情况

       盛邦安全网络空间搜索引擎发现全球台设备对公网开放，中国最多，台设备，其次是德国（台）、法国（台）、英国（台）、俄罗斯（台）。

       中国境内，台湾对公网开放VMwarevCenter设备最多（台），北京与浙江并列第二（各台），广东第四（台）。

       受影响设备

       修复方案及下载链接如下：

       vCenter Server 6.5 U3n: docs.vmware.com/en/VMwa...

       vCenter Server 6.7.U3l: docs.vmware.com/en/VMwa...

       vCenter Server 7.0.U1c: docs.vmware.com/en/VMwa...

       总结

       全球共有台设备使用VMware vCenter软件对公网开放，其中中国最多。攻击者可利用此远程代码执行漏洞实现任意代码执行。建议受影响用户及时更新修复。

CVE-- Spring​ Data MongoDB SpEL表达式注入漏洞分析

       VMware在6月日发布安全公告，修复了Spring Data MongoDB组件中的一个SpEL表达式注入漏洞，漏洞编号CVE--，威胁等级为高危。漏洞允许攻击者通过构造恶意数据执行远程代码，最终获取服务器权限。

       Spring Data MongoDB应用程序在使用包含查询参数占位符的SpEL表达式的方法时，若输入未被过滤，则容易遭受SpEL注入攻击。Spring Data for MongoDB是Spring Data项目的一部分，旨在提供一致的编程模型，同时保留存储的特定特征和功能。SpEL是一种强大的运行时查询和操作对象图的表达式语言，也是Bean装配的一种方式。

       Spring Data MongoDB版本3.4.0和3.3.0至3.3.4之间受到影响，更早或不再受支持的版本也可能存在此漏洞。使用threedr3am师傅的漏洞demo复现分析。

       在动态调式中，首先查看DemoController构造的请求路径为/demo，请求参数为keyword。通过对比差分记录发现漏洞修复主要在ParameterBindingJsonReader类的bindableValueFor函数。在运行环境开启debug模式，使用burp抓包并传入payload后，触发断点。在调试过程中发现，payload在未成功触发时，在org.springframework.data.mongodb.util.json.ParameterBindingJsonReader#bindableValueFor函数中进行了处理，value由id变为了:#{ ?0}。随后经过一系列处理，最终在StandardEvaluationContext中执行恶意攻击载荷，实现命令执行。

       为解决此漏洞，受影响用户应尽快升级至官方修复版本：Spring Data MongoDB 3.4.1或更高版本；Spring Data MongoDB 3.3.5或更高版本。更多详情可参考VMware的安全公告和GitHub上的下载链接。

       Portal Lab专注于前沿安全技术研究及能力工具化，主要研究方向包括API安全、应用安全和攻防对抗等。Lab成员成果曾发表于多个国内外知名安全会议，并多次发布开源安全工具。未来，Portal Lab将持续为安全社区及企业提供高质量的技术输出。

       欲了解更多消息，欢迎关注“星阑科技”和“星阑PortalLab”微信公众号。

我新建了个虚拟机，如果中木马了等等一系列问题会不会从我主机上（本机）**资料？

       理论上不会。不过前阵子听说VM有个漏洞，可以从虚拟机访问主机。但具体情况就不太清楚了，也不知道修补了没有。

       补充，又查了一下，起码出现过两个漏洞，一个是可以从虚拟机访问主机的共享文件夹。一个是MAC版本的VMWare可以从Windows虚拟机攻击Mac主机。当然，新版本的VMWare已经修复了，但很多人还在用老版本的汉化版，会不会受影响就不好说了。