Slide 1

Slide 1 text

雲端 DHCP 安全問題

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

用 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

Slide 4

Slide 4 text

一般的 IT 環境中 dhclient 從 DHCPACK 中得知 IP DHCP Server DHCPACK 封包 dhclient

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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 管理機制)

Slide 7

Slide 7 text

攻擊手法 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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

攻擊手法 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 請 注 意 兩 組 的 先 後 順 序

Slide 10

Slide 10 text

攻擊手法 Project Victim Instance Compute Engine 假 Metadata 對 guest-agent 執行惡意命令: 「這裡有一把 SSH key 把它放進 instance」 /etc/hosts Metadata Server 惡意命令 假 Metadata Server guest-agent

Slide 11

Slide 11 text

攻擊手法 Project Victim Instance Compute Engine 攻擊者成功植入 "登入 root 的 SSH Key" /etc/hosts Metadata Server 登入 root 的 SSH key 惡意命令 假 Metadata Server guest-agent

Slide 12

Slide 12 text

檢查異常連線 請檢查 /etc/hosts, metadata.google.internal 是否只有一筆, 且正確 IP 僅有 169.254.169.254 被插入的 IP 及 Hostname 原為該機器的 私人 IP 及 Hostname 正常情況 異常情況

Slide 13

Slide 13 text

我們的研究 跟前幾天的新聞差異

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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 加入了 「安全檢查」

Slide 18

Slide 18 text

如何修補漏洞?

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

如何預防類似攻擊?

Slide 21

Slide 21 text

預防方法 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

Slide 22

Slide 22 text

容器, 需不需要防守?

Slide 23

Slide 23 text

容器「需要防守」 問題 ● 容器 Network-mode 的複雜性 + ● DHCP 基於 UDP,可以偽造來源 IP 方法 ● host 端的 guest-configs 更新 (必須) ● host 端的 iptables 新增「 udp 68 僅接受 Metadata Server 的流量」 (額外建議)

Slide 24

Slide 24 text

容器「需要防守」 ● 容器 Network-mode 的複雜性 ● iptables 切出乾淨的規則 : ○ Host-to-Container ○ Container-to-Container ○ Container-to-Host ○ Container-to-Metadata ○ Container-to-WAN

Slide 25

Slide 25 text

規劃安全架構,保護敏感資料 Funny-Systems-OSS [email protected]

Slide 26

Slide 26 text

法泥系統 (Funny Systems) 可以協助您 ! 研究雲端元件 特性 & 漏洞 重現攻擊手段 提出防守策略 我們具備頂尖的資安攻防能力, 開發獨家工具

Slide 27

Slide 27 text

您認為一般的資安技術服務, (例如:滲透測試、原始碼檢查) 可以保護您在意的資料、個資 嗎? 程式碼改版,就又要花一筆檢測費用?

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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