.NET高级代码审计（第二课） Json.Net反序列化漏洞

0x00 前言

newtonsoft.json，这是一个开源的json.net库，官方地址： ，一个读写json效率非常高的.net库，在做开发的时候，很多数据交换都是以json格式传输的。而使用json的时候，开发者很多时候会涉及到几个序列化对象的使用：datacontractjsonserializer，javascriptserializer 和 json.net即newtonsoft.json。大多数人都会选择性能以及通用性较好json.net，这个虽不是微软的类库，但却是一个开源的世界级的json操作类库，从下面的性能对比就可以看到它的性能优点。

用它可轻松实现.net中所有类型(对象,基本数据类型等)同json之间的转换，在带来便捷的同时也隐藏了很大的安全隐患，在某些场景下开发者使用deserializeobject方法序列化不安全的数据，就会造成反序列化漏洞从而实现远程rce攻击，本文笔者从原理和代码审计的视角做了相关介绍和复现。

 

 

0x01 json.net序列化

在newtonsoft.json中使用jsonserializer可以非常方便的实现.net对象与json之间的转化，jsonserializer把.net对象的属性名转化为json数据中的key，把对象的属性值转化为json数据中的value，如下demo，定义testclass对象

并有三个成员，classname在序列化的过程中被忽略（jsonignore），此外实现了一个静态方法classmethod启动进程。 序列化过程通过创建对象实例分别给成员赋值，

用jsonconvert.serializeobject得到序列化后的字符串

json数据中并没有包含方法classmethod，因为它是静态方法，不参与实例化的过程，自然在testclass这个对象中不存在。这就是一个最简单的序列化demo。为了尽量保证序列化过程不抛出异常，笔者引入 serializeobject方法的第二个参数并实例化创建jsonserializersettings，下面列出属性

修改代码添加 typenameassemblyformathandling.full、typenamehandling.all

将代码改成这样后得到的teststring变量值才是笔者想要的，打印的数据中带有完整的程序集名等信息。

0x02 json.net反序列化

2.1、反序列化用法

反序列过程就是将json字符串转换为对象，通过创建一个新对象的方式调用jsonconvert.deserializeobject方法实现的，传入两个参数，第一个参数需要被序列化的字符串、第二个参数设置序列化配置选项来指定jsonserializer按照指定的类型名称处理，其中typenamehandling可选择的成员分为五种

 

 

默认情况下设置为typenamehandling.none，表示json.net在反序列化期间不读取或写入类型名称。具体代码可参考以下

2.2、攻击向量—objectdataprovider

漏洞的触发点也是在于typenamehandling这个枚举值，如果开发者设置为非空值、也就是对象（objects） 、数组（arrays） 、自动识别 (auto) 、所有值(all) 的时候都会造成反序列化漏洞，为此官方文档里也标注了警告，当您的应用程序从外部源反序列化json时应谨慎使用typenamehandling。

笔者继续选择objectdataprovider类方便调用任意被引用类中的方法，具体有关此类的用法可以看一下《.net高级代码审计（第一课）xmlserializer反序列化漏洞》，首先来序列化testclass 

指定typenamehandling.all、typenameassemblyformathandling.full后得到序列化后的json数据

如何构造system.diagnostics.process序列化的json字符串呢？笔者需要做的工作替换掉objectinstance的$type、methodname的值以及methodparameters的$type值，删除一些不需要的member、最终得到的反序列话json数据如下

再经过jsonconvert.deserializeobject反序列化（注意一点指定typenamehandling的值一定不能是none），成功弹出计算器。

 

2.3、攻击向量—windowsidentity

windowsidentity类位于system.security.principal命名空间下。顾名思义，用于表示基于windows认证的身份，认证是安全体系的第一道屏障肩负着守护着整个应用或者服务的第一道大门，此类定义了windows身份一系列属性

对于用于表示认证类型的authenticationtype属性来说，在工作组模式下返回ntlm。对于域模式，如果操作系统是vista或者以后的版本，该属性返回negotiate，表示采用spnego认证协议。而对于之前的windows版本，则该属性值为kerberos。groups属性返回windowsidentity对应的windows帐号所在的用户组（user group），而isguest则用于判断windows帐号是否存在于guest用户组中。issystem属性则表示windows帐号是否是一个系统帐号。对于匿名登录，iis实际上会采用一个预先指定的windows帐号进行登录。而在这里，isanonymous属性就表示该windowsidentity对应的windows帐号是否是匿名帐号。

