FINDING DESERIALIZATION BUGS IN THE SOLARWIND PLATFORM

This vulnerability targeted the SolarWinds Information Service. In order to deliver an AMQP message to the Information Service, the Routing-Key of the message must be set to SwisPubSub.
此漏洞以 SolarWinds Information Service 为目标。为了将 AMQP 消息传递到信息服务，必须将消息 Routing-Key 的 设置为 SwisPubSub 。

Now, let’s verify how SolarWinds handles those messages! We can start with the EasyNetQ.Consumer.HandleBasicDeliver method:
现在，让我们验证一下 SolarWinds 如何处理这些消息！我们可以从方法 EasyNetQ.Consumer.HandleBasicDeliver 开始：

At [1], the code retrieves the properties of the AMQP message. Those properties are controlled by the attacker who sends the message.
在 ， [1] 代码检索 AMQP 消息的属性。这些属性由发送消息的攻击者控制。

At [2], it creates an execution context, containing both the AMQP message properties and the message body.
在 时 [2] ，它将创建一个执行上下文，其中包含 AMQP 消息属性和消息正文。

At [3], it executes a task to consume the message.
在 时 [3] ，它将执行一个任务来使用消息。

This leads us to the Consume method:
这将我们引向以下 Consume 方法：

At [1], EasyNetQ.DefaultMessageSerializationStrategy.DeserializeMessage is called. It accepts the message properties and the message body as input. The interesting stuff happens here.
在 时 [1] EasyNetQ.DefaultMessageSerializationStrategy.DeserializeMessage ，被调用。它接受消息属性和消息正文作为输入。有趣的事情发生在这里。

At [1], we can see something really intriguing. A method named DeSerialize is called and it returns an output of type Type. As an input, it accepts the Type property from the message. That’s right – we can control messageType type through an AMQP message property!
在 [1] ，我们可以看到一些非常有趣的东西。调用名为 DeSerialize 的方法，它返回 Type .作为输入，它接受消息中的 Type 属性。没错 – 我们可以通过 AMQP 消息属性控制 messageType 类型！

At [2], it calls BytesToMessage, which accepts both the attacker-controlled type and the message body as input.
在 时 [2] ，它调用 BytesToMessage ，它接受攻击者控制的类型和消息正文作为输入。

At [1], the message body is decoded as a UTF-8 string. It is expected to contain JSON-formatted data.
在 ， [1] 消息正文被解码为 UTF-8 字符串。它应包含 JSON 格式的数据。

At [2], the deserialization is performed. We control both the target type and the serialized payload.
在 执行 [2] 反序列化。我们控制目标类型和序列化的有效负载。

At [3], it can be seen that the TypeNameHandling deserialization setting is set to Auto.
在 ， [3] TypeNameHandling 可以看出反序列化设置设置为 Auto 。

We have more than we need to achieve remote code execution here! To do that, we have to send an AMQP message with the Type property set to a dangerous type.
我们在这里实现远程代码执行所需的更多内容！为此，我们必须发送一条 AMQP 消息，并将 Type 属性设置为危险类型。

In the message body, we must deliver the corresponding JSON.NET gadget. I have used a simple WindowsPrincipal gadget from ysoserial.net, which is a bridge for the internally stored BinaryFormatter gadget. Upon the JSON deserialization, the RCE will be achieved through the underlying BinaryFormatter deserialization.
在消息正文中，我们必须提供相应的 JSON.NET 小工具。我使用了 ysoserial.net 的一个简单的 WindowsPrincipal 小工具，它是内部存储的BinaryFormatter小工具的桥梁。在 JSON 反序列化后，RCE 将通过底层 BinaryFormatter 反序列化来实现。

RCE achieved! RCE实现了！

CVE-2022-36957

In the previous vulnerability, we were able to fully control the target deserialization type through the AMQP property. When I find such a vulnerability, I like to ask myself the following question: “What does a legitimate message look like?” I often check the types that are being deserialized during typical product operation. It sometimes leads to interesting findings.
在以前的漏洞中，我们能够通过 AMQP 属性完全控制目标反序列化类型。当我发现这样的漏洞时，我喜欢问自己以下问题：“合法信息是什么样的？我经常检查在典型产品操作期间正在反序列化的类型。它有时会导致有趣的发现。

