从Cloud Foundry谈企业PaaS环境的安全风险与评估

* 本文作者：ipenox，本文属FreeBuf原创奖励计划，未经许可禁止转载

前言

PaaS是云计算领域的三大业态之一。PaaS作为应用的运行平台，提供一个操作系统级的容器，在该容器中安装应用运行时所需要的所有依赖，使得开发者可以更加专注于开发任务本身。Cloud Foundry（CF）是业界第一个开源的PaaS云平台，Pivotal是CloudFoundry代码的主要贡献者。作为PaaS领域的佼佼者，Pivotal Cloud Foundry（PCF）得到了相对广泛的应用。

尽管AWS上有成熟的原生CF环境可以使用，也有业企选择在自己的数据中心中自建CF环境，以便与已有的传统IT架构连接，以敏捷开发方式驱动，更好地支撑不断增长的业务创新需求。

在本文中，我将结合自己公司在应用PCF过程中的实践来谈谈企业PaaS环境中可能存在的风险，以及对CF做安全评估的方法。

CF架构

下图展示了典型Pivotal Cloud Foundry的架构。PCF提供了路由、控制、监控、认证、日志、构建等一整套运行时环境，开发者只需要实现自己的应用（App），部署上去就可以了（在图中Apps即代表应用池）。为了使Internet用户能够正常访问App，开发者还需要在互联网DNS中发布一个与该App相关的域名。具体的技术细节不在此展开，读者朋友可以自行到Pivotal的官方网站查阅。

部署架构

尽管CF支持在不同的底层基础架构上部署，但在企业数据中心中，最终还是落实到某个逻辑或者物理的区域中，通过网络和安全设备与企业内网互联。如下图是一个简化的部署示意图：

在这里，面向互联网提供服务的PaaS被放在了单独的DMZ区中，通过防火墙与其它区域隔离。实际可能有多个PaaS功能区域。例如，仅对生产网络提供服务的PaaS区域，将会被放在企业内网中。DMZ可能与数据中心一样跨越了不同的城市地域，以实现高可用性。

PaaS的安全风险

我们来看看企业在应用PaaS过程中可能面临哪些方面的安全风险。

（1）平台的漏洞与补丁升级。作为PaaS的基础，Cloud Foundry也会存在各种安全漏洞。你的PaaS平台及时进行补丁安装与升级了么？如果应用很少，升级应该不会遇到困难。但是如果有成百的应用在跑着，那平台负责人就得好好平衡下安全性与可用性的风险与收益了。

（2）二次开发。如果只有少量的应用，CF自带的功能完全能满足需求。而大的企业可能会基于CF进行二次开发，以适应企业内部的开发与运维环境。如我公司，光是DMZ PaaS的应用都已过百，由不同的团队开发和运维，需要控制版本、代码、权限、资源、上线、发布、回收等等诸多个性化需求，因而定制开发了多套辅助的系统。这些系统在提供生产力的同时，也可能会引入新的安全风险。

（3）DevOps。DevOps简单说就是开发与运维一体化。PaaS的特点非常适合DevOps实践，快速迭代，持续集成，持续交付。传统的模式是开发与运维分开。在DevOps理念中，应用的运维实际已交给了开发部门，运维部门只是在底层的IaaS、网络等提供支持。如果没有规范的应用发布流程，有缺陷的应用可能就会被随意发布到互联网中，危害整个平台。在我的实践中，曾看到过DMZ的PaaS中有HelloWorld应用，也有Test1到TestN的应用，甚至还有MySQL实例，这些应用不一定就有安全问题，但却反映了随意或者无管控的状态，这其实更可怕。

