It’s been a while since I have written a blog post, please accept my sincerest apologies. This is because a lot of fun stuff that I’ve recently done is going to be presented during conferences.
Please treat this post as a small introduction to my upcoming Hexacon 2023 talk titled “Exploiting Hardened .NET Deserialization: New Exploitation Ideas and Abuse of Insecure Serialization”. The entire talk and research was inspired by two small research projects, one of which focused on issues in SolarWinds deserialization.
In this blog post, I would like to present four old vulnerabilities that were fixed within the last year:
A small part of the Hexacon talk will show how I have bypassed patches to some of these vulnerabilities. Right now, we will focus on the original issues.
This vulnerability was already mentioned in this blog post. Let me reintroduce it to you in more detail.
Several SolarWinds services communicate with each other through a RabbitMQ instance, which is accessible through port 5671/TCP. Credentials are required to access it. However:
— High-privileged users were able to extract those credentials through SolarWinds Orion Platform.
— I later found CVE-2023-33225, which allowed low-privileged users to extract those credentials.
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
Now, let’s verify how SolarWinds handles those messages! We can start with the
, the code retrieves the properties of the AMQP message. Those properties are controlled by the attacker who sends the message.
, it creates an execution context, containing both the AMQP message properties and the message body.
, it executes a task to consume the message.
This leads us to the
EasyNetQ.DefaultMessageSerializationStrategy.DeserializeMessage is called. It accepts the message properties and the message body as input. The interesting stuff happens here.
, 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!
, it calls
BytesToMessage, which accepts both the attacker-controlled type and the message body as input.
, the message body is decoded as a UTF-8 string. It is expected to contain JSON-formatted data.
, the deserialization is performed. We control both the target type and the serialized payload.
, it can be seen that the
TypeNameHandling deserialization setting is set to
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.
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.
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.
I quickly realized that SolarWinds sends messages of one type only:
Let’s take a moment to analyze this type:
, we can see two public members of type
SolarWinds.MessageBus.Models.PropertyBag. The fun begins here.
, you can see the definition of the class in question,
, a custom converter is registered for this class -
SolarWinds.MessageBus.Models. PropertyBagJsonConverter. It implements the
ReadJson method, which will be called during deserialization.
, the code iterates over the JSON properties.
, a JSON value is retrieved and casted to the
Type is retrieved on the basis of the value stored in the
, the object stored in the
v key is deserialized, where we control the target deserialization type (again)!
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
Let’s have a look at a fragment of a legitimate message:
We can take any property, for instance:
IndicationId. Then, we need to:
• Set the value of the
t key to the name of a malicious type.
• Put a malicious serialized payload in the value of the
As the JSON deserialization settings are set to
TypeNameHandling.Auto, it is enough to deliver something like this:
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.
SolarWinds defines some inner methods/operations called “SWIS verbs”. Those verbs can be either:
a) Invoked directly through the API.
b) Invoked indirectly through the Orion Platform Web UI (Orion Platform invokes verbs internally).
There are several things that we need to know about SWIS verbs:
• They are invoked using a payload within an XML structure.
• 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.
The handling of arguments is performed by the method
SolarWinds.InformationService.Verb. VerbExecutorContext.UnpackageParameters(XmlElement, Stream):
Type is retrieved for the given verb argument.
DataContractSerializer is initialized with the retrieved argument type.
, the argument is deserialized.
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?
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!
ReadXml method is defined. It will be called during deserialization.
, the code iterates over the provided items.
key element is retrieved. If present, the code continues.
, the value of the
type element is retrieved. One may safely assume where it leads.
value element is retrieved.
Deserialize method is called, and the data contained in both the
type tags are provided as input.
, the serialized payload and type name are passed to the
Again, both the type and the serialized payload are controlled by the attacker. Let’s check this deserialization method.
, the code checks if the provided type is cached.
If not, the type is retrieved from a string at
, the static
DeserializeFromStrippedXml is called.
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.
Let’s see how the serializer is retrieved.
, the code tries to retrieve the serializer from a cache. In case of a cache miss, it retrieves the serializer by calling
), so our investigation continues with
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.
XmlStrippedSerializer object is initialized. Four arguments are supplied to the constructor:
• A new
XmlSerializer instance, where the type of the serializer is controlled by the attacker(!).
XsdElementName of the target type, obtained from the
Namespace of the type, also obtained from the
• 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
• We fully control the type provided to the
XmlSerializer constructor, which is a key condition for exploitation.
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:
System.Data.Services.Internal.ExpandedWrapper`2[[System.Web.UI.LosFormatter, System.Web, Version=184.108.40.206, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a],[System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=220.127.116.11, Culture=neutral, PublicKeyToken=31bf3856ad364e35]], System.Data.Services, Version=18.104.22.168, Culture=neutral, PublicKeyToken=b77a5c561934e08
However, let’s analyze the
XmlStrippedSerializer.DeserializeFromStrippedXml(String) before celebrating.
Something unusual is happening here. At
, a new XML string is being created. It has the following structure:
To sum up:
• The attacker’s XML gets wrapped with a tag derived from the delivered type (see
• Moreover, the retrieved
Namespace is inserted into the
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:
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
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:
• The original gadget defines two namespaces in the root tag:
• The current gadget contains an empty
xmlns attribute only.
ObjectInstance tag relies on the
xsi namespace. Consequently, deserialization will fail.
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:
In this way, we get a third RCE, where we fully control the target deserialization type!
Here is a fragment of the API request, where the malicious SWIS verb argument is defined:
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
An argument of this type is accepted by the
TestAlertingAction SWIS verb, thus this issue is exploitable through the 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.
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. These patch bypasses have also been patched by SolarWinds, but the discussion will show how hunting deserialization bugs can lead to some fun discoveries.
I hope you liked this writeup. Until my next post, you can follow me @chudypb and follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.