Amazon和Eucalyptus中的安全漏洞

德國研究員 Juraj Somorovsky、Mario Heiderich、Meiko Jensen、Jörg Schwenk、Nils Gruschka 和 Luigi Lo Iacono 在合著的一篇名為《你的云真的由你掌控嗎——云管理界面的安全分析》的文章中討論了 Amazon AWS 和 Eucalyptus 存在的安全漏洞，攻擊者可以利用這些漏洞來完全控制受害者賬戶以及與之相關的存儲數據。文章重點討論了一種通過 SOAP 接口進行的 XML 簽名攻擊，并且揭露了額外兩種跨站腳本（XSS）技術，攻擊者可以利用這些技術從 web 管理界面侵入用戶賬戶。Amazon 和 Eucalyptus 在這些漏洞被利用前對其進行了修復。

在傳統的 XML 簽名攻擊中：

原始 SOAP 消息體元素會被轉移到 SOAP 安全消息頭的一個新添加的偽造包裝器元素中。請注意，利用消息簽名中的標記符屬性 Id=“body”，簽名還是指向此前被移動的消息體。因為消息體元素本身沒有被修改（只是簡單轉移了位置），所以從密碼學角度簽名任然有效。其后，為了使 SOAP 消息的 XML 模式兼容，攻擊者會更改本來指向原始 SOAP 消息體的標識號（比如，他修改為 Id=“attack”）。這樣就可以開始向空 SOAP 消息體里填充偽造的消息內容了，由于簽名驗證無誤，那攻擊者定義的任何一個操作都可以被有效地執行了。

傳統的 XML 簽名攻擊至少可以有兩種方式來對付 AWS 和 Eucalyptus，其中一種對時間不敏感。這種攻擊尤其在對時間戳不敏感的情況下幾乎不需要滿足什么前提條件，所有攻擊者唯一要做的就是提供一個有效、經過簽名的 SOAP 請求消息，而這可以通過 AWS 開發者在 AWS 支持論壇發布幫助請求直接獲取。文章的幾位作者抱怨造成這種安全漏洞的原因是 SOAP 處理框架中對任務模塊的拆分。由于任務模塊化，相同的 XML 消息將以不同的方式在不同的模塊中訪問，消息的完整性從沒有得到過驗證。作者們建議：

最好的對策辦法就是增強簽名驗證功能和業務邏輯之間的接口。使用這種方法，簽名驗證可以緊跟在返回的布爾值后再加一些已簽名數據的位置信息。業務邏輯再決定將要處理的數據是否已被簽名。

作者們還揭露了兩種腳本注入攻擊，其中一種的目標直指 AWS 管理控制臺用戶，而另一種則利用了 amazon 商城界面和 AWS 之間的共享證書。前者利用了證書下載鏈接中的 GET 參數——用戶用此鏈接下載 Amazon 簽署的X.509證書。盡管如此，這種攻擊的前提條件要求相當高，不僅包括使用 UTF-7對注入的腳本進行編碼，使其能夠避開服務器邏輯從而對標準的 HTML 字符編碼，還需要特定 IE 版本中某些特性的支持。第二種腳本注入攻擊使用一種持續的跨站腳本攻擊，利用了 AWS 為首次登錄到 Amazones hop 界面的用戶創建的登陸會話。這種攻擊簡單而有效：

攻擊者必須要在某個商城物品、用戶自創標簽或其他實體上創建一個討論主題。一旦主題創建成功，討論主題的標題就會立刻顯示而不會做任何特定編碼，這樣就給注入惡意 HTML 代碼留出了空間。這使得我們能夠加入一些腳本標簽或其他活動標記來迫使用戶代理在 www.amazon.com 域上執行 JavaScript。

文章研究人員與 Eucalyptus 和 Amazon 的安全工作人員一起合作，在文章發表前就修復了這些漏洞。但就 Eucalyptus 或任何其他私有云部署的情況來看，任然存在不利因素：

修復該安全漏洞存在的難題在于：Eucalyptus 部署在數不勝數的私有化托管服務器上。因此，每個 Eucalyptus 管理員都必須手動更新其服務器版本。假設存在大量的設施（Eucalyptus 聲稱其客戶超過25000個），那我們真的懷疑能否在短期內修復每臺服務器上的攻擊。理論上這是依賴私有云基礎設施最大的不利因素之一。

文章最后的結論指出了這種安全隱患將造成的影響規模，它可能出現在任何已有的云服務上，因此至少文章中描述的“黑盒”方法學是很有必要的：

這表明了這類系統本身的復雜性為產生潛在的安全漏洞創建了一個大溫床。由此看來，在不遠的將來云控制界面很可能成為某些有組織犯罪團伙最感興趣的攻擊目標之一。我們發現的所有安全漏洞，其最重要的威脅不在于會對單個服務器或者公司造成影響，而在于可以立刻影響到整個相關的云用戶。另外，針對基于 Web 的云控制界面的跨站腳本攻擊會對整個云安全產生嚴重的影響。

查看英文原文：Security Vulnerabilities in Amazon and Eucalyptus