I quickly realized that SolarWinds sends messages of one type only:
我很快意识到SolarWinds只发送一种类型的消息：

         SolarWinds.MessageBus.Models.Indication

Let’s take a moment to analyze this type:
让我们花点时间分析一下这种类型：

At [1] and [2], we can see two public members of type SolarWinds.MessageBus.Models.PropertyBag. The fun begins here.
在 和 [2] 处 [1] ，我们可以看到两个类型的 SolarWinds.MessageBus.Models.PropertyBag 公共成员。乐趣从这里开始。

At [1], you can see the definition of the class in question, SolarWinds.MessageBus.Models.PropertyBag.
在 ， [1] 您可以看到相关类的定义 SolarWinds.MessageBus.Models.PropertyBag 。

At [2], a custom converter is registered for this class – SolarWinds.MessageBus.Models. PropertyBagJsonConverter. It implements the ReadJson method, which will be called during deserialization.
在 ， [2] 为此类注册了一个自定义转换器 – SolarWinds.MessageBus.Models. PropertyBagJsonConverter 。它实现将在 ReadJson 反序列化期间调用的方法。

At [1], the code iterates over the JSON properties.
在 处， [1] 代码将循环访问 JSON 属性。

At [2], a JSON value is retrieved and casted to the JObject type.
在 ， [2] 将检索 JSON 值并将其强制转换为 JObject 该类型。

At [3], a Type is retrieved on the basis of the value stored in the t key.
在 时 [3] ，将根据 t 存储在键中的值检索 a Type 。

At [4], the object stored in the v key is deserialized, where we control the target deserialization type (again)!
在 [4] ，存储在 v 键中的对象被反序列化，我们控制目标反序列化类型（再次）！

You can see that we are again able to control the deserialization type! This type is delivered through the t JSON key and the serialized payload is delivered through the v key.
您可以看到我们再次能够控制反序列化类型！此类型通过 t JSON 密钥传递，序列化的有效负载通过 v 密钥传递。

Let’s have a look at a fragment of a legitimate message:
让我们看一下合法消息的片段：

We can take any property, for instance: IndicationId. Then, we need to:
我们可以采用任何属性，例如： IndicationId .然后，我们需要：
• Set the value of the t key to the name of a malicious type.
• 将 t 密钥的值设置为恶意类型的名称。
• Put a malicious serialized payload in the value of the v key.
• 将恶意序列化的有效负载放在 v 密钥的值中。

As the JSON deserialization settings are set to TypeNameHandling.Auto, it is enough to deliver something like this:
由于 JSON 反序列化设置设置为 TypeNameHandling.Auto ，因此提供如下内容就足够了：

Now, let’s imagine that the first bug described above, CVE-2022-38108, got fixed by hardcoding of the target deserialization type to SolarWinds.MessageBus.Models.Indication. After all, this is the only legitimate type to be deserialized. That fix would not be enough, because SolarWinds.MessageBus.Models.Indication can be used to deliver an inner object, with an attacker-controlled type. We have a second RCE through control of the type here.
现在，让我们假设上述第一个错误 CVE-2022-38108 已通过将目标反序列化类型硬编码为 SolarWinds.MessageBus.Models.Indication .毕竟，这是唯一要反序列化的合法类型。该修复还不够，因为 SolarWinds.MessageBus.Models.Indication 可用于传递具有攻击者控制类型的内部对象。我们通过控制这里的类型有第二个 RCE。

CVE-2022-36958

SolarWinds defines some inner methods/operations called “SWIS verbs”. Those verbs can be either:
SolarWinds定义了一些称为“SWIS动词”的内部方法/操作。这些动词可以是：
a) Invoked directly through the API.
a） 直接通过 API 调用。
b) Invoked indirectly through the Orion Platform Web UI (Orion Platform invokes verbs internally).
b） 通过 Orion Platform Web UI 间接调用（Orion Platform 在内部调用动词）。

