?

微軟最近修補(bǔ)了其 Azure API 管理服務(wù)中的三個(gè)漏洞，其中兩個(gè)漏洞啟用了服務(wù)器端請(qǐng)求偽造 (SSRF) 攻擊，這些攻擊可能允許黑客訪問內(nèi)部 Azure 資產(chǎn)。

概念驗(yàn)證漏洞用于突出開發(fā)人員在嘗試為自己的 API 和服務(wù)實(shí)施基于黑名單的限制時(shí)可能犯的常見錯(cuò)誤。

Web API 已成為現(xiàn)代應(yīng)用程序開發(fā)不可或缺的一部分，尤其是在云中。它們?cè)试S服務(wù)進(jìn)行通信和交換數(shù)據(jù)，非瀏覽器客戶端（例如移動(dòng)應(yīng)用程序和物聯(lián)網(wǎng)設(shè)備）可以代表用戶安全地訪問數(shù)據(jù)和執(zhí)行操作，并且公司可以抽象出舊的服務(wù)器后端并快速將它們與現(xiàn)代應(yīng)用程序和服務(wù)互連。

API 是標(biāo)準(zhǔn)化的并且易于交互，而不是依賴于不是為 Web 構(gòu)建的自定義和遺留協(xié)議。

近年來，隨著公司在生產(chǎn)中快速推出 API，針對(duì)它們的攻擊數(shù)量激增，因?yàn)楣粽咴絹碓揭庾R(shí)到不安全的 API 可能會(huì)提供進(jìn)入數(shù)據(jù)庫和內(nèi)部基礎(chǔ)設(shè)施的后門。

據(jù)全球內(nèi)容交付網(wǎng)絡(luò)提供商 Akamai 稱，與 2021 年相比，2022 年針對(duì) API 和 Web 應(yīng)用程序的攻擊數(shù)量增長(zhǎng)了 2.5 倍。SSRF 是過去兩年涌現(xiàn)的攻擊媒介之一。Microsoft Exchange 服務(wù)器中的 ProxyLogon、ProxyNotShell 和 OWASSRF 缺陷是被大量利用的著名示例。

在過去的兩年里，Akamai 發(fā)現(xiàn)攻擊嘗試和授權(quán)漏洞掃描流量都在穩(wěn)步增加，這些流量在 Microsoft Exchange 以外的軟件中尋找 SSRF 漏洞。

此外，我們每天都看到平均有 1400 萬次 SSRF 嘗試探測(cè)我們的 App & API Protector 客戶的 Web 應(yīng)用程序和 API，這表明該向量的流行程度越來越高。值得注意的是這種增長(zhǎng)以及 SSRF 開發(fā)對(duì)組織造成的潛在影響。

通過?Azure?API?管理代理的?SSRF

Microsoft 的 Azure API Management 是一項(xiàng)服務(wù)，它允許公司將托管在 Azure 上或其私有網(wǎng)絡(luò)內(nèi)的服務(wù)公開為 API 并對(duì)其進(jìn)行監(jiān)控。它是一項(xiàng)針對(duì) API 開發(fā)人員的服務(wù)，由 API 網(wǎng)關(guān)、管理平面和開發(fā)人員門戶組成。

在 SSRF 攻擊中，攻擊者必須找到一種方法來使用應(yīng)用程序的功能作為訪問內(nèi)部資源的代理，搭載服務(wù)器的特權(quán)位置和訪問內(nèi)部網(wǎng)絡(luò)。換句話說，如果應(yīng)用程序或 API 允許用戶提供 URL，然后將抓取該 URL 并返回響應(yīng)，則如果不采取額外的安全措施，則可能會(huì)發(fā)生 SSRF 攻擊。

Azure API 管理有這樣的功能。它允許用戶為預(yù)期通過他們部署的 API 交換的 JSON 或 XML 數(shù)據(jù)的結(jié)構(gòu)指定模式。然而，據(jù)安全公司 Ermetic 的研究人員稱，該服務(wù)還可以通過向用戶提供的 URL 發(fā)出請(qǐng)求來指示自動(dòng)確定架構(gòu)，此功能稱為“從 URL 導(dǎo)入”。

一旦你指定了模式的 URL，Azure API 管理 CORS 代理就會(huì)通過向指定的 URL 發(fā)送 HTTP 請(qǐng)求來檢索模式，研究人員在他們的報(bào)告中說。

跨源資源共享 (CORS) 是一種基于 HTTP 標(biāo)頭的機(jī)制，它允許 Web 服務(wù)器向?yàn)g覽器指示允許加載腳本等資源的其他源（服務(wù)器）。這種情況下的 CORS 代理會(huì)攔截請(qǐng)求并修改 CORS 標(biāo)頭，以確保允許 portal.azure.com 和其他服務(wù)器之間的跨域請(qǐng)求。

一旦發(fā)現(xiàn)此功能，Ermetic 研究人員便考慮提供 http://localhost 或 http://127.0.1.1（環(huán)回地址）作為遠(yuǎn)程 URL，以獲取模式以查看 CORS 代理是否會(huì)在內(nèi)部到達(dá)服務(wù)器本身，實(shí)現(xiàn)SSRF。這導(dǎo)致了 HTTP 403 錯(cuò)誤（禁止訪問），表明存在黑名單。

然后研究人員注冊(cè)了一個(gè)名為 localhost.me 的域，然后編輯其 DNS 記錄以指向 127.0.1.1。因此，當(dāng) CORS 代理嘗試訪問 http://localhost.me 時(shí)，它會(huì)首先解析 DNS 并嘗試訪問返回的 IP 地址，該地址繞過黑名單指向自身。這奏效了。CORS 代理返回的響應(yīng)是 HTTP 錯(cuò)誤 404（未找到頁面），這意味著服務(wù)器不再拒絕請(qǐng)求但沒有可提供的頁面。

