From Contrast’s threat researchers: Proof that Contrast detects zero-days. The Contrast agent doesn’t require signatures or extensive framework knowledge; it identifies vulnerabilities by monitoring how untrusted data flows through a live application. 

While adding Echo router support, our Go agent surfaced an unvalidated redirect flaw that lined up with CVE-2022-40083. Despite having no awareness of the CVE, the bug, or the Echo framework, the bug surfaced. The agent simply traced untrusted data to a risky operation and raised the alarm. It found the issue the same way it would find a brand-new, undiscovered vulnerability.

In Echo v4.8.0 and earlier, an unvalidated redirect vulnerability existed in Echo Static handlers: https://github.com/labstack/echo/issues/2259. If you run Contrast with a vulnerable version of the Echo router, you will get a vulnerability report that looks like this:

_{Contrast platform showing detected vulnerability}

The Contrast agent made this detection independently. It has no knowledge of the CVE at the agent level. Instead, Contrast discovered this vulnerability from first principles. It tracks how untrusted data moves through the application (in this case a static file server handler) and notices that untrusted data is used to create a redirect target. The above report also shows that Contrast does not need a payload that looks like an attack in order to detect a vulnerability. The Contrast agent does not care about the contents of the payload: it only cares that the payload is untrusted because it came from the request. These two factors combined demonstrate that Contrast is capable of detecting a new zero-day vulnerability, before the attackers begin exploiting it.

Additionally, Contrast detected the flaw without any high-level understanding of the Echo routing framework. We demonstrated that Contrast could detect the CVE before we began work on officially supporting Echo.

Let’s dive into how Contrast is able to do this. For this blog post, we will be focusing solely on the Contrast Assess product.

Echo

To understand how Contrast is able to detect a vulnerability in Echo, first, we need to understand how Contrast can fully support Echo. As a router built off the standard library net/http router, we are already capable of tracking the request data as it gets processed by the Echo router, but we also need the ability to collect route information as well as a full suite of tests.

Route Coverage

Echo supports URL path params like the following:

_{Echo’s supported routing patterns}

Since this syntax is unique to Echo, we need to update our route discovery and route observation to detect these patterns. Without this update, each matching request URI would be reported as a separate route, rather than reporting the matched pattern.

_{Routes discovered}

_{Routes exercised}

Data Tracking

What about tracking data through the Echo API? We just talked about how we need to update the Contrast agent to detect URL path params for route coverage. Do we need to do any updates for tracking URL path parameters as well?

One of the core strengths of the Contrast agent is that the answer is no. The tracking code only cares about whether the string comes from the request URI. It does not know any Echo-specific code because it does not need to. We will examine the broader implications of this later, but for now, let’s explain more about tracking path param values with an example.

_{An XSS vulnerable router}

In this example, the “/param/:param” handler is vulnerable to a reflected XSS attack. This can be demonstrated by running localhost:8080/param/<script>alert(1)<%2fscript> in a browser. Since Contrast Assess is data-agnostic, we can also discover the vulnerability using an arbitrary payload.

How does Contrast detect the vulnerability? Let’s focus on the handler code up to but not including the c.HTML call. The value stored in variable p on line 13 will determine if Contrast is working properly. If Contrast knows this value is untrusted, then it has successfully navigated the c.Param call. This is what we see in the Contrast UI:

_{Contrast detects the string slicing happening inside the Echo router without any need to understand what a route parameter is.}

As you can see, we trace the untrusted data all the way from the request URI to the return value of the url.PathUnescape call. Contrast has no inherent knowledge of the Echo API. All it knows is how the user-controlled data from the request (in this case from the URI) moves through the application.

So what about the c.HTML call? How does Contrast know that an untrusted argument will cause a vulnerability?

_{Contrast notices the untrusted data was written to the HTTP response. The stack trace reveals this response write was initiated by echo.Context.HTML().}

The same thing happens in this part too. In a nutshell, the reflected XSS vulnerability happens when untrusted data is written to the response. All Contrast cares about is whether untrusted data is written to that underlying http.ResponseWriter.

Integration Testing

While Contrast’s API-agnostic behavior lets us have new router support almost fully done before we even start, we want to test this internally. We most often accomplish this through integration tests, where we instrument the code with our agent. How do we do this?

Well, to add Contrast to a normal app, you replace all instances of go with contrast-go. For example, go build ./myapp becomes contrast-go build ./myapp. The same works with go run and contrast-go run as well. If you want to hear more about the principles behind how Contrast works to instrument Go applications, you can watch this talk one of the Go Agent engineers gave at GopherCon.

But did you know you can also do this with go test? We do this internally to create integration tests.

_{This is similar to what our integration tests look like}

To run our integration tests, we run the above with contrast-go test instead of go test. Our internal utils package notwithstanding, this feature is available for our customers as well. (You will be able to view the results in the Contrast UI.)

For us to consider a routing package like Echo to be supported, we write integration tests for every API element that either: 1) retrieves data from the request, 2) propagates or encodes string/[]byte data, or 3) performs an operation that would be harmful if user-controlled (ex. file system operations, SQL queries, response writes, etc.).

Detecting a CVE

Here’s how Contrast independently detects a CVE. The first thing to note is that the Contrast agent does not know any known CVEs. (Contrast will check the packages it sees for known CVEs, but that is outside of the agent’s knowledge.) Instead, CVEs are detected by tracking data through the application.

As stated before, in Echo v4.8.0 and earlier, there was an unvalidated redirect vulnerability in Echo Static handlers: https://github.com/labstack/echo/issues/2259. The actual steps to exercise the vulnerability are a little convoluted, so let’s walk through the code. In Echo v4.8.0, e.Static(“/”, “.”) will eventually return the following handler:

_{Screenshot from github.com/labstack/echo/v4@v4.8.0 echo_fs_go1.16.go}

To execute the vulnerability, we need to control the contents of p on line 80. To get there, we need the returned file to be a directory. To accomplish this, we can send a request with the following URI: “//attacker-controlled-url.com%2f..”. Due to the .. path component on the end, the filename after cleanup is just ., which fulfills our requirement of the file being a directory. Then p is assigned to our attacker-controlled URL and is used as the redirect target!

Let’s look at what we see when we test the static method with Echo v4.8.0:

_{In reality, our Echo.Static tests are much more thorough}

And let’s see what this vulnerability looks like in the UI:

_{Vulnerability discovered regardless of the contents of the payload!}

Keep in mind that the agent does not know about the CVE, what the data it’s tracking looks like, or much if anything about the Echo router. Had this CVE remained undiscovered, we would have found it while writing our Echo support tests. This exercise demonstrates that Contrast is capable of detecting zero-day vulnerabilities.

This test was not about Echo. It was proof that Contrast can surface a dangerous flaw without signatures, attack payloads, or CVE awareness. The agent saw the vulnerability exactly the way it would see a zero-day: untrusted data flowing into a risky operation. That is the value of runtime analysis. Contrast does not wait for attackers or advisories. It finds the problem the moment it appears in code.