Vulnerabilities in the .Net Platform

Do you need to know about vulnerabilities in .NET? Perhaps you’ll take a fresh look at the code, or maybe your life. What if you want to change your qualifications and go into research of new types of attacks? Who knows. But if you asked about the vulnerability, then you are probably interested in how to develop reliable and secure applications.

So, let’s talk about the vulnerabilities that are found in the .NET Framework.

DoS (Denial of service) – attack on ASP .NET MVC application. This attack can seriously disrupt your site, for example, slow it down, and in some cases completely block it.

How does it work

The server makes requests that it cannot process, as a result of which the server does not have time to process the requests of ordinary visitors and looks like they are not working for them.

How to fix

  • Simplify the regular expression
  • Replace the regular expression with the custom algorithm
  • Set the timeout for processing any regular expression using the constructor, or for all regular expressions, using AppDomain.

These are excellent primitive measures when you do not really want to understand what regular expressions you have and how complex they are. Moreover, such solutions do not cost anything to you, but they give a result.

Attack of privilege escalation (EoP) on SQL-server. In this case, this is a luring attack, which can compromise all the data on the server.

Attack of privilege escalation (EoP) in ASP .NET Core 1.0. This vulnerability was fixed as a business logic error, but later it turned out that it could lead to data disclosure and increased user privileges.

How does it work

The attacker “lures” the more privileged component to do something on his behalf. The easiest way to accomplish such an attack is to convince the target to run the attacker’s code in a more privileged security context.

How to fix

A single story, how to avoid these vulnerabilities, unfortunately, no. Only general recommendations can be given. For example:

  • Register request-service in the context of a singleton
  • Double-check any code that works with security sensitive, with sandboxing and with data modification
  • Runtime check is another good way to protect against these things
  • Minimal privileges everywhere

Disclosure XXE is a vulnerability to XML injection, which leads to reading of arbitrary files on the attacked server.

How does it work

To understand the essence of XXE, let’s first deal with the XML format. The XML format can contain a description of its structure in the DOCTYPE tag. The same tag may contain some Entity. In simple terms, it is an analog of a constant, which can be used later in the XML code, and, when parsing this code, it will automatically be expanded. This circumstance can lead to DoS attack, if you add Entity, which recursively open, and do not specify timeout. The parser will begin to open them indefinitely.

The classic XXE attack is as follows. The attacker sends a compromised XML file to the server where the file is parsed, after which a response is returned from the server. The answer can be of absolutely any type, although it is possible that an attacker will get exactly the local file that he needs.

How to fix

  • Deny the use of DTD files and External Entity
  • Reset the resolver
  • Enter a limit on the size and setting of the timeout

One of the reasons for the appearance of vulnerabilities could be the deserialization of binary data. Data deserialization is the reverse process of serialization. That is, if during serialization we translate any data structure into a sequence of bits, then during deserialization we restore the initial state of this structure.

How can vulnerability arise in this process? Let’s say you have a class that implements a command that runs some kind of converter. You pass through the constructor parameters of this converter and they are validated in the constructor. In this case, you can use not everyone, but only your local designer.

What is the problem? And the problem is that when the data is deserialized, the constructor will not be started. That is, your data will be deserialized as it is, including private fields.

How to fix

  • Use custom serializer
  • Use the minimum privilege in the process of deserialization

About possible ways of deserialization you can learn more in the article of James Forshaw “Are you my Type? Breaking .NET Trough Serialization”.


To everyone’s regret, now there is no fully protected web application. Therefore, the problem of vulnerabilities remains relevant. Attackers are finding more and more ways to hack servers and do harm to companies or ordinary people. Therefore, to ensure the security of your application, you need to know how to fix and prevent vulnerabilities.

Leave a Reply

Your email address will not be published. Required fields are marked *