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反序列化漏洞文章，請大伙持續關注。