CVE-2021-44521:利用Apache Cassandra用户定义函数进行远程代码执行
JFrog的安全研究团队最近披露了一个RCE(远程代码执行)问题Apache Cassandra,已分配给cve - 2021 - 44521(CVSS 8.4)。这个Apache安全漏洞很容易被利用,有可能对系统造成严重破坏,但幸运的是,它只在Cassandra的非默认配置中出现。
Cassandra是一个高度可扩展的分布式NoSQL数据库,由于其分布式特性的好处而非常受欢迎。Cassandra被Netflix、Twitter、Urban Airship、Constant Contact、Reddit、Cisco、OpenX、Digg、CloudKick、Ooyala等企业使用。Cassandra在DevOps和原生云开发圈中也非常受欢迎,这可以从它在CNCF项目(例如Jaeger).
一些公司甚至提供基于Cassandra的基于云的交钥匙解决方案,例如DataStax(无服务器、多云的DBaaS)。
在这篇博文中,我们将介绍我们如何发现RCE的背景安全漏洞,提供关于PoC漏洞的详细信息,并分享建议的修复和缓解方案。
udf和Nashorn
Cassandra提供了创建用户定义函数(udf)的功能,以执行数据库中数据的自定义处理。
默认情况下,Cassandra udf可以用Java和JavaScript编写。在JavaScript中,它使用NashornJava运行时环境(JRE)是一个运行在Java虚拟机(JVM)之上的JavaScript引擎。
在接受不受信任的代码时,不能保证Nashorn是安全的。因此,任何允许这种行为的服务必须始终把纳霍恩的死刑装进沙箱里¹。
例如,运行下面的Nashorn JavaScript代码允许执行任意shell命令:
java.lang.Runtime.getRuntime()。exec(“砍”)
Cassandra的开发团队决定实现一个围绕UDF执行的自定义沙盒,它使用两种机制来限制UDF代码:
- 一种过滤机制白名单和黑名单(仅匹配白名单的类而且不匹配黑名单是允许的):
private static final String[] allowedPatterns = {"com/google/common/reflect/TypeToken", "java/io/IOException.class", "java/io/Serializable.class", "java/lang/", "java/math/", "java/net/Inet4Address.class",…private static final String[] disallowedPatterns = {"com/datastax/driver/core/Cluster.class", "com/datastax/driver/core/Metrics.class", "com/datastax/driver/core/NettyOptions.class", "com/datastax/driver/core/Session.class", "com/datastax/driver/core/Statement.class", "com/datastax/driver/core/TimestampGenerator.class", "java/lang/Compiler.class", "java/lang/InheritableThreadLocal.class", "java/lang/Package.class", "java/lang/Process.class",… - Java安全管理器的使用执行权限执行的代码的(在默认配置中,不授予任何权限)
某些项目如NashornEscape实现一个沙盒来保护Nashorn代码的执行
通过Nashorn访问Java类
通过使用,可以访问任意Java类Java.type.
例如:var System = Java.type("java.lang.System")能让我们进入有使用系统变量。
具有足够权限的用户可以使用创建函数查询例如,这个函数将输出它的输入到控制台:
javascript AS $$var System = Java.type("java.lang.System");System.out.println(名字),名称$ $;
用户可以使用下面的SELECT查询调用该函数。
Select print(name) from table;
CVE-2021-44521什么时候可以被开发?
当我们研究Cassandra UDF沙盒实现时,我们意识到混合特定(非默认)配置选项可以允许我们滥用Nashorn引擎,逃脱沙盒并实现远程代码执行。这是我们报告的CVE-2021-44521漏洞。
Cassandra部署容易受到CVE-2021-44521的攻击cassandra.yaml配置文件中包含以下定义:
Enable_user_defined_functions: true enable_scripted_user_defined_functions: true enable_user_defined_functions_threads: false
注意,这是惟一需要的非默认配置选项,因为在启用udf时,所有用户都可以创建和执行任意的udf。这包括匿名登录,它们在默认情况下启用(身份验证= AllowAllAuthenticator).
注意,Cassandra也可以通过Config.java配置文件,它支持与上面相同的标志。
公共布尔值enable_user_defined_functions = false;...
前两个标志启用了对Java和JavaScript²的UDF支持。
的enable_user_defined_functions_threads是CVE-2021-44521开发的关键。
²Cassandra还支持在udf中使用的其他脚本语言,如Python
JFrog产品易受Chth华体会最新官方网站VE-2021-44521攻击吗?
JFrog产hth华体会最新官方网站品不容易受到CVE-2021-44521的攻击,因为它们不使用Apache Cassandra。
解释enable_user_defined_functions_threads
从源代码(Config.java):

enable_user_defined_functions_threads设置为真正的这意味着每个被调用的UDF函数将运行在不同的线程中,使用一个没有任何权限的安全管理器——我们将在后面的部分中介绍对这个默认配置的DoS攻击。
当选项设置为假,所有调用的UDF函数都在Cassandra中运行守护进程线程,它有一个安全管理器一些权限。我们将展示如何滥用这些权限来实现沙盒转义和RCE。
注意,源代码中的文档暗指关闭该值是不安全的,但由于拒绝服务的问题。我们将演示关闭这个值直接导致远程代码执行。
RCE通过沙盒转义
UDF沙盒不允许我们直接在服务器上执行代码,例如通过调用.exec java.lang.Runtime.getRuntime () ().
在研究沙盒实现时,我们发现至少有两种方法可以逃脱沙盒:
- 滥用Nashorn引擎实例
有的负载而且loadLibrary功能
因为Cassandra的类过滤机制允许访问有,这两种方法都可以用来逃离沙盒。
方法1 -滥用Nashorn引擎实例
为了完全摆脱沙盒,我们必须:
- 关闭类过滤机制
- 在没有安全管理器的情况下运行
当enable_user_defined_functions_threads设置为假,我们的UDF代码运行在守护线程中,该守护线程具有调用的权限setSecurityManager!这立即允许我们关闭安全管理器,所以现在我们只需要绕过类过滤机制。
当在Nashorn上运行JavaScript代码时,我们可以使用this.engine访问nasorn实例引擎。正如在小心那头犀牛博客,这实际上允许我们通过创建绕过任何类过滤器一个新的脚本引擎,不受类过滤机制的限制。
但是,较新的Java版本(8u191和更高版本)已经收到了阻止访问的缓解措施this.engine当安全经理是活跃的。
对攻击者来说幸运的是——正如我们之前所建立的,我们可以调用setSecurityManager禁用安全管理器,然后进行访问this.engine.
把所有的东西放在一起,一个PoC查询可能看起来像这样:
System. setsecuritymanager (NULL);this.engine.factory.scriptEngine.eval('java.lang.Runtime.getRuntime(). System (' java.lang.System");Exec ("touch hacked")');name $$;
通过将安全管理器设置为,该查询将关闭安全管理器零然后创建一个不受类过滤机制限制的新脚本引擎,在Cassandra服务器上运行任意shell命令。
PoC运作中
执行PoC是为了在Cassandra服务器上创建一个名为“hacked”的新文件:

方法二:java.lang。系统’s load and loadLibrary functions
除了Nashorn转义技术之外,还有更多库函数没有被类过滤器过滤,当安全管理器关闭时,它们可能被滥用于代码执行。
例如,有的负载方法允许我们通过指定绝对路径加载任意共享对象。
假设攻击者可以以某种方式将恶意的共享目标文件上传到易受攻击的系统(只要攻击者知道上传文件的完整路径,就与受害机器上的上传目录无关)负载方法可用于加载库,该库可以运行任意代码作为其输入例程的一部分。
其他值得注意的问题
在我们的研究中,我们发现并披露了一些值得一提的问题,当在一些非默认(尽管合理)配置上运行Cassandra(和相关工具)时。这些选项被记录为不安全的,但是我们想强调这些问题及其确切的影响,以便供应商意识到不要在公共可访问的网络中部署这样的配置。
卡桑德拉UDF DoS
当UDF函数被启用时enable_user_defined_functions_threads标志设置为真正的(默认值)恶意用户可以创建一个UDF来关闭Cassandra守护进程。这是由UDF超时机制的行为引起的,该机制由user_defined_function_fail_timeout国旗。
如果一个UDF函数的运行时间超过了分配的时间,那么整个Cassandra守护进程将会关闭(不仅仅是运行UDF的线程)。尽管这是记录在案的行为,但攻击者可以通过创建一个永远循环的函数轻松地DoS整个数据库而(真).
我们目前还不知道有什么直接的方法来缓解这个问题user_function_timeout_policy国旗的死来忽略可能会导致更严重的DoS),尽管可以通过确保特权较低的用户不能创建任意UDF函数来间接缓解这个问题(请参阅下面的“可能的缓解措施”)。
通过不安全的对象反序列化来强调RCE
Cassandra包含一个叫做cassandra-stressd用来对数据库进行压力测试。这个工具Apache作为一个“不安全”的工具。
这是一个面向网络的工具,默认情况下只监听本地主机接口。
但是,这个工具可以通过提供- h标志和IP地址。
直接反序列化来自套接字的输入StressServer.java,这意味着攻击者可能会提供一个序列化的“gadget”对象,导致反序列化时任意执行代码:
公共静态类应力线程扩展线程{私有的最终套接字;public StressThread(Socket客户端){this。Socket =客户端;} public void run() {try{//任意反序列化!ObjectInputStream in = new ObjectInputStream(socket.getInputStream());...
这个问题的利用取决于正在运行的Cassandra实例的类路径中的可用类。
我们敦促用户确保他们没有运行cassandra-stressd工具带- h指向外部接口的标志。
如何修复CVE-2021-44521?
我们强烈建议所有Apache Cassandra用户升级到以下版本之一,以解决CVE-2021-44521:
3.0.xusers should upgrade to 3.0.26
3.11.xusers should upgrade to 3.11.12
4.0.xusers should upgrade to 4.0.2
Apache的补丁增加了一个新的标志-allow_extra_insecure_udfs(默认为false),它不允许关闭安全管理器,并阻止访问有.
希望自己的udf与沙盒之外的元素交互的用户(并且不介意潜在的安全风险)可以打开标志来恢复遗留行为(不推荐!)
如何缓解CVE-2021-44521?
对于无法升级Cassandra实例的用户,我们建议采取以下缓解措施:
- 如果udf没有被积极使用,可以通过设置完全禁用它们
enable_user_defined_functions来假(这是默认值) - 如果需要使用udf,请设置
enable_user_defined_functions_threads来真正的(这是默认值) - 通过移除以下权限,移除不信任用户的创建、修改和执行功能的权限:
所有的功能,所有的函数都在键空间中而且函数为创建,改变而且执行查询。
方法可以使用以下查询来完成此任务role_name到期望的角色。
撤销所有函数的CREATE,所有键空间中的函数< role_name >;撤销KEYSPACE中所有函数的CREATE< role_name >;撤销CREATE ON函数< role_name >;撤销所有函数上的ALTER,所有键空间中的函数< role_name >;撤销键空间中所有函数的ALTER< role_name >;撤销ALTER ON函数< role_name >;撤销执行所有函数,所有函数在键空间,函数从< role_name >;撤销KEYSPACE中所有函数的EXECUTE< role_name >;撤销EXECUTE ON函数< role_name >;
结论与致谢
最后,我们强烈建议升级你的Cassandra到最新版本,以避免CVE-2021-44521可能被利用。
我们要感谢Cassandra的维护者及时地验证和修复了该问题,并负责任地为该问题创建了CVE。
使用JFrog Xray查找脆弱版本
除了暴露新的安全漏洞和威胁之外,JFrog还为开发人员和安全团队提供了方便地访问其软件的最新相关信息的途径——包括使用Apache Cassandra开源库版本和相关的cve——通过自动安全扫描JFrog x光SCA工具。
