People used to argue about whether cyber security is a business problem or a technical problem. But this frames the issue poorly. “Problem” and “solution” imply that there is a definitive “solve.”
Cybercrime isn’t a technical problem that can be definitively solved. It is an inherent business risk of having something of value. And risk can’t be solved. Risk can only be managed.
The thing that differentiates cyber security from almost any other IT discipline (disaster recovery and business continuity in a post 9/11 world is another) is that with cyber security there is an adversary, and that adversary is motivated and incented to beat you. And if you have something of value to them, and if their reward outweighs their risk, they will continually evolve their tactics to get to it.
Business-driven digital transformation is driving exponential growth in the number of knowledge workers, websites, mobile apps, APIs, file servers, databases, etc. Each of these enable our businesses to collect, generate and/or use data to competitive advantage.
In security parlance, this is known as “surface area”; that which is exposed to an attacker. Each is either an end target of the cybercriminal, or a vector a cybercriminal uses to get to data. The more our businesses digitize, the more surface area there will be. Most of this surface area (the big exception is people themselves) is manifested as technology.
What’s This Got to Do with Apache Struts?
Apache Struts – and you’d have to work hard to find something that initially seems more disconnected from business risk as Apache Struts – illustrates this.
Apache Struts is a framework that extends the Java Servlet API for writing web/mobile/API-based applications. Digital transformation means more apps. More apps mean more use of frameworks like Struts. Which means more technical surface area exposed to attackers. This illustrates why “just reduce surface area” alone isn’t a strategy. Less surface area means less apps, which would mean less digital transformation itself. Given the perceived cost and revenue-side business benefits of digital transformation, this is not likely to happen.
Struts, and other similar frameworks, basically enable developers to write Java apps faster. Struts has been around, in one form or another, since 2000. The current framework – Apache Struts 2 – was initially released in 2007. Some estimate it is used by 65 percent of the Fortune 500.
Our research team – which is the same team that releases our WAF signatures/virtual patches for known vulnerabilities – collected the following stats on Struts:
- 75 published security vulnerabilities to date
- 83% of the vulnerabilities can be accessed via a remote attacker (i.e., via network)
- 75% of the vulnerabilities have working exploits
- 35% of the vulnerabilities may allow remote code execution (RCE) attacks
What is RCE?
RCE is nasty. IMHO, nastier than the more famous/infamous application vulnerability SQL injection. RCE, or remote code execution, allows an attacker to replace the parameters normally submitted as part of an API call with malicious code. Crafted carefully, this malicious code will then execute on the server. What this malicious code does is up to the attacker. Given that web apps frequently access back-end data stores, the potential for a RCE vulnerability to be exploited to breach data is apparent.
In 2017, there have been four different Apache Struts RCE vulnerabilities:
- CVE-2017-12611
- CVE-2017-9805
- CVE-2017-9791
- CVE-2017-5638
A close look at these shows several strategies for both reactively and proactively protecting application surface area. These certainly apply to Apache Struts, but also to most application frameworks.
Ways to Protect Application Surface Area
Patch Servers
The long-term fix for a vulnerability is to patch the servers. However, rolling out a patch across thousands of servers running hundreds of different apps owned by tens of different app teams is a not a trivial task. It can take months. Which is why most servers aren’t at current patch levels.
There is another bit of nastiness around patching as well. Sometimes patches aren’t backwards compatible. CVE-2017-9805 contains this: “It is possible that some REST actions stop working because of applied default restrictions on available classes.” In layman’s terms, this means applying the patch can break an existing app. This gets to the heart of why security is risk management: deciding to apply a patch prior to testing a patch with all apps runs the risk of breaking the apps (a.k.a., “potentially bringing down a website”).
Virtual Patching
A virtual patch uses a gateway (WAF, IDS, network firewall) that monitors traffic to identify and block an attack before it reaches a web server. Note, not all types of security gateways can apply a virtual patch to all types of vulnerabilities.
For Struts CVE-2017-9805, Imperva used the ThreatRadar Emergency Feed to distribute a signature and a corresponding virtual patch to SecureSphere Web Application Firewall users within 48 hours of the CVE’s disclosure. Emergency Feed is an opt-in service that leverages the communication channel between SecureSphere and the Imperva cloud to automatically distribute signatures and associated policies to mitigate highly critical vulnerabilities. This in effect automatically deploys a virtual patch for the vulnerability. A policy accomplishing the same thing was uploaded to Incapsula in the same timeframe, accomplishing the same thing for any Incapsula WAF customers.
Virtual patches for known CVEs are useful, but they are reactive. They are predicated upon knowing about a vulnerability in the first place. There is no (despite what some may say) general signature that spans all RCEs. The following are proactive defenses that can be used to protect against application vulnerabilities (RCE and otherwise).
Reputation-based Blocking
The vast majority of attacks launched against web app frameworks are automated. For example, for CVE-2017-9805, 40% of the attacks tracked by our research team originated from a single server in China. There is no reason for any traffic from any source like this to be reaching web servers. Imperva ThreatRadar IP Reputation can be set to fetch the latest IP Reputation feeds several times an hour. While this won’t catch every instance of an attack, it is an excellent filter that will proactively block a large portion of the automated attacks that target web apps.
Anti-automation
IP reputation isn’t the only mechanism for stopping automated attacks. Both SecureSphere and Incapsula provide functionality for identifying and blocking bots, regardless of the bot’s intent. Both use the same underlying technology to progressively profile a request to determine if the request is a human or a bot, and if a bot a good bot or a bad bot. Identifying and blocking requests from bad bots is another technique for scrubbing automated attacks targeting web apps.
Web Application Firewall Zero Day Protections
Reputation and anti-automation are extremely effective at filtering automated attacks from bad actors, but a careful attacker will be able to mask itself, especially when focusing upon a specific app or enterprise.
However, to exploit an RCE vulnerability in every case the attacker needs to send the malicious code – the “payload” – to the app in question. This payload will look wildly different from the typical content (e.g., an API call) submitted to an app. By learning what payloads are normally submitted via various form submissions and API calls, a solid WAF can prevent something like CVE-2017-9805 without knowing the vulnerability exists, and without ever seeing the payload before. The SecureSphere WAF uses machine learning to understand how an application normally behaves, and then uses it to identify and block anomalous requests.
Imperva zero day protections identified Apache Struts exploits almost immediately via a few different mechanisms:
- Upon learning of a vulnerability, attackers will frequently “spray and pray” an attack against numerous apps, and various forms/APIs within an app. Given automation, its more cost effective for them to just broadly launch an attack than it is first determine if an app/API is even vulnerable. We saw this for CVE-2017-9805 almost immediately, identifying it a “unknown content type for known URL”. In English, this translates to “not only is this not normal, it isn’t even content that this URL can process.” These kinds of alerts are an early “tell” that something is afoot, and our research team uses them as both an early indicator, as well as to inform our ThreatRadar threat intelligence feeds.
- If the app is susceptible to the vulnerability, a malicious payload will still not conform to normal application traffic. In the case of CVE-2017-9805, SecureSphere will identify an “unknown parameter” or “parameter type violation.”
- In most cases, the payload is much larger/longer than a normal request. In these cases, a “parameter length violation” will surface.
The Role of App Security Domain Expertise
What only someone who lives and breathes this stuff on a day-in/day-out basis knows is that any one of these violations by themselves isn’t necessarily an attack. Policies built on evaluating any of this in isolation can result in a high rate of false positives. False positives are the bane of IT security’s existence, because when looking at a screen full of alerts, you don’t know which ones are false and which aren’t. The net effect is ignoring them all.
SecureSphere WAF has patented capabilities that evaluate the relationships between multiple violations. This ability to analyze seemingly independent violations coming from different layers of the app stack (e.g., network protocol, parameter length, IP reputation, etc.) together greatly enhances accuracy. This not only minimizes false positives, but more importantly provides the confidence to actually block requests.
Manage Business Risk, Protect Against App Exploits
According to the 2017 Verizon Data Breach Investigation Report more successful breaches resulted from attacks on web apps than any other type of attack. This is telling since web app attacks are only number four in terms of incident frequency.
Attackers realize that web app frameworks like Struts (and all frameworks have security issues) are particularly attractive targets. Since they are used for public facing web apps, they can’t be hidden behind layers of network security. Their role is to accept inputs (web form parameters, API calls, etc.) and then process these inputs, which directly maps to particularly dangerous exploits like SQL injection and RCE. Since frameworks are widely adopted, attackers automate their attacks so they can cost effectively leverage their effort across thousands of websites.
Business will roll out more application functionality. The cost savings and revenue generating opportunities from digital transformation pretty much guarantee we’ll have more app surface area next year than this year. Learn more about how to use these capabilities to protect this ever growing surface area with Imperva SecureSphere Web Application Firewall (WAF) and Imperva Incapsula WAF.
Try Imperva for Free
Protect your business for 30 days on Imperva.