There are several things that we need to know about SWIS verbs:
关于SWIS动词，我们需要了解几件事：
• They are invoked using a payload within an XML structure.
• 使用 XML 结构中的有效负载调用它们。
• They accept arguments of predefined types.
• 它们接受预定义类型的参数。

For instance, consider the Orion.AgentManagement.Agent.Deploy verb. It accepts 12 arguments. The following screenshot presents those arguments and their corresponding types.
例如，考虑 Orion.AgentManagement.Agent.Deploy 动词。它接受 12 个参数。以下屏幕截图显示了这些参数及其相应的类型。

The handling of arguments is performed by the method SolarWinds.InformationService.Verb. VerbExecutorContext.UnpackageParameters(XmlElement[], Stream):
参数的处理由以下方法 SolarWinds.InformationService.Verb. VerbExecutorContext.UnpackageParameters(XmlElement[], Stream) 执行：

At [1], the Type is retrieved for the given verb argument.
在 ， [1] Type 为给定的谓词参数检索 。

At [2], a DataContractSerializer is initialized with the retrieved argument type.
在 ， [2] 使用 检索到的参数类型初始化 。 DataContractSerializer

At [3] and [4], the argument is deserialized.
在 和 [4] 时 [3] ，参数被反序列化。

We know that we are dealing with a DataContractSerializer. We cannot control the deserialization types though. My first thought was: I had already found some abusable PropertyBag classes. Maybe there are more to be found here?
我们知道我们正在处理一个 DataContractSerializer .但是，我们无法控制反序列化类型。我的第一个想法是：我已经找到了一些可 PropertyBag 滥用的课程。也许这里还有更多？

It quickly turned out to be a good direction. There are multiple SWIS verbs that accept arguments of a type named SolarWinds.InformationService.Addons.PropertyBag. We can provide arbitrary XML to be deserialized to an object of this type. Let’s investigate!
事实证明，这是一个很好的方向。有多个 SWIS 谓词接受名为 SolarWinds.InformationService.Addons.PropertyBag 的参数。我们可以提供任意 XML 来反序列化为这种类型的对象。让我们调查一下！

At [1], the ReadXml method is defined. It will be called during deserialization.
在 ， [1] 定义了 ReadXml 该方法。它将在反序列化期间调用。

At [2], the code iterates over the provided items.
在 处 [2] ，代码将循环访问提供的项。

At [3], the key element is retrieved. If present, the code continues.
在 ， [3] 将检索 key 该元素。如果存在，代码将继续。

At [4], the value of the type element is retrieved. One may safely assume where it leads.
在 ， [4] 将检索 type 元素的值。人们可以安全地假设它通向何方。

At [5], the value element is retrieved.
在 ， [5] 将检索 value 该元素。

At [6], the Deserialize method is called, and the data contained in both the value and type tags are provided as input.
在 ， [6] 将调用该方法 Deserialize ，并将 和 value type 标记中包含的数据作为输入提供。

At [7], the serialized payload and type name are passed to the SolarWinds.InformationService.Serialization.SerializationHelper.Deserialize method.
在 ， [7] 序列化的有效负载和类型名称将传递给 SolarWinds.InformationService.Serialization.SerializationHelper.Deserialize 该方法。

Again, both the type and the serialized payload are controlled by the attacker. Let’s check this deserialization method.
同样，类型和序列化的有效负载都由攻击者控制。让我们检查一下这个反序列化方法。

At [1], the code checks if the provided type is cached.
在 ， [1] 代码检查是否缓存了提供的类型。

If not, the type is retrieved from a string at [2].
如果不是，则从 的 [2] 字符串中检索该类型。

At [3], the static DeserializeFromStrippedXml is called.
在 ， [3] 调用静态 DeserializeFromStrippedXml 。

