Canada Revenue Agency Vulnerability: 2 + 2 = Apache Struts?

Last Friday (10 March 2017), the Canada Revenue Agency (Canada's tax collectors) took the unusual step of shutting down many of their online services due to an unspecified security vulnerability. There was no information from the CRA on what that vulnerability was other than a suggestion that it wasn't unique to them.

So let's see if we can put 2 + 2 together to make 5…

On 7 March a Remote Code Execution vulnerability was reported (CVE-2017-5638) in the Apache Struts framework. Could these two events be connected?

It's very easy to find out what technologies companies and government departments use nowadays. It's never been particularly difficult, but social media make it really easy. LMGTFY: (let me Google that for you).

Looks very plausible. People working at Canada Revenue Agency frequently report using Apache Struts in their resumes. (And note that I could do a similar search to identify companies using Apache Struts which are therefore likely to have this vulnerability).

So how bad is it?

If we read the description of the vulnerability we learn that:

1. It was detected in the wild, rather than being detected by a security researcher.
2. Proof of Concept (PoC) code was widely available within a day of the problem being detected.
3. The vulnerability is in the Content-Type field of an HTTP POST request. This is important, because it's not information that is usually logged by a proxy server. However, the vulnerability is in error handling, so it should trigger error messages in the Apache Struts logs. Since HTTP POST requests are generally used for login to a website, or for forms submission, it's quite likely that any vulnerability could be exploited without any prior user authentication.
4. The vulnerability allows arbitrary code execution. That means that (unless Apache Struts is being run in a very controlled environment) it may be possible to switch off firewalls, download and run programs, etc. The Imperva report (cited above) suggests that even before first being detected, there were a sizable number of attacks going on in the wild.
5. The Apache Struts environment is presumably being used to talk to other computers and databases to resolve user requests. An attacker has at least as good an access to these systems as the Apache Struts environment. It's possible some of these interactions are logged.

Damage Mitigation

Stopping future attacks should be relatively easy in a cloud environment: deploy new virtual machines with a patched version of Apache Struts.

However, assessing what may have been accessed by attackers, whether they successfully attacked other systems, stole credentials, downloaded tax information, or deployed malicious software somewhere on the network will take far longer.

So what would you do?

Hopefully you weren't using Apache Struts and weren't hit by this vulnerability. But your public facing systems are undoubtedly using other software packages which may one day be vulnerable.

If you discovered that your public facing server had been compromised with a Remote Code Execution exploit, how far could the attackers get? And how would you know what credentials and other systems had been compromised?

If you haven't yet run this scenario as a table-top exercise, perhaps now would be a good time.