前言
类似于 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 的介绍:
无论您拥有十几个 虚拟机 https://baike.baidu.com/item/虚拟机 , 还是几千个虚拟机, VMware vCenter Server 都是管理 VMware vSphere 最简单, 最有效的方法. 借助 VMware vCenter Server, 可从单个控制台统一管理 数据中心 https://baike.baidu.com/item/数据中心 的所有主机和虚拟机, 该控制台聚合了集群, 主机和虚拟机的性能监控功能. VMware vCenter Server 使管理员能够从一个位置深入了解虚拟基础架构的集群, 主机 https://baike.baidu.com/item/主机 , 虚拟机, 存储, 客户操作系统和其他关键组件等所有信息.
翻译成渗透者的 "黑话" 来说就是: 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 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 所引起).
总结
虚拟化给企业的数据中心带来了高效的运维和不错的经济效益, 但是也引入了与以往不一样的安全威胁与风险. 这一点上, 可能我们还没有深入地去考虑具体的应对策略, 也缺乏相应的管理措施及技术手段. 这使得企业的运维环境可能处于危险之中. 如何去识别, 管理并消弭这些风险, 确实值得安全从业者深思的事情. 本文从笔者这几年的实际工作经验中总结而来, 希望能抛砖引玉, 给大家一些启发.
本文相关的代码放在: https://github.com/penoxcn/VMware , 有兴趣的可以参考.
来源: http://www.tuicool.com/articles/eQbYvmY