云原生服务风险测绘分析

一、概述

Etcd是一个高可用的分布式键值对数据库,其是由CoreOS团队于2013年6月发起的开源项目,基于Go语言实现,距今已将近10年时间,目前在Github上已有40K的Star数和8.6K的Fork数,社区非常活跃,有超过700位贡献者。从版本整体发展历史来看,Etcd主要有v2和v3两个版本,v3版本较v2版本相同点在于它们共享一套Raft协议代码,不同点在于两个版本的数据是相互隔离的,即若将v2版本升级至v3版本,原来的v2版本的数据还是只能用v2版本的接口访问,而不能被v3版本的接口所访问。

Etcd也是Kubernetes中十分重要的存储组件,Kubernetes中主要有两个服务会用到Etcd来协同和存储相关配置,分别是CNI网络插件以及Kubernetes自身(包括各种对象的状态和元数据信息)。

2018年12月,Etcd以孵化项目形式加入CNCF,并于2020年10月24正式毕业,成为CNCF第14个毕业项目,目前,Etcd已被许多国内外企业用于生产环境,包括阿里巴巴,百度,华为,思科,IBM, Uber等。

本篇为云原生服务测绘系列的第五篇,主要从资产发现、资产漏洞、资产脆弱性发现三个维度对国内暴露的Etcd进行了测绘分析,最后笔者针对Etcd提供了一些安全建议,希望各位读者通过阅读此文可对Etcd服务风险暴露情况有更清晰的认识。

   注:文中统计的测绘数据为近一个月的国内数据,相关技术仅供研究交流,请勿应用于未授权的渗透测试。

二、Etcd资产风险测绘分析

2.1 Etcd资产暴露情况分析

借助测绘数据,我们可以了解到国内Etcd资产地区和版本的分布情况,笔者也以这两个维度为各位读者进行介绍。

2.1.1 Etcd资产地区分布

笔者从测绘数据中得到Etcd相关资产共10377条数据,地区分布如图1所示(资产数较少的由于篇幅原因不在图中显示)

图1. Etcd资产地区分布

同时,笔者也针对Etcd资产端口分布情况进行了统计,如图2所示:

图2. Etcd资产端口分布

由图1,图2我们可以得出如下信息:

  • 国内暴露的Etcd资产信息中有约75%的数据来源于北京市、上海市、广东省、浙江省、香港特别行政区,其中北京市暴露3848条数据位居第一;
  • 国内暴露的Etcd资产使用端口为2379端口,2379为Etcd用于客户端连接的端口,如果将该端口暴露至公网,可能会导致未授权访问的风险

2.1.2 Etcd资产版本分布

借助测绘数据,笔者对国内暴露的Etcd资产版本进行了分析,其分布情况如图3所示(资产版本数较少的由于篇幅原因不在图中显示):

图3. Etcd资产版本分布

上图可以看出在统计的Etcd资产中,在获取到具体版本的资产中,绝大多数资产暴露版本分布在3.3.11、3.4.3、3.3.8、3.5.0、3.4.15、3.4.13、3.3.13之中。其中3.3.11版本数量最多,占457个,该版本于2019年5月发布,距今已有3年,是较为老旧的版本,但在网上暴露的资产数却不少。

2.2 Etcd脆弱性风险和漏洞介绍

2.2.1 脆弱性风险介绍

Etcd配置文件项较多,其中包含一些较为敏感的配置,若用户配置不当会引起一定的风险,笔者将其脆弱性配置汇总如下:

–listen-client-urls

该配置项用于监听客户端通讯的 URL 列表。即该配置项会告诉Etcd在特定的Scheme://IP:Port接收客户端发来的请求。Scheme项可以是HTTP或HTTPS,若将IP指定为0.0.0.0,Port指定为2379,Etcd将接收任意内、外部发起的请求,Etcd也同时会暴露至公网。该配置项默认值为http://localhost:2379,需要注意的是,若有相关Web服务与Etcd部署在同一内网中,且相关Web服务含有SSRF漏洞,那么即使–listen-client-urls为默认配置,攻击者也可以通过该缺陷访问到Etcd服务。

笔者还注意到,若用户将–listen-client-urls配置中IP设置为0.0.0.0,还可以间接利用Etcd内部API获取到Etcd具体的版本信息,如图4所示:

