The .NET ecosystem is affected by a similar flaw that has wreaked havoc among Java apps and developers in 2016.

The flaw is in how .NET coding libraries handle deserialization operations, leading to situations where attackers can execute code on servers or computers handling deserialized data.

Serialization is the process of converting an object into a stream of bytes in order to store the object or transmit it to memory, a database, or a file. Its main purpose is to save the state of an object in order to be able to recreate it when needed. The reverse process is called deserialization.

The Java Apocalypse of 2015 and 2016

Attacks via deserialization operations have been known since 2011, but they became everyone's problem in early 2015 when two researchers — Chris Frohoff and Gabriel Lawrence — found a deserialization flaw in the Apache Commons Collection, a very popular Java application.

Researchers from Foxglove Security expanded on the initial work in late 2015, showing how an attacker could use a deserialization flaw in Java applications where developers have incorrectly used the Apache Commons Collection library to handle deserialization operations.

Their experiments showed that an attacker could upload malicious data inside popular Java apps such as WebLogic, WebSphere, JBoss, Jenkins, and OpenNMS. This data would be serialized and stored in a database or in memory, but when the app would deserialize it to use the content of the serialized data, it would also execute additional malicious code on affected systems.

The flaw rocked the Java ecosystem in 2016, as it also affected 70 other Java libraries, and was even used to compromise PayPal's servers.

Organizations such as Apache, Oracle, Cisco, Red Hat, Jenkins, VMWare, IBM, Intel, Adobe, HP, and SolarWinds , all issued security patches to fix their products.

The Java deserialization flaw was so dangerous that Google engineers banded together in their free time to repair open-source Java libraries and limit the flaw's reach, patching over 2,600 projects.

Internally at Google, the flaw was referenced to as Mad Gadget, but the world referred to it as the Java Apocalypse.

Deserialization woes also affect .NET apps

Now, new research from two HPE software security researchers — Alvaro Muñoz and Oleksandr Mirosh — reveal that a similar deserialization flaw affects the .NET ecosystem.

Just like with Java apps, the flaw is in how .NET libraries handle serialized data during deserialization, allowing an attacker to sneak in code that gets executed on a target's machine.

Just like in the Java world, the flaw is not always present. Some .NET libraries are not affected, and applications that use affected libraries are safe just because programmers treat serialized data as insecure and don't allow it access to certain functions and methods.

In their research paper, Muñoz and Mirosh focused their research on analyzing deserialization flaws in .NET and Java libraries that work with JSON data.

On page 5, researchers included reviews for all the .NET and Java apps they analyzed, pointing out which ones are safe and how developers should use them to avoid deserialization attacks when working with JSON data.

.NET deserialization flaw found in popular .NET projects

To show that the flaw they discovered can affect real-world apps, and is not just a theoretical threat, researchers identified: CVE-2017-9424 — a JSON deserialization flaw in Breeze, a .NET data management backend framework; and CVE-2017-9785 — a JSON deserialization flaw in NancyFX, a lightweight .NET web framework based on Ruby's Sinatra.

Besides JSON deserialization, the flaw is present in other libraries that handle deserialization of XML data objects as well. Researchers also identified CVE-2017-9822 — an XML deserialization flaw in DotNetNuke, today's most used .NET CMS.

As mentioned above, these flaws are a combination of vulnerabilities in .NET libraries but also bad coding practices on behalf of developers, who fail to recognize that serialized data is not necessarily secure by default.

Addressing the flaw would require security improvements to many .NET libraries, but also some conscious effort on the part of regular programmers.

"Serializers are security sensitive APIs and should not be used with untrusted data. This is not a problem specific to Java serialization, a specifc .NET formatter or any specific formats such as JSON, XML or Binary," researchers say. "All serializers need to reconstruct objects and will normally invoke methods that attackers will try to abuse to initiate gadget chains leading to arbitrary code execution."

The research team presented their findings at this year's Black Hat and DEF CON security conferences, held in early August in Las Vegas, USA.