一、概述
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
往期回顾：
云原生服务风险测绘分析（四）：Prometheus
云原生服务风险测绘分析（三）：Kong和Apache APISIX
云原生服务风险测绘分析（二）：Harbor
云原生服务风险测绘分析（一）：Docker和Kubernetes
关于星云实验室
星云实验室专注于云计算安全、解决方案研究与虚拟化网络安全问题研究。基于IaaS环境的安全防护，利用SDN/NFV等新技术和新理念，提出了软件定义安全的云安全防护体系。承担并完成多个国家、省、市以及行业重点单位创新研究课题，已成功孵化落地绿盟科技云安全解决方案。
内容编辑：创新研究院 浦 明
责任编辑：创新研究院 陈佛忠
