DevFest 2020 Taiwan - 駭客快樂礦場

89f41026db2c96853402524fca4a2ff8?s=47 Brent Chang
October 17, 2020

DevFest 2020 Taiwan - 駭客快樂礦場

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

89f41026db2c96853402524fca4a2ff8?s=128

Brent Chang

October 17, 2020
Tweet

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.