原文來自安全客，作者：Ivan1ee@360云影實驗室
原文鏈接：https://www.anquanke.com/post/id/172920

相關閱讀：

0X00 前言

Newtonsoft.Json，這是一個開源的Json.Net庫，官方地址：https://www.newtonsoft.com/json ，一個讀寫Json效率非常高的.Net庫，在做開發的時候，很多數據交換都是以json格式傳輸的。而使用Json的時候，開發者很多時候會涉及到幾個序列化對象的使用：DataContractJsonSerializer，JavaScriptSerializer 和 Json.NET即Newtonsoft.Json。大多數人都會選擇性能以及通用性較好Json.NET，這個雖不是微軟的類庫，但卻是一個開源的世界級的Json操作類庫，從下面的性能對比就可以看到它的性能優點。

img

用它可輕松實現.Net中所有類型(對象,基本數據類型等)同Json之間的轉換，在帶來便捷的同時也隱藏了很大的安全隱患，在某些場景下開發者使用DeserializeObject方法序列化不安全的數據，就會造成反序列化漏洞從而實現遠程RCE攻擊，本文筆者從原理和代碼審計的視角做了相關介紹和復現。

img

0X01 Json.Net序列化

在Newtonsoft.Json中使用JSONSerializer可以非常方便的實現.NET對象與Json之間的轉化，JSONSerializer把.NET對象的屬性名轉化為Json數據中的Key，把對象的屬性值轉化為Json數據中的Value，如下Demo，定義TestClass對象

img

并有三個成員，Classname在序列化的過程中被忽略（JsonIgnore），此外實現了一個靜態方法ClassMethod啟動進程。 序列化過程通過創建對象實例分別給成員賦值，

img

用JsonConvert.SerializeObject得到序列化后的字符串

img

Json字符串中并沒有包含方法ClassMethod，因為它是靜態方法，不參與實例化的過程，自然在testClass這個對象中不存在。這就是一個最簡單的序列化Demo。為了盡量保證序列化過程不拋出異常，筆者引入 SerializeObject方法的第二個參數并實例化創建JsonSerializerSettings，下面列出屬性

img

修改代碼添加 TypeNameAssemblyFormatHandling.Full、TypeNameHandling.ALL

img

將代碼改成這樣后得到的testString變量值才是筆者想要的，打印的數據中帶有完整的程序集名等信息。

img

0x02 Json.Net反序列化

2.1、反序列化用法

反序列過程就是將Json字符串轉換為對象，通過創建一個新對象的方式調用JsonConvert.DeserializeObject方法實現的，傳入兩個參數，第一個參數需要被序列化的字符串、第二個參數設置序列化配置選項來指定JsonSerializer按照指定的類型名稱處理，其中TypeNameHandling可選擇的成員分為五種

img

默認情況下設置為TypeNameHandling.None，表示Json.NET在反序列化期間不讀取或寫入類型名稱。具體代碼可參考以下

img

2.2、攻擊向量—ObjectDataProvider

漏洞的觸發點也是在于TypeNameHandling這個枚舉值，如果開發者設置為非空值、也就是對象（Objects） 、數組（Arrays） 、自動識別 (Auto) 、所有值(ALL) 的時候都會造成反序列化漏洞，為此官方文檔里也標注了警告，當您的應用程序從外部源反序列化JSON時應謹慎使用TypeNameHandling。

img

筆者繼續選擇ObjectDataProvider類方便調用任意被引用類中的方法，具體有關此類的用法可以看一下《.NET高級代碼審計（第一課）XmlSerializer反序列化漏洞》，首先來序列化TestClass

img

指定TypeNameHandling.All、TypeNameAssemblyFormatHandling.Full后得到序列化后的Json字符串

{"$type":"System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35","ObjectInstance":{"$type":"WpfApp1.TestClass, WpfApp1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null","Name":null,"Age":0},"MethodName":"ClassMethod","MethodParameters":{"$type":"MS.Internal.Data.ParameterCollection, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35","$values":["calc.exe"]},"IsAsynchronous":false,"IsInitialLoadEnabled":true,"Data":null,"Error":null}

如何構造System.Diagnostics.Process序列化的Json字符串呢？筆者需要做的工作替換掉ObjectInstance的type值，刪除一些不需要的Member、最終得到的反序列話Json字符串如下

{

'$type':'System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35',

'MethodName':'Start',

'MethodParameters':{

'$type':'System.Collections.ArrayList, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089',

'$values':['cmd','/c calc']

},

'ObjectInstance':{'$type':'System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'}

}

再經過JsonConvert.DeserializeObject反序列化（注意一點指定TypeNameHandling的值一定不能是None），成功彈出計算器。

