云原生服務風險測繪分析（五）：Etcd
一、概述
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