研究人員還發(fā)現(xiàn)，他們可以在請(qǐng)求中添加自定義標(biāo)頭，這些標(biāo)頭將由 CORS 代理代理到目標(biāo)服務(wù)器，從而為更復(fù)雜的攻擊打開大門。然后他們嘗試在不同的端口號(hào)上訪問內(nèi)部服務(wù)器，而不是默認(rèn)的 80，以探測(cè)其他服務(wù)是否可能在自定義端口上運(yùn)行，并注意到當(dāng)他們嘗試包括“300”的端口號(hào)時(shí)，例如 300、3000 或 30000 ，他們?cè)俅问盏藉e(cuò)誤 403 Forbidden。

研究人員說：“我們了解到，如果專門針對(duì)這些端口存在正則表達(dá)式 [正則表達(dá)式]，那么一些重要的服務(wù)必須在這些端口上偵聽?！?/p>

正則表達(dá)式是可用于構(gòu)建黑名單的搜索和匹配規(guī)則。例如，該規(guī)則可以匹配請(qǐng)求中包含術(shù)語 localhost 和由 300 組成的端口號(hào)的任何 URL。研究人員推斷，如果存在正則表達(dá)式，它必須應(yīng)用于請(qǐng)求標(biāo)頭中名為“Ocp-Apim-Url”的值，該值定義了 CORS 代理到達(dá)的 URL。因此，他們使用指向他們控制的域的 URL，然后將代理重定向回 http://localhost:30001。

這有效并再次繞過黑名單，允許研究人員發(fā)現(xiàn)和訪問不同端口號(hào)上的內(nèi)部服務(wù)：30001 - 開發(fā)人員門戶的經(jīng)過身份驗(yàn)證的視圖，30004 - Azure 的管理 API，30005 - Azure 的 Kudu API 管理，30006 - 未發(fā)布的開發(fā)人員站點(diǎn)（未經(jīng)身份驗(yàn)證）。Kudu是為 Azure App Service 的一些管理功能提供支持的引擎，Azure App Service 是一種用于在 Azure 上托管和部署 Web 應(yīng)用程序的服務(wù)。

SSRF?漏洞揭示黑名單弱點(diǎn)作為防御

這個(gè)通過 CORS 代理的 SSRF 漏洞類似于 Orca Security 的研究人員在 11 月份在同一服務(wù)中發(fā)現(xiàn)的漏洞。Ermetic 在 12 月向 Microsoft 報(bào)告了它的發(fā)現(xiàn)，并認(rèn)為它可能是同一個(gè)漏洞。然而，他們的漏洞利用繞過了 Microsoft 在 Orca 報(bào)告原始缺陷后實(shí)施的修復(fù)，使其成為一個(gè)單獨(dú)的漏洞。這凸顯了依靠正則表達(dá)式等黑名單技術(shù)作為這些類型功能的防御機(jī)制的困難，因?yàn)榭偸怯卸喾N方法可以繞過它們。

Ermetic 研究人員并沒有就此停止他們的分析，并發(fā)現(xiàn)了第二個(gè) SSRF，這次是在 Azure API 管理托管代理中——一個(gè)不同的代理，用于在創(chuàng)建 API 時(shí)為 API 動(dòng)態(tài)配置后端服務(wù) URL。

“當(dāng)從用戶指定的前端發(fā)送請(qǐng)求時(shí)，請(qǐng)求將被發(fā)送到入站處理代理，然后再發(fā)送到指定的后端，”研究人員說。在此過程中，代理將根據(jù)用戶定義的入站和出站處理策略對(duì)請(qǐng)求進(jìn)行修改。

研究人員發(fā)現(xiàn)，用戶可以將 set-backend-service 策略配置為指向 http://localhost 而不是他們真正的 API 后端服務(wù) URL，從而欺騙代理將從 API 前端接收到的請(qǐng)求定向到它自己。

“由于我們可以控制前端和入站處理策略，我們可以使用我們選擇的 HTTP 動(dòng)詞/方法和自定義標(biāo)頭發(fā)送 SSRF，”他們說?！拔覀兡軌蛟L問內(nèi)部 HTTP 端口 80 以進(jìn)行 POC [概念驗(yàn)證]?！?/p>

對(duì)于這兩個(gè)漏洞，研究人員停止了調(diào)查，以避免對(duì)內(nèi)部服務(wù)和基礎(chǔ)設(shè)施造成損害，或者避免通過通常需要身份驗(yàn)證的 SSRF 探測(cè)訪問敏感數(shù)據(jù)的風(fēng)險(xiǎn)。

API?Management?Developer?Portal中的路徑遍歷漏洞?

最后，研究人員還能夠在導(dǎo)致路徑遍歷的 API 管理開發(fā)人員門戶中找到不受限制的文件上傳功能。這有可能影響最終用戶部署的任何自托管 API 管理開發(fā)人員門戶以及他們自己的基礎(chǔ)設(shè)施。

“我們發(fā)現(xiàn) Azure 不會(huì)驗(yàn)證上傳文件的文件類型和路徑，”研究人員說。“經(jīng)過身份驗(yàn)證的用戶可以遍歷上傳文件時(shí)指定的路徑，將惡意文件上傳到開發(fā)人員門戶服務(wù)器，并可能使用 DLL 劫持、iisnode 配置交換或任何其他相關(guān)攻擊媒介在其上執(zhí)行代碼?！?span toymoban-style="hidden">文章來源地址http://www.zghlxwxcb.cn/news/detail-641784.html

到了這里，關(guān)于Azure API 管理缺陷突出了 API 開發(fā)中的服務(wù)器端請(qǐng)求偽造風(fēng)險(xiǎn)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！