浅谈企业虚拟化环境的安全风险与渗透测试方法

Posted 2021-05-02 FreeBuf

前言

类似于VMware这样的服务器虚拟化技术出现以来，极大地提升了企业数据中心的建设效率、运维弹性以及经济效益。回想起十来年前，我们想要部署一个新系统时，首先需要申请采购服务器，到货后还需要自己搬到机房里，找到位置安装到机架上，然后加电、跳网线、安装操作系统，等到最终能够ping通新服务器的IP时，时间往往已经过去了好几个月。而在数据中心全面推进虚拟化之后，这过程变得很轻松：需要多少台机器，我只需要在私有“云”管理平台上提一个申请单，平台管理员审批之后，就开始自动部署你需要的虚拟机，整个过程最快几乎达到了小时的级别。

在享受着虚拟化的诸多好处的同时，我们可能还没有意识到，随着虚拟化技术的大规模应用，企业数据中心的基础架构、运行维护、组织管理等都已经发生了大变化，所面临的安全风险也已不同于往日了。

传统环境与虚拟化环境对比

让我们拿渗透测试人员都喜欢挑战的域控制器来做例子。在以前，域控在网络中的位置和逻辑关系是下图这样的：

*图1：传统的部署示意图，DC指域控制器Domain Controller，SA指服务器自动化（Server Automation）系统。

域控装在独立的物理服务器上，域管理员清楚地知道它们在机房里的位置，为它们设置复杂的操作系统密码并小心地保管，第一时间打上微软的补丁，用严格的规范管理用户和权限，敏感地注意着服务器和自己终端上的任何风吹草动。这时候的域控像个坚固的堡垒，要想从网络中成功地渗透，其实是非常困难的。

而在使用VMware虚拟化之后，典型的部署场景是这样的：

*图2：虚拟化部署示意图，VM指虚拟机Virtual Machine，VCenter 指vSphere Center，vSAN指虚拟存储，DC指域控制器。

在物理服务器上安装的都是VMware ESXi系统，通过VCenter集中管理所有的虚拟机资源。为了给其它人员提供便捷的资源申请途径，很可能部署了某种“云”管理系统，通过一个Web Portal给内部用户提供访问入口，通过自动化部署后台（Auto Deployment）与VMware的接口互动实现虚拟机资源的分配、变更与回收等操作。而无论是域控DC，还是VCenter，抑或是“云”管理平台，它们都是虚拟资源池中的一个普通的VM而已。

再来看此时的域控DC：域管理员无法确知它的CPU和内存运行在哪台物理服务器上，不知道它的磁盘放在哪个存储上，不知道TCP/IP报文会从哪根网线上流过，更不知道在虚拟的世界里有没有其它人对它做过什么手脚。此时即使管理员还是如以前一样严丝密缝地守护着DC服务器，恐怕也要在心里嘀咕着它是否还与以往一样坚固不可侵犯吧？

虚拟化环境风险的分层解析

让我们思考一下虚拟化给企业数据中心带来的运维环境的变化，以及由此带来的各种可能的安全风险。

虚拟化的应用使得“服务器”这一基础设施由以前的分散运维走向集中运维，从硬件服务器，到虚拟化操作系统，再到虚拟机，以及各种外围支撑系统，现在建设和运维工作都集中到虚拟化团队身上了。大型企业的数据中心，物理服务器成百上千台，管理虚拟机数千台，这意味着这个团队需要大量具备不同技能的人员来分工完成如此复杂的运维任务。以目前国内的环境，他们几乎不可能都是专业的安全人员，或者具有同等的安全意识，在某些环节出现某些失误几乎是不可避免的。

1**、首先**，要有效管理和监控大量的物理服务器，管理员必须借助服务器提供的硬件管理接口和带外管理网络才能实现。例如，惠普的iLO接口，Dell和浪潮的IPMI接口，通过一个Web或Ssh界面，都能实现服务器硬件健康状态的监控、电源和开关、操作系统的安装、远程控制台等功能。

风险点一：管理员可能没有修改带外管理接口的默认密码，或者设置了弱密码、企业内众所周知的通用密码。统一硬件管理/监控平台（如果有的话）可能有漏洞。下面的图展示了我在实际的渗透测试中，发现的使用弱密码的惠普iLO管理接口：

*图3：惠普服务器iLO管理界面

以及浪潮的IPMI管理接口：

*图4：浪潮服务器的IPMI管理界面

2**、其次**，在虚拟主机操作系统层面，管理员需要管理大量的ESXi Server，可能需要借助外包或驻场才能完成系统的安装和初始设置，然后才能投入使用。

风险点二：某些ESXi Server可能使用了弱密码，后来忘了修改。所有的ESXi Server使用相同的密码，也许写在了运维手册里。

关于弱密码实际是非常容易遇到的。ESXi的ssh界面可以使用VMware的定制的shell；Web界面可以浏览它里面部署的客户机的虚拟磁盘；使用vSphere Client连接则可以进行所有的管理操作了。下面的图展示了我在实际的渗透测试中，猜到了密码的一个ESXi主机，可以通过Web界面浏览虚拟机的磁盘文件：

*图5：浏览VMware数据存储

而使用vmware sdk，可以将虚拟磁盘映射到本地来访问，避免下载巨大的磁盘文件：

*图6：使用VMware SDK远程挂载虚拟磁盘

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产品的扫描和发现

~# /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")

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>'''

接着就可以利用历史上的各种漏洞对它们进行检测了。

利用以上扫描的结果绘制出网络中所有的VMware关系图，类似于这样的效果：

*图15：全网VMware一览图

截取一角来说明一下：

*图16：VMware与ESXi的逻辑关系，以及漏洞情况

图中的ESXi都有标注，包含版本；没有ESXi的则是vCenter了。vCenter用箭头指向它所纳管的ESXi。vCenter或者ESXi都有可能是孤立无联系的。红色的节点是有漏洞的。当时扫描测试了三个漏洞：一个是心脏滴血（SSL），一个是vCenter的RMI漏洞（CVE-2015-2342），还有一个是XXE漏洞（Apache Flex BlazeDS所引起）。

总结

虚拟化给企业的数据中心带来了高效的运维和不错的经济效益，但是也引入了与以往不一样的安全威胁与风险。这一点上，可能我们还没有深入地去考虑具体的应对策略，也缺乏相应的管理措施及技术手段。这使得企业的运维环境可能处于危险之中。如何去识别、管理并消弭这些风险，确实值得安全从业者深思的事情。本文从笔者这几年的实际工作经验中总结而来，希望能抛砖引玉，给大家一些启发。

本文相关的代码放在：https://github.com/penoxcn/VMware，有兴趣的可以参考。