謝謝大家支持！粉專已經破 100 讚！
也謝謝大家給我們建議和想法，如果你還有什麼想知道的資安問題，歡迎大家持續告訴我們。
關於日後的文章發佈時間，我們目前預計是每月至少寫 3 篇文，也許在未來穩定之後會有固定的發文時間，請大家持續關注。
在使用雲端服務或架設服務的時候，除了考慮穩定性、可用性等，安全性也是不可忽視的。
今天我們會來用 AWS S3 「真實漏洞的例子」，跟大家介紹「配置錯誤」所造成的資訊洩漏問題，以及探討可能是「什麼樣的原因」導致這樣的錯誤發生。
AWS S3 常見用途與風險
S3（Simple Storage Service）是一個雲端儲存服務，你可以想像是一個大硬碟、Google Drive 之類的東西，讓我們儲存和管理大量資料。
在企業，S3 通常會有幾個用途：
- 架設靜態網站
- 儲存日誌紀錄、備份檔、映像檔等
- 用戶資料上傳
但各自都有一些潛在風險。
架設靜態網站
S3 儲存桶可以上傳 HTML 檔案，可以架設成一個靜態網站。
不過需要將 S3 權限設定為「公用讀取權限」讓大家讀取。而這樣架站常見的問題，是會「不小心」把不該上傳的也傳上去了。
像是如果上傳了 .git 資料夾，攻擊者就可以拿到你的原始碼。現在前端程式碼都用 Webpack 打包的年代，前端原始碼也變成一個不能隨意外流的重要資產。
儲存日誌、備份檔、映像檔
S3 最常見的用途，像是儲存主機日誌、或是我們部署容器的映像檔、系統軟體包等等，我們有時會藉由 S3 這樣的大硬碟來長期存放。
潛在風險在於權限，如果多給了不必要的「讀取」權限可能會導致資訊的洩漏。
且如果需要從其他雲端服務送日誌、映像檔過來，但貪圖一時方便而設定成「公開存取」，就更提高了洩漏的風險。
用戶資料上傳
想像像是 Trello 的平台，為了讓用戶可以自由上傳檔案，開放讓大家「公用寫入權限」。
舉個例子，像是用戶 Alice 可以把大頭貼上傳到 /Alice/6384e2b2184bcbf58eccf10ca7a6563c.jpg，而因為大頭貼檔名被改名成亂碼，用戶 Bob 因為不知道那串亂碼檔名，所以他無法讀取 Alice 的大頭貼。
在介紹這個功能的風險之前，我們先來看一下歷史事件。
歷史被駭事件
S3 真實被駭的例子，大多是因為疏忽權限配置所導致。
近幾年的歷史事件，可以在這個列表查看。之所以會洩漏資訊，在於兩個主要問題：
- 公開讀取
- 權限設定錯誤
公開讀取
前面提到 S3 最常被用來儲存日誌或備份。有間數據管理公司就被發現他們儲存在 S3 的資料可以被公開讀取，裡面存放了醫療紀錄，包含驗血結果、醫生姓名、患者姓名、地址、電話號碼等等。
還有一間珠寶商也用 S3 來備份檔案，而他們權限也是公開讀取的。他們甚至被發現備份檔裡面有明文密碼。
為什麼會這樣設定 S3 權限？
除了貪圖一時方便之外，其中一個原因是他們相信「隱匿的安全（Security by Obscurity）」。
讓我們先來了解 S3 的特色：
當你開一個叫做 thisistest 的 S3 儲存桶，並且在裡面放一個 a.log 的檔案，要存取這個檔案的方法，可以用 https://thisistest.s3.amazonaws.com/a.log 這樣的方式存取。
重點來了，有些人認為，只要攻擊者不知道我的儲存桶名字叫做 thisistest，就算我權限設為公開，攻擊者也無法偷到我儲存的東西。這種以為別人不知道所以就沒事的做法，就是「隱匿的安全」。
珠寶商的新聞中，發現問題的資安研究員有提到：
它（S3 儲存桶）有一個易於猜測的名稱，在這麼多掃描工具中，很容易用「品牌名字加上常見的字尾單字」來搜出這個儲存桶的名稱。
沒錯，Github 上面有很多專門暴力搜尋 S3 儲存桶名稱的工具。
並且，因為 S3 儲存桶的名稱不能重複（就像辦 Gmail 帳號不能重複一樣），所以企業習慣用 [企業名稱]-[功能] 來命名，像是 trello-avatars、company-bak 等等。
這樣的常見命名方式，如果剛好被攻擊者猜中或暴力搜出來，且 S3 權限是公開讀取，公司就可以上新聞了。
權限設定錯誤
另一個問題是權限設定。S3 在以前有一個群組（Group）設定，他可以設定「通過驗證的 AWS 使用者（Any Authenticated AWS User）」的權限。
有些人會「認為」這個群組是給為「公司內擁有 AWS 帳號的人」的設定，所以自然就打開了存取權限。
但實際在 AWS 官方文件中，他們寫道：
警告
當您將存取授予通過身份驗證的使用者群組時，世界上任何通過 AWS 身份驗證的使用者都可以存取您的資源。
而真實案例，可以看白帽駭客找到的 賞金 1000 美金的 Shopify 漏洞。
所幸 AWS 也發現了這些問題，他們不斷在 S3 上加強權限管理，並且在 UI 上不斷強調「公開存取權限」的警告，盡可能避免這樣問題的發生。
用戶資料上傳
了解 S3 權限常見問題之後，我們回來看「用戶資料上傳」這個功能的風險。
這個功能可能有兩個問題：
- 攻擊者猜到檔名
- 錯誤配置「列出物件」的權限
如果你有發現，其實前面提到的 /Alice/6384e2b2184bcbf58eccf10ca7a6563c.jpg 裡面的 6384e2b2184bcbf58eccf10ca7a6563c，是 alice md5 之後的結果。
企業如果沒有把檔名處理好，容易會被猜到，這樣的保護就跟「隱匿的安全」一樣，是不夠安全的。
第二個是「列出物件的權限」，如果你做了這樣的事情：
就可以讓攻擊者不用猜別人的檔名，可以光明正大地瀏覽別人上傳的資料有哪些。
觸發問題的原因？
上述的資安問題看似只跟 S3 有關，但觸發問題的原因可能有幾種：
- 為了方便而忽略安全性
- 隱匿的安全（Security by Obscurity）
- 權限配置錯誤
- 不小心、臨時、緊急修改
- 開發環境變產品環境
貪圖方便而忽略了安全性是最危險的，這樣的情況就算 S3 權限做得再好，或是今後用別的服務，還是會發生資安問題。
而「隱匿的安全」通常建立在「攻擊者猜不到」的情況。實際上，攻擊者也不斷在揣測企業的想法，甚至用「AI」來學習攻擊。隱匿的安全如果真的夠難被猜到，在一些方便性考量上的情境是適合的，但就要面對被猜出來的機率和風險。
權限配置錯誤，不管是在 S3 或是任何服務都是有可能發生的。可能是一開始給太多權限、覆水難收，或是官方文件寫一大串很難看懂這權限在幹嘛，導致問題的發生。
然而常見的也有「不小心、臨時和緊急」的修改，不小心改到、臨時的測試、客戶緊急需要，在改完權限之後沒有改回來，就因此留下了一個坑。
最後是開發習慣和開發時程的問題，一開始的開發環境，老闆突然說明天要上線，你會怎麼做？可能就整組開發環境直接上了。但開發環境的權限、除錯模式通常都會打開，變成駭客的溫床。
歸納原因，其實在於我們對「防禦」的想法。
防禦的想法，來自對危險的認知，和不放棄的精神
資安防禦離不開「風險」，我們對危險評估的結果，會決定我們要做什麼樣的防禦。
每當我們接觸一個新環境、新服務的時候，如果隨時問自己：「我這樣配置，攻擊者會怎麼打？」主動揣摩攻擊，自然就會慢慢培養對危險的認知，注意到權限的配置、和修改造成的問題。
並且要相信有好的、讓產品更安全的解法，不要被一時方便和怠惰而打壞了一路上為資安的努力。
雖然開發時真的有太多狀況和問題，像是隔天要上線，但我們不要放棄在「有限資源」和「資安風險」之間嘗試找到一個平衡點，讓產品順利發展，並且持續保有安全性。
這篇是藉由 S3 的一些歷史回顧，來提醒今後不管在配置服務、或自己架設服務時，你可能也會面臨到類似 S3 這樣的配置問題。這時如果能停下來思考一下資安，也許這瞬間，可能就是決定公司會不會上新聞的關鍵。