2.3.1、iserializable

跟踪定义得知继承于claimsidentity类，并且实现了iserializable接口

查看定义得知，只有一个方法getobjectdata

在.net运行时序列化的过程中clr提供了控制序列化数据的特性，如：onserializing、onserialized、nonserialized等。为了对序列化数据进行完全控制，就需要实现serialization.iseralizable接口，这个接口只有一个方法，即 getobjectdata，第一个参数serializationinfo包含了要为对象序列化的值的合集，传递两个参数给它：type和iformatterconverter，其中type参数表示要序列化的对象全名（包括了程序集名、版本、公钥等），这点对于构造恶意的反序列化字符串至关重要

另一方面getobjectdata又调用serializationinfo 类提供的addvalue多个重载方法来指定序列化的信息，addvalue添加的是一组<key,value> ；getobjectdata负责添加好所有必要的序列化信息。

2.3.2、claimsidentity

claimsidentity（声称标识）位于system.security.claims命名空间下，首先看下类的定义

其实就是一个个包含了claims构成的单元体，举个栗子：驾照中的“身份证号码：000000”是一个claim、持证人的“姓名: ivan1ee”是另一个claim、这一组键值对构成了一个identity，具有这些claims的identity就是claimsidentity，通常用在登录cookie验证，如下代码

一般使用的场景我想已经说明白了，现在来看下类的成员有哪些，能赋值的又有哪些？参考官方文档可以看到 lable、bootstrapcontext、actor三个属性具备了set

查阅文档可知，这几个属性的原始成员分别为actor、bootstrapcontext、lable如下

claimsidentity类初始化方法有两个重载，并且通过前文介绍的serializationinfo来传入数据，最后用deserialize反序列化数据。

追溯的过程有点像框架类的代码审计，跟踪到deserialize方法体内，查找bootstrapcontextkey才知道原来它还需要被外层base64解码后带入反序列化

2.3.3、打造poc

回过头来想一下，如果使用getobjectdata类中的addvalue方法添加“key : system.security.claimsidentity.bootstrapcontext“、”value :  base64编码后的payload“，最后实现system.security.principal.windowsidentity.iserializable接口就能攻击成功。首先定义windowsidentitytest类

笔者用ysoserial生成反序列化base64 payload赋值给bootstrapcontextkey，实现代码如下

到这步生成变量obj1的值就是一段poc，但还需改造一下，将$type值改为system.security.principal.windowsidentity完全限定名

最后改进后交给反序列化代码执行，抛出异常之前触发计算器，效果如下图

0x03 代码审计视角

从代码审计的角度其实很容易找到漏洞的污染点，通过前面几个小节的知识能发现需要满足一个关键条件非typenamehandling.none的枚举值都可以被反序列化，例如以下json类

都设置成typenamehandling.all，攻击者只需要控制传入参数 _in便可轻松实现反序列化漏洞攻击。github上很多的json类存在漏洞，例如下图

 

 

代码中改用了auto这个值，只要不是none值在条件许可的情况下都可以触发漏洞，笔者相信肯定还有更多的漏洞污染点，需要大家在代码审计的过程中一起去发掘。

0x04 案例复盘

最后再通过下面案例来复盘整个过程，全程展示在vs里调试里通过反序列化漏洞弹出计算器。

1. 输入http://localhost:5651/default post加载value值

2. 通过jsonconvert.deserializeobject 反序列化 ，并弹出计算器

最后附上动图

0x05 总结

newtonsoft.json库在实际开发中使用率还是很高的，攻击场景也较丰富，作为漏洞挖掘者可以多多关注这个点，攻击向量建议选择objectdataprovider，只因生成的poc体积相对较小。最后.net反序列化系列课程笔者会同步到 https://github.com/ivan1ee/ 、 ，后续笔者将陆续推出高质量的.net反序列化漏洞文章，请大伙持续关注。