研究人員警告說(shuō)，由于16個(gè)不同的URL解析庫(kù)之間的不一致而導(dǎo)致的8個(gè)不同的安全漏洞，可能導(dǎo)致多種Web應(yīng)用程序中的拒絕服務(wù)(DoS)情況、信息泄漏和遠(yuǎn)程代碼執(zhí)行(RCE)。

這些漏洞是在為各種語(yǔ)言編寫的第三方Web包中發(fā)現(xiàn)的，并且像Log4Shell和其他軟件供應(yīng)鏈威脅一樣，可能已被導(dǎo)入到數(shù)百或數(shù)千個(gè)不同的Web應(yīng)用程序和項(xiàng)目中。受影響的是Flask(一個(gè)用Python編寫的微型Web框架)、Video.js(HTML5視頻播放器)、Belledonne(免費(fèi)的VoIP和IP視頻電話)、Nagios XI(網(wǎng)絡(luò)和服務(wù)器監(jiān)控)和Clearance(Ruby密碼驗(yàn)證)。

跳至問(wèn)題概要。

理解URL解析混亂

URL解析是將Web地址分解為其底層組件的過(guò)程，以便正確地將流量路由到不同的鏈接或不同的服務(wù)器?？捎糜诟鞣N編程語(yǔ)言的URL解析庫(kù)通常被導(dǎo)入到應(yīng)用程序中以實(shí)現(xiàn)此功能。

來(lái)自Claroty Team82研究部門和Synk的研究人員在周一的一份分析報(bào)告中寫道：“URL實(shí)際上是由五個(gè)不同的組件構(gòu)成的：方案、權(quán)限、路徑、查詢和片段。”“每個(gè)組件都扮演著不同的角色，它決定了請(qǐng)求的協(xié)議、持有資源的主機(jī)、應(yīng)該獲取的確切資源等等。”

根據(jù)綜合分析，由于每個(gè)庫(kù)進(jìn)行解析活動(dòng)的方式不同，安全漏洞會(huì)突然出現(xiàn)。

Team82和Synk研究了16個(gè)不同的URL解析庫(kù)，包括：urllib(Python)、urllib3(Python)、rfc3986(Python)、httptools(Python)、curl lib(cURL)、Wget、Chrome(Browser)、Uri(.NET)、URL(Java)、URI(Java)、parse_url(PHP)、url(NodeJS)、url-parse(NodeJS)、net/url(Go)、uri(Ruby)和URI(Perl)。

他們?cè)谶@些庫(kù)解析組件的方式中發(fā)現(xiàn)了五類不一致：

• Scheme混淆：涉及丟失或Scheme格式錯(cuò)誤的URL的混淆
• 斜杠混淆：包含不規(guī)則斜杠數(shù)量的URL混淆
• 反斜杠混淆：涉及包含反斜杠(\)的URL混淆
• URL編碼數(shù)據(jù)混淆：涉及包含URL編碼數(shù)據(jù)的URL混淆
• Scheme Mix-ups：涉及在沒(méi)有特定Scheme解析器的情況下解析屬于某個(gè)Scheme的URL混淆

根據(jù)報(bào)告，問(wèn)題在于，由于兩個(gè)主要的Web應(yīng)用程序開(kāi)發(fā)漏洞，這些不一致可能會(huì)產(chǎn)生易受攻擊的代碼塊：

• 使用多個(gè)解析器：無(wú)論是出于設(shè)計(jì)還是疏忽，開(kāi)發(fā)人員有時(shí)會(huì)在項(xiàng)目中使用多個(gè)URL解析庫(kù)。由于某些庫(kù)可能會(huì)以不同方式解析相同的URL，因此可能會(huì)在代碼中引入漏洞。
• 規(guī)范不兼容：不同的解析庫(kù)是根據(jù)不同的Web標(biāo)準(zhǔn)或URL規(guī)范編寫的，這在設(shè)計(jì)上造成了不一致，這也會(huì)導(dǎo)致漏洞，因?yàn)殚_(kāi)發(fā)人員可能不熟悉URL規(guī)范之間的差異及其含義(例如，應(yīng)該檢查或清理的內(nèi)容)。