图4. 通过Etcd API获取Etcd服务版本信息

–client-cert-auth

该配置项用于开启客户端证书认证,默认为false。若用户将–listen-client-urls设置为0.0.0.0:2379,–client-cert-auth设置为false, 那么攻击者可对Etcd服务进行未授权访问,窃取存放在Etcd中的敏感数据。若将–client-cert-auth设置为true,用户需要进行证书校验才能访问到Etcd存放的数据,校验过程中涉及三个相关证书文件,分别是client.crt,client.key和ca.cert,通过etcdctl(Etcd的命令行工具),我们可对Etcd进行访问,如下图展示了如何通过etcdctl获取foo这个key对应的value:

图5. 通过证书访问Etcd

需要注意的是,如果证书遭到泄露,攻击者仍然可以通过以上访问方式窃取隐私数据。

2.2.2 漏洞介绍

Etcd于2013年开源至今,已有约9年时间,在此期间一共曝出六个漏洞[1],漏洞数量相对较少,从CVE编号信息我们可以看出漏洞披露时间分别在2018、2020年,根据CVSS2.0标准,这六个漏洞中仅有一个是低危漏洞,剩余五个均为中危漏洞。CVE-2018-1098,CVE-2018-1099为CSRF和DNS重绑定漏洞,CVE-2020-15136和CVE-2020-16886为权限绕过类漏洞,CVE-2020-15114为DoS漏洞,CVE-2020-15115为账户暴破漏洞,其中CVE-2020-15115CVE-2020-15114CVE-2020-16886在市面上曝光度较大,笔者针对以上漏洞进行了信息汇总,如图6所示:

图6. Etcd漏洞介绍

2.3 Etcd资产脆弱性暴露情况分析

借助测绘数据,笔者从Etcd漏洞维度,统计了现有暴露资产的漏洞分布情况,如图7所示:

图7. Etcd漏洞介绍

可以看出,在国内互联网暴露的Etcd资产中,有1904个资产被曝出含未授权访问漏洞,约占总资产数18%1261个资产含有CVE-2020-15115漏洞(账户爆破),约占总资产数12%578个资产含有CVE-2020-15114漏洞(DoS),约占总资产数6%441个资产含有CVE-2018-16886漏洞(权限绕过),约占总资产数4%,其中每个资产可能命中多条CVE,剩余CVE漏洞曝光度较少。从前面的Etcd漏洞介绍中,我们可以进一步了解这些漏洞,篇幅原因此处不再赘述。

2.4 安全建议

  • 确保Etcd的启动配置文件中client-cert-auth项配置为true,即开启客户端证书校验
  • 禁止将Etcd的启动配置文件中listen-client-urls项IP配置为0.0.0, 避免暴露至公网
  • 针对Etcd服务定时进行扫描,发现并清理相关安全漏洞
  • 针对Etcd数据进行加密存储
  • 及时根据官方补丁进行修复或升级至最新版本

三、总结

Etcd凭借自身简单易操作、强一致性、高可用性、安全性的特点,加之有CoreOS和Kubernetes两个重要项目为其背书,现已被众多大型企业在内部深度应用,但如Docker、Kubernetes等云原生服务一样,由于项目自身热度较高,自然也会引起攻击者的注意,通过利用Etcd的脆弱性配置及漏洞,攻击者可以针对公网暴露的资产进行大规模渗透测试,造成巨大危害。借助测绘数据,我们可以了解到Etcd资产在公网的暴露面及风险面。本篇是云原生服务风险系列第五篇,笔者将持续关注云原生环境下的其它组件,并进行相应的测绘风险分析,感谢各位读者持续关注系列文章,若有任何问题欢迎提出,互相交流学习。

参考文献

[1] https://www.cvedetails.com/product/45128/Redhat-Etcd.html?vendor_id=25

版权声明
本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司(“绿盟科技”)。作为分享技术资讯的平台,绿盟科技期待与广大用户互动交流,并欢迎在标明出处(绿盟科技-技术博客)及网址的情形下,全文转发。
上述情形之外的任何使用形式,均需提前向绿盟科技(010-68438880-5462)申请版权授权。如擅自使用,绿盟科技保留追责权利。同时,如因擅自使用博客内容引发法律纠纷,由使用者自行承担全部法律责任,与绿盟科技无关。

Spread the word. Share this post!

Meet The Author