VMWare vRealize运营经理设备有一个身份验证的REST API被称为“套件API“这是通过TCP端口443。的一些API调用接受HTTP post载荷的”relay-request“在XML或JSON格式。有两个漏洞,当结合使用,导致认证low-privilege用户实现远程代码执行。
# 1套API CollectorHttpRelayController RelayRequest对象DiskFileItem反序列化(cve - 2016 - 7462)
这个问题是由于任意对象通过套件API反序列化和Apache Commons在类库类路径。具体地说,CollectorHttpRelayController反序列化base64'd对象存储在“relay-request“XML。攻击者可以利用这个通过嵌入一个操作DiskFileItem在XML。有一些url,可以用来达到这个控制器(如。https://[目标]/ suite api /内部继电器/心跳)。
攻击通过写作这个向量是有限的(使用自定义内容)和移动文件,但不覆盖。图书馆设计,以便上传文件创建部分静态名称(“upload_ % u_ % u.tmp“% u是一个UUID,另一个是一个领先的计数器),攻击者无法控制的。即使移动文件,使用随机名称相同类型的实现,这是一个限制因素。孤独,这个漏洞可以用来上传和移动文件和web服务器的权限,允许一个有效的拒绝服务。VMWare vRealize操作,这种攻击允许移动web服务器文件、数据库、文件/usr/lib/vmware-vcops,文件/存储/,等等。通过基本的实验,我们发现,移动文件/存储/导致设备停止允许远程终端登录奇怪。
# 2 Commons InvokerTransformer集合类Java Unserialization远程代码执行(cve - 2015 - 6934)
这个问题之前已经昭然于Apache Commons集合,以及许多数十家供应商实现图书馆以这样一种方式,允许远程代码执行。然而,关于VMware vRealize操作中提到vmsa - 2015 - 0009咨询对于下议院集合问题。然而,有一个脚注在受影响的产品表,说:“剥削的问题vRealize操作,vCenter操作和vCenter仅限于本地应用程序发现经理特权升级。“向量我们发现允许远程访问,通过一个POST请求。由于剥削是有限的几个因素,如没有看到你的命令输出,上传或下载一个定制的二进制不可靠,和工具等wget或旋度不太可能被发现在Windows目标,开发与这类问题让你与饼干肉汁火车轮子。
由于CVE抽象为Apache Commons per-vendor基础上被跟踪的问题,这个向量将属于CVE - 2015 - 6934。
开发注意事项:
当发邮件到https://[目标]/ suite api /内部继电器/心跳作为一个例子,系统将提示您通过基本身份验证的用户名/密码。此外,您将需要包括这些HTTP头两行:
- ”
X-vRealizeOps-API-use-unsupported:是的\ r \ n”
- ”
内容类型:应用程序/ xml \ r \ n”
Apache - v -供应商,指责:
我们把这类问题Apache的关注一段时间,他们不认为这是一个漏洞。他们对我们的反应,他们说:
”回顾你的报告,我们得出结论,它不代表一个有效的在Apache Commons文件上传漏洞。如果应用程序反序列化的数据从一个不可信的来源没有过滤和/或验证应用程序漏洞不是漏洞在图书馆潜在的攻击者可能会利用。”
站得住脚的认为,如果一个应用程序想要反序列化DiskFileItems然后他们仍然容易受到改变对象,他们可以在任何地方文件写服务器,这似乎跨特权边界由图书馆基于代码。
基于我们的研究,没有警告不相信这个对象包含在他们的图书馆,或提及潜在的问题。似乎有几行代码,以防止意外的方面(文件写入任意位置),同时仍然保持图书馆的功能。在这样做,它将增加一层保护的公司实现图书馆(许多,我们发现脆弱)。
又一个Apache人提到“. io .文件是可序列化的,太. .我认为入侵者管理有DiskFileItem创建和getInputStream()调用,也可以创建一个文件(或字符串),并调用新文件(输入输出)|流吗?“我们提醒他们的行为反序列化DiskFileItem会导致任意文件被写入到磁盘。攻击者不需要调用一个新的outputstream因为DiskFileItemreadObject ()功能已经为他做过。这不是就我们所知道的最好的预期行为。这也不像反序列化Java.io.File。说,我们尊重Apache的立场,并联系供应商,实现共享类库的方式使他们的软件脆弱。