快捷搜索:  网络  后门  CVE  渗透  木马  扫描  黑客  as

从Cloud Foundry谈企业PaaS环境的安全危害与评估

*

媒介

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的官方网站查阅。

Cloud-Foundry-diagram.png

部署架构

绝管CF支持在不同的底层基础架构上部署,但在企业数据中心中,终极照样落实到某个逻辑或者物理的地区中,通过收集以及安全设备与企业内网互联。以下图是一个简化的部署示意图:

dmzhybrid.png

在这里,面向互联网提供服务的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来简单探测一下:

默认要求:

curl-特征.png

返归404。

配置随便一个Host头:

curl-特征1.png

返归404。

配置一个真实存在的Host头:

curl-特征2.png

返归200。

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

shodan.png

这仅仅只是其中的一个例子。人人注意SSL证书,Co妹妹on 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的输出:

cloud.gov.enum.png

找到的应用列表以下:

usgov.png

cloud.gov.enum2.png

看看其中一个应用的模样:

usgovment.png

3.CF通用的应用

Cloud Foundry体系自身一般有下列几个应用:

api/login/uaa/loggregator/apps/console/metrics等。api应用提供了CF平台的版本信息,login以及uaa是CF平台的用户以及认证治理,console通常为发布控制台。

来看挪移的一个例子:

挪移paas.png

在外部DNS是不解析这个paas二级子域名的(也许挪移已弃置它了?),然则可以通过配置Host字段头来(写host文件)走访到。

4.渗透排泄测试评估

PaaS应用尽大部分都是Web应用,怎么样对其进行渗透排泄测试评估,套路人人应该都很熟了,在此我就简单的说一下思路以及经验吧。

(1)走访每一个发现的PaaS域名,看看它是干什么的,寻觅感兴致的目标。无意候不需要做什么探测也许就有大发现。例如我曾遇到一个xxxSpider应用,应该是个爬虫:

cmb1.png

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

(2)寻觅PaaS控制台、用户治理入口的登录凭据。尝试创建一个账号,在login应用里,PCF提供了注册账号的模板,试试是否可以成功?

福特1.png

(3)寻觅定制开发的治理控制台的入口,尝试弱暗码。在测试实施过程中,颇有可能会遗留一些默认账号、测试账号、预设账号,使用了简单暗码。我就发现本人公司的PaaS,其中两个开发人员的账号,照样初始暗码123456:

cmb2.png

要是有充足的权限,就可以发布本人的应用了:

人人看到内里都是test应用–而这是在生产的PaaS体系里!

发布个JSP版的WebShell:

cmb4.png

(4)CF的应用都是有日记的,尝试猜测下日记的应用名字。日记中包含大批信息,正常情形下不应该暴露在互联网中。我们的Log都上大数据了,前端应用就是Kibana:

cmb5.png

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

(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发布控制台来发布应用。开发人员的账号以及权限也相应地进行了清理。

总结

作为比较成熟的PaaS平台,Cloud Foundry自身在安全控制方面做得很不错了。通过上文的经验分享,我们看到很多安全的问题,实在都是详细实施时我们对其了解不够透彻或者治理不规范酿成的。希翼本文能够给到人人一些参考以及启发,感谢。

*

您可能还会对下面的文章感兴趣: