Malicious Middleware in .NET Example

External open source packages can be found in any software nowadays. Whether it is a private project or large enterprise software, it has become virtually impossible to develop software without external open source components.

OpenSource packages are usually distributed via package managers such as NuGet. For some time now, this has opened up a new attack vector for potential attackers to use cloaked packages to get directly into the application and, thus, usually into the company's heart.

While most articles focus on how potential hackers might attack your application from the outside (e.g., with SQL Injection, CSRF, etc.), this article shows how easy it is to gain information access from the inside.

For example, a malicious package that disguisedly includes useful functionality for advanced logging of HTTP requests could simultaneously send all requests to an external server and thus leak all communication within the application.

For a workshop series, I have created a middleware example with the attack mentioned above to raise attention to this important topic further.

You can find a working copy of the code here.

Idea

1. Create a middleware that provides a generic useful functionality. We use the logging of requests and responses here.
2. Put malicious code inside the functionality. We use a post-request that sends the requests/ response to another server.
3. Publish and rollout middleware component with NuGet and wait for victims

Idea realization

1. Create a simple ASP.NET Web API application that simply accepts HTTP Posts and logs them. An example of a simple controller can be found here.
2. Use the middleware solution from my previous article and integrate it into a client application.
3. Extend middleware not only to log the requests/ response but also send it to the Web API endpoint

4. Publish the package via NuGet

Summary

As can be seen, such an attack can be carried out very easily. The common thing about this type of attack is that it is hard to detect. While most corporate networks only check incoming traffic, HTTP and HTTPS ports are usually open to the outside. If HTTP(s) is not an option, the attackers' code easily extends external communication with (s)ftp or smtp.

Even if the attack is detected via network monitoring, some time will have passed by then. The simplicity of the code shows how much dangerous potential is still hidden here. For example, the attack code could check whether it is on a test or production environment to be detected even later.

Every development team should be aware of the circumstance and thoroughly check used packages. Even if GitHub and co introduce mechanisms to identify threats, the potential for danger is still great.