3、再次，因为每个虚拟主机上都跑着几十上百个的虚拟客户机，使得管理员轻易做不敢对虚拟主机任何变更操作。想象一下“重启”这么简单的事情，在操作之前，管理员可能得花大力气提前通知每一个虚拟机的用户，将可以停机的虚拟机关机，对不能停机的虚拟机临时进行热迁移，在指定的变更窗口重启完之后，再将各虚拟机开启，将之前迁移的虚拟机迁回来，再通知各个用户进行业务验证……如此小心谨慎不是毫无理由的，因为对于企业数据中心来说，保证可用性是第一位的。这也意味着，除了出了性能问题或故障，一般不会主动对虚拟主机安装补丁或进行升级。
风险点三、ESXi Server从来没有打过补丁，可能存在安全漏洞。
例如，在过去了一两年之后，我还能在开发测试环境的ESXi中找到有OpenSSL心脏滴血漏洞的：
*图7：心脏滴血漏洞获取64K内存
有的时候它们漏洞会泄露内部SOAP接口（vpxa）之间的Session值，而拿着这个Session可以调用很多内部的API（这些vpxa API管理员也未必听说，需要你去翻VMware的技术文档了解），例如，获得所有虚拟客户机的存储列表：
*图8：利用泄露的Session获取ESXi中的信息
4、再往更高的层走，到达vCenter这里。vCenter的功能是什么呢？来看看VMware的介绍：
无论您拥有十几个虚拟机，还是几千个虚拟机，VMware vCenter Server 都是管理 VMware vSphere 最简单、最有效的方法。借助 VMware vCenter Server，可从单个控制台统一管理数据中心的所有主机和虚拟机，该控制台聚合了集群、主机和虚拟机的性能监控功能。 VMware vCenter Server 使管理员能够从一个位置深入了解虚拟基础架构的集群、主机、虚拟机、存储、客户操作系统和其他关键组件等所有信息。
翻译成渗透者的“黑话”来说就是：vCenter是虚拟化世界的皇宫，vCenter管理员便是国王。拿到vCenter的管理权限，便可以统治成百上千的虚拟机了。而管理成百上千台的虚拟机，肯定不是一两个人可以做得来的。也许需要按照功能区域划分给不同的人去管理，日常的变更操作也许会交给驻场团队去进行。这便涉及到账号和权限的安全问题。有人使用简单密码变成了大概率事件。有时候图省事，也许还会把密码交给你–某一次我要重置一个虚机的root密码需要console时，驻场工程师便把vCenter的管理员账号密码给我，让我自己登录上去连接console。也许，某人在测试自动化部署的程序，把高权限账号和密码写在某个脚本里，而某天存放脚本的服务器刚好因为弱密码被你渗透了–我说也许，只是说它不一定会在你的环境里发生，但我确实在我的环境中真实遇到过。
同样的，vCenter也会有漏洞，如ESXi一样，管理员也极有可能不会那么勤快地打上补丁。2015年vCenter有个Java RMI远程代码执行漏洞CVE-2015-2342，可以轻松地拿下vCenter：
*图9,10,11：利用RMI漏洞反弹一个System权限的Shell
祭上mimikatz读取vCenter管理员密码，便可以登录vCenter了：
*图12：登录vCenter，掌控所有的虚拟机
这个exploit今天也许你还可以用得上。
在主要的vCenter上，也许域控服务器就在其中，你现在可以对它进行一个热克隆操作，克隆一个离线的虚拟机，然后用vCenter的控制台去登录它，导出域数据库，通过vCenter拷贝到其它你控制的虚拟机中（例如，通过共享虚拟磁盘），再把克隆的机器删除。这个过程对于域控管理员来说，一点感知都没有，域控服务器自身也不会有任何异常的系统事件产生。
*图13：热克隆一个目标服务器
关于vCenter的另一个问题是虚拟机模板，新建虚拟机一般由有限的模板生成的，其Administrator密码或root密码已固化，如果没有机制去修改初始密码就交付给用户，那么vCenter就会不断量产具有相同管理员密码的虚拟机。所以，尝试用初始密码对所有虚拟机进行密码扫描，看看有什么发现吧！
5、让我们把目光投向更远的地方，落在那个称为“云”管理平台的系统上。实际上，它可能有其它的名字，叫“云”只是时髦一点。功能是类似的，就是通过Web门户，向内部IT用户提供便捷的通道去申请、维护和销毁虚拟机资源。这是一个很自然的需求，也有很多第三方厂家去做这样的平台。这样的平台也可能存在各种安全问题。例如：它的Web Portal账号是如何创建并管理的？它有多少个管理员权限的用户？它有没有默认密码？它的管理员账号日常是交给谁管理的？Web Portal有没有常见的Web漏洞，如SQL注入等。它后台的服务器包括数据库服务器有没有弱密码？它与vCenter、vSphere的联动是通过vCenter账号还是API Key来进行的？账号或API Key有没有加密存储？等等。
在实践中曾经遇到过：Web Portal和后台服务器都是用相同的Linux模板生成的，这个模板有一个uid也是0的admin用户，使用固定密码。恰恰“云”管理平台的人员只是修改了root的密码，没有修改admin账号的密码。然后在Web平台中发现了数据库的连接账号，在数据库中又发现“云”管理平台的账号密码是用无盐的md5哈希的，大量的账号从OA系统同步过来，并预设为了同一个密码，平台管理员也使用了简单的密码。于是这个管理平台也就沦陷了。以平台管理员登录，自己给自己创建申请单，然后审批通过，就可以无限制的部署虚拟机了！
*图14：某种“云”平台–虚拟化管理平台
6、补充：VMware产品的扫描和发现
作为一个内部渗透人员，如果对企业环境中的VMware产品（包括vCenter、ESXi等）进行发现和识别呢？这个也是有技巧的。首先VMware产品有特定的服务端口，例如22,80,427,443,902,9875等。其次服务的banner信息，或者ssl证书信息中包含有VMware或vSphere等关键字。这样就可以使用zmap等扫描器+banner获取快速地发现网络中VMware产品。那么，如何确定vCenter与它所纳管的ESXi之间的逻辑关系呢？诀窍就是SLP协议与vpxa的API。SLP协议可以获取目标IP地址的VMware主机名、ESXi版本，例如：
~# /usr/bin/slptool 'unicastfindsrvs' 10.1.12.135 'service:VMwareInfrastructure' service:VMwareInfrastructure://10.1.12.135,65535 ~# /usr/bin/slptool 'unicastfindattrs' 10.1.12.135 'service:VMwareInfrastructure' (product="VMware ESXi 6.0.0build-1921158"),(hardwareUuid="32393735-3733-4E43-4731-313954385050") |
而vpxa API可以查询到ESXi所纳管的vCenter地址：
URL为：url_fmt = ‘https://%s/vpxa‘ %(ip)
两个SOAP请求如下：
apixml1='''<?xml version="1.0"encoding="UTF-8"?> <soapenv:Envelopexmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd=" http://www.w3.org/2001/XMLSchema"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body><QueryVpxaStatusxmlns="urn:vpxa3"><_this type="VpxapiVpxaService">vpxa</_this></QueryVpxaStatus></soapenv:Body></soapenv:Envelope>''' apixml2='''<?xml version="1.0"encoding="UTF-8"?> <soapenv:Envelopexmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body><GetVpxaInfoxmlns="urn:vpxa3"><_thistype="VpxapiVpxaService">vpxa</_this></GetVpxaInfo></soapenv:Body></soapenv:Envelope>''' |
返回的响应报文中包含vCenter的地址。
接着就可以利用历史上的各种漏洞对它们进行检测了。
利用以上扫描的结果绘制出网络中所有的VMware关系图，类似于这样的效果：
*图15：全网VMware一览图
截取一角来说明一下：
*图16：VMware与ESXi的逻辑关系，以及漏洞情况
图中的ESXi都有标注，包含版本；没有ESXi的则是vCenter了。vCenter用箭头指向它所纳管的ESXi。vCenter或者ESXi都有可能是孤立无联系的。红色的节点是有漏洞的。当时扫描测试了三个漏洞：一个是心脏滴血（SSL），一个是vCenter的RMI漏洞（CVE-2015-2342），还有一个是XXE漏洞（Apache Flex BlazeDS所引起）。
总结
虚拟化给企业的数据中心带来了高效的运维和不错的经济效益，但是也引入了与以往不一样的安全威胁与风险。这一点上，可能我们还没有深入地去考虑具体的应对策略，也缺乏相应的管理措施及技术手段。这使得企业的运维环境可能处于危险之中。如何去识别、管理并消弭这些风险，确实值得安全从业者深思的事情。本文从笔者这几年的实际工作经验中总结而来，希望能抛砖引玉，给大家一些启发。
