透過西爾萊特
建構任何服務都必然包括持續的安全工作。 安全是一個持續的過程，包括不斷分析和改進產品安全、監控有關漏洞的新聞等等。 包括審計。 審計由內部和外部專家進行，他們可以從根本上幫助安全，因為他們沒有沉浸在專案中並且有開放的心態。
本文介紹了幫助 Mail.ru 雲端解決方案 (MCS) 團隊測試雲端服務的外部專家的最直接觀點以及他們的發現。 作為“外部力量”，MCS選擇了在資訊安全領域擁有深厚專業知識的Digital Security公司。 在本文中，我們將分析作為外部審計的一部分發現的一些有趣的漏洞 - 以便您在創建自己的雲端服務時避免相同的佣金。
Описаниепродукта
是一個在雲端中建構虛擬基礎架構的平台。 它包括 IaaS、PaaS 以及為開發人員提供的現成應用程式映像市場。 考慮到MCS架構，有必要在以下幾個方面檢查產品的安全性：
- 保護虛擬化環境的基礎架構：管理程序、路由、防火牆；
- 保護客戶的虛擬基礎架構：相互隔離，包括SDN中的網路、專用網路；
- OpenStack 及其開放元件；
- 我們自己設計的S3；
- IAM：具有角色模型的多租戶專案；
- 視覺（電腦視覺）：處理影像時的 API 和漏洞；
- Web 介面和經典的 Web 攻擊；
- PaaS組件的漏洞；
- 所有元件的API。
也許這就是進一步歷史所必需的一切。
進行了哪些工作以及為什麼需要進行這些工作？
安全審核旨在識別可能導致個人資料外洩、敏感資訊修改或服務可用性中斷的漏洞和設定錯誤。
在平均持續 1-2 個月的工作中，審核員重複潛在攻擊者的操作，並尋找所選服務的用戶端和伺服器部分中的漏洞。 在 MCS 雲端平台審核的背景下，確定了以下目標：
- 服務中的身份驗證分析。 該元件中的漏洞將有助於立即進入其他人的帳戶。
- 研究角色模型和不同帳戶之間的存取控制。 對於攻擊者來說，能夠存取其他人的虛擬機器是理想的目標。
- 客戶端漏洞。 XSS/CSRF/CRLF/等。 是否有可能透過惡意連結攻擊其他用戶？
- 伺服器端漏洞：RCE和各類別注入（SQL/XXE/SSRF等）。 伺服器漏洞通常更難發現，但它們會導致許多用戶同時受到傷害。
- 網路層面的用戶段隔離分析。 對於攻擊者來說，缺乏隔離會大大增加針對其他使用者的攻擊面。
- 業務邏輯分析。 難道可以欺騙商家，免費創建虛擬機器嗎？
在這個專案中，工作是按照「灰盒」模型進行的：審計人員以普通用戶的權限與服務進行交互，但擁有部分API的源代碼，並有機會與開發人員澄清細節。 這通常是最方便的，同時也是相當現實的工作模型：攻擊者仍然可以收集內部訊息，這只是時間問題。
發現漏洞
在審計員開始向隨機位置發送各種有效負載（用於執行攻擊的有效負載）之前，有必要了解事物的工作原理以及提供的功能。 這似乎是一個無用的練習，因為在大多數研究的地方都不存在漏洞。 但只有了解應用程式的結構及其運作邏輯，才有可能找到最複雜的攻擊向量。
找到看起來可疑或在某些方面與其他地方非常不同的地方很重要。 第一個危險漏洞就這樣被發現了。
多爾
IDOR（不安全直接物件參考）漏洞是業務邏輯中最常見的漏洞之一，它允許一個或另一個存取實際上不允許存取的物件。 IDOR 漏洞使得取得不同重要程度的使用者的資訊成為可能。
IDOR 選項之一是透過操縱系統物件（使用者、銀行帳戶、購物車中的物品）的存取識別碼來執行這些物件的操作。 這會導致最不可預測的後果。 例如，可以替換資金發送者的帳戶，透過它您可以從其他用戶那裡竊取資金。
就 MCS 而言，稽核人員剛剛發現了與非安全性識別碼相關的 IDOR 漏洞。 在使用者的個人帳戶中，UUID 識別碼用於存取任何對象，正如安全專家所說，這似乎非常不安全（即免受暴力攻擊）。 但對於某些實體，人們發現常規的可預測數字用於獲取有關應用程式使用者的信息。 我想你可以猜到，有可能將用戶ID更改XNUMX，再次發送請求，從而繞過ACL（訪問控制列表，進程和用戶的資料存取規則）獲取資訊。
伺服器端請求偽造 (SSRF)
開源產品的好處是它們有大量的論壇，其中有對出現的問題的詳細技術描述，如果幸運的話，還有解決方案的描述。 但這枚硬幣也有另一面：已知的漏洞也有詳細描述。 例如OpenStack論壇上有精彩的漏洞描述 и ，由於某種原因沒有人急於修復。
應用程式的一個常見功能是用戶能夠向伺服器發送鏈接，伺服器單擊該鏈接（例如，從指定來源下載圖像）。 如果安全工具不過濾連結本身或從伺服器傳回給使用者的回應，則此類功能很容易被攻擊者利用。
SSRF 漏洞可以大大促進攻擊的發展。 攻擊者可以獲得：
- 對受攻擊本地網路的存取受到限制，例如只能透過某些網段並使用某種協定；
- 如果可以從應用層降級到傳輸層，則可以完全存取本地網絡，從而實現應用層的滿載管理；
- 存取讀取伺服器上的本機檔案（如果支援 file:/// 方案）；
- 等等。
OpenStack 中的SSRF 漏洞早已為人所知，其本質上是「盲目」的：當您聯繫伺服器時，您沒有收到伺服器的回應，但您會收到不同類型的錯誤/延遲，具體取決於請求的結果。 基於此，您可以對內部網路的主機進行連接埠掃描，隨之而來的一切後果不容小覷。 例如，產品可能具有隻能從公司網路存取的後台 API。 透過文件（不要忘記內部人員），攻擊者可以使用 SSRF 存取內部方法。 例如，如果您能夠以某種方式獲得有用 URL 的大致列表，那麼使用 SSRF 您可以瀏覽它們並執行請求 - 相對而言，從一個帳戶轉移到另一個帳戶或更改限額。
這不是 OpenStack 第一次發現 SSRF 漏洞。 過去，可以從直接連結下載VM ISO映像，這也導致了類似的後果。 該功能現已從 OpenStack 中刪除。 顯然，社群認為這是解決這個問題最簡單、最可靠的方法。
而在 來自 HackerOne 服務 (h1) 的公開報告顯示，利用不再盲目的 SSRF 並能夠讀取實例元數據，可以實現對整個 Shopify 基礎設施的 Root 存取。
在MCS中，在兩個具有類似功能的地方發現了SSRF漏洞，但由於防火牆和其他保護措施，它們幾乎不可能被利用。 不管怎樣，MCS 團隊還是解決了這個問題，沒有等待社群。
XSS而不是載入shell
儘管撰寫了數百份研究報告，但年復一年的 XSS（跨站腳本）攻擊仍然是最嚴重的 網路漏洞（或 ？）。
文件上傳是任何安全研究人員最喜歡的地方。 事實證明，您通常可以載入任意腳本（asp/jsp/php）並執行作業系統命令，用滲透測試人員的術語來說就是「載入 shell」。 但此類漏洞的流行是雙向的：它們被記住，並且針對它們制定了補救措施，因此最近「加載 shell」的機率趨於零。
攻擊團隊（以 Digital Security 為代表）很幸運。 好的，在伺服器端的 MCS 中檢查了下載檔案的內容，只允許使用映像。 但SVG也是一張圖片。 SVG 影像有什麼危險？ 因為您可以將 JavaScript 片段嵌入其中！
事實證明，下載的檔案可供MCS服務的所有用戶使用，這意味著有可能攻擊其他雲端用戶，也就是管理員。
針對網路釣魚登入表單的 XSS 攻擊範例
XSS 攻擊利用範例：
- 如果載入的腳本可以立即存取資源 API，為什麼要嘗試竊取會話（尤其是現在 HTTP-Only cookie 無所不在，可以使用 js 腳本防止竊盜）？ 在這種情況下，有效負載可以使用 XHR 請求來變更伺服器配置，例如，新增攻擊者的公共 SSH 金鑰並獲得對伺服器的 SSH 存取權。
- 如果 CSP 策略（內容保護策略）禁止 JavaScript 注入，那麼攻擊者無需注入 JavaScript 也能成功。 使用純 HTML，為網站建立一個虛假的登入表單，並透過這種高級網路釣魚竊取管理員密碼：使用者的網路釣魚頁面最終位於相同的 URL，而使用者更難以偵測到它。
- 最後，攻擊者可以安排 — 設定大於 4 KB 的 Cookie。 用戶只需要打開一次鏈接，整個網站就變得無法訪問，直到用戶想到專門清理瀏覽器：在絕大多數情況下，Web 伺服器會拒絕接受這樣的客戶端。
讓我們來看看另一個偵測到的 XSS 範例，這次有一個更巧妙的利用。 MCS 服務可讓您將防火牆設定組合成群組。 組名是偵測到 XSS 的位置。 它的奇特之處在於，向量不會立即觸發，不是在查看規則清單時觸發，而是在刪除群組時觸發：
也就是說，場景如下：攻擊者建立了一條名稱中帶有「load」的防火牆規則，管理員在一段時間後注意到它並啟動了刪除過程。 這就是惡意 JS 的作用所在。
對於 MCS 開發人員來說，要防止上傳的 SVG 影像中的 XSS（如果不能省略），數位安全團隊建議：
- 將使用者上傳的檔案放置在與「cookie」無關的單獨網域中。 該腳本將在不同網域的上下文中執行，不會對 MCS 構成威脅。
- 在伺服器的 HTTP 回應中，傳送「Content-disposition：attachment」標頭。 然後文件將被瀏覽器下載並且不會被執行。
此外，現在開發人員可以透過多種方法來降低 XSS 攻擊的風險：
- 使用「HTTP Only」標誌，您可以使惡意 JavaScript 無法存取會話「Cookies」標頭；
- 將使攻擊者更難利用 XSS；
- 現代模板引擎（例如 Angular 或 React）會在將使用者資料輸出到使用者瀏覽器之前自動對其進行清理。
雙重認證漏洞
為了提高帳戶安全性，建議使用者啟用2FA（雙重認證）。 事實上，如果用戶的憑證已洩露，這是防止攻擊者獲得服務存取權限的有效方法。
但是使用第二個身份驗證因素是否總是能保證帳戶安全？ 2FA的實施有以下安全性問題：
- 暴力搜尋 OTP 碼（一次性代碼）。 儘管操作簡單，大公司也會遇到諸如缺乏OTP暴力破解防護等錯誤： , .
- 弱生成演算法，例如預測下一個程式碼的能力。
- 邏輯錯誤，例如能夠在您的手機上請求他人的 OTP，如下所示 來自 Shopify。
對於 MCS，2FA 是基於 Google Authenticator 實現的， 。 協定本身已經經過了時間的考驗，但應用端程式碼驗證的實作值得檢驗。
MCS 2FA 用於多個地方：
- 驗證使用者身份時。 有針對暴力破解的保護：使用者只能嘗試幾次輸入一次性密碼，然後輸入會被阻止一段時間。 這阻止了暴力選擇 OTP 的可能性。
- 當產生離線備份代碼以執行 2FA 時，以及停用它。 在這裡，沒有實施暴力保護，如果您有帳戶密碼和活動會話，則可以重新產生備份代碼或完全停用 2FA。
考慮到備份程式碼與 OTP 應用程式產生的字串值位於相同範圍內，因此在短時間內找到程式碼的機會要高得多。
使用「Burp: Intruder」工具選擇 OTP 來停用 2FA 的過程
導致
總體而言，MCS 作為一種產品似乎是安全的。 在審計過程中，滲透測試團隊無法存取客戶端虛擬機器及其數據，MCS 團隊很快就修正了發現的漏洞。
但這裡要注意的是，安全是一項持續的工作。 服務不是靜態的，而是不斷發展的。 且不可能開發出完全沒有漏洞的產品。 但你可以及時發現它們並最大限度地減少它們復發的機會。
目前MCS中提到的所有漏洞都已修復。 為了將新的數量保持在最低限度並縮短其生命週期，平台團隊繼續這樣做：
- 定期由外部公司進行審計；
- 支持和發展參與;
- 從事安全工作。 🙂
來源： www.habr.com