Top 5 Tomcat Vulnerabilities

June 12, 2019 By Sylvia Fronczak

3 minute read time

Those who spend time monitoring and patching open source projects will be quite aware that Tomcat has some vulnerabilities.

Today, at the Nexus User Conference, we’ll be running down the top five of those vulnerabilities.

Constraint Bypass

Let’s first discuss constraint bypass.

With this vulnerability, a small window exists where a URL is available that shouldn’t be. For the example in the demo of this presentation, there was a simple account service, accessible through the “/account” url. There’s also “/account/withdrawal” that will remove money from the account in the demo.

Even though we use Servlet Security constraints on the /account url, if the /account/withdrawal is invoked first, it bypasses the security constraints.

To demonstrate, Jonathan Gallimore of Tomitribe showed a simple account screen where a user could withdrawal money from an account.

unnamed (9)

Jonathan also executed some curl against the /account/withdrawal endpoint, and instead of getting the expected 401 error, he received HTML. That indicates that the security was bypassed and we’re actually getting to the screen that should have been blocked by the Servlet Security code.

This was fixed in patches, so you should check your versions of Tomcat to make sure you’re protected from this particular vulnerability.

Denial of Service

With the denial of service vulnerability, you can create an infinite loop with the HTTP/2 protocol.

For example, Jonathan executed a curl GET request, adding a large header field with any text whatsoever. When he submitted the request, the request seemed to keep going. It never sent a response. In the console, you can see Tomcat stuck in an infinite loop that could bring your system down.

unnamed (10)

This can happen whenever you have HTTP/2 enabled with Tomcat 8.5.x and 9.x, though was fixed in 8.5.8 and 9.0.0.M13.

Remote Code Execution (RCE)

These are particularly nasty, as they allow remote execution of code on your machine. We’ll cover a few of them.

For the first one (CVE-2019-0232), the vulnerability affects windows where parameters are parsed incorrectly. The attacker can inject commands by crafting a particular URL format. This requires that the CGI servlet be enabled to cause the issue.

When calling a simple hello.bat, we can show how adding additional parameters can inject commands. In the demo, we actually stop the Tomcat server by constructing the correct URL.

This vulnerability was just announced recently. And it’s still not patched in Tomcat 6.x or 8.0.x, though those have hit end of life. However, 7.0.94, 8.5.40, and 9.0.19 are covered.

Lastly, SONATYPE-2017-0413 isn’t an issue within Tomcat itself. It actually affects JSF implementations. It was flagged up by NexusIQ and the exploit is publicly available.

The vulnerability relies on modifying view state. For the demo, we have a simple app that tracks the name of a person to say hello to. It’s your traditional hello world app. This exploit works by running the JexBoss exploit tool against the app. From the attacking server, we’re able to create a shell into the server running the hello world app. And the attacker now has access to everything.

This is the worst case scenario, where the attacker can then run code as the user account that runs the server.

Takeaways

Check your server and apps for these vulnerabilities. Verify your components have patched versions that fix these identified vulnerabilities. And lean on your support vendor if you find you’re vulnerable to identify mitigations.

 

Tags: vulnerability, Everything Open Source, Tomcat, apache tomcat, How-tos

Written by Sylvia Fronczak

Sylvia Fronczak is a software developer that has worked in various industries with various software methodologies. She’s currently focused on design practices that the whole team can own, understand, and evolve over time.