DevFest 2020 Taiwan - 駭客快樂礦場

本議程將藉由案例來了解疏於控管的雲端 Key 如何被駭客利用，並在雲端上進行惡意挖礦行為，且由您來支付雲端費用。
並會由此案例分享 GCP 主動通報機制、最佳實踐與 GCP IAM 權限控管、以及退費申請流程。

Transcript

1. GCP淪為駭客快樂礦場 源自洩漏的 Key -實際案例改編 Brent Chang Cloud Architect, CloudMile Inc.
2. The story begins...
3. “客戶收到警吿信！這是什麼意思？”
4. 挖礦警告信 • 不允許挖礦行為 • 通知專案管理者 • 停用該台 VM
5. “客戶沒在挖礦， 他們確認過那台 VM 沒在用， 已經將它刪除了”
6. “為什麼開機沒在用的 VM 會被拿來挖礦？”
7. 1. SSH 開啟密碼驗證 2. SSH 允許 root 登入 3. root 密碼過於簡單 4. root/sudoer Key 外流 5. 對外服務漏洞遭利用 6. 防火牆過於開放 VM 遭惡意挖礦常見原因
8. How could GCP protect a single VM?
9. 1. SSH 密碼驗證 關閉 2. SSH 不允許 root 登入 3. SSH 使用金鑰驗證 4. 作業系統與套件 自動更新 GCP 預設的 VM 設定
10. 1. OS Login 2FA 2. IAP SSH tunnel 3. OS Patch management 4. Web Security Scanner GCP 強化 VM 防護參考
11. 1. IAM 控管 user/sudoer 2. PAM module 3. 支援多因素驗證 >強化 SSH 帳號驗證 OS Login 2FA
12. OS Login 2FA
13. 限縮 SSH 防火牆 無外部 IP 也可用 >無需自行架設跳板機 IAP SSH tunnel
14. OS Patch Management Win/Linux皆支援 統一管理系統更新 排程設置 更新範圍設置 >減少安全漏洞
15. Web Security Scanner 排程 Web 掃描 XSS/明文密碼 git/svn暴露 過時 lib 等 >減少Web漏洞
16. The story continues...
17. 單台 VM 挖礦被停用
18. 單台 VM 挖礦被停用 ？？？？？？？
19. “客戶的專案出現超多台 VM 耶！”
20. 世界各地，能開的都開了一波
21. 一夕之間 VM 被建立在客戶的專案下 每台VM開超大規格(96vCPU, 360GB RAM) 並被啟用防刪除保護 ~500台
22. 1. 某服務帳戶大量建 VM 2. 服務帳戶有建立 key 3. 具備 專案編輯者 權限 調查該專案發現:
23. 1. 刪除該服務帳戶 key 2. 刪除所有 VM 減少損失 3. 收集資料聯絡 Google Billing Support 救火措施
24. “服務帳戶是什麼概念？”
25. 1. VM 或非人類使用的帳號 2. 可直接套用在 GCE/GAE/GKE..等 3. JSON key 包含服務帳戶 的帳號密碼 服務帳戶 Service Account
26. 單台 VM 挖礦被停用 ？？？？？？？
27. 單台 VM 挖礦被停用 被開了500台超大 VM ？？？？？？
28. 開發人員不小心將 專案編輯者的服務帳戶 key 上傳至公開的 repository 根本原因
29. 開發人員行為分析 遵循既有 流程產生 JSON Key JSON Key 誤上傳 至公開 repo 無人知曉 直到出事
30. 駭客行為分析 公開 repo 掃描 JSON Key 使用 JSON key 登入專案 程式建立 大量 VM
31. 單台 VM 挖礦被停用 被開了500台超大 VM 服務帳戶 JSON key 上傳 GitHub 公開 repo
32. “Blameless postmortems are a tenet of SRE culture.” -Site Reliability Engineering Chap.15
33. How could we prevent form this?
34. 不要將服務帳戶金鑰 JSON Key 上傳到 SCM
35. 1. 透過 CI 掃描是否有 Key 2. 最小權限管理 3. 設置預算警報 避免類似意外
36. 1. Google Source Repository 2. GitHub Secret Scan 3. GitLab Secret Detection 4. zricethezav/gitleaks 5. dxa4481/truffleHog 透過 CI 掃描是否有 Key
37. • 僅提供該角色需要的權限 • 有需要再加開 >將意外損失範圍降到最小 最小權限管理
38. 如果洩漏的 key 僅有 Project viewer 權限..? 最小權限管理
39. 駭客行為分析 - 僅有檢視權限 從公開 repo 掃描 JSON KEY 使用 JSON KEY 登入客 戶專案 用程式建立 大量 VM
40. IAM Recommandation 分析近 90 天存取紀錄 協助實現最小權限 最小權限管理
41. • 監控花費 • 提早得知費用異常 • 降低意外損失金額 設定預算警報
42. 1. SSH 不要開放 root 及密碼驗證 2. 防火牆盡量不要開 0.0.0.0/0 3. OS Login SSH 2FA 4. IAP SSH tunnel 5. 排程系統更新 Key takeaways
43. 1. 服務帳戶 JSON Key 不要上傳 SCM 2. 使用 CI 檢查是否有 JSON Key 3. 最小權限控管 4. 設置預算警報 Key takeaways (cont.)
44. GCP淪為駭客快樂礦場 源自洩漏的 Key -實際案例改編 Brent Chang Cloud Architect, CloudMile Inc.