img

2.3、攻擊向量—WindowsIdentity

WindowsIdentity類位于System.Security.Principal命名空間下。顧名思義，用于表示基于Windows認證的身份，認證是安全體系的第一道屏障肩負著守護著整個應用或者服務的第一道大門，此類定義了Windows身份一系列屬性

img

對于用于表示認證類型的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接口

img

查看定義得知，只有一個方法GetObjectData

img

在.NET運行時序列化的過程中CLR提供了控制序列化數據的特性，如：OnSerializing、OnSerialized、NonSerialized等。為了對序列化數據進行完全控制，就需要實現Serialization.ISeralizable接口，這個接口只有一個方法，即 GetObjectData，第一個參數SerializationInfo包含了要為對象序列化的值的合集，傳遞兩個參數給它：Type和IFormatterConverter，其中Type參數表示要序列化的對象全名（包括了程序集名、版本、公鑰等），這點對于構造惡意的反序列化字符串至關重要

img

另一方面GetObjectData又調用SerializationInfo 類提供的AddValue多個重載方法來指定序列化的信息，AddValue添加的是一組<key,value> ；GetObjectData負責添加好所有必要的序列化信息。

img

2.3.2、ClaimsIdentity

ClaimsIdentity（聲稱標識）位于System.Security.Claims命名空間下，首先看下類的定義

img

其實就是一個個包含了claims構成的單元體，舉個栗子：駕照中的“身份證號碼：000000”是一個claim、持證人的“姓名: Ivan1ee”是另一個claim、這一組鍵值對構成了一個Identity，具有這些claims的Identity就是ClaimsIdentity，通常用在登錄Cookie驗證，如下代碼

img

一般使用的場景我想已經說明白了，現在來看下類的成員有哪些，能賦值的又有哪些？

參考官方文檔可以看到 Lable、BootstrapContext、Actor三個屬性具備了set

img

查閱文檔可知，這幾個屬性的原始成員分別為actor、bootstrapContext、lable如下

img

ClaimsIdentity類初始化方法有兩個重載，并且通過前文介紹的SerializationInfo來傳入數據，最后用Deserialize反序列化數據。

img

追溯的過程有點像框架類的代碼審計，跟蹤到Deserialize方法體內，查找BootstrapContextKey才知道原來它還需要被外層base64解碼后帶入反序列化

img

2.3.3、打造Poc

回過頭來想一下，如果使用GetObjectData類中的AddValue方法添加“key : System.Security.ClaimsIdentity.bootstrapContext“、”value : base64編碼后的payload“，最后實現System.Security.Principal.WindowsIdentity.ISerializable接口就能攻擊成功。首先定義WindowsIdentityTest類

img

筆者用ysoserial生成反序列化Base64 Payload賦值給BootstrapContextKey，實現代碼如下

img

到這步生成變量obj1的值就是一段poc，但還需改造一下，將$type值改為System.Security.Principal.WindowsIdentity完全限定名

img

最后改進后交給反序列化代碼執行，拋出異常之前觸發計算器，效果如下圖

img

0x03 代碼審計視角

從代碼審計的角度其實很容易找到漏洞的污染點，通過前面幾個小節的知識能發現需要滿足一個關鍵條件非TypeNameHandling.None的枚舉值都可以被反序列化，例如以下Json類

img

都設置成TypeNameHandling.All，攻擊者只需要控制傳入參數 _in便可輕松實現反序列化漏洞攻擊。Github上很多的json類存在漏洞，例如下圖

img

代碼中改用了Auto這個值，只要不是None值在條件許可的情況下都可以觸發漏洞，筆者相信肯定還有更多的漏洞污染點，需要大家在代碼審計的過程中一起去發掘。

0x04 案例復盤

最后再通過下面案例來復盤整個過程，全程展示在VS里調試里通過反序列化漏洞彈出計算器。

  1. 輸入http://localhost:5651/Default Post加載value值

    img

  2. 通過JsonConvert.DeserializeObject 反序列化 ，并彈出計算器

    img

最后附上動圖

img

0x05 總結

Newtonsoft.Json庫在實際開發中使用率還是很高的，攻擊場景也較豐富，作為漏洞挖掘者可以多多關注這個點，攻擊向量建議選擇ObjectDataProvider，只因生成的Poc體積相對較小。最后.NET反序列化系列課程筆者會同步到 https://github.com/Ivan1ee/ 、https://ivan1ee.gitbook.io/ ，后續筆者將陸續推出高質量的.NET反序列化漏洞文章，請大伙持續關注。

本文經安全客授權發布，轉載請聯系安全客平臺。

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/843/