Apache Tomcat Bug Exploited in 30 Hours

I know to some of you I sound like a broken record. Sorry.

Today’s alert is a problem on two levels.

First, for those of you running Apache Tomcat webservers, it is time to patch. Proof of concept code is available and it doesn’t take much to get from there to you’ve been hacked. They have released patches for Tomcat 9, 10 and 11.

It appears that this attack is relatively easy to exploit and does not require any cooperation by the website operator.

So, if you are running Tomcat, time to fix it.

But here is the bigger concern.

We have a bug that is relatively easy to exploit and doesn’t require the victim to do anything for the attacker to exploit it. This, actually, this situation is not that rare.

How long does it take for hackers to start exploiting it?

In this case, that number was 30 hours. Think about that for a minute. Are you able to deploy patches within 30 hours of sample code to exploit the bug being released? Do you even know about the bug that quickly?

Also consider this. We didn’t say 30 hours after the vendor released a patch. We said 30 hours after sample exploit code was released. Sometimes that is after the patch has been released (that is called responsible disclosure).

Other times the hacker or researcher is upset for whatever reason and he just releases it. A prime example of this is when the person contacts the vendor and the vendor (a) ignores them or (b) claims it is not really a bug or (c) says the problem isn’t that bad so we may fix it some time in the future. Or not.

Sometimes researchers give the vendor a window to release a patch (typically around 90 days) and if the vendor doesn’t fix it, the researcher or hacker or whomever releases the bug information and sample code that proves that there is a bug. This happens to big players like Microsoft, Apple and Google on a regular basis.

Bottom line is you need to prioritize patching. It also means that you have to do that not just for your operating systems but also for the applications that are running on your workstations and servers. That also means that you have to stay alert to the news so you know if a bug just became public. You can then assess the risk.

For all the warts that cloud software has, this is one place where it provides a big lift because there is only on place the software is running – in the vendor’s cloud(s) – and the vendor is usually quite motivated to reduce their liability by pushing the patch quickly.

If you are not comfortable with how quickly you patch every system company wide – called your patching cadence – please contact us.

Credit: The Hacker News