What you need to know about Evil-Colon attacks

While novel attacks seem to emerge faster than TikTok trends, some warrant action before they’ve even had a chance to surface. This is the case for an attack we’ll refer to as Evil-Colon, which operates similarly to the now defunct Poison-NULL-Byte attacks. Though Poison-NULL-Byte attacks are now obsolete, they may have paved the path for new, similar attacks that could wreak havoc in your code if not dealt with properly.

Case in point: When performing a source code audit, I stumbled across a situation where Evil-Colon might be used to overcome the path sanitization process. In this instance, I discovered a uniquely interesting approach to attacking path manipulation vulnerabilities on applications deployed on Windows operating systems. Since this is a Windows-specific issue, the Evil-Colon attack method would likely work on applications deployed on any Windows servers.

How Evil-Colon works

Let’s dig a little deeper into how this could play out. Imagine there is an application deployed on a Windows system that takes user input, doesn’t filter for colon characters, and creates a file on a filesystem using that user input. In this scenario, it is possible to omit additional “sanitization” data that is placed at the end of the filename.

Here’s an example of the small Java application “WriteFile.jsp” source code:

The first part of this script will create new files in directory c:\testing\webdata\, but with sanitization in place the application will append “.txt” extension to all newly created files. What can be done here is to pass a colon (“:”) character at the end of the user input filename, and the “.txt” extension will be created as an Alternate Data Stream.

So, what will be created on the filesystem is a file with an arbitrary file extension.

If you pass an argument to the script, it would look like this:

http://localhost:8080/examples/WriteFile.jsp?
filename=evil.jsp:&data=TEST_31337

After this, file evil.jsp will be created in directory c:\testing\webdata, without the “.txt” extension, but with the “.jsp” extension because a colon character was used at the end of filename and it “strips off” the rest of the filename string into Alternate Data Stream.

Now, if there is a possibility to somehow manipulate previously created files later in the application workflow, that situation could lead to serious security issues.

If you look at the Java application source code, you’ll see that the user or malicious actor is able to modify existing files later in the code, which will effectively allow them to modify the “.jsp” file content into anything they want. It’s important to note that this second part of application behavior is not a vulnerability by itself, but a situation in which an Evil-Colon attack is fully exploitable.

Here’s how it looks:

If you then delve further and look into the evil.jsp content on the filesystem, you’ll see that it contains an “EVIL_CONTENT” string in it. This demonstration is just an example, but in the real world it could also be a JSP webshell script allowing malicious actors to achieve remote code execution (RCE) on a vulnerable application/server.

Implications of an Evil-Colon attack

What does all this mean? In a nutshell, it’s possible to exploit applications that are performing path-based operations with user input in various ways. Eventually, this could lead to much more serious attacks.

To paint a picture of a severe issue, take the case of user input. When user input is leveraged in constructing the file path, data within that file can later be altered by some additional code flows. A scenario like this could result in dangerous situations, which could include circumventing file uploads logic for specific file types, as well as various arbitrary data injections, among other problems.

How to prepare for Evil-Colon attacks

While it’s never possible to fully prevent a novel attack, developers can and should be prepared. First, remember that this class of vulnerabilities must be prioritized by case, per application. It’s not a one-size-fits-all approach to mitigation and remediation. However, there are measures that developers can take to help reduce the chances of such vulnerabilities.

In the case of Evil-Colon, the attacker would probably try all code flows, which could lead to path creation with user input that would generate arbitrary file names and could be later exploited for dangerous and malicious actions.

To defend against this, it’s critical to eliminate colon characters from any possible path operations using filters or simple string check/replace operations.

Next, determine the impact that a colon byte can have in various situations. It’s also pivotal to implement code audits in CI/CD processes, as well as on applications.

Security teams should proactively analyze and secure application source code as soon as possible in a shift-left way. Testing early and often will inevitably reduce the number of issues and hours spent trying to remediate later after something has gone wrong.