2021 CYBERSEC 資安大會 — DevSecOps/ Container 筆記整理

DevOps、Docker 容器安全

前言

我本身只了解一些像 XSS、SQL Injection 等常見的 Web 應用層面的資安，便想透過這個機會補一些知識。

參加了 5/6 週四的資安大會，這天的議程主要以 DevSecOps 、容器安全為主。剛好這些是我開發上有接觸過的，除了比較容易理解，未來也較有機會派上用場。

選了幾場議程 (點擊可以跳到該段)：

1. 拯救你的雲端安全！ (DevSecOps，議程)
2. IaC Security (DevSecOps，議程)
3. 容器壞壞 (Container，議程)
4. 雲端資料掉光光 ~ GCP 事件調查真實案例~ (DevSecOps，議程)

會後雖然有簡報可以看，不過只看上面少少幾個字一定看不懂。想說趁記憶猶新，把過程中寫下的筆記整理起來。若有朋友剛好沒參加到也可以稍微參考一下，自己以後有需要也可以回來看看。

拯救你的雲端安全！

講者林劭謙是 Mai Coin 的網路安全工程師。介紹的內容主要給大家一些大方向去思考。簡單分成幾點：

使用雲端的優缺點、使用上容易遇到的狀況

使用雲端服務好處很多：速度快、不需要自己買機器蓋機房、方便檢視資源、具有高可用度（例如 Multi-AZ）等等優點。

雖然好用，但也相對帶來一些缺點，例如：硬體都是服務供應商包好的，我們除了服務以外不能看到硬體相關的狀態。

聽到這點就想到我自己之前使用 AWS 的 Elasticsearch，遇到突然叢集停擺直接掛掉，導致我們服務也葛屁了。後來問 Support 弄半天，才發現是他們那個叢集有發生硬體故障，我們也只能暫時把服務 degrade 等他們修…

也有提到因為雲端各種大大小小 config 設定實在是太多了，常常第一次使用服務都會為了先打通、想趕快上線新產品，而遺漏了一些資安的顧慮，甚至不小心關了一些重要的安全設定，發生如講者說的：

「YAY！服務打通了！……結果駭客也通了」

聽到這句我真的是嘴角失守。

像是把資料放在 AWS S3 上面，當管理者不完全了解設定組態，無法如預期存取資源，為了急著產品上線或各種原因把它開成了 public，這樣就成為一個漏洞。

此外公司有一定規模時，權限控管也真的是一個課題，各種 key 、 credentials 權限大小不一，不小心掉了一個都有可能成為可怕的漏洞，嚴重會導致你全家都被加密、資料被偷走。

針對常見漏洞的預防建議

可以花點時間去完整了解自家架構，去定出一套自己的資安策略。之後不管是要建立什麼新服務，都一律要遵守。更重要的是要定期去 Review 架構，思考哪邊可能還有遺漏的地方。

各種 Key 的權限必須遵守 principle of least privilege (POLP)，就是說盡量一個 key 就對應一個權限，不要一個 key 什麼都可以存取，不然你想想看它被駭客拿走會發生什麼事。若是使用者的登入機制，若能做 2FA （二階段驗證）就做。

個別服務，要留意各種 Default 設定，有些可能是會有疑慮的。這一點我自己大概覺得，像是開新的 EC2 我是否有必要有 public IP ?

若要偵測漏洞，可以從哪些地方下手

1. 檢視各種 Key / Credentials 權限
2. 檢視各服務的 Log
3. 流量鏡像 (Mirror Trafficking)：AWS VPC 提供的方法，可以複製一份 VPC 網路流量出來，用來分析流量狀況。

一些工具

最後因為時間的關係，迅速地提了一些檢測可使用的工具：

• Google Cloud Forensics Utils/libcloudforensics: 用來做鑑識資料分析 (FDA, Forensic Data Analytics)的工具，例如可以將 AWS 上的某個 Volume 複製一份出來做資料分析使用。
• AWS Guard Duty: 可以透過 UI 上按一按，把各種資源的資料搜集起來，例如 VPC 流量 Log、CloudTrail 日誌、DNS 日誌等等，並協助偵測惡意活動跟一些未授權的行為。
• Tines: 一個將 Workflow 自動化的平台，因為講很快只記得可以用它把各種要檢測的工作串成 Workflow，也可搭配一些通知服務（例如 Twilio ），當有異常時來發送通知到手機。

IaC Security

講者 Chang Yu Wu 是樂屋國際IT 部 MIS 資深經理。

首先帶大家速速了解 IaC (Infrastructure as Code) 與其優缺點。

針對 IaC 的介紹

IaC 旨在使用程式碼/文件來建立出整套雲端服務 — 真的會節省很多人力成本，甚至可以將這份程式碼加入版本控管、融合持續部署/交付流程。

像是 AWS CloudFormation、Azure Resource Manager、Google Cloud Deployment Manager、Terraform 等等都提供這樣的服務。

只要有對應的程式碼 / 文件，就能快速建出整個系統架構。圖片引用自這邊

IaC 具有

• 恢復性：當服務出現非預期崩潰，用這份程式碼可以重建一模一樣的環境
• 實行快：因為程式碼包含所有組態，直接省略了所有設定組態步驟
• 可視性：看程式碼就知道你家有什麼東西

自動化畏懼循環

講者也提到說，面對導入自動化的過程，也有機會遇到「自動化畏懼循環」。

來源：https://www.thoughtworks.com/insights/blog/infrastructure-code-automation-fear-spiral

有找到詳細的文章，有興趣可以上面圖片的連結。

