www-announce mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sally Khudairi ...@apache.org>
Subject Apache Struts Statement on Equifax Security Breach
Date Sat, 09 Sep 2017 15:30:35 GMT
[this announcement is available online at https://s.apache.org/8thB ]

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

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.

3. Any complex software contains flaws. Don't build your security policy
on the assumption that supporting software products are flawless,
especially in terms of security vulnerabilities.

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.

For the Apache Struts Project Management Committee,

René Gielen
Vice President, Apache Struts 

[2] https://cwiki.apache.org/confluence/display/WW/S2-052
[3] https://cwiki.apache.org/confluence/display/WW/Version+Notes+2.5.13
[4] https://cwiki.apache.org/confluence/display/WW/Version+Notes+2.3.34

= = =

NOTE: you are receiving this message because you are subscribed to the
announce@apache.org distribution list. To unsubscribe, send email from
the recipient account to announce-unsubscribe@apache.org with the word
"Unsubscribe" in the subject line. 

View raw message