作為真實(shí)攻擊場(chǎng)景的示例，斜線混淆可能導(dǎo)致服務(wù)器端請(qǐng)求偽造(SSRF)漏洞，這可用于實(shí)現(xiàn)RCE。研究人員解釋說(shuō)，不同的庫(kù)以不同的方式處理斜杠數(shù)量超過(guò)通常數(shù)量的URL(例如https:///www.google.com)：其中一些會(huì)忽略多余的斜杠，而另一些則將URL解釋為沒(méi)有主機(jī)。

對(duì)于前者(大多數(shù)現(xiàn)代瀏覽器和cURL都采用這種方法)，接受格式錯(cuò)誤、斜杠數(shù)量不正確的URL可能導(dǎo)致SSRF，研究人員解釋說(shuō)：“[不]忽略額外斜杠的庫(kù)......將解析這個(gè)[格式錯(cuò)誤]URL作為具有空權(quán)限(netloc)的URL，因此通過(guò)了對(duì)netloc(在本例中為空字符串)與google.com進(jìn)行比較的安全檢查。但是，由于cURL忽略了多余的斜杠，因此它將獲取URL從而繞過(guò)嘗試的驗(yàn)證，并導(dǎo)致SSRF漏洞。”

根據(jù)Claroty的說(shuō)法，URL混淆也是繞過(guò)Log4Shell補(bǔ)丁的原因，因?yàn)樵贘NDI查找過(guò)程中使用了兩種不同的URL解析器：一個(gè)解析器用于驗(yàn)證URL，另一個(gè)解析器用于獲取URL。

研究人員解釋說(shuō)：“根據(jù)每個(gè)解析器處理URL的片段部分(#)的不同，權(quán)限也會(huì)發(fā)生變化。”“為了驗(yàn)證URL的主機(jī)是否被允許，Java的URI被使用，它解析URL、提取主機(jī)，并檢查主機(jī)是否在允許主機(jī)的白名單中。事實(shí)上，如果我們使用Java的URI解析這個(gè)URL，我們會(huì)發(fā)現(xiàn)URL的主機(jī)號(hào)是127.0.0.1，它包含在白名單中。但是，在某些操作系統(tǒng)(主要是macOS)和特定配置上，當(dāng)JNDI查找進(jìn)程獲取此URL時(shí)，它不會(huì)嘗試從127.0.0.1獲取它，而是向127.0.0.1#.evilhost.com發(fā)出請(qǐng)求。這意味著雖然此惡意負(fù)載將繞過(guò)AllowedDaPost localhost驗(yàn)證(由URI解析器完成)，但它仍將嘗試從遠(yuǎn)程位置獲取類。”

URL解析安全漏洞

在他們的分析中，研究人員在第三方Web應(yīng)用程序中發(fā)現(xiàn)了八個(gè)由URL解析混淆導(dǎo)致的高危漏洞。他們說(shuō)，除了在不受支持的Flask版本中發(fā)現(xiàn)的那些之外，所有這些都已被修補(bǔ)，因此開(kāi)發(fā)人員應(yīng)該使用更新的版本更新他們的應(yīng)用程序：

1. Flask-security開(kāi)放重定向(Python，CVE-2021-23385)

2. Flask-security-too開(kāi)放重定向(Python，CVE-2021-32618)

3. Flask-User開(kāi)放重定向(Python，CVE-2021-23401)

4. Flask-unchained開(kāi)放重定向(Python，CVE-2021-23393)

5. Belledonne的SIP堆?？罩羔橀g接引用(DoS)(C，CVE-2021-33056)

6. Video.js跨站腳本(XSS)(JavaScript，CVE-2021-23414)

7. Nagios XI開(kāi)放重定向(PHP，CVE-2021-37352)

8. Clearance開(kāi)放重定向(Ruby，CVE-2021-23435)

開(kāi)放重定向漏洞很容易被利用，因?yàn)樗鼈兛梢赃M(jìn)行欺騙、網(wǎng)絡(luò)釣魚和中間人攻擊(MITM)。當(dāng)Web應(yīng)用程序接受用戶控制的輸入，該輸入指定用戶在特定操作后將被重定向到的URL時(shí)，就會(huì)發(fā)生這種情況。例如，當(dāng)用戶登錄網(wǎng)站時(shí)，他們可能會(huì)被重定向到惡意網(wǎng)站。

研究人員解釋說(shuō)，開(kāi)放式重定向攻擊通常通過(guò)驗(yàn)證來(lái)阻止：“Web服務(wù)器驗(yàn)證給定的URL，并且只允許屬于同一站點(diǎn)或受信任域列表的URL。”