As you can see, the static DeserializeFromStrippedXml method retrieves a serializer object by calling SerializationHelper.serializerCache.GetSerializer(type). Then, it calls the (non-static) DeserializeFromStrippedXml(string) method on the retrieved serializer object.
如您所见，静态 DeserializeFromStrippedXml 方法通过调用 SerializationHelper.serializerCache.GetSerializer(type) 来检索序列化程序对象。然后，它在检索到的序列化程序对象上调用（非静态） DeserializeFromStrippedXml(string) 方法。

Let’s see how the serializer is retrieved.
让我们看看如何检索序列化程序。

At [1], the code tries to retrieve the serializer from a cache. In case of a cache miss, it retrieves the serializer by calling GetSerializerInternal ([2]), so our investigation continues with GetSerializerInternal.
在 ， [1] 代码尝试从缓存中检索序列化程序。如果缓存未命中，它通过调用 GetSerializerInternal （ [2] ） 来检索序列化程序，因此我们的调查继续使用 GetSerializerInternal 。

At [3], an XmlTypeMapping is retrieved on the basis of the attacker-controlled type. It does not implement any security measures. It is only used to retrieve some basic information about the given type.
在 时 [3] ，将根据攻击者控制的类型检索 。 XmlTypeMapping 它不实施任何安全措施。它仅用于检索有关给定类型的一些基本信息。

At [4], an XmlStrippedSerializer object is initialized. Four arguments are supplied to the constructor:
在 处 [4] 初始化对象 XmlStrippedSerializer 。向构造函数提供了四个参数：
• A new XmlSerializer instance, where the type of the serializer is controlled by the attacker(!).
• 一个新 XmlSerializer 实例，其中序列化程序的类型由攻击者控制（！
• The XsdElementName of the target type, obtained from the XmlTypeMapping.
• 目标类型的 ， XsdElementName 从 . XmlTypeMapping
• The Namespace of the type, also obtained from the XmlTypeMapping.
Namespace • 的类型，也从 . XmlTypeMapping
• The type itself. • 类型本身。

So far, we have two crucial facts:
到目前为止，我们有两个关键事实：
• We are switching deserializers. The overall SWIS verb payload and arguments are deserialized with a DataContractSerializer. However, our PropertyBag object will eventually be deserialized with an XmlSerializer.
• 我们正在切换解串器。整个 SWIS 动词有效负载和参数使用 . DataContractSerializer 但是，我们的 PropertyBag 对象最终将使用 XmlSerializer .
• We fully control the type provided to the XmlSerializer constructor, which is a key condition for exploitation.
• 我们完全控制提供给 XmlSerializer 构造函数的类型，这是开发的关键条件。

It seems that we have it, another RCE through type control in deserialization. As XmlSerializer can be abused through the ObjectDataProvider, we can set the target deserialization type to the following:
似乎我们有它，另一个通过反序列化中的类型控制的 RCE。由于可以通过 ObjectDataProvider 滥用，我们可以 XmlSerializer 将目标反序列化类型设置为以下内容：

However, let’s analyze the XmlStrippedSerializer.DeserializeFromStrippedXml(String) before celebrating.
但是，让我们在庆祝 XmlStrippedSerializer.DeserializeFromStrippedXml(String) 之前分析一下。

Something unusual is happening here. At [1], a new XML string is being created. It has the following structure:
这里正在发生一些不寻常的事情。在 处， [1] 正在创建新的 XML 字符串。它具有以下结构：

         <XsdElementName xmlns=’Namespace’>ATTACKER-XML</XsdElementName>

To sum up: 总结一下：
• The attacker’s XML gets wrapped with a tag derived from the delivered type (see GetSerializerInternal method).
• 攻击者的 XML 被从传送类型派生的标记包装起来（请参阅 GetSerializerInternal 方法）。
• Moreover, the retrieved Namespace is inserted into the xmlns attribute.
• 此外，检索到的将插入到 Namespace 属性中 xmlns 。

The attacker controls a major fragment of the final XML and controls the type. However, due to the custom XML wrapping, the ysoserial.net gadget will not work out of the box. The generated gadget looks like this:
攻击者控制最终 XML 的主要片段并控制类型。但是，由于自定义 XML 包装，该 ysoserial.net 小工具将无法开箱即用。生成的小工具如下所示：

