Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
雲端 DHCP 安全問題
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Funny Systems
July 07, 2021
Technology
1.1k
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
雲端 DHCP 安全問題
Funny Systems
July 07, 2021
More Decks by Funny Systems
See All by Funny Systems
雲端資料掉光光 - GCP 事件調查真實案例
funnysystems
2
1.7k
頑固吧!GCP Cloud SQL (Why Hardening GCP Cloud SQL)
funnysystems
0
510
SMB 捲土重來 (Turning SMB Server Side Bug to Client Side)
funnysystems
0
320
跟壞鄰居想的一樣,供應鏈安全與硬體後門
funnysystems
1
800
以安全工程角度,連結實務與設計
funnysystems
0
410
FunnyPot ‐ 改造 Windows 核心,強固化、蜜罐化
funnysystems
0
750
攻擊者的視角 - 兼談匿名識別度與可追蹤性
funnysystems
1
490
黑客技術,黑科技樹 II
funnysystems
1
870
黑科技樹,黑客技術
funnysystems
1
610
Other Decks in Technology
See All in Technology
LLM/Agent評価:トップ営業の発言を「正解」にする 〜暗黙的正解による評価を営業資産に変える〜
takkuhiro
1
230
【Claude Code】鹿野さんに聞く 私の推しの並行開発環境 大公開 / claude-code-parallel-2026-07-15
tonkotsuboy_com
12
8.5k
Gen3R: 3D Scene Generation Meets Feed-Forward Reconstruction
spatial_ai_network
0
130
AmplifyHostingConstructからSSRフレームワークのためのホスティング設計を考察する/amplify-hosting-construct
fossamagna
1
190
AI Driven AI Governance
pict3
0
480
End-to-Endで考える信頼性 —LINEアプリにおけるクライアント開発×SRE連携の実践
maruloop
4
4.5k
“それは自分の仕事じゃない"を越えて行け
yuukiyo
1
450
Alphaモジュール使っていいのかい!?いけないのかい!?どっちなんだいっ!?
watany
1
260
SRE Next 2026 何でも屋からの脱却
bto
0
890
個人開発で育てる「大規模設計の苗床」 - AI時代の1人開発から始める業務への知識接続 / The Seedbed for Large-Scale Design - From AI-Era Solo Projects to Professional Knowledge
bitkey
PRO
1
280
非定型なドキュメントを効率よくリファクタする 〜えぇ!?仕様書27本の移行が1日で終わったって!?〜
subroh0508
2
550
AI時代の闇と光
tatsuya1970
0
100
Featured
See All Featured
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
WENDY [Excerpt]
tessaabrams
11
38k
Accessibility Awareness
sabderemane
1
150
What Being in a Rock Band Can Teach Us About Real World SEO
427marketing
0
1k
How to Think Like a Performance Engineer
csswizardry
28
2.7k
エンジニアに許された特別な時間の終わり
watany
108
250k
Balancing Empowerment & Direction
lara
6
1.2k
SEO for Brand Visibility & Recognition
aleyda
0
4.6k
Heart Work Chapter 1 - Part 1
lfama
PRO
8
36k
How to train your dragon (web standard)
notwaldorf
97
6.7k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
6k
How to Get Subject Matter Experts Bought In and Actively Contributing to SEO & PR Initiatives.
livdayseo
0
150
Transcript
雲端 DHCP 安全問題
None
用 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
一般的 IT 環境中 dhclient 從 DHCPACK 中得知 IP DHCP Server
DHCPACK 封包 dhclient
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
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 管理機制)
攻擊手法 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
攻擊手法 Project Victim Instance Compute Engine guest-agent 會 (定期) 存取
Metadata, 但從 /etc/hosts 解析域名時, 它只會找第一個看到的 Metadata 的 IP,所以找到假 Metadata /etc/hosts Metadata Server 假 Metadata Server guest-agent
攻擊手法 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 請 注 意 兩 組 的 先 後 順 序
攻擊手法 Project Victim Instance Compute Engine 假 Metadata 對 guest-agent
執行惡意命令: 「這裡有一把 SSH key 把它放進 instance」 /etc/hosts Metadata Server 惡意命令 假 Metadata Server guest-agent
攻擊手法 Project Victim Instance Compute Engine 攻擊者成功植入 "登入 root 的
SSH Key" /etc/hosts Metadata Server 登入 root 的 SSH key 惡意命令 假 Metadata Server guest-agent
檢查異常連線 請檢查 /etc/hosts, metadata.google.internal 是否只有一筆, 且正確 IP 僅有 169.254.169.254 被插入的
IP 及 Hostname 原為該機器的 私人 IP 及 Hostname 正常情況 異常情況
我們的研究 跟前幾天的新聞差異
從發現者的文件得知 [1] [1] https://github.com/irsl/gcp-dhcp-takeover-code-exec 發現者認為是 ISC DHCP 的亂數弱點
從發現者的文件得知 [1] [1] https://github.com/irsl/gcp-dhcp-takeover-code-exec GCP 拖了快一年的時間,還沒修補漏洞,攻擊程式已經公開
發現者沒說的事情、關鍵漏洞 [1] [1] https://github.com/GoogleCloudPlatform/guest-configs 萬惡之源 !!
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 加入了 「安全檢查」
如何修補漏洞?
如何修補漏洞? 請檢查、更新 GCE 機器中的 /usr/bin/google_set_hostname [1] [1] https://github.com/GoogleCloudPlatform/guest-configs/blob/master/src/usr/bin/google_set_hostname
如何預防類似攻擊?
預防方法 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
容器, 需不需要防守?
容器「需要防守」 問題 • 容器 Network-mode 的複雜性 + • DHCP 基於
UDP,可以偽造來源 IP 方法 • host 端的 guest-configs 更新 (必須) • host 端的 iptables 新增「 udp 68 僅接受 Metadata Server 的流量」 (額外建議)
容器「需要防守」 • 容器 Network-mode 的複雜性 • iptables 切出乾淨的規則 : ◦
Host-to-Container ◦ Container-to-Container ◦ Container-to-Host ◦ Container-to-Metadata ◦ Container-to-WAN
規劃安全架構,保護敏感資料 Funny-Systems-OSS
[email protected]
法泥系統 (Funny Systems) 可以協助您 ! 研究雲端元件 特性 & 漏洞 重現攻擊手段
提出防守策略 我們具備頂尖的資安攻防能力, 開發獨家工具
您認為一般的資安技術服務, (例如:滲透測試、原始碼檢查) 可以保護您在意的資料、個資 嗎? 程式碼改版,就又要花一筆檢測費用?
以應用程式安全為核心目標 了解需求 滲透測試 原始碼檢查
以資料安全為核心目標 了解需求 改造流程 重整架構 開發私房工具 滲透測試 原始碼檢查 獨立資料路由 敏感資料分離 憑證透明解密
備份透明加密 SQL 透明加解密