URL庫(kù)混淆會(huì)干擾正確的驗(yàn)證，就像Clearance漏洞一樣。研究人員指出，Clearance(Ruby的Rails框架中一個(gè)廣泛應(yīng)用的第三方插件，可以實(shí)現(xiàn)簡(jiǎn)單安全的電子郵件和密碼身份驗(yàn)證)中的易受攻擊的函數(shù)是“return_to”。此函數(shù)在登錄/注銷過(guò)程之后調(diào)用，并且應(yīng)該將用戶安全地重定向到他們之前請(qǐng)求的頁(yè)面。但是，如果可以說(shuō)服目標(biāo)單擊具有以下語(yǔ)法的URL，則可將其破壞：http://www.victim.com/////evil.com。

研究人員解釋說(shuō)：“由于Rails忽略了URL中的多個(gè)斜杠，因此路徑段將完整到達(dá)Clearance(/////evil.com)并在其進(jìn)行解析。”“由于URI.parse刪除了兩個(gè)斜杠，因此生成的URL是///evil.com。每當(dāng)服務(wù)器將用戶重定向到此URL///evil.com時(shí)，瀏覽器都會(huì)將此網(wǎng)絡(luò)路徑相對(duì)引用轉(zhuǎn)換為指向evil.com域(主機(jī))的絕對(duì)http://evil.com URL。”

Belledonne VoIP崩潰

在Belledonne的Linphone中發(fā)現(xiàn)了一個(gè)更有趣的漏洞，這是一個(gè)免費(fèi)的IP語(yǔ)音軟電話、SIP客戶端和用于音頻和視頻通話的服務(wù)。根據(jù)分析，由于它處理SIP消息解析的方式，它遭受了scheme混淆。

研究人員解釋說(shuō)：“通過(guò)研究Belledone的URL解析功能，我們發(fā)現(xiàn)[a]段代碼解析了to/from SIP header中的SIP URL。”“Belledone將SIP URL解析為通用URL，并使用strcasecmp檢查方案是SIP還是SIP，以及給定的URL是否為SIP URL。”

然而，他們解釋說(shuō)，Belledonne generic_uri接受由不同URL組件創(chuàng)建的URL，而不需要存在特定組件。

他們總結(jié)說(shuō)：“這意味著僅包含路徑而沒(méi)有URL scheme的URL是有效的URL。”“通過(guò)此方法，我們提供了一個(gè)只包含一個(gè)斜杠(/)的URL，導(dǎo)致URL的方案結(jié)果為NULL。然后，當(dāng)Belledone使用strcasecmp時(shí)，它會(huì)比較一個(gè)NULL指針(因?yàn)闆](méi)有提供scheme)，從而導(dǎo)致NULL指針取消引用和應(yīng)用程序崩潰。”

該團(tuán)隊(duì)創(chuàng)建了一個(gè)概念驗(yàn)證漏洞利用代碼，該代碼能夠通過(guò)簡(jiǎn)單的惡意VoIP呼叫來(lái)使任何遠(yuǎn)程用戶的應(yīng)用程序崩潰，“要求受攻擊用戶的零交互”。

Team82和Synk研究人員指出，“可能會(huì)出現(xiàn)許多漏洞，從可能導(dǎo)致遠(yuǎn)程代碼執(zhí)行的SSRF漏洞到可能導(dǎo)致復(fù)雜網(wǎng)絡(luò)釣魚攻擊的開(kāi)放重定向漏洞。”他們說(shuō)，為了保護(hù)他們的應(yīng)用程序，開(kāi)發(fā)人員應(yīng)采用以下措施：

使用盡可能少的解析器。研究人員說(shuō)：“我們建議您完全避免使用URL解析器，而且一般情況下這是很容易實(shí)現(xiàn)。”

在microservice環(huán)境中傳輸解析的URL。他們指出：“如果microservice是在不同的框架或編程語(yǔ)言中實(shí)現(xiàn)，他們可能會(huì)使用不同的URL解析器。”“為了避免這個(gè)問(wèn)題，你可以簡(jiǎn)單地在前端microservice中解析URL，并以解析后的形式進(jìn)一步傳輸它。”

了解與應(yīng)用程序業(yè)務(wù)邏輯相關(guān)的解析器的差異。有時(shí)無(wú)法避免使用多個(gè)解析器，因此開(kāi)發(fā)人員需要注意解析行為的差異。

在解析之前始終規(guī)范化URL。始終確保應(yīng)用程序刪除多個(gè)正向/反向斜杠、空格和控制字符，以便在解析之前將URL恢復(fù)為正確的形式。

本文翻譯自：https://threatpost.com/url-parsing-bugs-dos-rce-spoofing/177493/如若轉(zhuǎn)載，請(qǐng)注明原文地址。