URL解析错误导致DoS、RCE等 - 嘶吼 RoarTalk – 回归最本质的信息安全,互联网安全新媒体,4hou.com

URL解析错误导致DoS、RCE等

我们会有自己的猫 事件 2022-01-13 11:45:00
收藏

导语:由16个流行的第三方URL解析库之间的不一致引起的安全漏洞可能会影响大量的Web应用程序。

研究人员警告说,由于16个不同的URL解析库之间的不一致而导致的8个不同的安全漏洞,可能导致多种Web应用程序中的拒绝服务(DoS)情况、信息泄漏和远程代码执行(RCE)。

这些漏洞是在为各种语言编写的第三方Web包中发现的,并且像Log4Shell和其他软件供应链威胁一样,可能已被导入到数百或数千个不同的Web应用程序和项目中。受影响的是Flask(一个用Python编写的微型Web框架)、Video.js(HTML5视频播放器)、Belledonne(免费的VoIP和IP视频电话)、Nagios XI(网络和服务器监控)和Clearance(Ruby密码验证)。

跳至问题概要。

理解URL解析混乱

URL解析是将Web地址分解为其底层组件的过程,以便正确地将流量路由到不同的链接或不同的服务器。可用于各种编程语言的URL解析库通常被导入到应用程序中以实现此功能。

来自Claroty Team82研究部门和Synk的研究人员在周一的一份分析报告中写道:“URL实际上是由五个不同的组件构成的:方案、权限、路径、查询和片段。”“每个组件都扮演着不同的角色,它决定了请求的协议、持有资源的主机、应该获取的确切资源等等。”

根据综合分析,由于每个库进行解析活动的方式不同,安全漏洞会突然出现。

Team82和Synk研究了16个不同的URL解析库,包括: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)。

他们在这些库解析组件的方式中发现了五类不一致:

· Scheme混淆:涉及丢失或Scheme格式错误的URL的混淆

· 斜杠混淆:包含不规则斜杠数量的URL混淆

· 反斜杠混淆:涉及包含反斜杠(\)的URL混淆

· URL编码数据混淆:涉及包含URL编码数据的URL混淆

· Scheme Mix-ups:涉及在没有特定Scheme解析器的情况下解析属于某个Scheme的URL混淆

根据报告,问题在于,由于两个主要的Web应用程序开发漏洞,这些不一致可能会产生易受攻击的代码块:

· 使用多个解析器:无论是出于设计还是疏忽,开发人员有时会在项目中使用多个URL解析库。由于某些库可能会以不同方式解析相同的URL,因此可能会在代码中引入漏洞。

· 规范不兼容:不同的解析库是根据不同的Web标准或URL规范编写的,这在设计上造成了不一致,这也会导致漏洞,因为开发人员可能不熟悉URL规范之间的差异及其含义(例如,应该检查或清理的内容)。

