謝謝大家支持!粉專已經破 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-avatarscompany-bak 等等。

這樣的常見命名方式,如果剛好被攻擊者猜中或暴力搜出來,且 S3 權限是公開讀取,公司就可以上新聞了。

權限設定錯誤

另一個問題是權限設定。S3 在以前有一個群組(Group)設定,他可以設定「通過驗證的 AWS 使用者(Any Authenticated AWS User)」的權限。

有些人會「認為」這個群組是給為「公司內擁有 AWS 帳號的人」的設定,所以自然就打開了存取權限。

但實際在 AWS 官方文件中,他們寫道:

警告

當您將存取授予通過身份驗證的使用者群組時,世界上任何通過 AWS 身份驗證的使用者都可以存取您的資源。

而真實案例,可以看白帽駭客找到的 賞金 1000 美金的 Shopify 漏洞

所幸 AWS 也發現了這些問題,他們不斷在 S3 上加強權限管理,並且在 UI 上不斷強調「公開存取權限」的警告,盡可能避免這樣問題的發生。

s3-alert

用戶資料上傳

了解 S3 權限常見問題之後,我們回來看「用戶資料上傳」這個功能的風險。

這個功能可能有兩個問題:

  • 攻擊者猜到檔名
  • 錯誤配置「列出物件」的權限

如果你有發現,其實前面提到的 /Alice/6384e2b2184bcbf58eccf10ca7a6563c.jpg 裡面的 6384e2b2184bcbf58eccf10ca7a6563c,是 alice md5 之後的結果。

企業如果沒有把檔名處理好,容易會被猜到,這樣的保護就跟「隱匿的安全」一樣,是不夠安全的。

第二個是「列出物件的權限」,如果你做了這樣的事情:

s3-list

就可以讓攻擊者不用猜別人的檔名,可以光明正大地瀏覽別人上傳的資料有哪些。

觸發問題的原因?

上述的資安問題看似只跟 S3 有關,但觸發問題的原因可能有幾種:

  • 為了方便而忽略安全性
  • 隱匿的安全(Security by Obscurity)
  • 權限配置錯誤
  • 不小心、臨時、緊急修改
  • 開發環境變產品環境

貪圖方便而忽略了安全性是最危險的,這樣的情況就算 S3 權限做得再好,或是今後用別的服務,還是會發生資安問題。

而「隱匿的安全」通常建立在「攻擊者猜不到」的情況。實際上,攻擊者也不斷在揣測企業的想法,甚至用「AI」來學習攻擊。隱匿的安全如果真的夠難被猜到,在一些方便性考量上的情境是適合的,但就要面對被猜出來的機率和風險。

權限配置錯誤,不管是在 S3 或是任何服務都是有可能發生的。可能是一開始給太多權限、覆水難收,或是官方文件寫一大串很難看懂這權限在幹嘛,導致問題的發生。

然而常見的也有「不小心、臨時和緊急」的修改,不小心改到、臨時的測試、客戶緊急需要,在改完權限之後沒有改回來,就因此留下了一個坑。

最後是開發習慣和開發時程的問題,一開始的開發環境,老闆突然說明天要上線,你會怎麼做?可能就整組開發環境直接上了。但開發環境的權限、除錯模式通常都會打開,變成駭客的溫床。

歸納原因,其實在於我們對「防禦」的想法。

防禦的想法,來自對危險的認知,和不放棄的精神

資安防禦離不開「風險」,我們對危險評估的結果,會決定我們要做什麼樣的防禦。

每當我們接觸一個新環境、新服務的時候,如果隨時問自己:「我這樣配置,攻擊者會怎麼打?」主動揣摩攻擊,自然就會慢慢培養對危險的認知,注意到權限的配置、和修改造成的問題。

並且要相信有好的、讓產品更安全的解法,不要被一時方便和怠惰而打壞了一路上為資安的努力。

雖然開發時真的有太多狀況和問題,像是隔天要上線,但我們不要放棄在「有限資源」和「資安風險」之間嘗試找到一個平衡點,讓產品順利發展,並且持續保有安全性。

這篇是藉由 S3 的一些歷史回顧,來提醒今後不管在配置服務、或自己架設服務時,你可能也會面臨到類似 S3 這樣的配置問題。這時如果能停下來思考一下資安,也許這瞬間,可能就是決定公司會不會上新聞的關鍵。