主要是說因為我們不夠信任自動化，導致即使是自動化，還是經常需要人為介入。該文章作者建議是可以在過程中增加各種測試、回報系統、安全監控，來增加自動化的信心。

雲端上該檢視的項目？

• 使用者權限管理：注意權限很大的帳號，整體也是同上一場的做法。
• 架構評估：架構上要注意有哪些弱點？例如使用 Master-Node 架構，就要特別注意 Master 的安全性，如果這顆被駭，其他 Node 也沒救了。
• 憑證管理狀況：各 Key 跟密碼管理 ，應遵守 POLP 原則 (上面一場也有提到)。
• 使用的資源本身是否乾淨：你部署用的 Image 是否內含惡意程式碼，或是第三方套件是否安全等等。
• 是否發生「組態飄移」：如果系統自動化部署以後，因為各種原因需要手動去更改各種組態，會導致上面那張圖說的「我的伺服器們不一致」，除了會讓你陷入畏懼循環，也增加管理困難度，降低自動化系統完整性。
• 資源是否清楚標示：這邊我自己舉一個比較極端的例子，假設你進了一家公司，看到前人在雲端上有一台 server_a 也沒有標記，你除了不知道在幹嘛以外，更無法得知它是否會成為漏洞。

在 DevOps 流程中安排測試

講者舉了一個簡單的例子：在 push commit 時，讓專案透過 Github Hook 加入一個安全測試流程，當通過以後才可以進行 Merge。

安全測試可以測哪些？

講者給了我們四個方向：

• 程式碼面：靜態程式碼分析跟漏洞掃描
• IaC 架構程式碼面：遺漏的組態設定、過程中使用到的資源漏洞檢測
• 應用程式面：就是像 SQL Injection、XSS、錯誤的 API 呼叫等問題檢測。
• 網路面：防火牆設定檢測、存取控制清單(ACL，Access Control List) 設定檢測。

安全測試應該被自動化！

最後講者強調，當測試安排與監控好了以後，重要的是也將這部分也自動化。若安全測試還需要手動執行，將會需要花費很多人力資源。

容器壞壞

講者 Jie 是一位 IBM 的資安工程師。

最主要由 「Docker 容器跟一般 VM 不同之處」進入議程，指出因容器跟當下 host 的作業系統共用核心，導致駭客容易從容器內去取得 host 的 root 的權限，或是因為不良的設定導致容器具有很大的權限，甚至可以在該容器操作其他容器。

其中的攻擊範例有：

當用 root 身份 / 帶 — privilege 選項啟動容器

這樣的條件下，駭客可以從該容器內部就輕易地存取到 host 資源。

當 docker.sock 被共享到容器 volume中

可能有人為了使用上的方便/各種原因將 docker.sock 給 Mount 進去容器裡面。而因為 docker.sock 是 docker API 主要聆聽的入口，透過它就可以下一些 docker ps、docker run 等指令。

這個跑進去容器裡，如果這時駭客可以進到這個容器中，他就可以亂開自己的容器，甚至以 privilege 權限執行！

當暴露了 Docker API

如果為了架構上的方便，將 Docker 的 API 開放在網路上，駭客如果找到，他就可以用簡單的 API 到你家開他自己的容器，甚至具有 privilege 權限。

Jie 也分享了 Shodan 搜尋引擎，可以透過它找到網路上相連的各種裝置。

他找到了一個被攻擊的 Docker API ，裡面的 script 不僅在網路上繼續搜尋更多開放的 Docker API，更會對每個受害者的機器啟動一個帶有挖礦 script 的容器。講者自己看了都開玩笑道「這個根本財富自由了」。

他也提了很多容器潛在的漏洞，不過因為時間關係就速速講過。

本圖攝自當時議程簡報過程。

這場主要都是實作範例，這邊小記就簡單分享概要。Demo 的細節建議可以直接到講者的 Youtube 看影片。

雲端資料掉光光 ~ GCP 事件調查真實案例~

講者王立弘是法泥系統的研發部雲端安全顧問。

分享了他的團隊如何解決客戶被駭客入侵， GCP 上的資料被偷走的案例解法及心路歷程。

主要的重點是提到 GCP 上的 Cloud SQL Proxy 是用明文的「服務帳號金鑰」方式來進行驗證，是個超大的漏洞。

可怕的是，在 GCP 上服務帳號的權限很大。駭客取得了這個服務帳號金鑰，開了一個服務帳號來亂搞，無痛把資料輸出之後偷走。

解決的契機也是因為發現活動記錄裡，找到一個沒人在用的神奇服務帳號，多次嘗試了 Cloud SQL Proxy 的存取。更重要的是，客戶的金鑰好幾年都沒有換！只能說天時地利人和 (喂。

最後不僅換了金鑰，講者的團隊更自製了一個新的 Cloud SQL Proxy 「Hardening」，強制使用加密過的金鑰來驗證，這樣一來就安全多了。

總結

大到雲端架構、小到開發者使用的語言，每一個環節都可能成為資安漏洞，要做好管理真的是一大工程。

身為一名 Web 開發人員，我們除了先從 Web 應用層面的安全做好（可以參考這篇，寫的很詳細！），到雲端上先從 Key/ Credentials 管理、檢查是否有 public access 的資源來下手，即使沒法馬上做大量更改，也應該從現在開始要制定自己的規範，像是若要建立新的 Key，一定要比照 POLP 原則等等。

感謝各位讀到這邊。以上是一整天聽下來的筆記整理，希望各位看完有一些收穫！