Apache Struts, RCE and Managing App Risk

Apache Struts, RCE and Managing App Risk

Technology Problems vs. Business Problems vs. Business Risks

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)

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:

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 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.