CVE-2020-13942发现RCE漏洞

  • A+

译文声明
本文是翻译文章,文章原作者Eugene Rojavski
原文地址:https://securityboulevard.com/2020/11/apache-unomi-cve-2020-13942-rce-vulnerabilities-discovered/
译文仅供参考,具体内容表达以及含义以原文为准

“ Apache Unomi是一个Java开源数据平台,这是一个Java服务器,旨在管理客户,潜在顾客和访问者的数据,并优化客户个性化体验,”。Unomi可用于在各个不同的系统(例如CMS,CRM,问题跟踪器,本机移动应用程序等)中集成个性化和配置文件管理。Unomi在2019年被宣布为Apache的顶级产品,具有高度的可扩展性和易用性。

鉴于Unomi包含大量数据并具有与其他系统的紧密集成,使其攻击成为可能,Checkmarx安全研究团队分析了该平台以发现潜在的安全问题。以下详细介绍了这些发现。

我们发现了什么

Apache Unomi允许远程攻击者可能使用包含任意类的MVEL和OGNL表达式发送恶意请求,从而产生具有Unomi应用程序特权的远程代码执行(RCE)。MVEL和OGNL表达式由Unomi程序包的不同内部程序包中的不同类评估,从而使它们成为两个单独的漏洞。这些漏洞的严重性更高,因为它们可以通过公共端点加以利用,因此应通过设计使这些漏洞保持公开状态,以使应用程序正常运行,而无需进行身份验证,并且没有攻击者的先验知识。

这个名为CVE-2020-13942的漏洞的CVS分数均为10.0(严重),因为它们除了允许访问底层操作系统之外,还导致对Unomi服务的机密性,完整性和可访问性的全面损害。

在Unomi中找到以前的RCE

Unomi除了提供应用程序可以上传和检索用户数据的点之外,还提供了受限制的API,该API允许检索和处理数据。Unomi在向其端点的请求中允许复杂条件。

Unomi依赖于诸如OGNL或MVEL之类的语言(EL),来实现允许用户制定复杂而细致的查询操作。在访问存储的数据之前,将会评估基于EL的条件。

在1.5.1之前的版本中,这些表达语言完全不受限制,从而使Unomi容易通过SQL注入而受到RCE的攻击。攻击者可以通过发送单个请求在Unomi服务器上执行任意代码和OS命令。此漏洞被分类为CVE-2020-11975,并且已修复。但是,基于Checkmarx安全研究小组的进一步调查,我们发现此修复程序不够充分,可以轻易绕开。

CVE-2020-11975的修补程序引入了SecureFilteringClassLoader,该函数允许列表和阻止列表检查表达式中使用的类。SecureFilteringClassLoader依赖于这样的假设:MVEL和OGNL表达式中的每个类都是使用ClassLoader类的loadClass()方法加载的。SecureFilteringClassLoader重写ClassLoader loadClass方法,并引入了允许列表和阻止列表检查。这个假设刚好是不正确的。除了调用loadClass()方法外,还有多种加载类的方法,这会导致安全控制轻松绕过,并使Unomi向RCE开放。

首先,在某些情况下,MVEL表达式使用已实例化的类(例如Runtime或System),而无需调用loadClass()。这导致了Unomi(1.5.1)的最新版本,允许评估条件内的MVEL表达式,该条件包含任意类。

以下HTTP请求的条件是带有包含MVEL表达式的参数(script :: Runtime r = Runtime.getRuntime(); r.exec(“ touch / tmp / POC”);)。Unomi会解析该值,并以MVEL表达式的形式执行script ::之后的代码。以下示例中的表达式创建一个Runtime对象并运行“ touch”操作系统命令,该命令在/tmp目录中创建一个空文件。

漏洞1

image.png

其次,有一种方法可以在OGNL表达式中加载类,而无需触发loadClass()调用。以下HTTP请求获取运行时,并使用Java Reflections API执行OS命令。

漏洞2

image.png

有效负载可能看起来很吓人,但它只是Runtime r = Runtime.getRuntime(); r.exec(“ touch / tmp / POC”); 使用反射API编写并包装为OGNL语法。

两种提出的方​​法都成功绕过了1.5.1版中引入的安全控制,使其容易受到RCE的攻击。

Unomi可以与通常驻留在内部网络中的各种数据存储和数据分析系统集成。该漏洞是通过公共端点触发的,并允许攻击者在易受攻击的服务器上运行OS命令。脆弱的公共端点使Unomi成为企业网络的理想入口点。

在发现并验证了漏洞之后,我们将发现的结果通知了Apache,并在整个修复过程中与他们合作,直到他们告知我们所有的问题都已得到适当修补。

披露时间表

2020年6月24日–向Apache Unomi开发人员披露了漏洞

2020年8月20日–混合代码合并到主分支

2020年11月13日–包含固定代码的1.5.2版发布

2020年11月17日–公开披露

结尾

用户定义的表达语言语句的评估是危险的,并且难以约束。Struts 2是一个很好的例子,说明限制动态OGNL表达式和避免RCE有多困难。这些尝试从EL内部/内部强加使用限制,而不是出于通用目的限制受污染的EL使用,这是一种迭代方法,而不是确定的方法。相反,一种更可靠的防止RCE的方法是完全取消对任意EL表达式的支持,从而创建一组依赖于动态参数的静态表达式。

像CxSAST这样的静态应用程序安全测试解决方案,可以检测源代码中的OGNL注入,并防止这种漏洞进入产生环境。同时,诸如CxSCA之类的软件组成分析(SCA)解决方案将具有有关易受攻击程序包的必要数据,并将在漏洞公开后立即更新CxSCA用户。