目录导航
Apache Unomi简介
“ Apache Unomi是一个Java开源客户数据平台，这是一个Java服务器，旨在管理客户，潜在顾客和访问者的数据，并帮助个性化客户体验，”其网站表示。Unomi可用于在不同的系统（例如CMS，CRM，问题跟踪器，本机移动应用程序等）中集成个性化和配置文件管理。Unomi在2019年被宣布为Apache的顶级产品，具有高度的可扩展性和易用性考虑整合。
鉴于Unomi包含大量数据并具有与其他系统的紧密集成，使其成为攻击者的理想目标，Checkmarx安全研究团队分析了该平台以发现潜在的安全问题。以下详细介绍了这些发现。
CVE-2020-13942漏洞摘要
我们发现了什么
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容易通过表达语言注入而受到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目录中创建一个空文件。
漏洞①
其次，有一种方法可以在OGNL表达式中加载类，而无需触发loadClass()调用。以下HTTP请求获取运行时，并使用Java Reflections API执行OS命令。
漏洞②
payload可能看起来很吓人，但它只是Runtime r=Runtime.getRuntime(); r.exec(“touch/tmp/POC”); 使用反射API编写并包装为OGNL语法。
两种提出的方法都成功绕过了1.5.1版中引入的安全控制，使其容易受到两个位置的RCE的攻击。
可能的攻击情形
Unomi可以与通常驻留在内部网络中的各种数据存储和数据分析系统集成。该漏洞是通过公共端点触发的，并允许攻击者在易受攻击的服务器上运行OS命令。脆弱的公共端点使Unomi成为企业网络的理想入口点。它与其他服务的紧密集成也使其成为内部网络中进一步横向移动的垫脚石。
披露和事件摘要
在发现并验证了漏洞之后，我们将发现的结果通知了Apache，并在整个修复过程中与他们合作，直到他们告知我们所有的问题都已得到适当修补。
要了解有关这些类型漏洞的更多信息，OWASP和CWE提供了描述，示例，后果和相关控制，如以下链接所示：
- https://owasp.org/www-community/vulnerabilities/Expression_Language_Injection
- https://cwe.mitre.org/data/definitions/917.html
此外，阅读代码，分析了修复，并了解如何通过我们的互动CxCodebashing教训减轻类似的问题在这里。
披露时间表
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用户。要了解如何缓解类似问题，请在此处访问我们的CxCodebashing课程。
总结
这种类型的研究是Checkmarx安全研究小组不断努力的一部分，以推动所有组织之间的软件安全实践进行必要的更改。Checkmarx致力于分析开源软件，以帮助开发团队构建和部署更安全的应用程序。Checkmarx安全研究团队建立了我们的开源库和漏洞数据库，从而为CxSCA客户提供了风险详细信息，补救指南和NVD以外的专有漏洞。
要了解有关此类RCE漏洞的更多信息，请阅读我们关于Struts 2的博客。有关更多信息，或与Checkmarx专家讨论如何在代码中检测，确定优先级和补救开源风险，请与我们联系。