The first tag is equal to ExpandedWrapperOfLosFormatterObjectDataProvider. This tag will be automatically generated by the DeserializeFromStrippedXml method, thus we need to remove it from the generated payload! When we do so, the following XML will be passed to the XmlSerializer.Deserialize method:
第一个标记等于 ExpandedWrapperOfLosFormatterObjectDataProvider 。这个标签将由 DeserializeFromStrippedXml 该方法自动生成，因此我们需要从生成的有效负载中删除它！当我们这样做时，以下 XML 将被传递给该方法 XmlSerializer.Deserialize ：

We still have a major issue here. Can you spot it?
我们这里仍然有一个主要问题。你能发现它吗？

When you compare both the original ysoserial.net gadget and our current gadget, one big difference can be spotted:
当您比较原始 ysoserial.net 小工具和我们当前的小工具时，可以发现一个很大的区别：
• The original gadget defines two namespaces in the root tag: xsi and xsd.
• 原始小工具在根标记中定义了两个命名空间： xsi 和 xsd 。
• The current gadget contains an empty xmlns attribute only.
• 当前小工具仅包含一个空 xmlns 属性。

The ObjectInstance tag relies on the xsi namespace. Consequently, deserialization will fail.
标记 ObjectInstance 依赖于 xsi 命名空间。因此，反序列化将失败。

Luckily, the namespace does not have to be defined in the root tag specifically. Accordingly, we can fix our gadget by defining both namespaces in the ProjectedProperty0 tag. The final gadget is as follows:
幸运的是，命名空间不必专门在根标记中定义。因此，我们可以通过在 ProjectedProperty0 标签中定义两个命名空间来修复我们的小工具。最后一个小工具如下：

In this way, we get a third RCE, where we fully control the target deserialization type!
通过这种方式，我们得到了第三个 RCE，在那里我们完全控制目标反序列化类型！

Here is a fragment of the API request, where the malicious SWIS verb argument is defined:
下面是 API 请求的一个片段，其中定义了恶意 SWIS 动词参数：

CVE-2022-36964

Technically, this issue is identical to CVE-2022-36958. However, it exists in a different class that shares the same implementation of the ReadXml method. In this case, the vulnerable class is SolarWinds.InformationService.Contract2.PropertyBag.
从技术上讲，此问题与 CVE-2022-36958 相同。但是，它存在于共享 ReadXml 相同方法实现的不同类中。在这种情况下，易受攻击的类是 SolarWinds.InformationService.Contract2.PropertyBag 。

An argument of this type is accepted by the TestAlertingAction SWIS verb, thus this issue is exploitable through the API.
TestAlertingAction SWIS 动词接受这种类型的参数，因此此问题可通过 API 利用。

This class may appear familiar to some of you. I already abused that same class with JSON.NET deserialization in CVE-2021-31474. Almost one and a half years later, I realized that this class can be abused in a totally different way as well.
对于你们中的某些人来说，这门课可能看起来很熟悉。我已经在 CVE-2021-31474 中滥用了同一个类 JSON.NET 反序列化。差不多一年半后，我意识到这个班级也可以以完全不同的方式被滥用。

Summary 总结

In this blog post, I have shown you four different deserialization vulnerabilities in SolarWinds where the attacker could control the type of the deserialized object. One of them was particularly interesting, because DataContractSerializer could be used to ultimately reach XmlSerializer. During my Hexacon 2023 talk, I will show you some of the patches applied to the described issues and I will show you how I have bypassed them by using custom deserialization gadgets.
在这篇博文中，我向您展示了 SolarWinds 中的四个不同的反序列化漏洞，攻击者可以在这些漏洞中控制反序列化对象的类型。其中一个特别有趣，因为 DataContractSerializer 可以用来最终达到 XmlSerializer .在我的 Hexacon 2023 演讲中，我将向您展示一些应用于所描述问题的补丁，并将向您展示我如何使用自定义反序列化小工具绕过它们。