Skip to main content

7 posts tagged with "Security"

View All Tags

· 6 min read
HungWei Chiu

標題: 「Tetragon, 基於 eBPF 的 Kubernetes 資安管理工具」 類別: others 連結: https://isovalent.com/blog/post/2022-05-16-tetragon

Cillium 的開發團隊 isovalent 最近公布其內部一直使用的資安相關專案， Teragon (可愛的蜜蜂戰士)。

Teragon 底層是基於 eBPF 的技術，其目的就是讓你的 Kubernetes 於資安方面可以獲得超級強大的能力，包含

  1. 詳細的視覺化功能，讓你可以一目瞭然到底系統中各項資源的發生過程
  2. 動態強化，可以讓你透過 Kubernetes CRD, OPA, Json 等各種格式來描述相關規範，然後動態無縫的套入到你的 Kubernetes 叢集中

探討 Teragon 前，要先理解以前目前已知的相關解決方案有哪些，而這些解決方案又有什麼樣的優缺點，包含

  1. App Instrumentation
  2. LD_PRELOAD
  3. ptrace
  4. seccomp
  5. SELinux/LSM
  6. Kernel Module

上述六個方式都有各自的特點，這邊簡單敘述

App Instrumentation O 效率高，可以看到非常細部的資訊 X 程式碼需要修改，不夠透明 X 單純的視覺化，不能套入資安規則來防護應用程式 X 應用程式為主，不能理解整個系統的狀況

LD_PRELOAD (動態切換載入的 Library ) O 效率高 O 應用程式不需要修改 X 如果是 Static Llinking 的應用程式那就沒有用了 X 幾乎沒有什麼觀察性可言

ptrace (透過 kernel 提供的功能來檢視使用的 syscall) O 透明，應用程式不用修改 X 效能負擔比較高 X 應用程式有辦法偵測到自己目前被 ptrace 給監控 X 整體範圍只能針對 syscall(系統呼叫)

seccomp (可以過濾應用程式呼叫的 syscall) O 有效率，應用程式不需要修改 X 規則只能針對 syscall 去阻擋 X 沒有很好的視覺化方式

SELinux/LSM (Kernel 內建的 security 框架，可以針對存取去控制) O 有效率，應用程式不需要修改 O 可防 TOCTTOU 攻擊 X 針對 Contaienr/Kubernetes 的整合很有限 X 不容易擴充 X 要針對攻擊類型去設定

Kernel Module O 有效率，應用程式不需要修改 O 不用修改 Kernel 就可以擴充功能 X 不是每個環境都允許使用者去載入 kenrel Module X Module 有問題會打爆你的 Kernel X 沒辦法無縫升級，意味你升級功能的過程中必須要將kernel module給 uninstall ，然後重新安裝

上列六個解決方案有的只能檢視相關流程，有的只能設定規則去防護，但是就是沒有一個工具可以全面處理，而基於 eBPF 實作的 Tetragon 則是一個 能夠提供兩項功能的全新解決方案。

首先資安防護方面， Tetragon 採取的是更底層的概念，不去探討特定的 CVE 操作手法，取而代之的是從幾個常見的攻擊方式來防禦。 假如有任何應用程式有不預期的下列行為，就可以直接將該 Process 移除

  1. 使用到不該使用的 capability
  2. 使用到不該使用的 linux namespace
  3. 使用到不該使用的 binary
  4. 看到不該出現的 Pid
  5. ...

這些規則都可以透過 Kubernetes CRD 來描述，當這些規則被送到 Kubernetes 後，相關的 Controller 就會將規則給轉換後續讓 eBPF 來處理 此外因為 eBPF 以及 kprobe 的架構，Tetragon 能夠看到非常多 kernel 的資源存取與操作，譬如

  1. syscall(系統呼叫)
  2. Virtual FS
  3. TCP/IP
  4. namespace
  5. Storage
  6. Network

Tetragon 收集上列不同資訊的資料後進行二次處理，透過精美的網頁來顯示系統中的各種資訊，這些資訊可以提供包含

  1. 哪些 Pod 一直存取 /etc/passwd, 採用何種方式存取 /etc/passwd
  2. 特定 Pod 中對外的網路流量資訊，從封包內容到用什麼指令去存取都可以看光光
  3. ...

eBPF 的應用愈來愈多，而目前看起來 isovalent 更是 Kubernetes 生態系中的領頭羊，雖然不確定未來是否能夠被廣泛採用，但是至少這方面還沒有看到其他解決方案有這麼積極的基於 eBPF 來開發 有餘力的話花點時間學習一下 eBPF 的概念可以加強自己對於這類型文章的速度與理解度

· 3 min read
HungWei Chiu

標題: 「istio 下因為YAML 與 Go template 結合產生的 CVE」 類別: others
連結: https://paper.seebug.org/1882/

熟悉 Kubernetes 的使用者一定對於各式各樣的資源格式感到不陌生，譬如描寫一個 Pod 需要準備些關於 containers 的基本資料，其餘還有 Label, Annotation 等 各種資料需要填寫。

