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架构，源码大数据分布式应用源码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--、、creo的源码。其中，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渗透过程（主要是踩坑分享）
针对VMware vCenter的介绍就不多说了，大佬们可以自行搜索。本文主要分享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。vb搜索 源码根据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已经修复了，但很多人还在用老版本的汉化版，会不会受影响就不好说了。
