Carbon Black CLoud WorkLoad是Vmware的一套提供云端服务的产品，该设备托管在本地，是组织基础架构与端点保护平 VMware Carbon Black Cloud的重要组件。
VMware Carbon Black App Control存在CVE-2021-21998认证绕过漏洞，该漏洞是由于Envoy在处理请求转发时不支持URL编码，导致可以匿名访问API接口获取认证Token。
安装比较简单，下载`cwp-va-1.0.1.0-${version}_OVF10.ova`虚拟机文件导入后启动即可，cwp密码需要定期修改，忘记密码后修复方法如下。
首先使用linux虚拟机挂载cwp虚拟机磁盘文件：
登录后通过chroot命令备份并修改cwp根文件系统中的root和admin密码：
使用新密码登录系统：
系统启动后，将开启80、443、3030、3010、3020等多个接口，80和443采用envoy服务：
Envoy 是专为大型现代 SOA（面向服务架构）架构设计的 L7 代理和通信总线，支持进行代理转发。
可以把Envoy理解为一个类似于Nginx的反向代理，根据配置文件`/opt/vmware/cwp/appliance-gateway/conf/cwp-appliance-gateway.yaml`梳理出主要代理配置项目：
| cluster名称 | 端口 | 转发地址 | 备注 || -------------- | ---- | --------- | ---- || service_vsw | 3030 | 127.0.0.1 | || service_apw | 3020 | 127.0.0.1 | || service_acs | 3010 | 127.0.0.1 | || service_plugin | 8080 | 127.0.0.1 | |
而后端服务都使用`java`语言编写：
对比`cwp-va-1.0.1.0`和`cwp-va-1.0.2.0`版本，在`/vmware/cwp/appliance-worker/bin/run.sh`中添加了HTTP头校验，注意到其中的`http://localhost:3010/acs/api/v1/service-token/apw`开头的URL：
其中acs即`Access Control Service`，代码和配置位于`/opt/vmwarwe/cwp/access-control-service`：
查看处理代码，通过`/api/v1/service-token/${servicename}`接口可获取管理员token：
该URL并不能通过443端口远程访问：
而本地请求后可以简单返回登录Token：
回来继续看Envoy的使用，使用该框架作为代理时，可使用`Route Discovery API`动态生成URL路由转发规则列表。后端服务使用`io.envoyproxy.envoy.api`包中的`DiscoveryRequest`和其他实体来描述路由的配置，通过`/v2/discovery:routes`接口返回路由信息：
在`EnvoyXDSServiceImpl`中实现了转发路由的生成规则：
上传静态编译的`tcpdump`文件捕获本地请求报文，正好可以捕获到本地`/v2/discovery:routes`报文：
Envoy路由能够精确匹配到协议、地址、端口、URL路径等，可根据指定规则转发和修改请求。根据返回的路由列表，`/acs/api/v1/service-token`开始的接口由`service_vsw`（3030端口）处理，以 `/acs/`开始的接口由acs服务处理，且`/acs/api/v1/service-token`优先级高于`/acs/`：
远程构造URL请求样例，经过测试情况如下。值得注意的是，如果`/acs/api/v1/service-token`中`/acs/`后面的一个字符串进行URL编码，将会导致`/acs/`规则被匹配，请求被转发到`3010`端口处理，导致功能与设计不一致：
| 远程请求URL | 转发端口 | 转发URL | 备注 || ----------------------------- | --------------------------- | ------- | -------------- || / | /awp/login | 443 | 返回302 || /acs/api/v1/service-token | /no_cloud | 3030 | 转发至本地端口 || /acs/api/v1/service-token/awp | /no_cloud/awp | 3030 | 转发至本地端口 || /acs/wp | /acs/wp | 3010 | 转发至本地端口 || /acs/api/v%31/service-token | /acs/api/v%31/service-token | 3010 | 转发至本地端口 |
发送`/acs/api/v%31/service-token`请求，便可以未授权获取`TOKEN`了，造成认证绕过问题发生：
产生的问题原因是`Envoy`框架默认未启用对请求的URL编解码处理。Envoy开发人员建议在使用`RBAC过滤器`时启用`normalize_path_settings`特性，但本次漏洞研究的环境并没有开启：
而`3010`端口使用spring-boot编写，默认是支持URL编码的：
使用url编码绕过：
利用token访问API：
首先`X-RREQUEST-TYPE: INTERNAL`请求头来标识本地请求，同时URL路径和转发规则也做了修改：
漏洞产生的原因是Envoy在转发时不进行URL编码处理，而CarbonBlack定制路由规则时采用了`/PAT1/API1`和`/PAT1/`两个处理规则，且后台处理代码也不同。通过构造`/PAT1/$URLENCODE(APT1)`的方式可以绕过第一个规则检查，从而按照第二个规则进行转发处理，同时SpringBoot能够处理URL编码，导致未授权获取token。与反向代理模式下认证绕过类似，是不是似曾相似的赶脚？
由于传播、利用此文档提供的信息而造成任何直接或间接的后果及损害，均由使用本人负责，且听安全团队及文章作者不为此承担任何责任。
点关注，不迷路！
关注公众号回复“漏洞”获取研究环境或工具
原文始发于微信公众号（且听安全）：【经典回顾系列】CVE-2021-21988 VMware Carbon Black App Control认证绕过漏洞分析