作为真实攻击场景的示例,斜线混淆可能导致服务器端请求伪造(SSRF)漏洞,这可用于实现RCE。研究人员解释说,不同的库以不同的方式处理斜杠数量超过通常数量的URL(例如https:///www.google.com):其中一些会忽略多余的斜杠,而另一些则将URL解释为没有主机。

对于前者(大多数现代浏览器和cURL都采用这种方法),接受格式错误、斜杠数量不正确的URL可能导致SSRF,研究人员解释说:“[不]忽略额外斜杠的库......将解析这个[格式错误]URL作为具有空权限(netloc)的URL,因此通过了对netloc(在本例中为空字符串)与google.com进行比较的安全检查。但是,由于cURL忽略了多余的斜杠,因此它将获取URL从而绕过尝试的验证,并导致SSRF漏洞。”

根据Claroty的说法,URL混淆也是绕过Log4Shell补丁的原因,因为在JNDI查找过程中使用了两种不同的URL解析器:一个解析器用于验证URL,另一个解析器用于获取URL。

研究人员解释说:“根据每个解析器处理URL的片段部分(#)的不同,权限也会发生变化。”“为了验证URL的主机是否被允许,Java的URI被使用,它解析URL、提取主机,并检查主机是否在允许主机的白名单中。事实上,如果我们使用Java的URI解析这个URL,我们会发现URL的主机号是127.0.0.1,它包含在白名单中。但是,在某些操作系统(主要是macOS)和特定配置上,当JNDI查找进程获取此URL时,它不会尝试从127.0.0.1获取它,而是向127.0.0.1#.evilhost.com发出请求。这意味着虽然此恶意负载将绕过AllowedDaPost localhost验证(由URI解析器完成),但它仍将尝试从远程位置获取类。”

URL解析安全漏洞

在他们的分析中,研究人员在第三方Web应用程序中发现了八个由URL解析混淆导致的高危漏洞。他们说,除了在不受支持的Flask版本中发现的那些之外,所有这些都已被修补,因此开发人员应该使用更新的版本更新他们的应用程序:

1. Flask-security开放重定向(Python,CVE-2021-23385

2. Flask-security-too开放重定向(Python,CVE-2021-32618

3. Flask-User开放重定向(Python,CVE-2021-23401

4. Flask-unchained开放重定向(Python,CVE-2021-23393

5. Belledonne的SIP堆栈空指针间接引用(DoS)(C,CVE-2021-33056

6. Video.js跨站脚本(XSS)(JavaScript,CVE-2021-23414

7. Nagios XI开放重定向(PHP,CVE-2021-37352

8. Clearance开放重定向(Ruby,CVE-2021-23435

开放重定向漏洞很容易被利用,因为它们可以进行欺骗、网络钓鱼和中间人攻击(MITM)。当Web应用程序接受用户控制的输入,该输入指定用户在特定操作后将被重定向到的URL时,就会发生这种情况。例如,当用户登录网站时,他们可能会被重定向到恶意网站。

研究人员解释说,开放式重定向攻击通常通过验证来阻止:“Web服务器验证给定的URL,并且只允许属于同一站点或受信任域列表的URL。”

URL库混淆会干扰正确的验证,就像Clearance漏洞一样。研究人员指出,Clearance(Ruby的Rails框架中一个广泛应用的第三方插件,可以实现简单安全的电子邮件和密码身份验证)中的易受攻击的函数是“return_to”。此函数在登录/注销过程之后调用,并且应该将用户安全地重定向到他们之前请求的页面。但是,如果可以说服目标单击具有以下语法的URL,则可将其破坏:http://www.victim.com/////evil.com。

研究人员解释说:“由于Rails忽略了URL中的多个斜杠,因此路径段将完整到达Clearance(/////evil.com)并在其进行解析。”“由于URI.parse删除了两个斜杠,因此生成的URL是///evil.com。每当服务器将用户重定向到此URL///evil.com时,浏览器都会将此网络路径相对引用转换为指向evil.com域(主机)的绝对http://evil.com URL。”

Belledonne VoIP崩溃

在Belledonne的Linphone中发现了一个更有趣的漏洞,这是一个免费的IP语音软电话、SIP客户端和用于音频和视频通话的服务。根据分析,由于它处理SIP消息解析的方式,它遭受了scheme混淆。

研究人员解释说:“通过研究Belledone的URL解析功能,我们发现[a]段代码解析了to/from SIP header中的SIP URL。”“Belledone将SIP URL解析为通用URL,并使用strcasecmp检查方案是SIP还是SIP,以及给定的URL是否为SIP URL。”

然而,他们解释说,Belledonne generic_uri接受由不同URL组件创建的URL,而不需要存在特定组件。

他们总结说:“这意味着仅包含路径而没有URL scheme的URL是有效的URL。”“通过此方法,我们提供了一个只包含一个斜杠(/)的URL,导致URL的方案结果为NULL。然后,当Belledone使用strcasecmp时,它会比较一个NULL指针(因为没有提供scheme),从而导致NULL指针取消引用和应用程序崩溃。”

该团队创建了一个概念验证漏洞利用代码,该代码能够通过简单的恶意VoIP呼叫来使任何远程用户的应用程序崩溃,“要求受攻击用户的零交互”。

Team82和Synk研究人员指出,“可能会出现许多漏洞,从可能导致远程代码执行的SSRF漏洞到可能导致复杂网络钓鱼攻击的开放重定向漏洞。”他们说,为了保护他们的应用程序,开发人员应采用以下措施:

使用尽可能少的解析器。研究人员说:“我们建议您完全避免使用URL解析器,而且一般情况下这是很容易实现。”

在microservice环境中传输解析的URL。他们指出:“如果microservice是在不同的框架或编程语言中实现,他们可能会使用不同的URL解析器。”“为了避免这个问题,你可以简单地在前端microservice中解析URL,并以解析后的形式进一步传输它。”

了解与应用程序业务逻辑相关的解析器的差异。有时无法避免使用多个解析器,因此开发人员需要注意解析行为的差异。

在解析之前始终规范化URL。始终确保应用程序删除多个正向/反向斜杠、空格和控制字符,以便在解析之前将URL恢复为正确的形式。

本文翻译自:https://threatpost.com/url-parsing-bugs-dos-rce-spoofing/177493/如若转载,请注明原文地址
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论