（4）网络访问控制。传统的DMZ中，应用部署在特定的主机（物理或虚拟）上，有固定地址，与内部网络的访问需求可以通过防火墙策略进行精细的控制。而在PaaS环境中，应用部署在PaaS集群中的不特定的容器上，无法固定地址，每当需要访问内部网络时，只能将PaaS集群作为一个整体来开通防火墙策略，所有在PaaS上的应用也自动地获得了相应的访问策略。慢慢地，在防火墙上，内部网络向PaaS集群暴露的口子就会越来越大。一旦某个应用存在漏洞，比如RCE了，就能更容易渗透进企业内网中去。

（5）应用的访问控制。有些应用，如发布管理控制台，应该只允许从内部网络访问。但是PaaS对于互联网来说，也是一个统一的入口，仅通过域名来将连接路由到相应应用的端点。这意味着需要由措施控制哪些域名能够被外部访问，哪些不能被外部访问。传统的状态防火墙是做不到的，仅仅将外部DNS的解析去除也不够的。而在CF上做域名过滤，可能相对很麻烦，而且在职责上（谁来维护这个过滤，是开发团队，还是基础运维团队，亦或是安全团队）含混不清。

（6）应用漏洞管理。应用漏洞的发现和处置一般都是安全团队的责任。毫无疑问，随着PaaS应用的大规模上线，如何有效对应用进行漏洞扫描、渗透评估、应急处置、修复跟踪，将会大大考验安全团队的能力和智慧。

Cloud Foundry安全评估实践

1. Cloud Foundry应用的特征

CloudFoundry部署时要求分配单独的二级域名给PaaS应用使用（例如*.paas.example.com），每个应用通过独一无二的三级域名进行识别（例如appX.paas.example.com），所有应用的域名解析到相同的地址。在进行DNS解析时，有不同的处理方法：

（1）按需配置解析，来一个域名配置一条解析记录，虽然指向都是一样的；

（2）泛解析，预先就将二级域名*.paas.example.com统一解析到PaaS平台的入口地址，一劳永逸；

（3）不配置公网DNS，通过host文件提供解析，这在开发测试阶段比较常见。

通过以上的情况可知，尽管每个应用都有一个独一无二的域名关联，但是PaaS应用的发现却不适宜使用域名枚举/爆破的方式来进行。

那么CF应用有什么特征吗？

让我们来看一个例子，美国政府的PaaS云： https://cloud.gov。它上面有完善的文档，还有结构图什么的。从文档中我们可以知道它们PaaS专用的二级域名分别是：*.fr.cloud.gov和*.app.cloud.gov。

看看地址：

>dig any.app.cloud.gov

;; ANSWERSECTION:
any.app.cloud.gov.      59     IN      A       52.61.92.213
any.app.cloud.gov.      59     IN      A       96.127.94.32

>dig any.fr.cloud.gov

;; ANSWERSECTION:
any.fr.cloud.gov.       59     IN      A       52.222.114.76
any.fr.cloud.gov.       59     IN      A       52.222.90.11

从上面解析的输出可以看出它们的域名做的是泛解析。

我们用curl来简单探测一下：

默认请求：

返回404。

设置随意一个Host头：

返回404。

设置一个真实存在的Host头：

返回200。

从上图可以看到，当没有指定Host头或者Host不存在时会返回404错误。因此可以通过Host头字段来指定应用的名称，通过HTTP头部的关键字unknown_route、vcap以及正文中“Requested route (‘***’) does not exist”等来识别PaaS平台，通过HTTPS证书来识别域名。我们用SHODAN来试试：

这仅仅只是其中的一个例子。大家注意SSL证书，Common Name字段指出了它所代表的域名。如果不知道域名，我们基本无法对其进行任何评估和测试。

SHODAN中发现的Cloud Foundry还是有比较多的，不过大多还是在AWS、GAE、Azure上，自建的可能较少。在其中我们可以发现小米、平安、福特、奥迪、奔驰、安联等公司的身影。

2. Cloud Foundry应用的枚举

