In a previous blog post, I talked about the Struts CVE (CVE-2017-5638) that’s affecting much of the Java Web App world these days. A security engineer at IMMUNIO provided his technical perspective as well.

My argument was that we see this type of event all the time. Code is written, and vulnerabilities exist in it undetected for years. Then we have to rush to fix it immediately. Meanwhile, we have no idea if any damage has occurred. As is quite common in the security vendor world, vendors rush to tell you that they’ve provided a new ‘rule’ to prevent the exploitation. Unfortunately, as is the case with any blacklisting or pattern matching based technology, very rarely do you get it right the first, second, or third time.

Within a day or two, bypasses were disclosed to various vendors, some added new rules for those bypasses, some still haven’t. We actually figured out some more since then.

Well, now there’s another way to exploit the same vulnerability, that is not detectable by any rule or any WAF (to the best of our knowledge).

This time, however, it won’t be so easy for WAF’s to effectively secure against these exploits. The technical reason lies in the fact that the malicious payloads will reside in the body part of large multipart requests. If you have enough sites behind a WAF, enabling inspection on these will result in quite a bit of strain on the WAF (which translates to fail open or delay, depending on the vendor). Furthermore, there will be False Positives.

This is yet another example of why WAF’s are not effective Application layer protection technologies. Next-generation approaches, such as security instrumentation, and RASP, in particular, are much more adept at handling these types of issues. There is no pattern matching involved. It does deal with the variant cases as well. Our approach profiles your application. It understands its execution. It knows what commands should and should be allowed to execute. And it can show you all of that.