Upgrade to Pro — share decks privately, control downloads, hide ads and more …

雲端 DHCP 安全問題

雲端 DHCP 安全問題

D69e77fd50edf1a9c6d5ffcddd03dd90?s=128

Funny Systems

July 07, 2021
Tweet

Transcript

  1. 雲端 DHCP 安全問題

  2. None
  3. 用 DHCP 協定 拿下 GCP 的主機[1] 1. 發送假 DHCPACK 封包,

    誘使 dhclient 等污染 hosts 檔後, GCP guest-agent [2] (其他 agent 也有可能) 對 metadata 發出請求時, 其 DNS 解析被受污染的 hosts 影響 2. VPC Firewall 預設的規則,會放行區網內 udp 68 的連線[3] [1] https://github.com/irsl/gcp-dhcp-takeover-code-exec [2] https://github.com/GoogleCloudPlatform/guest-agent [3] https://cloud.google.com/vpc/docs/firewalls#more_rules_default_vpc
  4. 一般的 IT 環境中 dhclient 從 DHCPACK 中得知 IP DHCP Server

    DHCPACK 封包 dhclient
  5. GCP 獨特的機制 Project Victim Instance Compute Engine guest-configs 從 dhclient

    把 Victim 的 IP 及 hostname 寫入 /etc/hosts /etc/hosts Metadata Server (DHCP Server) [1] guest-configs DHCPACK 封包 [1] https://cloud.google.com/vpc/docs/firewalls#alwaysallowed 寫入 dhclient
  6. GCP 獨特的機制 Project Victim Instance Compute Engine guest-configs 從 dhclient

    把 Victim 的 IP 及 hostname 寫入 /etc/hosts /etc/hosts Metadata Server (DHCP Server) [1] guest-configs DHCPACK 封包 寫入 dhclient 該機器的 私人 IP 及 Hostname (某種 IP 管理機制)
  7. 攻擊手法 Project Victim Instance Compute Engine /etc/hosts Metadata Server (DHCP

    Server) guest-configs 寫入 dhclient DHCPACK 假封包 攻擊者透過 DHCPACK 發送一堆假封包, 讓 guest-configs 將原本 Victim 的 IP 及 hostname 替換成 假 Metadata 的 IP 及 關鍵的 hostname[1] [1] metadata.google.internal
  8. 攻擊手法 Project Victim Instance Compute Engine guest-agent 會 (定期) 存取

    Metadata, 但從 /etc/hosts 解析域名時, 它只會找第一個看到的 Metadata 的 IP,所以找到假 Metadata /etc/hosts Metadata Server 假 Metadata Server guest-agent
  9. 攻擊手法 Project Victim Instance Compute Engine guest-agent 會 (定期) 存取

    Metadata, 但從 /etc/hosts 解析域名時, 它只會找第一個看到的 Metadata 的 IP,所以找到假 Metadata /etc/hosts Metadata Server 假 Metadata Server guest-agent 被插入的 IP 及 Hostname 正確的 Metadata Server IP 及 Hostname 請 注 意 兩 組 的 先 後 順 序
  10. 攻擊手法 Project Victim Instance Compute Engine 假 Metadata 對 guest-agent

    執行惡意命令: 「這裡有一把 SSH key 把它放進 instance」 /etc/hosts Metadata Server 惡意命令 假 Metadata Server guest-agent
  11. 攻擊手法 Project Victim Instance Compute Engine 攻擊者成功植入 "登入 root 的

    SSH Key" /etc/hosts Metadata Server 登入 root 的 SSH key 惡意命令 假 Metadata Server guest-agent
  12. 檢查異常連線 請檢查 /etc/hosts, metadata.google.internal 是否只有一筆, 且正確 IP 僅有 169.254.169.254 被插入的

    IP 及 Hostname 原為該機器的 私人 IP 及 Hostname 正常情況 異常情況
  13. 我們的研究 跟前幾天的新聞差異

  14. 從發現者的文件得知 [1] [1] https://github.com/irsl/gcp-dhcp-takeover-code-exec 發現者認為是 ISC DHCP 的亂數弱點

  15. 從發現者的文件得知 [1] [1] https://github.com/irsl/gcp-dhcp-takeover-code-exec GCP 拖了快一年的時間,還沒修補漏洞,攻擊程式已經公開

  16. 發現者沒說的事情、關鍵漏洞 [1] [1] https://github.com/GoogleCloudPlatform/guest-configs 萬惡之源 !!

  17. Patch Diff [1] https://github.com/GoogleCloudPlatform/guest-configs/blob/b23d6ef85bc750370f52e77aa15ba36f735668af/src/usr/bin/google_set_hostname#L23 看來 GCP 實際上修改的是這個腳本呢 ! 舊版本 新版本

    被插入的 IP 及 Hostname 正確的 Metadata Server IP 及 Hostname 加入了 「安全檢查」
  18. 如何修補漏洞?

  19. 如何修補漏洞? 請檢查、更新 GCE 機器中的 /usr/bin/google_set_hostname [1] [1] https://github.com/GoogleCloudPlatform/guest-configs/blob/master/src/usr/bin/google_set_hostname

  20. 如何預防類似攻擊?

  21. 預防方法 1. Host 端 : 使用 iptables,udp 68 僅接受 Metadata

    Server 的流量 sudo iptables -I INPUT ! -s 169.254.169.254 -p udp -m udp --dport 68 -j DROP 2. VPC : 僅允許來自 169.254.169.254 的 udp 68 連入[1] (顯式) gcloud compute firewall-rules create default-allow-dhcp-from-metadata --allow "udp:68" --source-ranges "169.254.169.254" --priority 0 3. VPC : udp 68 不接受任何連入流量 gcloud compute firewall-rules create default-deny-dhcp --action deny --rules "udp:68" --source-ranges "0.0.0.0/0" --priority 1 [1] https://cloud.google.com/vpc/docs/firewalls#more_rules_default_vpc
  22. 容器, 需不需要防守?

  23. 容器「需要防守」 問題 • 容器 Network-mode 的複雜性 + • DHCP 基於

    UDP,可以偽造來源 IP 方法 • host 端的 guest-configs 更新 (必須) • host 端的 iptables 新增「 udp 68 僅接受 Metadata Server 的流量」 (額外建議)
  24. 容器「需要防守」 • 容器 Network-mode 的複雜性 • iptables 切出乾淨的規則 : ◦

    Host-to-Container ◦ Container-to-Container ◦ Container-to-Host ◦ Container-to-Metadata ◦ Container-to-WAN
  25. 規劃安全架構,保護敏感資料 Funny-Systems-OSS info@funny.systems

  26. 法泥系統 (Funny Systems) 可以協助您 ! 研究雲端元件 特性 & 漏洞 重現攻擊手段

    提出防守策略 我們具備頂尖的資安攻防能力, 開發獨家工具
  27. 您認為一般的資安技術服務, (例如:滲透測試、原始碼檢查) 可以保護您在意的資料、個資 嗎? 程式碼改版,就又要花一筆檢測費用?

  28. 以應用程式安全為核心目標 了解需求 滲透測試 原始碼檢查

  29. 以資料安全為核心目標 了解需求 改造流程 重整架構 開發私房工具 滲透測試 原始碼檢查 獨立資料路由 敏感資料分離 憑證透明解密

    備份透明加密 SQL 透明加解密