Protecting our customers Our security research team has built and deployed a rule to protect…
Patching servers is a notoriously difficult problem to address. Software gets out-of-date and new vulnerabilities are released–before you know it, you have attackers unleashing new payloads against your site. The vuln-to-exploit cycle now happens in hours, which means you need an active defense against attacks to provide time to update the systems affected. This is exactly what Signal Sciences provides through our virtual patching feature which stops vulnerabilities in their tracks, giving your team time to respond.
Struts CVE Round 2
Signal Sciences recently became aware of yet another Struts vulnerability from this blog post. Based on our awareness of the impact from 2017’s Apache Struts vulnerability that was made infamous due to its correlation with the Equifax incident, we released a virtual patch today. We strive to look out for our customers’ interests and stay on top of new CVEs.
To add this protection in Signal Sciences, go to Configure > Templated Rules and find this virtual patch and choose configure.
You will then be presented with the option to enable the rule and set up blocking or logging for the rule.
That’s it!
Signal Sciences Virtual Patching via Power Rules
Signal Sciences has been fortunate enough to work with some significant brands in multiple verticals from finance and ecommerce to entertainment and games. We work with some of the largest web-scale companies on the Internet. Given this unique opportunity, our customers have also begun to look to us to not only build an amazing product, but to also be a leader when it comes to researching and developing coverage for things like this that do not fit into the neat box of the OWASP Top 10.
Signal Sciences Engineering Timeline
It’s one thing to be able to identify these new issues, but another great benefit of not only preaching DevOps is that we practice this in-house. To help understand what this means, let’s look at the timeline for us to release a virtual patch.
– 08/22 – 09:30 PST: the blog post on the CVE was discovered. We run out automated CVE identifier and realize it’s not seeing anything so go about our day. No proof of concept (PoC) was released.
– 08/22 – 10:40 PST: we developed communication to send to customers on the issue.
– 08/22 – 10:50 PST: we pulled the list of customers using the virtual patch for the Struts 2017 exploit and began contacting them with a workaround to tighten defenses, while we build a virtual patch.
– 08/22 – ~11:30 PST: a PoC of the exploit was uploaded to github, but we weren’t aware of it.
– 08/22 – 23:24 PST: one of our engineers noticed this tweet to the PoC of the exploit.
– 08/23 – 00:20 PST: a virtual patch was developed and an internal pull request was submitted.
– 08/23 – 13:30 PST: after a couple iterations and tuning, we released the virtual patch to our customers.
– 08/23 – 14:42 PST: several customers have already turned this on.
Lessons Learned
We were generally happy with how fast we went from CVE announcement to virtual patch ready for customers, however we are looking for ways to improve and we have already started reviewing how we can better respond to these types of issues even faster. Our goal is to have these types of patches available within hours to customers.
Demand More from Your WAF
If you need appsec defense that outpaces attackers and our approach sounds interesting to you then we would like to ask you to give us a try. We can be up-and-running in your environment in minutes, and you get immediate value in blocking and visibility, saving you time from testing and configuring other types of WAFs on the market. We will show you that vetting a web application firewall solution doesn’t have to take weeks or months.
Related Posts
