一、概述
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我们可以得出如下信息:
1. 国内暴露的Etcd资产信息中有约75%的数据来源于北京市、上海市、广东省、浙江省、香港特别行政区,其中北京市暴露3848条数据位居第一;
2. 国内暴露的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-15115,CVE-2020-15114,CVE-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
安全建议
1. 确保Etcd的启动配置文件中client-cert-auth项配置为true,即开启客户端证书校验
2. 禁止将Etcd的启动配置文件中listen-client-urls项IP配置为0.0.0.0, 避免暴露至公网
3. 针对Etcd服务定时进行扫描,发现并清理相关安全漏洞
4. 针对Etcd数据进行加密存储
5. 及时根据官方补丁进行修复或升级至最新版本
三. 总结
Etcd凭借自身简单易操作、强一致性、高可用性、安全性的特点,加之有CoreOS和Kubernetes两个重要项目为其背书,现已被众多大型企业在内部深度应用,但如Docker、Kubernetes等云原生服务一样,由于项目自身热度较高,自然也会引起攻击者的注意,通过利用Etcd的脆弱性配置及漏洞,攻击者可以针对公网暴露的资产进行大规模渗透测试,造成巨大危害。借助测绘数据,我们可以了解到Etcd资产在公网的暴露面及风险面。本篇是云原生服务风险系列第五篇,笔者将持续关注云原生环境下的其它组件,并进行相应的测绘风险分析,感谢各位读者持续关注系列文章,若有任何问题欢迎提出,互相交流学习。
参考文献
[1] https://www.cvedetails.com/product/45128/Redhat-Etcd.html?vendor_id=25
往期回顾:
云原生服务风险测绘分析(三):Kong和Apache APISIX
云原生服务风险测绘分析(一):Docker和Kubernetes
关于星云实验室
星云实验室专注于云计算安全、解决方案研究与虚拟化网络安全问题研究。基于IaaS环境的安全防护,利用SDN/NFV等新技术和新理念,提出了软件定义安全的云安全防护体系。承担并完成多个国家、省、市以及行业重点单位创新研究课题,已成功孵化落地绿盟科技云安全解决方案。
内容编辑:创新研究院 浦 明
责任编辑:创新研究院 陈佛忠