0X00 前言

Newtonsoft.Json，這是一個開源的Json.Net庫，官方地址：https://www.newtonsoft.com/json ，一個讀寫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/ 、https://ivan1ee.gitbook.io/ ，後續筆者將陸續推出高質量的.NET反序列化漏洞文章，請大伙持續關註。