Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
雲端 DHCP 安全問題
Search
Funny Systems
July 07, 2021
Technology
1.2k
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
530
SMB 捲土重來 (Turning SMB Server Side Bug to Client Side)
funnysystems
0
330
跟壞鄰居想的一樣,供應鏈安全與硬體後門
funnysystems
1
820
以安全工程角度,連結實務與設計
funnysystems
0
430
FunnyPot ‐ 改造 Windows 核心,強固化、蜜罐化
funnysystems
0
760
攻擊者的視角 - 兼談匿名識別度與可追蹤性
funnysystems
1
510
黑客技術,黑科技樹 II
funnysystems
1
880
黑科技樹,黑客技術
funnysystems
1
640
Other Decks in Technology
See All in Technology
aws-iot-platform-architecture-use-cases.pdf
ma2shita
0
400
白金鉱業Meetup Vol.25 アウトカムが二値のデータに対するCausal Impact
brainpadpr
0
260
`t*(42&t>>10)`だけで音楽が鳴る、Swiftで実装するBytebeat / iOSDC Japan 2026
yutailang0119
0
120
新機種発売前に見直そう!端末移行で再ログインが要るアプリ・要らないアプリは何が違うのか 〜シームレスに再開できる設計と実装〜
zozotech
PRO
0
220
AI時代の「技術的負債」の変質ー概念の終焉と再解釈、エージェントと共に向かう先
nwiizo
1
2.9k
サーバーレスをどこまで使う? WebRTC対戦ゲームで選んだVPSとの共存設計
kaidouji85
0
200
10Xに技術的負債をもたらした「2つの境界の歪み」その構造と解消への営み
10xinc
0
2.1k
データ_AIの事業の勝敗をわけるもの
nek0128
1
460
ソフトウェアDNAとクラウドエージェントのススメ
cloudace
0
120
Claude Codeを「使うほど育つ」AI秘書にするノウハウ
minorun365
PRO
32
29k
おい、エージェントを使って終わらせろ
nwiizo
2
760
その Lambda、8分で 管理者権限まで奪われます
k1nakayama
7
3.3k
Featured
See All Featured
Information Architects: The Missing Link in Design Systems
soysaucechin
1
1.2k
Dominate Local Search Results - an insider guide to GBP, reviews, and Local SEO
greggifford
PRO
0
330
We Have a Design System, Now What?
morganepeng
55
8.3k
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
280
Paper Plane (Part 1)
katiecoart
PRO
2
11k
What does AI have to do with Human Rights?
axbom
PRO
1
2.4k
Java REST API Framework Comparison - PWX 2021
mraible
34
9.7k
Principles of Awesome APIs and How to Build Them.
keavy
128
18k
End of SEO as We Know It (SMX Advanced Version)
ipullrank
3
4.4k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
23k
Designing for humans not robots
tammielis
254
26k
New Earth Scene 8
popppiees
4
2.6k
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 透明加解密