Kubernetes 內透過 apimachinery 的方式來驗證每個欄位是不是合法，譬如最常見的就是創建資源名稱時有時候會因為等出現格式不符合，準確來說是 Pod 的方式來驗證每個欄位是不是合法，譬如最常見的就是創建資源名稱時有時候會因為等出現格式不符合，準確來說是 透過 DNS RFC 1123 來驗證 Pod 是否合法。 部分的數值資料可能會於 Controller 中額外去檢查，至於自定義的 CRD(Customer Resource Definition) 則是創建時可以透過 openAPIV3Schema 去定義每個欄位的合法數值。

今天這篇文章要介紹的問題是跟 istio 環境的問題，當使用者創建一個名為 Gateway 的資源到叢集中時， istio 會去讀取該 Gateway 資料並且轉換為 Service/Deployment 兩個底層資源。 作者仔細研究發現創建 Service 時會從 Gateway 中的 Annotation 找到名為 "networking.istio.io/service-type" 的資料，並用其作為 Serivce 的 type.

然而 Annotation 的數值沒有並沒有任何檢查機制，所以使用者可以於該欄位 "networking.istio.io/service-type" 填入各種數值，因此作者就嘗試撰寫一個非常長的 Annotation，譬如

  annotations:
    networking.istio.io/service-type: |-
      "LoadBalancer"
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: pwned-deployment
        namespace: istio-ingress
      spec:
        selector:
          matchLabels:
            app: nginx
        replicas: 1
        template:
          metadata:
            labels:
              app: nginx
          spec:
            containers:
            - name: nginx
              image: nginx:1.14.3
              ports:
              - containerPort: 80
              securityContext:
                privileged: true

結果非常順利的， isio 最終創造了一個作者故意描述的 deployment，而該 deployment 還特別的設定 privileged: true 的選項並且透過這次的測試證明該 YAML 的檢查問題導致使用者有機會插入任何想要的資源到環境中 對本文有興趣的可以觀看一下

· 2 min read
HungWei Chiu

標題: 「如何於 Docker 環境中運行 rootless 模式」 類別: container 連結: https://thenewstack.io/how-to-run-docker-in-rootless-mode/

雖然可以使用非 root 的方式去安裝 Docker 服務，但是 Docker 本身服務中還有其他各種元件需要透過 root 身份去運行，譬如 dockerd, containerd, runc 等元件， 而本篇文章則是探討要如何以真正 rootless 的方式來運行一個 docker container 。

使用 rootless container 有一些要注意的事情，譬如 port number 沒有辦法使用 1024 以下，所以如果你的服務有需要被外界存取時要使用大於 1024 的 port number。 此外 AppArmor, host network mode 這些都不支援，因此使用上會有一些情境要注意。

安裝其實滿簡單的， Docker 官網有提供 rootless 的安裝檔案，安裝後需要針對一個使用者 ID 進行處理，這個處理主要是因為要將 container 內的 root 使用者給轉換到系統上的非 root 使用者，所以才會有相關的 userID 要設定。 當然如果真的要完全追求 rootless 的容器解決方案可以考慮使用 Podman 來使用，其本身的設定就是針對 rootless 去開發的，使用上會相對於 docker 來說更為簡單。

· 2 min read
HungWei Chiu

標題: 「PwnKit, 長達 12 年可以讓一般使用者輕鬆變成 Root 的 CVE」 類別: others 連結: https://blog.qualys.com/vulnerabilities-threat-research/2022/01/25/pwnkit-local-privilege-escalation-vulnerability-discovered-in-polkits-pkexec-cve-2021-4034

CVE-2021-4034 講述的是 pkexec 此工具的 vulnerability，其影響範圍非常廣大，主要原因有

  1. 滿多系統預設都有安裝這個工具，而該工具預設有 SUID 的權限
  2. 2009 後的版本就內建此安全性問題，所以請趕緊更新系統上的 pkexec
  3. 任何使用者可以輕鬆地直接透過此漏洞變成 root 的身份，譬如你今天取得一個 nobody 的角色，你也是有辦法變成 root 的。

漏洞細節文章中有解釋非常多，主要是記憶體位置的處理沒有處理，當運行參數為空的時候，程式會意外地去讀取到後面的 envp 這塊用來存放環境變數的區塊，搭配 pkexec 後續的程式邏輯就有機會觸發本次 CVE 的安全性問題。 所以請趕緊更新系統上的 pkexec，確保該版本已經更新，否則任何一個使用者都可以輕鬆變成 root。

Ubuntu 使用者可參考 https://ubuntu.com/security/CVE-2021-4034

· One min read
HungWei Chiu

連結: https://www.cncf.io/blog/2020/09/09/how-to-enforce-kubernetes-network-security-policies-using-opa

不知道大家是否都有使用 Network Policy 來設定 Kubernetes 內部的 ACL? 這邊有個叫做 OPA 的工具可以用幫你驗證你的 Network Policy 是否運作良好，甚至當有新的應用服務要部署的時候，也會確定是否有跟 Network Policy 衝突 有興趣的人可以研究看看