The Apache Struts Project Management Committee (PMC) would like to comment on the Equifax security breach, its relation to the Apache Struts Web Framework and associated media coverage.

We are sorry to hear news that Equifax suffered from a security breach and information disclosure incident that was potentially carried out by exploiting a vulnerability in the Apache Struts Web Framework. At this point in time it is not clear which Struts vulnerability would have been utilized, if any. In an online article published on Quartz.com [1], the assumption was made that the breach could be related to CVE-2017-9805, which was publicly announced on 2017-09-04 [2] along with new Struts Framework software releases to patch this and other vulnerabilities [3][4]. However, the security breach was already detected in July [5], which means that the attackers either used an earlier announced vulnerability on an unpatched Equifax server or exploited a vulnerability not known at this point in time --a so-called Zero-Day-Exploit. If the breach was caused by exploiting CVE-2017-9805, it would have been a Zero-Day-Exploit by that time. The article also states that the CVE-2017-9805 vulnerability exists for nine years now.

We as the Apache Struts PMC want to make clear that the development team puts enormous efforts in securing and hardening the software we produce, and fixing problems whenever they come to our attention. In alignment with the Apache security policies, once we get notified of a possible security issue, we privately work with the reporting entity to reproduce and fix the problem and roll out a new release hardened against the found vulnerability. We then publicly announce the problem description and how to fix it. Even if exploit code is known to us, we try to hold back this information for several weeks to give Struts Framework users as much time as possible to patch their software products before exploits will pop up in the wild. However, since vulnerability detection and exploitation has become a professional business, it is and always will be likely that attacks will occur even before we fully disclose the attack vectors, by reverse engineering the code that fixes the vulnerability in question or by scanning for yet unknown vulnerabilities.

Regarding the assertion that especially CVE-2017-9805 is a nine year old security flaw, one has to understand that there is a huge difference between detecting a flaw after nine years and knowing about a flaw for several years. If the latter was the case, the team would have had a hard time to provide a good answer why they did not fix this earlier. But this was actually not the case here --we were notified just recently on how a certain piece of code can be misused, and we fixed this ASAP. What we saw here is common software engineering business --people write code for achieving a desired function, but may not be aware of undesired side-effects. Once this awareness is reached, we as well as hopefully all other library and framework maintainers put high efforts into removing the side-effects as soon as possible. It's probably fair to say that we met this goal pretty well in case of CVE-2017-9805.

Our general advice to businesses and individuals utilizing Apache Struts as well as any other open or closed source supporting library in their software products and services is as follows:

1. Understand which supporting frameworks and libraries are used in your software products and in which versions. Keep track of security announcements affecting this products and versions.

2. Establish a process to quickly roll out a security fix release of your software product once supporting frameworks or libraries needs to be updated for security reasons. Best is to think in terms of hours or a few days, not weeks or months. Most breaches we become aware of are caused by failure to update software components that are known to be vulnerable for months or even years.

4. Establish security layers. It is good software engineering practice to have individually secured layers behind a public-facing presentation layer such as the Apache Struts framework. A breach into the presentation layer should never empower access to significant or even all back-end information resources.

5. Establish monitoring for unusual access patterns to your public Web resources. Nowadays there are a lot of open source and commercial products available to detect such patterns and give alerts. We recommend such monitoring as good operations practice for business critical Web-based services.

Once followed, these recommendations help to prevent breaches such as unfortunately experienced by Equifax.

Thanks Apache PMC ... very helpful note! Amidst the plague-like prevalence of sycophancy and lucky-licker decision-makers among the 'fraternity', a few balanced heads with a semblance of common sense would do well to (indeed) adopt these recommendations as part of organizational best practices; but then sensationalism remains in vogue as does myopia [and did someone say, herd-mentality].
Até logo!

1A. Work with a reputable IPS provider to protect your assets and make sure that you keep the solution up to date. Some top-tier IPS solutions can provide updates to protect against vulnerabilities that coincide with the announcement of security flaws. This gives admins breathing room to evaluate the proposed patches to make sure they don't have any unexpected adverse effects on the environment while providing protection until the patches can be stabilized and rolled out. Até mais!

I used older versions of Apache for many years and know that many millions of others have also had the pleasure of depending on it for years of nearly faultless operation. The reciprocal is generally true for other well-known OS and HTTP software providers (you know who they are and you know the havoc they have created with their trash server software). Thank you Apache. My heart-felt condolences to you and Equifax.

Very Thankful to Apache PMC for the helpful note! I am sorry for my brother D.Bose's complex comment. He has been preparing for GMAT and randomly comments on different websites to practice his skills.
I hope sane comments will prevail and his comments will be ignored.

I agree with everything in this statement and I do trust the Struts team to be transparent with issues that are reported to them.
But.. it seems the issue was mitigated by updating a library which had a known vulnerability (CVE-2016-3674) published on 2016-05-17
[https://github.com/apache/struts/commit/8216ec1c4d2d1f558558b2464bbcdcd1efe86bc7]
I would like to see the Struts team do a little better at their own advice, especially...
"1. Understand which supporting frameworks and libraries are used in your software products and in which versions. Keep track of security announcements affecting this products and versions."
Hackers are looking for gaps.. which libraries use libraries with known vulnerabilities. And b/c of that this issue was probably known to some back in 2016.

Any insight whether Infosys was responsible for the poor design the allowed an Apache vulnerability to expose our financial data?
Equifax was proud of their outsourcing to Infosys of India:
https://youtu.be/3CfWDYU2LaM

So you hold yourselves up as providers of the latest gotta-have-it nonsense framework, yet you caution your users not to base their security policies upon any notion that your product is robust? First, please learn what the term "security policy" means. Second, please explain what value your product provide AT ALL. To me, it's the latest inane Johnny-come-lately, the latest reflection of the insistence that everyone must keep up with the Joneses and their sixty-eight cousins regarding every trivial featural extension to what-have-you. Losers like you chase every nitwit development idea, trying to "simplify" things by introducing umpteen more layers and pointless APIs, while frauds that litter both coastlines provide "monitoring" services that are beyond worthless. ABSOLUTELY PATHETIC . . .

I can't believe that a company that holds that much sensitive data just doesn't keep their systems up-to-date. They should be obligated to keep up with todays vulnerabilities and do updates accordingly. Exploits can happen, but if you dont act upon them its your own fault. In my opinion Apache Struts has no fault in this. Até a vista!

At this point Equifax is stating that the initial attack vector utilized was the Apache Struts CVE-2017-5638 vulnerability and not CVE-2017-9805 as suggested above. CVE-2017-5638 was released to the public around March 10, 2017, based on a quick seach. Exploit DB has code as early as March 07, 2017. It's basically a low skill level attack once its available in metasploit. So one question is when did the attack take place...early March? An upgrade path existed in early March. Shame on Experian if the attack took place mid-March or later.
The following link provides details.
https://www.equifaxsecurity2017.com/

At this point Equifax is stating that the initial attack vector utilized was the Apache Struts CVE-2017-5638 vulnerability and not CVE-2017-9805 as suggested above. CVE-2017-5638 was released to the public around March 10, 2017, based on a quick seach. Exploit DB has code as early as March 07, 2017. It's basically a low skill level attack once its available in metasploit. So one question is when did the attack take place...early March? An upgrade path existed in early March. Shame on Experian if the attack took place mid-March or later.
The following link provides details.
https://www.equifaxsecurity2017.com/