根据上文提到的特征，我用Python实现了一个枚举PaaS应用的脚本，逻辑很简单：收集一个top 1w的主机名字典，用requests+gevent循环发出HTTP(S)请求，检测是否出现特定关键字来判断一个应用是否存在。代码和字典放在我的git上了：https://github.com/penoxcn/CloudFoundry。使用20个并发，大约1分多钟就可以跑完1w个名字。

来看看cloud.gov的输出：

找到的应用列表如下：

看看其中一个应用的样子：

3.CF通用的应用

Cloud Foundry系统自身一般有以下几个应用：

api/login/uaa/loggregator/apps/console/metrics等。api应用提供了CF平台的版本信息，login和uaa是CF平台的用户和认证管理，console一般是发布控制台。

来看移动的一个例子：

在外部DNS是不解析这个paas二级子域名的（也许移动已弃置它了？），但是可以通过设置Host字段头来（写host文件）访问到。

4.渗透测试评估

PaaS应用绝大部分都是Web应用，如何对其进行渗透测试评估，套路大家应该都很熟了，在此我就简单的说一下思路和经验吧。

（1）访问每个发现的PaaS域名，看看它是干什么的，寻找感兴趣的目标。有时候不需要做什么探测也许就有大发现。例如我曾遇到一个xxxSpider应用，应该是个爬虫：

可以直接在界面右边写Python代码（原意只是一个爬取Web页面的任务函数）然后执行，在左边显示结果。然后我把任务函数内容改改就直接SHELL了–这可是生产DMZ啊。一问开发，对方无辜地说：我这个应用只能内部访问啊，不应该放到互联网去，我上线单里面提的申请就写得清清楚楚的。球踢回来，我们才发现安全团队对PaaS的存在还没有感知，更别提管控了。

（2）寻找PaaS控制台、用户管理入口的登录凭证。尝试创建一个账号，在login应用里，PCF提供了注册账号的模板，试试是否可以成功？

（3）寻找定制开发的管理控制台的入口，尝试弱密码。在测试实施过程中，很有可能会遗留一些默认账号、测试账号、预设账号，使用了简单密码。我就发现自己公司的PaaS，其中两个开发人员的账号，还是初始密码123456：

如果有足够的权限，就可以发布自己的应用了：

大家看到里面都是test应用–而这是在生产的PaaS系统里！

发布个JSP版的WebShell：

（4）CF的应用都是有日志的，尝试猜测下日志的应用名字。日志中包含大量信息，正常情况下不应该暴露在互联网中。我们的Log都上大数据了，前端应用就是Kibana：

当然如此逆天的应用都得第一时间在互联网上掐断访问了。

（5）虽然CF应用都是运行在容器上，权限受限，但一旦有机会获得一个WebShell，你仍然可以通过与系统交互获得极大的扩展，各种Linux系统命令、Python环境、Perl环境、Java环境甚至编译环境都可以为你所用，用WebShell进行内部网络扫描探测、TCP代理隧道等都是可能的。

加固措施

一旦我们对Cloud Foundry的特点了解清楚，就可以根据实际的情况作出相应的安全加固措施了。在做完渗透测试评估后，我们陆续做了以下的改进措施：

（1）将PaaS区从传统的DMZ区域中逐步迁移到单独的DMZ区域中，使用单独的防火墙控制，减少其与传统DMZ区的相互影响；

（2）在互联网接入层，我们用的是F5做负载均衡，新建了一条iRules规则，检查访问PaaS的Host字段必须在登记的列表中。不在列表中的应用从互联网是不能访问的，但不会影响内部正常使用；

（3）一旦我们能够控制了互联网入口，我们改进了上线的流程，要求所有新的互联网PaaS应用上线前，必须先进行漏洞扫描，确认无漏洞之后，才能在F5上加入该应用的Host名字，配置DNS解析，允许互联网的访问；

（4）在内部也限制了PaaS发布控制台的访问，要求只能从专用的跳板机访问PaaS发布控制台来发布应用。开发人员的账号和权限也相应地进行了清理。